The gateway may allow passthrough for requests that were never meant to be trusted locally, especially when the target server is not actually configured for OAuth2. That can let arbitrary callers reach connected MCP servers through routes such as `/mcp/{server}` or `/{server}/mcp`. The practical outcome is unauthorized access to the downstream services the gateway was meant to broker.
Why the auth-mode check is the trust boundary, not a detail
When a gateway exposes MCP routes, it is not just forwarding traffic. It is asserting that the upstream caller is entitled to reach the downstream server. If LiteLLM does not verify whether the target mcp server expects OAuth2, it can create a false sense of trust around routes that should have been treated as untrusted passthrough. That matters because the gateway becomes an access broker for the connected service, not merely a transport layer. For agentic and integration-heavy deployments, this is exactly where trust boundary mistakes turn into unintended reach.
From an architecture perspective, the issue is not limited to one route shape. Whether the exposure is through OWASP Top 10 for Agentic Applications 2026 style tool exposure or a broader proxy pattern, the core failure is the same: the broker assumes an authentication mode that the downstream server does not actually enforce. In practice, many security teams encounter this only after a supposedly internal integration is reachable by callers that should never have been able to touch the brokered service.
How the routing failure turns into downstream access
A safe MCP gateway has to treat authentication mode as a routing precondition. If the target server is configured for OAuth2, the gateway can enforce the expected handshake and only pass requests that satisfy that mode. If the server is not using OAuth2, the gateway should not silently “help” by exposing the same route anyway, because that changes the trust model from authenticated brokering to unaudited forwarding. The vulnerability emerges when the gateway equates “route exists” with “route is safe to expose.”
In practice, the failure often appears in one of three ways. First, the gateway makes both /mcp/{server} and /{server}/mcp available even though the downstream server was never intended to be directly callable. Second, the gateway does not distinguish between local access policy and the server’s real auth mode, so callers inherit access they should not have. Third, operators assume the gateway is enforcing the same authentication semantics as the server, when it is only relaying requests. That is an authorization design problem, not just a configuration typo.
The security consequence is broader than simple “bypass.” Once the gateway exposes the route, the brokered server becomes reachable through the gateway’s trust path, which can surface data, actions, or tool calls that were meant to stay behind an authenticated boundary. This is especially relevant for MCP deployments that connect into internal services, because the exposed surface is often more valuable than the gateway itself. NIST’s AI risk guidance is useful here because it emphasizes managing model and system integration risks as part of the full AI application lifecycle, not as isolated component checks. Where the gateway sits between the caller and the tool server, its job is to verify the access model before it publishes the route. When it does not, the downstream service inherits the weakest caller that can reach the broker.
Where this breaks down, and why the edge cases matter
Tighter gateway enforcement often increases setup friction, because the operator must keep route exposure aligned with the downstream server’s actual auth mode rather than with a default proxy pattern. That tradeoff is worth it, because the alternative is a route that looks controlled but behaves like an open bridge.
One edge case is a mixed environment where some MCP servers use OAuth2 and others use a different or weaker access pattern. In that situation, the correct response is not to normalise all servers into one route policy. It is to preserve the distinction and make the gateway fail closed when the auth mode is unknown, inconsistent, or not explicitly supported. Another edge case is an internal-only deployment. “Internal” does not remove the risk if the gateway itself is reachable by other systems, automation, or tenants. The trust boundary still exists, and the route still needs an explicit decision.
Guidance versus consensus matters here: the industry has not fully converged on one universal MCP exposure model, especially for agentic tool routing. What is clear is that a broker must not infer trust from route presence alone. If the gateway cannot confirm the target server’s auth mode, the safe default is to withhold the route rather than expose a passthrough path that may grant unintended access.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, CIS Controls v8 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A2 — Tool and Connector Security | MCP route exposure is an agentic tool-access control problem. |
| Recommendation — Enforce explicit trust checks before exposing any tool or connector route. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Inventory and Ownership of Non-Human Identities | MCP servers and their auth modes are machine-accessed trust endpoints. |
| Recommendation — Inventory each MCP server and verify its authentication model before brokering access. | ||
| NIST CSF 2.0 | PR.AC-4 — Access Permissions | The gateway must enforce access permissions consistently at the trust boundary. |
| Recommendation — Apply least-privilege access rules before publishing brokered routes. | ||
| CIS Controls v8 | 6.3 — Access Control Management | Misaligned route exposure is an access-control governance failure. |
| Recommendation — Validate and revoke exposed access paths that do not match the target server’s auth mode. | ||
| NIST AI RMF | GOV-4 — Map, Measure, and Manage AI Risks | Agentic routing requires managing integration risk across the full AI system. |
| Recommendation — Assess tool-routing trust assumptions as part of the AI system risk profile. | ||
Practitioner Guidance
What to verify: Confirm that route publication is conditional on the downstream server’s declared auth mode, not on a generic service registry entry. If the gateway cannot prove the server’s expected authentication pattern, treat that as a release blocker rather than an acceptable warning.
Decision rule: Expose MCP routes only when the broker can enforce the same access assumptions the server expects; if the server is not using the supported auth mode, deny exposure by default. That rule is more important than convenience because it prevents the gateway from becoming an implicit privilege amplifier.
Practitioner takeaway: The key judgement is to treat auth-mode verification as part of authorization, not as metadata validation. If the gateway cannot align route exposure with the downstream server’s real trust model, the safest outcome is no route.
Related resources from NHI Mgmt Group
- Who should be accountable when a federated MCP registry exposes the wrong server or auth metadata?
- What happens when filesystem access is attempted without proper symlink handling in an MCP server?
- What happens when an MCP server is connected to an AI client without tight command and data controls?
- What breaks when MCP runs behind gateways without defined auth propagation?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 7, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
