Your MCP Gateway Routes Traffic. It Doesn't Inspect It.

In the middle of a feature-launch post — between the streaming architecture and the OAuth token-exchange diagrams — AWS hands its customers a security responsibility. Describing the new resource primitives in Amazon Bedrock AgentCore Gateway, the engineering team writes that resource URIs "aren't validated or sanitized by AgentCore Gateway," and tells readers to validate and sanitise those URIs themselves before following them, and not to auto-fetch URIs from untrusted servers.

That is not a footnote. It is a line being drawn. On one side is what a managed MCP gateway does: route, authenticate, govern, observe. On the other side is what it does not do: inspect the content flowing across it for threats. AWS just drew that line in its own launch material, and put content threat detection on the customer's side of it.

If you run an AI platform and you route Model Context Protocol traffic through AgentCore Gateway, this post is about the half of the problem the gateway hands back to you — and why "we route MCP through a managed gateway" is not the same sentence as "our MCP traffic is inspected."

First, give the gateway its due

The argument here is narrow, so it is worth being precise about what AgentCore Gateway actually delivers, because it is substantial.

It collapses per-server infrastructure into one trusted entry point. Instead of every team's MCP server independently handling credentials, connectivity, and logging, the gateway centralises them. It supports AWS PrivateLink for control-plane and data-plane traffic, so connections stay inside your VPC boundary. It centralises credential management, so individual servers no longer hold long-lived secrets. Its session management scopes every session to the authenticated user and validates that each request in a session comes from that same user, which closes off a class of session-hijacking. And its OAuth 2.0 on-behalf-of token exchange propagates the original user's identity across each hop while scoping each token to its intended audience — a genuine zero-trust identity model for multi-hop tool calls.

These are real security properties. They reduce real risk: credential sprawl, network exposure, identity confusion, session theft. A platform team that adopts AgentCore Gateway is better off than one wiring up twenty MCP servers by hand. None of what follows contradicts that.

The point is simply that none of it inspects content.

Governance is not detection

It helps to separate two questions that often get collapsed into one.

The first question is who is allowed to do what. Can this agent call this tool? Is this user permitted to see this capability? Is the caller who they claim to be? This is governance — identity, authorisation, access control, audit. AgentCore Gateway answers it well, and AWS layers more on top: AgentCore Policy (in preview) adds Cedar-based authorisation, deterministic rules about what an agent may access and do, enforced centrally before tool access.

The second question is entirely different: is the content moving across the wire dangerous. Does this tool response contain a prompt injection aimed at the model? Does this resource body carry an exfiltration instruction? Does this URI point at an internal metadata endpoint? Is this elicitation prompt socially engineering the user into approving something they shouldn't? This is detection — inspecting the actual JSON-RPC payloads in both directions and judging their content.

Authorisation decides whether a message is allowed. Detection decides whether a message is safe. A correctly authorised, fully authenticated, perfectly logged tool call can still carry a malicious payload, because the authorisation layer never looked at the content. That is not a gap in AgentCore Gateway's design; it is a different layer of the stack. The gateway is built to answer the first question. The second one is the customer's.

The gateway routes and authenticates the traffic. A separate inspection layer reads every message — Allow, Quarantine, or Block.

The new primitives widen the surface that isn't inspected

This release is notable precisely because it expands what the gateway routes without changing what it inspects. Three of the new capabilities add content surface.

Resources, passed through untouched. Tools and prompts returned through the gateway are prefixed with their target name. Resource URIs are not — the original URI from the downstream MCP server is passed through as-is. AWS is explicit about the consequence: a malicious or compromised server could return URIs pointing to internal endpoints or local file paths, and the gateway does not validate or sanitise them. The fetch-or-don't-fetch decision, and the safety of the URI, land on the operator.

Dynamic listing, forwarded live. In dynamic listing mode, the gateway does not cache a target's capabilities. Instead, tools/list, prompts/list, and resources/list calls are forwarded live to the MCP server at request time. That is useful for per-user, permission-aware catalogues. It also means the tool definitions an agent receives are not indexed or fixed at the gateway — they are whatever the server returns at that moment. A tool whose definition mutates between calls is exactly the surface that tool-definition poisoning targets, and a live-forwarding gateway has no reason to notice the change.

Elicitation, including a redirect mode. Elicitation lets a server pause mid-execution and request input from the user. AgentCore Gateway supports three modes: a form mode, a URL mode where the server sends a URL the client opens, and a URL-exception mode where the server returns an error carrying a URL and prompts the client to redirect the user and retry. This is a powerful human-in-the-loop primitive. It is also a new server-initiated channel that can put a prompt, or a URL, in front of a human, and the gateway forwards those exchanges rather than inspecting them for deception.

Each of these is a reasonable feature. Together they mean the channel the gateway routes got wider, while the inspection the gateway performs stayed at zero by design.

"But AWS has content safety products"

It does, and they matter — but neither one covers this layer, and conflating them is how platform teams end up with a blind spot they think is covered.

Amazon Bedrock Guardrails operates on model input and output: it filters the content going into and coming out of a foundation model. AgentCore Policy, as above, is Cedar-based authorisation: it governs what an agent is permitted to do. Both are valuable. Neither inspects the JSON-RPC traffic between an agent and its MCP tools for embedded threats. An injection sitting inside a resources/read response body, an exfiltration URI returned from a tools/call, a deceptive elicitation/create prompt — these travel in the tool-call and tool-response channel, which sits between model-I/O safety and authorisation. That channel is the one with no owner by default.

One more clarification, because the word invites it: AgentCore's tooling references an "MCP Inspector," but that is the standard open-source @modelcontextprotocol/inspector developer and debugging tool, explicitly not a production threat-inspection control. The name is a coincidence, not a capability.

What inspecting the wire actually means

This is the layer the industry has begun to name: Agent Detection & Response (ADR) — runtime detection and enforcement on what agents actually do, at the layer endpoint and authorisation tools can't see. It is the layer CheckedAgent is built for: an inline, MCP-native ADR proxy that sits on the wire between an agent and the MCP servers it calls, and classifies every JSON-RPC message ALLOW, QUARANTINE, or BLOCK in real time — in both directions, on the same connection. Where the gateway routes, an inspection layer reads. Concretely, against the surfaces this release widened:

The unvalidated resource URI is the cleanest example. CheckedAgent applies request-grade URI canonicalisation and threat classification to URIs that appear in tool responses — scheme allowlisting, blocking of private-IP and internal-network targets — at exactly the point where a routing gateway passes the URI through. That is a direct, mechanical answer to the warning AWS prints in its own post.

Dynamic listing's live-forwarded tool definitions are the case for Tool Definition Integrity. CheckedAgent's trust-on-first-use model (TOFU v2) tracks tool definitions and flags mutations, so a definition that changes between calls is caught rather than silently trusted — the gap that opens when tools/list is forwarded live and never indexed.

Elicitation calls for inspecting the reverse direction — server-initiated requests, not just agent requests. CheckedAgent gates undeclared elicitation and sampling capability and scans elicitation prompts as part of response-side inspection, so a server that was never authorised to interrupt the user with a prompt is caught attempting it, and the prompt itself is read rather than waved through.

Across all of it, the property that matters is bidirectional inspection on a single connection, which is what makes request–response correlation possible: the request that looked benign and the response that reveals the poisoning are seen together, not as two unrelated events.

The framing we'd offer a sceptical platform owner is not that the gateway is wrong. It is that the gateway is the road and inspection is what travels on it. The two are complementary layers. AgentCore Gateway centralises governance; an inspection layer reads the content that governance waves through. They are not substitutes, and a platform that has one does not automatically have the other. (Where a co-existence pattern is concerned, AgentCore Gateway's Lambda interceptors are a plausible insertion point for an inspection step — a design possibility worth noting, not a shipped integration, and not an endorsement either way.)

The question to take to your next architecture review

If you operate MCP at scale, the useful outcome of AWS's post is a single question, asked deliberately: who inspects the content?

Not who routes it — you know that. Not who authenticates it, authorises it, or logs it — the gateway does. The question is who reads the tool responses, the resource bodies, and the elicitation prompts, and decides whether the content is a threat. If the answer is "the managed gateway," re-read the launch post: AWS has told you, in plain terms, that resource URIs are not validated or sanitised, and that following them safely is your job.

That is not a failure on AWS's part. It is a hyperscaler being precise about where its responsibility ends — and handing you the other half on purpose. The only mistake a platform team can make here is not noticing the handoff.

The road is managed. The traffic on it still needs watching.

CheckedAgent is an Agent Detection & Response (ADR) platform for MCP: an inline proxy that inspects JSON-RPC traffic between AI agents and their tools in both directions, classifying every message ALLOW / QUARANTINE / BLOCK in real time. It complements managed gateways and identity providers; it does not replace them.