MCP servers are proliferating fast inside enterprises. Every team ships one, each one independently handles credentials, every security team reviews them separately, and nobody has a unified view of what tools are being called by whom. Amazon Bedrock AgentCore Gateway just got a significant capability expansion — and the additions tell you exactly where enterprise MCP deployments are breaking down in production.
The Problem With Federated MCP at Scale
The moment you have more than a handful of MCP servers in an organization, you have a governance problem. Your legal team's contract review server, your finance team's data retrieval server, and your operations team's incident response server each carry the same infrastructure burden: credential management, access control, logging, private network connectivity. Security reviews stack up. Developers wait on approvals. And when an agent calls across three different MCP servers in a single task, there's no unified audit trail — just three separate logs in three separate systems.
The standard fix has been to build that shared layer yourself. AgentCore Gateway's proposition is that you shouldn't have to.
How AgentCore Gateway Actually Works Now
AgentCore Gateway sits between MCP clients and every MCP server in your organization, acting as the single authenticated entry point for all MCP traffic. Teams build only the business logic for their server. The gateway handles everything else — credential management, policy enforcement, observability, private network routing via AWS PrivateLink, and now a substantially expanded protocol surface.
The new capabilities fall into five categories, each addressing a specific production failure mode.
Full MCP primitive support. Previously, Gateway focused primarily on tool calls. It now treats MCP prompts and MCP resources as first-class citizens alongside tools. Clients connected to Gateway see one unified catalog — one tool list, one prompt library, one resource namespace — aggregated from every backend server. The full method set is supported: tools/list, tools/call, prompts/list, prompts/get, resources/list, resources/read, and resources/templates/list. Tool definitions now also carry outputSchema for defining expected output structure and annotations describing behavioral properties like whether a tool is read-only or destructive.
Dynamic listing for per-user capability scoping. This is the subtler addition and it matters for multi-tenant deployments. In default listing mode, Gateway caches tool and capability lists at target registration time and serves them from cache on list calls. Fast, but static. In dynamic listing mode, list calls are forwarded live to the MCP server at request time, under the calling user's identity — meaning the server itself decides what to show each user. A permissions-aware server can surface approve_expense only to managers. A healthcare-facing server can return HIPAA-compliant tools only to healthcare-credentialed customers. The backend server's existing access control logic carries through without re-implementing it at the gateway layer.
Streaming via Streamable HTTP transport. Without streaming, a tool call that runs for 45 seconds returns nothing until completion. With the new SSE-based streaming support, clients that send Accept: application/json, text/event-stream get real-time progress notifications, logging messages, and the final result as they're emitted by the backend server. Clients that send only Accept: application/json continue to receive a single JSON response — full backward compatibility preserved. Streaming is opt-in, enabled by setting enableResponseStreaming: true in the gateway protocol configuration.
Session management for stateful multi-turn workflows. Gateway now generates a Mcp-Session-Id on the first initialize request and returns it as a response header. Clients include this header on subsequent requests, letting Gateway maintain state across a multi-step conversation — including mapping client sessions to downstream server sessions and reusing those mappings to avoid repeated initialization overhead. Sessions are user-scoped: Gateway derives the user identity from the JWT bearer token or IAM credentials and validates that every request in a session comes from the same user. This directly prevents session hijacking. Timeouts are configurable from 15 minutes to 8 hours.
Elicitation for human-in-the-loop mid-execution. This is the most operationally interesting addition. Elicitation lets an MCP server behind Gateway pause execution and request input from the end user before proceeding. Three modes: form mode (server sends a JSON Schema, client renders a form), URL mode (server sends a URL — typically an OAuth consent screen or external approval workflow), and URL exception mode (server returns a URLElicitationRequiredError, client redirects the user and retries after completion). Elicitation requires both streaming and sessions to be enabled. Gateway handles capability negotiation — if a client doesn't declare elicitation support during initialization, the backend server won't attempt to send elicitation requests. Multiple concurrent elicitations per session are supported.
OAuth 2.0 on-behalf-of token exchange. When agents need to access downstream resources on behalf of authenticated users, Gateway now supports RFC 8693 token exchange through AgentCore Identity. The original user's identity is preserved and propagated through every hop in the chain — Gateway receives JWT A scoped to the gateway audience, exchanges it for JWT B scoped to the MCP server audience, and the MCP server can obtain JWT C scoped to a further downstream API. At every hop, the original user's sub claim carries forward. Downstream services can enforce per-user authorization without triggering additional consent flows. AgentCore Identity acts as the central token broker; neither Gateway nor the MCP servers handle credentials directly.
What Teams Are Actually Using This For
The practical picture: a single Gateway deployment replaces per-server credential management for every MCP server in the organization. The Lambda interceptor capability lets you inject custom authorization logic, sanitization, or request transformation at the gateway layer rather than duplicating it across every server. AgentCore Policy (currently in preview) adds Cedar-based deterministic policy enforcement at the gateway plane — the same "can you do this right now" enforcement layer covered in the AgentOps framework, now directly wired into MCP traffic.
The dual listing mode architecture handles the case that trips up most multi-tenant implementations: some capabilities are universal, some are per-user. Default mode for the shared catalog, dynamic mode for anything that needs to scope by identity. Both route through the same Gateway endpoint.
Why This Is a Bigger Deal Than It Looks
MCP is becoming load-bearing infrastructure for agentic AI deployments, and the enterprise adoption question has always been governance — not capability. Any competent engineering team can stand up MCP servers. What they can't easily do is provide a compliance team with a unified audit trail, a security team with centralized credential management, and a platform team with network isolation guarantees — all simultaneously, for dozens of MCP servers across different business units.
Gateway's expansion to cover prompts and resources as first-class primitives, combined with streaming, sessions, elicitation, and OBO token exchange, closes the gap between "MCP works in a demo" and "MCP works in a regulated enterprise environment." The elicitation support in particular is a meaningful protocol-level commitment — it treats human-in-the-loop not as an application-layer afterthought but as a primitive the infrastructure handles explicitly.
The resource URI security note in the AWS documentation is worth highlighting for anyone deploying this: because resource URIs come from downstream MCP servers and are not sanitized by Gateway, a compromised server could return URIs pointing to internal endpoints or local filesystem paths. Validate resource URIs before following them from any untrusted target. That's a production concern, not a theoretical one.
Availability and Access
All capabilities described here are available now in Amazon Bedrock AgentCore Gateway. Streaming is configured at the CreateGateway / UpdateGateway API level. Session management and elicitation each require explicit enablement — elicitation requires both streaming and sessions to be on. Dynamic listing is specified per target during CreateGatewayTarget. OAuth OBO token exchange is handled through AgentCore Identity. Hands-on examples are in the awslabs/agentcore-samples GitHub repository. AgentCore Policy integration remains in preview.
The MCP ecosystem now has a managed enterprise infrastructure layer. The question isn't whether enterprises need something like this — it's whether AWS has built the one they'll actually adopt.
Follow for more coverage on MCP, agentic AI, and AI infrastructure.
Top comments (0)