Do you need an MCP gateway as well?

You need MCP-aware controls when agents share tools whose discovery, execution permissions or upstream credentials must be governed centrally. An LLM gateway that routes model calls does not, by itself, govern those tool calls. One product can perform both roles, but each traffic path needs its own tested policy.

For platform teams connecting agents to remote tools. The examples cover Kong AI Gateway 2.0 and agentgateway standalone documentation; they do not establish feature parity across their editions. Primary documentation reviewed 18 September 2026. Vendor capabilities below are documented, not independently benchmarked. The evaluation procedures are GatewayScore recommendations.

Separate the model path from the tool path

A model proposes an action; an application or agent runtime executes it. That creates two different authorization decisions. The model request may be allowed while the proposed tool action is forbidden. Draw the actual connections before choosing another service: agent to model gateway to inference provider, and agent to MCP gateway to tool server to business system.

A gateway only controls traffic that passes through it. A local shell tool, a direct database connection or an MCP server contacted outside the governed route needs controls at that execution boundary. Adding an MCP endpoint does not contain an agent that still holds broad credentials elsewhere. Start by inventorying those bypass paths, not by counting supported tool integrations.

What current products document

Kong’s 1 September 2026 GA announcement describes MCP server bundling with caller-specific discovery and execution controls through its MCP ACL integration. This is evidence for that release’s advertised capability, not proof that an existing Kong installation has the relevant plugins enabled. Kong AI Gateway 2.0 release.

Agentgateway’s standalone MCP authorization documentation describes policies evaluated for MCP method invocations and filtering of disallowed tools from list responses. Route- and backend-level attachment have different scopes. Record the version and policy attachment used in your deployment; do not transplant examples between standalone and Kubernetes configuration without checking them. Agentgateway MCP authorization.

Preserve the identity and authority of each hop

Write down three principals separately: the human requesting work, the running agent or workload, and the credential used by the upstream business system. The same individual may initiate several workloads, and an unattended workload may have no active human session. A useful audit trail records those distinctions rather than assigning every action to one shared integration account.

For HTTP-based MCP, the authorization specification defines an OAuth-based framework and resource-specific token handling. The security guidance rejects token passthrough and warns against treating a session identifier as authentication. An authenticated MCP connection therefore should not be taken as permission to forward an arbitrary token to every downstream API. MCP authorization specification; MCP security guidance.

As an implementation review, ask where resource-level decisions happen. “Can invoke invoice_lookup” is narrower than “can read invoices for any tenant.” Require the tool server or business API to enforce object scope as well. Keep secret values out of traces; use stable credential identifiers to join the records.

When an additional gateway is worth operating

Centralization introduces an operational dependency. Assign ownership for policy review, credential rotation, availability and emergency revocation. Decide which tools remain available if the policy service is unavailable. Treat this as an explicit requirement and a failure test; missing vendor documentation is not evidence of either fail-open or fail-closed behavior.

Run a two-user, two-tool acceptance test

1. Create two test callers with different tool permissions and two harmless tools: one available to both, one restricted. Use a non-production tenant.
2. Compare discovery responses, then attempt the restricted tool by name with the unauthorized caller. Passing the discovery test alone is insufficient.
3. Request an object owned by a different tenant through an otherwise allowed tool. Verify the business system rejects it.
4. Revoke the caller or its grant, then repeat on an existing session and a new session. Record the actual delay until access stops.
5. Simulate an unavailable identity or policy dependency. Confirm the observed outcome matches the documented operating policy.
6. Trace one allowed and one rejected action across gateway and upstream logs. Verify caller identity, decision, tool target and request correlation without logging credentials.

Save the configuration revision, exact client/server versions, expected outcomes and observed results. A test that has not been executed stays marked “not tested.” For consequential write tools, add approval and duplicate-execution tests before expanding the rollout.

Use the right neighboring guide

If your immediate problem is deciding where gateways fit, start with what an LLM gateway does. For controls over unsafe content, read how gateway guardrails fail; content filtering and tool authorization answer different questions. Compare sourced product details for agentgateway before selecting a deployment.

Evidence and maintenance

Review this guide when the MCP authorization specification changes, gateway policy attachment changes, or a tool gains write capabilities. Repeat the access matrix after changes to identity mapping or upstream credentials.

This guide uses the selected sources cited above, not a census or ranking of every gateway. Undocumented behavior remains unknown. Review the exact product edition, deployment and configuration before relying on a control.