mech.app
Dev Tools

MCP Gateway Pattern: How Amazon Bedrock AgentCore Centralizes Tool Access Control Across Multi-Agent Systems

AWS introduces a middleware gateway for Model Context Protocol servers that centralizes credentials, observability, and security boundaries for multi-te...

Source: aws.amazon.com
MCP Gateway Pattern: How Amazon Bedrock AgentCore Centralizes Tool Access Control Across Multi-Agent Systems

When you move from a single MCP demo to production multi-agent deployments, the infrastructure problem shifts. Instead of one agent calling one tool server, you have dozens of agents across different teams sharing the same MCP servers. Each server needs credentials, audit trails, rate limits, and security boundaries. Without a gateway, every MCP server reimplements the same access control, credential management, and observability logic.

Amazon Bedrock AgentCore Gateway addresses this by sitting between MCP servers and the clients that consume them. It centralizes credential management, observability, and secure connectivity into a single trusted entry point. The recent extension adds support for MCP prompts, resources, dynamic server discovery, streaming sessions, mid-execution elicitation, and OAuth 2.0 token exchange.

The Gateway-as-Middleware Pattern

AgentCore Gateway intercepts MCP traffic before it reaches tool servers. Instead of each MCP server handling authentication, policy enforcement, and logging independently, the gateway becomes the single enforcement point.

Key responsibilities:

  • Credential injection: The gateway holds secrets and injects them into MCP tool calls. Your legal team’s contract review server never sees raw credentials.
  • Access control: Policy rules determine which agents can call which tools. Finance data retrieval tools stay isolated from operations incident response tools.
  • Observability: All MCP traffic flows through one point, making it possible to log tool calls, measure latency, and track usage across teams.
  • Private connectivity: MCP servers run in private subnets. The gateway handles VPC peering, PrivateLink, or VPN tunnels.

This pattern trades latency for operational simplicity. Every tool call adds a network hop, but you eliminate the need to audit and secure each MCP server individually.

Protocol Extensions for Enterprise Workflows

The new capabilities extend MCP beyond simple tool calls.

MCP Prompts and Resources

MCP prompts are reusable templates that agents can invoke. Instead of hardcoding prompt text in agent code, you store prompts in MCP servers and reference them by name. The gateway exposes these prompts as first-class primitives, so agents can list available prompts and invoke them with parameters.

MCP resources are static or dynamic data sources (files, database queries, API responses) that agents can read. The gateway treats resources the same way it treats tools: access control, credential injection, and logging apply uniformly.

Dynamic Server Discovery

In a multi-tenant deployment, MCP servers come and go. New teams spin up servers, old servers get decommissioned. Dynamic listing lets agents discover available MCP servers at runtime without hardcoding server addresses.

The gateway maintains a registry of active MCP servers. When an agent queries the gateway, it returns a list of servers the agent is authorized to use. This avoids the brittle pattern of updating agent configuration files every time a new MCP server launches.

Streaming and Session Management

MCP tool calls can be long-running. A contract review tool might take 30 seconds to scan a document. Without streaming, the agent waits for the entire response before proceeding.

The gateway supports streaming MCP responses. As the tool server generates output, the gateway forwards chunks to the agent. This keeps the agent responsive and allows it to start processing partial results.

Session management tracks stateful interactions. If a tool call requires multiple round trips (for example, paginated results or interactive workflows), the gateway maintains session state so the agent doesn’t need to re-authenticate or re-establish context on each call.

Mid-Execution Elicitation

Some tool calls require additional input mid-execution. A database query tool might need the agent to clarify which table to query. Instead of failing the tool call, the gateway supports elicitation: the tool server pauses, requests input from the agent, and resumes once the agent provides the missing parameter.

This pattern avoids the need to design tools with every possible parameter upfront. Tools can be more flexible, asking for clarification only when needed.

OAuth 2.0 On-Behalf-Of Token Exchange

In a multi-tenant system, agents act on behalf of users. A finance agent querying a database should inherit the user’s permissions, not the agent’s permissions. OAuth 2.0 on-behalf-of (OBO) token exchange solves this.

The agent presents a user token to the gateway. The gateway exchanges it for a new token scoped to the MCP server. The MCP server sees the user’s identity and enforces user-level permissions. This prevents privilege escalation: an agent can’t access data the user isn’t authorized to see.

Architecture: Gateway as Policy Enforcement Point

┌─────────────────┐
│   Agent Fleet   │
│  (Legal, Ops,   │
│   Finance...)   │
└────────┬────────┘
         │
         │ MCP Requests
         ▼
┌─────────────────────────────────────┐
│   AgentCore Gateway                 │
│                                     │
│  ┌──────────────────────────────┐  │
│  │  Authentication & AuthZ      │  │
│  │  (OAuth OBO, IAM Roles)      │  │
│  └──────────────────────────────┘  │
│                                     │
│  ┌──────────────────────────────┐  │
│  │  Credential Injection        │  │
│  │  (Secrets Manager, Vault)    │  │
│  └──────────────────────────────┘  │
│                                     │
│  ┌──────────────────────────────┐  │
│  │  Observability & Logging     │  │
│  │  (CloudWatch, X-Ray)         │  │
│  └──────────────────────────────┘  │
│                                     │
│  ┌──────────────────────────────┐  │
│  │  Session & Stream Manager    │  │
│  └──────────────────────────────┘  │
└──────────┬──────────────────────────┘
           │
           │ Authorized MCP Calls
           ▼
┌──────────────────────────────────────┐
│   MCP Server Pool                    │
│                                      │
│  ┌─────────┐  ┌─────────┐  ┌──────┐│
│  │Contract │  │Finance  │  │Ops   ││
│  │Review   │  │Data     │  │Tools ││
│  └─────────┘  └─────────┘  └──────┘│
└──────────────────────────────────────┘

The gateway sits at the network boundary. Agents never talk directly to MCP servers. All traffic flows through the gateway, which enforces policy before forwarding requests.

State Management and Failure Modes

State Isolation

Each agent-server interaction gets a unique session ID. The gateway stores session state in a distributed cache (ElastiCache, DynamoDB). If a tool call requires multiple round trips, the gateway retrieves session state on each request.

State isolation prevents cross-contamination. Agent A’s session state never leaks into Agent B’s session, even if both agents call the same MCP server concurrently.

Failure Modes

Failure ScenarioImpactMitigation
Gateway unavailableAll MCP traffic stopsDeploy gateway in multiple AZs with load balancer health checks
Session state lossIn-flight tool calls failUse persistent session store (DynamoDB) with point-in-time recovery
Credential rotationTool calls fail until gateway reloads secretsImplement secret rotation with grace period and automatic reload
MCP server timeoutAgent waits indefinitelySet gateway-level timeout (30s default) and return error to agent
OAuth token expiryMid-session tool calls failGateway refreshes tokens proactively before expiry

The gateway becomes a single point of failure. If it goes down, no agent can call any MCP server. The mitigation is standard high-availability patterns: multi-AZ deployment, health checks, and automatic failover.

Latency Budget

Every tool call adds a gateway hop. Typical latency breakdown:

  • Agent to gateway: 10-20ms (same region)
  • Gateway authentication/authorization: 5-10ms (cached IAM policy)
  • Gateway to MCP server: 10-20ms (VPC peering)
  • MCP server processing: 100-5000ms (depends on tool)
  • Total overhead: 25-50ms

For tools with sub-100ms execution time, the gateway overhead is significant. For tools that take seconds (database queries, document processing), the overhead is negligible.

Observability and Instrumentation

The gateway logs every MCP interaction:

  • Tool call request (agent ID, tool name, parameters)
  • Authorization decision (allow/deny, policy rule matched)
  • Credential injection (which secret was used, without exposing the secret)
  • MCP server response (latency, status code, error message)
  • Session lifecycle (created, resumed, expired)

This creates a unified audit trail. Security teams can answer questions like “Which agents accessed finance data last week?” or “How many tool calls failed due to permission errors?”

The gateway integrates with AWS X-Ray for distributed tracing. Each tool call becomes a trace segment, showing the full path from agent to gateway to MCP server and back.

Code Example: Gateway Configuration

# gateway-config.yaml
mcp_servers:
  - name: contract-review
    endpoint: https://contract-review.internal:8080
    auth:
      type: oauth-obo
      token_exchange_endpoint: https://auth.internal/token
    access_policy:
      allow_agents:
        - legal-agent-*
      deny_agents:
        - ops-agent-*
    credentials:
      secret_arn: arn:aws:secretsmanager:us-east-1:123456789012:secret:contract-review-api-key
    observability:
      log_requests: true
      log_responses: false  # responses may contain PII
      trace_enabled: true

  - name: finance-data
    endpoint: https://finance-data.internal:8080
    auth:
      type: iam-role
      role_arn: arn:aws:iam::123456789012:role/FinanceDataAccess
    access_policy:
      allow_agents:
        - finance-agent-*
    rate_limits:
      requests_per_minute: 100
      burst: 20
    timeout_seconds: 30

The gateway reads this configuration and enforces policy for each MCP server. Agents authenticate once to the gateway, then the gateway handles per-server authentication and authorization.

Deployment Patterns

Single-Region Deployment

Deploy the gateway in one region with MCP servers in the same VPC. Agents connect via private endpoints. This minimizes latency but lacks cross-region failover.

Multi-Region Active-Passive

Deploy gateways in two regions. Primary region handles all traffic. Secondary region stays warm but doesn’t serve traffic unless primary fails. Session state replicates to secondary region via DynamoDB global tables.

Multi-Region Active-Active

Deploy gateways in multiple regions. Agents connect to the nearest gateway. Session state replicates across regions. This adds complexity: you need distributed session management and eventual consistency guarantees.

Security Boundaries

The gateway enforces three security boundaries:

  1. Agent-to-gateway: Agents authenticate using IAM roles or OAuth tokens. The gateway verifies the agent’s identity before forwarding requests.

  2. Gateway-to-server: The gateway injects credentials (API keys, OAuth tokens) into MCP requests. MCP servers never see the agent’s credentials, only the gateway’s injected credentials.

  3. User-to-data: For OAuth OBO flows, the gateway exchanges the user’s token for a server-scoped token. The MCP server enforces user-level permissions, preventing agents from accessing data the user isn’t authorized to see.

This layered approach prevents several attack vectors:

  • Credential theft: Agents never hold credentials for MCP servers. If an agent is compromised, the attacker can’t directly call MCP servers.
  • Privilege escalation: Agents can’t bypass user-level permissions. Even if an agent is compromised, it can only access data the user is authorized to see.
  • Data exfiltration: The gateway logs all tool calls. Unusual access patterns (for example, an agent suddenly calling a finance tool it never called before) trigger alerts.

Technical Verdict

Use AgentCore Gateway when:

  • You have multiple teams building MCP servers and need centralized access control
  • You need a unified audit trail for compliance or security investigations
  • You want to avoid duplicating credential management, observability, and policy enforcement across every MCP server
  • You’re deploying agents in a multi-tenant environment where isolation and rate limiting matter

Avoid it when:

  • You have a single agent calling a single MCP server (the gateway adds unnecessary complexity)
  • Latency is critical and you can’t afford an extra network hop (sub-100ms tool calls)
  • You need custom protocol extensions that the gateway doesn’t support (you’ll need to fork or wait for AWS to add features)
  • You’re running outside AWS and don’t want to depend on AWS-specific services (IAM, Secrets Manager, CloudWatch)

The gateway pattern trades latency for operational simplicity. If you’re building a production multi-agent system, the trade-off is usually worth it. If you’re prototyping or running a single-agent demo, skip the gateway and connect directly to MCP servers.