An agent gateway is the data plane of enterprise agent infrastructure: the inline component that every agent invocation passes through, where authentication is verified, RBAC is enforced, the call is routed, rate limits and circuit breakers fire, and an observability record is written for the audit trail. It is the only point in the stack where you can answer the runtime question — should this particular invocation actually happen right now? — with the version, policy, and identity context of the moment.
The gateway pairs with the agent registry on the catalog-plane side, and frequently with an MCP gateway when the agents being governed are MCP servers. The three are not interchangeable. The registry tells you what exists. The gateway enforces what runs. The MCP gateway is the protocol-specific flavor of the agent gateway when MCP is the wire.
What an agent gateway has to enforce
A serviceable agent gateway enforces five things at every invocation. Anything less is a reverse proxy with extra logging.
- 01
Authentication
OAuth 2.1 with PKCE, RFC 8707 resource indicators (mandatory in MCP since March 15, 2026), and on-behalf-of token exchange so the downstream agent runs under the calling user's identity, not a shared service account.
- 02
Authorization
RBAC referencing IdP groups, evaluated against the access policy the registry currently advertises for the called agent. Not the policy from the last sync — the current one.
- 03
Routing
Pick the right backend version of the agent (active vs deprecated vs canary), with the routing decision logged so audit can answer "which version of agent X served this call."
- 04
Rate limiting and circuit breakers
Per-user, per-agent, per-tool quotas, with circuit breakers that trip when downstream MCP servers degrade. Without this, an autonomous agent in a loop will quietly bankrupt the budget.
- 05
Observability
A structured record per tool call: identity, agent version, MCP tool name, inputs, expanded results, success/failure, and the policy version that authorized the call. Not raw HTTP logs.
Gateway vs registry: where the line sits
The cleanest framing we have found for procurement conversations: the registry is the catalog plane (out of the call path, source of record), and the gateway is the data plane (in the call path, enforcement point). Both are required for governed agent infrastructure. Neither is a substitute for the other.
The two must share state — schema, policy objects, version reference — or the gateway becomes either over-permissive (enforcing a stale schema that is now broader than the current one) or under-permissive (refusing a call that the registry approved last week). We work through the three concrete failure modes, and the two diagnostic questions that catch them, in Agent Registry vs. Agent Gateway: Two Roles, One Control Plane.
How an agent gateway differs from a standard API gateway
An API gateway terminates TLS, authenticates the call, and forwards. An agent gateway has to do four extra things that no Kong / Apigee / AWS API Gateway configuration will handle natively.
- It speaks MCP and A2A natively. The wire is JSON-RPC 2.0 with tool definitions and structured results, not REST or GraphQL. Authorization is at the per-tool level, not per-endpoint.
- It propagates identity through tool calls. When the language-model orchestrator invokes an MCP tool that itself calls another MCP tool, the on-behalf-of identity has to follow. Standard API gateways drop this on the second hop.
- It records semantics, not bytes. The observability record is the resolved tool name, the resolved arguments, the resolved result — not the raw JSON-RPC frame. Compliance auditors do not want to read JSON-RPC.
- It enforces against a versioned schema. The agent's capability surface changes with each version; the gateway has to enforce against the version the registry currently advertises, not the one frozen into the gateway config six months ago.
Five questions for an agent gateway vendor
If you are running a gateway evaluation, these five questions are the floor. Vendors that hedge on any of them are not yet enterprise-ready, regardless of what the deck says.
- 01
Revocation timing
If you revoke a user's access in the registry now, how long until the gateway stops authorizing their invocations? Real-time or first-call. Anything else is a security gap.
- 02
Deprecation timing
If you deprecate an agent version in the registry now, how long until the gateway stops routing to it? Same answer. Sync-interval propagation is the wrong shape.
- 03
Audit granularity
Does the per-call record name the specific MCP tool invoked (apply_compile, run_diff, etc.) or just the agent? Tool-level granularity is what compliance asks for.
- 04
Policy snapshot
Does the audit record include the policy configuration in effect at the moment of the call, not just a policy ID? IDs mutate; snapshots do not.
- 05
Multi-provider reach
Can it gateway across AWS AgentCore, Azure AI Foundry, Cloudflare MCP Server Portals, and self-hosted MCP servers — or does each provider need its own gateway, with reconciliation by hand?
Jarvis Registry as a unified gateway
Jarvis Registry is the gateway and the registry at the same time. The catalog plane and the data plane share the schema, the policy objects, and the version reference. Deprecation in the catalog takes effect in the gateway on the next call, not the next sync. Each per-call audit record names the registry version and policy snapshot in effect at the moment of the call. RBAC consumes IdP groups directly through SAML / OIDC; there is no parallel role system to drift from.
The product registers as the unified MCP endpoint that Jarvis Chat, Claude Desktop, Claude Code, VS Code, Cursor, GitHub Copilot, Microsoft Copilot, Windsurf, and ChatGPT all connect to. From the client's perspective there is one MCP server. Behind it, Jarvis Registry is gatewaying invocations across AgentCore, Azure AI Foundry, and self-hosted servers — with one audit trail, one policy surface, one version of the truth.