AgentCore course → Lesson 3

Lesson 3· ~11 min· Reading + retrieval practice

Gateway, Identity, and Policy

Building an agent is fast. Connecting it safely to systems that already exist is where projects stall for months. This is the layer where AgentCore earns its keep, and the one where a whiteboard sketch does more work than any slide.

Start from what you have

You've seen the failure mode already: an agent with a hard-coded API key that acts with the same permissions for every user, where the only thing stopping it doing something destructive is a sentence in the system prompt. You know that isn't security. This lesson is about what replaces it.

Draw this path, not the boxes

Architecture diagrams of AgentCore usually show a row of capability boxes, which teaches nothing. What a customer needs to see is a single tool call travelling through the system, and what each hop prevents.

A sequence diagram of one tool call. The user's request is authenticated inbound by Identity. The agent asks Gateway to invoke a tool. Gateway asks Policy whether the action may proceed. If Policy denies, the call is refused and never executed. If Policy allows, Gateway obtains a user-scoped credential from Identity, calls the target system, and returns the result to the agent.
Figure 1. One tool call, fully governed. Identity verifies the caller on the way in. The agent asks Gateway to invoke a tool, never the target directly. Gateway checks with Policy first: on deny, the call is refused and the target is never touched. On allow, Gateway fetches a credential from Identity scoped to that specific user, makes the real call, and hands back the result. Every hop is traced.

Open full-size diagram

The one idea

Gateway is a chokepoint, and that is the point. Because every tool call passes through it, it is the one place where governance can be enforced rather than requested. That is why Policy attaches there and not inside the agent.

Gateway: turning what exists into tools

Gateway converts APIs, Lambda functions, and existing services into MCP-compatible tools, and connects to MCP servers you already run, exposing all of them to an agent through Gateway endpoints.Gateway description and integration list, AgentCore Developer Guide overview. AWS names Salesforce, Zoom, Jira, and Slack among supported integrations. Retrieved 2026-08-05.

The part worth raising unprompted is tool discovery at scale. Once a customer has two hundred tools, the binding constraint stops being connectivity and becomes selection. An agent handed two hundred tool descriptions chooses badly. Gateway indexes tools and offers semantic search over them, which is why there is a separate meter for it: $0.02 per 100 tools indexed per month, and $0.025 per thousand search calls, against $0.005 per thousand ordinary invocations.Gateway meters, AgentCore pricing. Retrieved 2026-08-05.

Say this to a customer

"How many tools will this agent have in a year? If the answer is more than about thirty, connectivity stops being the hard part and choosing the right tool becomes it. That's a retrieval problem, and it's worth designing for now rather than discovering later."

Identity: two directions, and customers only think about one

This is the distinction that separates a 200-level answer from a 250-level one. Identity covers agent access and authentication management, compatible with existing identity providers, and AWS is explicit that it eliminates the need for user migration or rebuilding authentication flows. Cognito, Okta, Microsoft Entra ID, and Auth0 are all named.Identity description and IdP list, AgentCore Developer Guide overview. Retrieved 2026-08-05.

Inbound: who is calling the agent?

Authenticating the caller against the customer's existing IdP. This is the part customers expect and ask about.

Easy to reason about: it looks like authenticating any other application.

Outbound: what may the agent call, as whom?

The agent acting on behalf of a specific user against a third-party system, with a credential scoped to that user rather than a shared service key.

This is the hard half, the one that gets skipped, and the one that fails a security review.

Why outbound matters so much in practice: if an agent holds one shared credential, then every user of that agent has the union of all permissions that credential carries. A support agent that can read one customer's records can read everyone's. No prompt prevents this. Per-user outbound credentials are the only structural fix, and they are genuinely tedious to build yourself, which is the honest argument for this capability.

Commercially useful detail: Identity is billed at $0.010 per thousand token or API key requests for non-AWS resources, but is free when used through Runtime or Gateway. For most architectures that means it costs nothing.

Policy: governance the agent cannot talk its way past

Policy is an authorization capability that controls which actions an agent is permitted to take. It integrates with Gateway to intercept every tool call before execution, and rules are authored either in natural language or in Cedar, AWS's open-source Policy language. You define which tools an agent may reach, what actions it may perform, and under what conditions.Policy description and Cedar authoring, AgentCore Developer Guide overview. Retrieved 2026-08-05.

The property that matters is where it runs. AWS puts it precisely: Policy is evaluated at the Gateway perimeter, outside the agent's code, ensuring consistent enforcement regardless of the agent's autonomy. And every Policy evaluation is logged through Observability, for auditing as well as optimisation.Perimeter enforcement, autonomy-independence, and logging via Observability, from AgentCore now supports Bedrock Guardrails in Policy, 17 June 2026. Retrieved 2026-08-05.

Say that sentence to an engineer and watch it land. "Regardless of the agent's autonomy" is the whole argument: prompt-level instructions are advisory and degrade as an agent becomes more capable, whereas a check at the perimeter holds no matter what the model decides to attempt. It also needs no new infrastructure, since Policy works with existing Gateway deployments.

Guardrails within Policy: related, separate, and not in Canada

Policy can invoke Bedrock Guardrails to evaluate content: the outputs of every authorized action and the inputs of every call to a Gateway target, detecting and blocking prompt injection, harmful content, and sensitive-information exposure before it reaches downstream systems.Same source as above. Retrieved 2026-08-05.

Keep the two clearly apart, because the region footprints differ and a customer will catch you out:

PolicyGuardrails within Policy
Question it answers Is this action permitted? Is this content safe?
Mechanism Deterministic authorization, Cedar or natural language Content inspection of inputs and outputs
Status GA GA Jun 2026
ca-central-1 Yes No, five regions only

Canada consequence

A Canadian customer can author and enforce Cedar authorization rules in ca-central-1 today. They cannot get managed prompt-injection or PII screening at the Gateway perimeter in-region. Guardrails within Policy is limited to N. Virginia, London, Stockholm, Sydney, and Tokyo. Their options are an out-of-region deployment for that layer, or screening content in their own application code.

Also carry forward from Lesson 2: Policy's own inference routes to any commercial region globally, with no opt-out and no CloudTrail record of where. See the Canada card.

Don't overclaim

Policy publishes two meters: $0.000025 per authorization request, and $0.13 per thousand input tokens processed. That token rate is high enough that a content-heavy Policy configuration could dominate a customer's bill by an order of magnitude, and the documentation does not make clear which configurations incur it. Do not model Policy at scale from the pricing page alone; verify with the service team first.

Read this next: 4 minutes, and quotable

Amazon Bedrock AgentCore now supports Bedrock Guardrails in Policy

Short, and contains the single most useful sentence in the AgentCore corpus for a security conversation, namely that Policy is evaluated at the Gateway perimeter, outside the agent's code, ensuring consistent enforcement regardless of the agent's autonomy. Learn that phrasing. Retrieved 2026-08-05.

Retrieval practice

Four questions. The last one interleaves Lesson 2, deliberately.

  1. What does the outbound half of Identity govern?

    • Which users are allowed to invoke the agent
    • Which tools the agent is permitted to invoke
    • Which credential the agent uses per end user

    Answer: C. The per-user credential the agent acts with.

  2. Why is a Policy check at the Gateway stronger than the same rule written into the system prompt?

    • It resolves faster than the model can read it
    • It sits outside agent code, so autonomy cannot bypass it
    • It costs far less than the tokens a prompt uses

    Answer: B. It is enforced outside the agent's code.

  3. A customer wants prompt-injection screening on every tool call. Which capability are they asking for?

    • Guardrails within Policy, inspecting the content
    • Policy on its own, authorizing each action
    • Identity, verifying the caller on each request

    Answer: A (Guardrails within Policy).

  4. A Montréal customer must stay in ca-central-1. What can you promise them at the Gateway perimeter?

    • Both authorization rules and content screening
    • Content screening but not authorization rules
    • Authorization rules but not content screening

    Answer: C. Authorization yes, content screening no.

Where to go next

You can now draw the governed tool-call path and say what each hop prevents. That sketch plus the compute tree from Lesson 2 covers most architecture whiteboarding you will be asked to do.

Lesson 4 takes on Memory properly. It is the capability most likely to surprise a customer on their first invoice, and the one where the compliance-friendly choice happens to also be the cheap one.

Supporting cards: the terminology card (the Policy-versus-Guardrails row especially), the Canada card, and the pricing cheat sheet.

Questions to take forward