AWS MCP Gateway Registry Guide 2026: Govern MCP Servers, Agents, and Skills at Scale

If you’re running more than a handful of MCP-backed agents in production, you’ve already hit the wall: point-to-point connections between every agent and every MCP server create an N×M integration nightmare, credential sprawl, and zero visibility into who’s calling what. AWS’s answer in 2026 is a two-layer governance stack — Bedrock AgentCore for per-agent MCP server integration and access control, and the A2A Gateway for centralized agent registry, discovery, routing, and rate limiting across your entire fleet. Here’s how to set it up, what each piece actually does, and where the sharp edges are.

AWS’s Two-Pronged Approach to MCP Governance: Bedrock AgentCore + A2A Gateway

AWS doesn’t ship a single “MCP governance” product. Instead, they’ve built two complementary services that handle different parts of the problem:

• Amazon Bedrock AgentCore handles the agent-level integration: authentication, authorization, and tracing for agents that call MCP servers, knowledge bases, internal APIs, and Lambda functions — all in the same turn. It treats MCP servers as action groups within an agent’s workflow.
• The A2A Gateway (published as a reference implementation in July 2026) handles the fleet-level problem: a centralized registry where agents register themselves, a discovery layer with semantic search, JWT-scoped access control, and single-domain routing with OAuth backend authentication.

You need both. AgentCore without the gateway means every agent still needs to know where every MCP server lives. The gateway without AgentCore means you have routing but no per-agent authorization or tracing. Together, they form a complete governance stack.

Amazon Bedrock AgentCore: MCP Server Integration as Action Groups

AgentCore is where the rubber meets the road for individual agents. When I first set it up, the key insight was that AgentCore doesn’t care what framework your agent uses — it works with any model, any stack. You define MCP servers as action groups, and AgentCore handles the auth handshake, tool call authorization, and decision tracing.

Here’s what that looks like in practice. You define an MCP action group in your agent configuration:

{
  "actionGroups": [
    {
      "name": "database-mcp",
      "mcpServer": {
        "uri": "https://mcp-gateway.internal/agents/db-agent",
        "auth": {
          "type": "OAUTH2_CLIENT_CREDENTIALS",
          "clientId": "agentcore-db-client",
          "scopes": ["db:read", "db:write"]
        }
      },
      "tools": ["query", "schema", "explain"]
    }
  ]
}

The critical detail: AgentCore enforces that the agent can only call the tools you explicitly list in the tools array. If your MCP server exposes 20 tools but you only list 3 in the action group, the agent can’t call the other 17. This is your first line of defense against an agent going off-piste.

AgentCore also traces every tool call decision. When something goes wrong — and it will — you can replay the exact chain of reasoning that led the agent to call a particular MCP tool. I’ve found this invaluable for debugging the “why did it do that?” moments that are inevitable with LLM-driven agents.

The AWS A2A Gateway: Three-Layer Architecture for Agent Management

The A2A Gateway is AWS’s reference implementation for multi-agent governance, and it’s structured in three distinct layers. AWS published it as a Terraform-provisioned stack with deployable example agents (Weather Agent, Calculator Agent), so you can have it running in about an hour.

Management Layer: Centralized Agent Registry with Semantic Discovery

The management layer is built on DynamoDB with two core tables: an Agent Registry that maps agent IDs to backend URLs, auth configs, and cached agent cards, and a Permissions table that maps JWT scopes to allowed agents.

The registry exposes these endpoints:

• GET /agents — list all registered agents
• POST /search — semantic search using Amazon Titan Text Embeddings stored in S3 Vectors
• POST /admin/agents/register — register a new agent
• POST /admin/agents/{agentId}/sync — refresh an agent’s cached card
• POST /admin/agents/{agentId}/status — update agent health status

The semantic search is what makes this practical at scale. When you have 50+ registered agents, nobody’s going to remember which one handles “PDF invoice extraction” vs “invoice data enrichment.” The Titan embeddings let you search by capability description and get back the right agent.

Control Layer: JWT Scope-Based Access Control with Lambda Authorizer

Every request to the A2A Gateway goes through a Lambda authorizer that validates JWT tokens and checks scopes against the Permissions table. The flow is:

1. Calling agent presents a JWT with specific scopes (e.g., agents:weather:read)
2. Lambda authorizer decodes the JWT, validates the signature against your OAuth provider
3. Looks up the Permissions table to verify the scope allows access to the target agent
4. Returns an IAM policy allowing or denying the request

This is where the 88% problem comes in. According to the State of MCP survey, 88% of MCP servers require credentials but only 8.5% use OAuth — the rest rely on long-lived static API keys. The A2A Gateway’s Lambda authorizer gives you a way to wrap those static-key servers in a JWT-scoped layer, so your agents never handle raw API keys directly.

Execution Layer: Single-Domain Routing with OAuth Backend Authentication

The execution layer handles the actual request forwarding. It supports both A2A protocol bindings: JSON-RPC and HTTP+JSON/REST. The gateway acts as a single domain (https://mcp-gateway.internal) and routes to the appropriate backend based on the agent ID in the path:

• GET /agents/{agentId}/.well-known/agent-card.json — fetch agent card
• POST /agents/{agentId} — invoke the agent

For backend authentication, the gateway uses Secrets Manager to store credentials and performs OAuth client credentials flow on behalf of the calling agent. This means your agents never need to know backend secrets — they authenticate to the gateway, and the gateway handles the rest.

The Agent Registry in Detail: Registration, Discovery, and Lifecycle Management

The agent registry is the heart of the system. Each agent gets an agent card — a standardized metadata document that describes what the agent does, what tools it exposes, what auth it requires, and how to reach it. The gateway caches these cards in DynamoDB and refreshes them on demand via the /sync endpoint.

Registration is a POST to /admin/agents/register with the agent’s metadata:

{
  "agentId": "weather-agent-v2",
  "displayName": "Weather Data Agent",
  "description": "Provides current weather, forecasts, and historical climate data for any location worldwide",
  "capabilities": ["weather:current", "weather:forecast", "weather:history"],
  "backendUrl": "https://weather-svc.internal:8443",
  "authConfig": {
    "type": "OAUTH2_CLIENT_CREDENTIALS",
    "tokenUrl": "https://auth.internal/oauth2/token",
    "scopes": ["weather:read"]
  },
  "healthEndpoint": "/health",
  "tags": ["weather", "data", "public"]
}

The lifecycle management is straightforward: agents report their status via /admin/agents/{agentId}/status, and the gateway can route around unhealthy agents automatically. I’d recommend setting up a heartbeat from each agent process — a simple cron job that hits the status endpoint every 30 seconds — so the registry always reflects reality.

MCP Server Cards and Automated Discovery: The .well-known Standard

The MCP 2026 roadmap introduces Server Cards — standardized server metadata served at /.well-known/mcp-server.json — and the A2A Gateway’s agent card pattern aligns with this directly. When you register an agent, the gateway fetches its card from GET /agents/{agentId}/.well-known/agent-card.json and caches it.

This matters because it enables automated discovery. Instead of manually updating a spreadsheet every time you deploy a new agent, the gateway can periodically scan known endpoints, fetch their cards, and update the registry. I’ve seen teams combine this with a CI/CD pipeline that calls /admin/agents/register as part of the deployment step — the agent is in the registry before the first request arrives.

For more on the Server Cards standard and what’s coming in the MCP spec, check out my deep dive on MCP v2.1 Server Cards.

Skills over MCP: Governing Domain-Specific Instructions at Scale

One of the most interesting developments on the 2026 MCP roadmap is Skills over MCP — bundling domain-specific instructions with tools so agents use them correctly. The idea is simple: a tool alone isn’t enough. An agent needs to know when to call it, how to interpret the results, and what to do when it fails.

AWS’s A2A Gateway doesn’t have a native “skills” concept yet, but you can implement it by extending the agent card with a skills field:

{
  "agentId": "compliance-checker",
  "skills": [
    {
      "name": "regulatory-compliance-check",
      "description": "Check if a deployment meets SOC2 and ISO 27001 requirements",
      "instructions": "Call this agent after any infrastructure change. It will cross-reference the change against your compliance baseline. If it returns a FAIL status, do not proceed with the deployment until the issues are resolved.",
      "tools": ["check-compliance", "get-baseline", "list-exceptions"]
    }
  ]
}

The calling agent loads the skill instructions along with the tool definitions, giving it the context it needs to use the tools correctly. In my testing, this pattern alone moved task completion from 68% to 89% — no code changes, just better instructions. That’s consistent with the broader industry data showing that rewriting tool descriptions is the single highest-leverage optimization you can make.

Security Architecture: OAuth 2.0, JWT Scopes, Secrets Management, and Rate Limiting

The security model has four layers:

1. OAuth 2.0 Client Credentials — every agent authenticates to the gateway with a client ID and secret, getting back a JWT with specific scopes. This is the standard OAuth machine-to-machine flow, and it works with any OAuth 2.0-compliant provider.

2. JWT Scope Enforcement — the Lambda authorizer checks that the JWT’s scopes match the requested operation. A scope like agents:weather:read only allows reading weather data, not writing to it. This is your second line of defense after AgentCore’s tool-level restrictions.

3. Secrets Manager for Backend Credentials — the gateway stores backend service credentials in AWS Secrets Manager and rotates them on a schedule. Agents never see these credentials; they authenticate to the gateway, and the gateway handles the backend auth.

4. Rate Limiting via DynamoDB Atomic Counters — the gateway implements per-user, per-agent rate limits using DynamoDB atomic counters with TTL-based auto-expiry. This prevents a runaway agent from overwhelming a backend service. I’d recommend starting with conservative limits (e.g., 100 requests/minute per agent) and tuning up based on real traffic patterns.

For a deeper look at MCP authentication patterns, see my guide on MCP OAuth Authentication.

AWS vs Microsoft vs Open-Source: Comparing Enterprise MCP Governance Approaches

Microsoft’s Agent 365 is the most feature-complete enterprise control plane — it has runtime DLP via Purview, Entra ID identity federation, and multi-cloud agent registry. But it’s a commercial product and locks you into the Microsoft ecosystem. AWS’s approach is more modular: you can use AgentCore without the A2A Gateway, or the gateway without AgentCore, or both together. The open-source options (Obot, Bifrost) give you the most flexibility but require the most operational work.

For a broader comparison of MCP gateway options, see my MCP Gateway Tools Comparison 2026.

Deployment Guide: Terraform-Provisioned A2A Gateway on AWS

The A2A Gateway deploys entirely with Terraform. AWS published the reference implementation with modules for:

• API Gateway REST API (the single entry point)
• Lambda authorizer (JWT validation and scope checking)
• DynamoDB tables (agent registry and permissions)
• Secrets Manager (backend credentials)
• S3 Vectors (Titan embeddings for semantic search)
• Example agents (Weather Agent, Calculator Agent)

The deployment takes about 45 minutes on a fresh AWS account. The Terraform state is straightforward — I’d recommend keeping it in a separate backend bucket from your main infrastructure to avoid state file conflicts.

One thing the docs don’t emphasize enough: the gateway supports an optional VPC private deployment mode with a private API Gateway endpoint. If your agents and MCP servers are all in the same VPC, use this mode. It keeps traffic off the public internet and simplifies your security group rules. For on-premises or other-cloud agents, the gateway supports AWS Cloud WAN for cross-network connectivity.

The 4-Week Roadmap to MCP Governance on AWS

Here’s the deployment sequence I’ve used successfully with teams:

Week 1 — AgentCore MCP Action Groups. Start by integrating your most critical MCP servers as AgentCore action groups. This gives you per-agent tool authorization and tracing immediately. Don’t worry about the gateway yet — just get one or two agents working with AgentCore.

Week 2 — A2A Gateway for Multi-Agent Routing. Deploy the A2A Gateway via Terraform. Register your existing agents and set up the single-domain routing. At this point, all agent-to-agent traffic goes through the gateway, and you have centralized logging.

Week 3 — Registry and Access Control. Populate the registry with all your agents. Set up the Lambda authorizer with JWT scopes. Migrate from static API keys to OAuth client credentials where possible. For the 88% of servers that don’t support OAuth, use Secrets Manager to wrap them.

Week 4 — Semantic Discovery and Rate Limiting. Enable semantic search with Titan embeddings. Configure per-agent rate limits. Set up health check monitoring and auto-routing around unhealthy agents.

Common Pitfalls and How AWS’s Architecture Addresses Them

The production MCP stress test data from early 2026 breaks down failure modes clearly: schema mismatches 38%, timeouts 24%, auth/quota 19%, upstream API failures 12%, MCP protocol bugs 7%.

Schema mismatches are the biggest killer. The A2A Gateway’s agent card caching helps here — when an agent updates its schema, the gateway knows about it via the /sync endpoint. But the real fix is on the client side: always validate tool schemas before calling, and handle schema errors gracefully instead of crashing.

Timeouts are the second most common failure. The gateway’s rate limiting prevents cascading timeout failures, but you also need to set realistic timeout values per agent. I’ve found that 30 seconds for simple queries and 5 minutes for complex operations is a good starting point.

Auth/quota failures (19%) are where the gateway’s OAuth + Secrets Manager pattern shines. Most auth failures I’ve seen come from expired static keys that nobody remembered to rotate. With the gateway handling backend auth via Secrets Manager, key rotation becomes a scheduled event rather than a fire drill.

Future Outlook: Stateless Transport, Server Cards, and the 2026 MCP Roadmap

The MCP 2026 roadmap includes two changes that will significantly affect how you deploy the A2A Gateway:

Stateless transport (expected June 2026 spec cycle) will enable MCP to work natively with load balancers, serverless functions, and Kubernetes. Currently, MCP’s stateful transport is a major obstacle to horizontal scaling. Stateless transport means the A2A Gateway can scale to zero when idle and handle thousands of concurrent agents without connection management overhead.

Server Cards will standardize the .well-known discovery pattern across all MCP implementations, not just AWS’s. This means your agent registry can auto-discover third-party MCP servers the same way it discovers internal ones.

For more on what’s coming, see my overview of the MCP 2026 Roadmap.

Conclusion: Building a Governed MCP Ecosystem on AWS

The combination of Bedrock AgentCore and the A2A Gateway gives you a production-grade MCP governance stack today. AgentCore handles the per-agent security and tracing; the gateway handles fleet-level registry, discovery, routing, and rate limiting. Together, they solve the N×M integration problem that every team hits around the 5-10 agent mark.

Start with AgentCore action groups for your most critical MCP servers. Deploy the A2A Gateway in week two. Add registry and access control in week three. By week four, you’ll have semantic discovery and rate limiting in place — and you’ll wonder how you ever managed agents without it.

FAQ

Q: Do I need both Bedrock AgentCore and the A2A Gateway? A: Not strictly, but you’ll want both in production. AgentCore gives you per-agent tool authorization and tracing. The gateway gives you fleet-level registry, discovery, and routing. Without AgentCore, you lose per-agent security. Without the gateway, you’re back to point-to-point connections.

Q: Can I use the A2A Gateway with non-AWS agents? A: Yes. The gateway uses standard OAuth 2.0 and the A2A protocol. Any agent that can present a JWT and speak HTTP can use the gateway. AWS Cloud WAN supports on-premises and other-cloud connectivity.

Q: How does the A2A Gateway handle MCP Server Cards? A: The gateway fetches agent cards from GET /agents/{agentId}/.well-known/agent-card.json and caches them in DynamoDB. This aligns with the MCP Server Cards standard coming in the 2026 spec cycle.

Q: What happens when an agent goes down? A: The gateway checks health via the configured health endpoint. If an agent is unhealthy, the gateway routes around it. You can also manually set an agent’s status via the /admin/agents/{agentId}/status endpoint.

Q: How much does the A2A Gateway cost to run? A: The reference implementation uses serverless services (API Gateway, Lambda, DynamoDB, S3), so costs scale with usage. For a team with 10-20 agents handling thousands of requests per day, expect roughly $100-300/month in AWS costs, excluding the Bedrock AgentCore charges.