Gateway, Identity, Policy — the trust boundary
Lesson 3 of 6 in Amazon Bedrock AgentCore, Service by Service.
These three services form one story, so learn them together: Gateway is where tool calls happen, Identity is who is making them, and Policy is whether they are allowed. Put differently — Gateway is the choke point, and a choke point is the only place you can enforce anything.
Start with Gateway. Its job is unglamorous and enormously useful: turn things you already have into MCP tools. Point it at a Lambda function, an Amazon API Gateway REST API stage, an OpenAPI schema, a Smithy model, a remote MCP server, or a built-in connector, and it publishes MCP tools at a Gateway endpoint. For OpenAPI, Lambda and Smithy targets it translates between MCP and the backend format for you.
Vignette. An insurer has forty years of claims logic behind a REST API and no appetite for a rewrite. They register the OpenAPI spec as a Gateway target. Their agent — running on EKS, not AgentCore — connects to the Gateway as an MCP client and sees getClaim, updateReserve, listPayments as tools. Nobody wrote an MCP server. Nobody touched the claims system.
Aggregation mode — one endpoint, many MCP servers
If you already run five MCP servers, Gateway can front all of them. Its tools/list consolidates their catalogues, and during synchronization it discovers every capability each server advertises. Your agent holds one MCP connection and one set of credentials instead of five.
This is also a governance move. Five direct connections means five places to audit; one aggregating gateway means one place where Policy and logging apply.
Semantic tool search — why 400 tools does not blow up your context
Gateway generates embeddings from each tool’s name, description and parameter descriptions at synchronization time, and exposes a built-in MCP tool named x_amz_bedrock_agentcore_search. The agent searches for the tool it needs instead of receiving every definition up front — and because the index is built at sync time, discovery needs no real-time calls to backend MCP servers.
Two consequences worth internalising. First, tool descriptions are now retrieval documents, not just prompts: a vague description is now an undiscoverable tool. Second, an agent that must search for tools can search wrongly — evaluate tool selection, do not assume it.
Ingress and egress authentication
AWS positions Gateway as providing both ingress authentication (who may call the gateway) and egress authentication (credentials used to reach backend targets), fully managed. MCP targets additionally support three-legged OAuth (3LO) at the target level, and Gateway gained IAM authorization for agent-to-tool MCP calls at GA in October 2025.
The design point: the agent never holds the backend’s secret. It authenticates to the Gateway; the Gateway authenticates to the target. Compromise the agent’s context and you have not thereby exfiltrated the claims-system API key.
Built-in connectors, including Web Search
Beyond your own APIs, Gateway offers built-in connectors and integration-provider templates. Web Search — a managed grounding tool built on Amazon’s proprietary web index plus knowledge graph — went GA in July 2026 as a built-in MCP connector target, returning ranked results with snippets, source URLs, titles and publication dates. AWS describes it as keeping data residency inside the customer’s AWS environment with zero data egress.
For grounding work this removes a classic trifecta-adjacent dependency: no third-party search key living in your agent’s environment.
Identity answers a question most agent projects postpone until it hurts: who is the agent? Not "which human is using it" — the agent itself. AgentCore Identity is an identity and credential management service built for AI agents and automated workloads; agent identities are workload identities with specialized attributes, and each one gets a distinct ARN in a central directory.
Four components do the work: the agent identity directory (single source of truth), the agent authorizer (may this caller invoke this agent?), resource credential providers (how to obtain credentials for a downstream resource server such as Google or GitHub), and the resource token vault (holding users’ OAuth access tokens for delegated, on-behalf-of access).
Vignette. A recruiting agent must read a hiring manager’s Google Calendar. The manager consents once through a standard OAuth flow; the resulting tokens land in the token vault, encrypted with AWS KMS keys — customer-managed keys supported — and user-specific credentials are accessible only by the individual agent acting on behalf of that user. The agent never sees a long-lived shared credential, and revoking the manager’s consent revokes the agent’s reach.
| Pattern | How the caller authenticates | What you configure | When it is right |
|---|---|---|---|
IAM (SigV4) | AWS credentials, signed request | Runtime configured for IAM authorization. No extra Identity setup. | Callers already inside your AWS security boundary — a Lambda, a service, an internal job. |
OAuth / JWT via Identity | Bearer JWT from your IdP (Cognito, Okta, Microsoft Entra ID) | An authorizer at | End users in a web or mobile app — and any case where the agent must act on behalf of a named user downstream. |
Outbound (either pattern) | The agent presents a token the vault brokered | Resource credential providers plus the token vault; native integration with AWS Secrets Manager. Outbound tokens are cached keyed by (agent workload identity, user ID). | Third-party SaaS access. Access to AWS resources instead goes through the Runtime execution role. |
Policy is the layer that makes "the agent must not do X" true rather than merely requested. It provides real-time, deterministic control over agent tool use through Gateway: fine-grained attribute-based policies written in the open-source Cedar language — permit/forbid over principal, action, resource, with optional when conditions — evaluated against every agent action that passes through the Gateway. Policy went GA in March 2026, and AWS added natural-language authoring that compiles down to Cedar.
The placement is the whole point. A rule in the system prompt is a request a model can be argued out of by injected text; a Cedar forbid at the Gateway is an evaluation the model never participates in. And because every tool routes through the Gateway, new agent capabilities inherit the same enforcement automatically — you are not re-implementing authorization each time someone adds a tool.
Vignette. The insurer’s agent may quote coverage, but only up to a limit. The Cedar condition reads on tool-call input attributes — context.input.coverage_amount <= 1000000 — so a model that decides to quote fifty million produces a denied action and a log line, not a policy exposure.
Interactive sorting exercise: Each requirement below has exactly one right enforcement home in an AgentCore deployment. Sort them — the wrong home is usually "the prompt".
Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.