Part 1 argued that an agent's blast radius is its identity, not its model. The natural next question is where you enforce that. The wrong answer — the one most teams reach for first — is the system prompt.
Advisory vs. enforced
A rule in a prompt ("never delete production data") is a request to a model that can be reasoned out of it. A rule at the gateway — the single point every MCP tool call passes through — runs before the call executes and does not care what the model was persuaded to want. That is the whole game: move the control from a layer that can be talked around to one that can't.
What the gateway actually gives you
On AWS, Amazon Bedrock AgentCore Gateway is built to be that chokepoint for MCP. The properties that matter for security are concrete and verifiable:
- Per-user, bounded sessions. AgentCore Gateway scopes MCP streamable-HTTP sessions to the authenticated user, with session timeouts configurable from 15 minutes to 8 hours (default 1 hour) and validation that prevents session hijacking (AWS, Extending MCP support for AgentCore Gateway). A session is tied to an identity and expires; it is not an open pipe.
- Discovery filtered by the caller. Its "dynamic" listing mode forwards tool and resource discovery live at request time, using the calling user's identity for access control (AWS). Two different callers asking "what tools can I use?" can get two different answers. An agent cannot invoke what it was never shown.
- Richer, safer tool contracts. The gateway added MCP prompts and resources
as first-class primitives and extended tool schemas with
outputSchemaand behavioral annotations — including read-only and destructive markers (AWS). "This tool is destructive" becomes machine-readable metadata you can gate on, not a comment in a README.
A mental model
Think of the gateway as doing three jobs the prompt can't:
| Job | At the prompt (advisory) | At the gateway (enforced) |
|---|---|---|
| Who is this? | inferred from context | authenticated session, bounded TTL |
| What can it see? | whatever you described | discovery filtered by caller identity |
| Can it run this? | "please don't" | authorization decision before execution |
None of this makes prompt injection impossible — nothing does. What it does is shrink the consequence. An injected instruction can still try to call a dangerous tool; at the gateway, the call meets an identity check, a session boundary, and a discovery filter before anything happens.
The takeaway
If you are wiring agents to tools, put a gateway between them and treat it as the policy enforcement point: authenticate every session, bound its lifetime, and let the caller's identity decide what is even discoverable. Then the model layer is free to be creative, because the identity layer is the thing standing between "the agent wanted to" and "the agent did."
Part 3 takes the next step: even a perfectly governed gateway is undermined if the agent behind it holds a standing key. Time to retire long-lived credentials entirely.
Researched and drafted with AI assistance; the AgentCore Gateway capabilities above are cited to AWS's documentation, and a human reviewed before publishing.
I help teams across Asia-Pacific turn ambitious AI ideas into shipped, well-crafted products — pairing deep cloud architecture with a product designer's eye for clarity and trust. I write and speak about applied AI, developer experience, and the craft of building things that last.