leejk/ jk lee

Agent Governance: The Chapter After Standardization · 2026.05

AgentCore Gateway vs MCP Gateway: Who Owns the Routing Plane

Vendor-outsourced vs self-hosted — the ownership model that splits the same MCP federation

·
#agent-governance#mcp-gateway#agentcore#mcp#routing#governance#landscape

AWS AgentCore Gateway and the open-source mcp-gateway-registry both fold many MCP servers behind one endpoint and add auth and audit — but they own the routing plane in opposite ways. AgentCore outsources translation, composition, and per-tool credential injection to AWS IAM and Cognito; mcp-gateway-registry self-hosts it with Keycloak and Entra OAuth and OTEL-based audit.

TL;DR. AgentCore Gateway and mcp-gateway-registry do the same job — federating multiple MCP servers, plus auth and audit. What differs is who owns the routing plane. AgentCore binds Translation, Composition, and per-tool credential injection (Secure Credential Exchange) to AWS IAM and Cognito and outsources it to the vendor; agentic-community's mcp-gateway-registry bundles Gateway, Registry, A2A, and audit into one box and self-hosts it with Keycloak/Entra OAuth. The decision AWS Agent Registry's friction #6 deferred — where you route and where you discover — gets settled head-on here.

Why this matters now

AWS Agent Registry's friction #6 forward-references this exact spot: "If you already run your own MCP Gateway in-house, you have to redefine where you route and where you discover, and you can end up running both in parallel."

That dual operation isn't hypothetical — it's a fork that already exists inside organizations. When a team running a self-hosted MCP Gateway evaluates bringing in a vendor-managed Gateway, the decision narrows down not to a feature comparison but to who owns the routing plane.

What the two gateways are

AWS Bedrock AgentCore Gateway — a vendor-managed routing layer that exposes APIs, Lambdas, existing services, and existing MCP servers as a single MCP-compatible endpoint. It does three things: Translation (converting between an agent's MCP requests and API/Lambda calls), Composition (synthesizing multiple APIs, functions, and MCP servers into a single MCP endpoint), and Secure Credential Exchange (injecting credentials to match each tool's distinct auth requirements). It takes MCP servers directly as a target type and supports protocol versions 2025-06-18, 2025-03-26, and 2025-11-25. Per its official positioning, it's complementary to AgentCore Registry (discovery and governance) — the Gateway handles execution and federation, the Registry handles discovery.

agentic-community/mcp-gateway-registry — open source that bundles Gateway, Registry, an A2A hub, and audit into one box, self-hosted via Docker Compose. A unified gateway over multiple MCP servers, plus a registration/discovery/governance registry, plus an agent-to-agent communication hub. Auth runs through OAuth providers like Keycloak and Entra; audit trails are scoped per individual agent; metrics take a dual path of SQLite (detailed history) plus OTEL export (Prometheus, CloudWatch, Datadog); and there are three storage backends for servers, agents, and scopes.

Axis AgentCore Gateway — vendor-outsourced mcp-gateway-registry — self-hosted
Routing plane ownership AWS-managed endpoint Your own infra (Docker Compose)
Auth IAM SigV4 / Cognito·BYO OAuth + per-tool Secure Credential Exchange Keycloak·Entra OAuth, per-agent scopes
Composition unit API·Lambda·MCP server → single MCP endpoint Multiple MCP servers → unified gateway
Audit CloudTrail family (AWS plane) SQLite + OTEL → Prometheus·CloudWatch·Datadog
Protocol version Vendor decides (2025-06-18 / 2025-03-26 / 2025-11-25) Operator decides
Discovery·governance Split into a separate product (AgentCore Registry) Bundled with Gateway in one box

Same job, opposite plane

Both solve the routing side of agent sprawl — folding scattered MCP servers behind a single entry point and layering on auth and audit. The difference isn't the feature list; it's the ownership of the routing plane. AgentCore outsources translation, composition, and credentials to the AWS plane: the operational burden disappears, but control over auth, protocol versions, and target definitions goes with it. mcp-gateway-registry is the inverse: you keep control, but you operate the gateway, registry, and audit infrastructure yourself.

Picking one side is easy. The hard part is when an organization that already runs a self-hosted gateway adds a vendor gateway — that is, when both exist at once.

Synthesis

The MCP index concluded that "the remaining problem is operations," and the governance index split that operations question into four axes. The lesson of the routing axis is sharper than the rest: the gateway absorbs governance.

The very fact that mcp-gateway-registry bundles Gateway, Registry, A2A, and audit into one box is the signal. Whoever owns the routing plane ends up holding discovery, auth, and audit too — so the index's four axes effectively converge into a single axis on top of the Gateway plane. That's why "keep both" isn't a stable state but a deferred decision — both planes lay claim to all four axes at once.

Next quarter's decision narrows to one thing: which side gets the routing plane, and whether you demote the other to a mirror. Same conclusion as AWS Agent Registry — defer the decision and the next governance layer to arrive makes it for you. The difference is that on the Gateway axis, that enforcement comes quietly, and sooner, as auth and protocol-version mismatches.

References

Same topic