MCP Gateway vs API Gateway: What Enterprise Agents Actually Need

Reviewed 11 August 2026 · 13 minute read

An API gateway and an MCP gateway are not interchangeable. An API gateway controls network requests to services. An enterprise MCP gateway must also understand agent tool calls, bind the exact arguments to delegated authority, check current mandate and revocation state, prevent replay, filter tool results and produce evidence for the action. The strongest architecture composes them: keep mature traffic controls, then add an agent-aware authorization layer.

This article is for platform and security engineers deciding whether an existing gateway can safely front consequential MCP tools. The outcome is a concrete division of responsibilities and a test fixture you can run against either design.

For the broader category and deployment choices, use the AI agent authorization guide. For the MCP-specific authority model behind this comparison, read MCP authorization for enterprise tools.

MCP gateway vs API gateway in one table

An API gateway can enforce many controls an MCP deployment needs. The difference is the object being authorized.

The table does not imply that every product marketed as an MCP gateway implements the right-hand column. "MCP-aware" may mean protocol translation or tool discovery. Ask what the gateway verifies at execution time.

API gateways still own important controls

Do not rebuild TLS termination, routing, connection limits, request-size enforcement, rate limiting, WAF integration and service observability inside an agent product. Existing gateways are good at these jobs.

Envoy's external authorization filter, for example, can send request context to an HTTP or gRPC authorization service and deny the request before it reaches the upstream. Its default failure_mode_allow is false, and the documentation warns that route-cache changes after authorization can create a bypass. Envoy's ext_authz documentation is a useful model for placing an agent authorizer in the traffic path without pretending the filter itself understands mandates.

An API gateway can also validate OAuth access tokens. MCP's authorization specification uses OAuth conventions and requires resource or audience binding so a token issued for one MCP server is not accepted by another. The MCP authorization specification covers discovery and token validation. This authenticates access to the MCP resource server. It does not prove that the agent may refund order 8421 for EUR 480.

MCP changes the policy subject

A conventional route policy might say:

principal.role == "support" && route == POST /refunds

An agent transaction needs more context:

type AgentTransaction = {
  agentId: string;
  organisationId: string;
  sponsor: string;
  mandateId: string;
  action: 'refund.create';
  resource: `order:${string}`;
  purpose: string;
  amount: string;
  currency: string;
  destination: 'original_payment_method';
  audience: string;
  requestDigest: `sha256:${string}`;
  nonce: string;
};

The policy subject is not merely the OAuth client. It is the agent under a specific delegation from an accountable organization. The gateway must derive tenant and agent identity from verified credentials, not caller-selected headers.

MCP tools are model-controlled operations with schemas. The official tools specification requires servers to validate inputs and implement access controls, and it tells clients to treat tool annotations as untrusted unless they come from trusted servers. MCP tools defines the wire objects, not the enterprise's business-authority semantics.

Bind the tool call through every transformation

Most MCP servers eventually call an HTTP, gRPC or queue-based backend. An authorization decision over the MCP arguments can become irrelevant if the translation changes their meaning.

Use a canonical digest over the tool call:

const normalized = canonicalJson({
  tool: 'issue_refund',
  arguments: {
    order_id: 'ord_8421',
    amount: '480.00',
    currency: 'EUR',
    destination: 'original_payment_method',
  },
  audience: 'mcp://support.example/tools',
});

const requestDigest = sha256(normalized);

At the final refund service, compare the protected fields with the signed transaction. If MCP middleware authorized EUR 48 but the adapter sends EUR 480, deny before execution.

This means the gateway needs an explicit mapping from tool schema to stable action and resource identifiers:

tools:
  issue_refund:
    action: refund.create
    resource: 'order:{arguments.order_id}'
    protected_arguments:
      - amount
      - currency
      - destination
      - reason
    max_body_bytes: 16384

Treat this as illustrative configuration. A production mapper must reject unknown arguments, ambiguous number formats and schema versions it does not understand.

Authorization order matters

The agent-aware layer should use a deterministic verification order:

1. Enforce transport and object size limits.
2. Parse MCP JSON-RPC and validate the tool's input schema.
3. Authenticate the runtime token or proof and pin tenant and audience.
4. Resolve issuer, key, Passport and current revocation state.
5. Verify the Mandate signature, time window and subject.
6. Canonicalize the call and compare the request digest.
7. Claim the proof nonce in a shared replay store.
8. Evaluate action, resource, purpose, destination and budget.
9. Atomically reserve one-time or cumulative mandate usage.
10. Execute with a downstream-specific credential.
11. Filter the result and emit an action receipt.

An ordinary API policy can perform steps 1 through 3 and route step 8 to an external authorizer. It does not acquire the remaining semantics merely because the upstream speaks MCP.

Replay and retry are separate problems

A proof nonce stops the same signed proof from being accepted twice. An idempotency key stops an intentionally retried business action from executing twice. Keep both.

const replayKey = `${verificationMethod}\0${audience}\0${proofNonce}`;
const claimed = await replayStore.claimOnce(replayKey, proofExpiresAt);
if (!claimed) return deny('REPLAY_DETECTED');

const operation = await idempotencyStore.getOrCreate({
  tenantId,
  key: businessIdempotencyKey,
  requestDigest,
});
if (operation.digestConflict) return deny('IDEMPOTENCY_CONFLICT');

If the replay store is unavailable, material actions should fail closed. Low-risk reads may have an explicitly different policy. A generic gateway setting that allows all requests when authorization is unavailable is too broad for irreversible tools.

Revocation must reach the data plane

Token expiry is not enough. An enterprise may revoke an agent key, Passport, Mandate or parent mandate before its natural expiry. The enforcement layer needs authenticated status with a bounded freshness policy.

Cache by target ID and record observed_at. A cached "active" result is not permanent. For a refund or payment, reject when revocation state is older than the action policy allows. For a public catalog read, a longer window may be reasonable.

The customer data plane should continue evaluating signed local policy during a control-plane outage, but only while its trust inputs remain valid. This is a product requirement, not a reason to call a reference integration highly available.

Evidence goes beyond an access log

An API access log might show a 200 for tools/call. An action receipt can bind the agent, organization, mandate, request digest, policy decision, tool result digest and downstream reference.

That receipt proves what its issuer signed and recorded. It does not prove the customer deserved the refund or that the payment processor told the truth. Reconciliation and retention remain separate operational systems.

For a complete transaction walkthrough, see from MCP tool call to auditable enterprise transaction. For log and receipt differences, see the AI agent audit-trail guide.

Reproducible gateway evaluation

Run the same fixture against the API-only path and the agent-aware path:

{
  "tool": "issue_refund",
  "arguments": {
    "order_id": "ord_8421",
    "amount": "480.00",
    "currency": "EUR",
    "destination": "original_payment_method"
  },
  "expected_action": "refund.create",
  "expected_resource": "order:ord_8421"
}

Mutate one field per test:

Capture decision codes, upstream-call counts and receipts. A passing test means denied variants never reach the backend and the valid idempotent retry creates one business operation.

Current Intelliger and OATI boundary

OATI currently provides a developer-preview framework with schemas, canonical signing, trust resolution, deterministic Mandate evaluation, replay checks, receipts and TypeScript middleware. The public repository includes a reference Envoy, authorizer, Valkey and lookup integration test.

That is not a fully operated customer gateway fleet. Production outage drills, prolonged concurrency testing, durable evidence workflows and independent cryptographic and protocol review remain incomplete. The broader Enterprise Agent Gateway product, policy editor, approval queue and managed lifecycle are target or MVP components, not shipped production claims.

Intelliger builds AI systems that can safely perform consequential enterprise work. The Agent Trust architecture explains how the Enterprise Agent Gateway and OATI fit that company-level definition.

Implementation checklist

• Keep the API gateway for transport, routing and network policy.
• Add an MCP-aware normalizer for tool, action, resource and arguments.
• Derive agent and tenant identity from verified credentials.
• Bind canonical tool arguments through the final execution request.
• Evaluate short-lived delegated authority in deterministic code.
• Separate proof replay from business idempotency.
• Propagate revocation with action-specific freshness limits.
• Reserve one-time and budget state atomically.
• Filter tool outputs under destination and data policy.
• Emit verifiable evidence without storing secrets in receipts.
• Test bypass, mutation, replay, outage and uncertain execution.

Expert review required before publication: a security and MCP protocol reviewer should verify the authorization order, OAuth audience handling, route-bypass analysis, replay semantics and all production-readiness claims.

Ready to test the boundary? Start with the OATI developer documentation and verifier before selecting a managed gateway design.