An LLM proxy can still route model calls while leaving tool authorisation, identity resolution, and audit evidence outside the control plane. That creates a gap where teams may think requests are governed even though the platform cannot prove who invoked a tool, what credentials were used, or how far the request could reach.
Why an LLM proxy leaves governed MCP access incomplete
The break is architectural, not cosmetic: the proxy can govern prompt flow while MCP tool authority still lives somewhere else. If the control plane only sees the model request, it cannot reliably bind a specific user, workload, or delegation path to the tool call that follows. That weakens governance even when the chat surface looks controlled.
In practice, this is where teams confuse “the LLM is fronted by a proxy” with “the whole action path is governed.” The proxy may filter messages, enforce rate limits, or log prompt metadata, but governed tool access also needs identity resolution, scoped authorisation, and auditable token handling at the MCP boundary itself.
That distinction matters because MCP is designed around explicit authorisation semantics, including audience-bound access and rejection of token passthrough. When the proxy sits in front of that model without participating in the same trust and authorisation model, it becomes a parallel path rather than the governance point.
For the MCP authorisation model, see MCP authorization specification, which is the part most likely to break if the proxy is treated as the full control plane.
What gets lost: identity, delegation, and tool-scoped evidence
The first loss is identity continuity. A proxy may authenticate the caller to the model endpoint, but that does not automatically prove who authorised the downstream tool invocation, or whether the tool acted on behalf of the end user, the application, or an intermediate service identity. In governed environments, that distinction is central to access review and accountability.
The second loss is delegation fidelity. Tool access often depends on constrained tokens, resource indicators, or explicit exchange flows that narrow what the caller can do. If the proxy substitutes its own credentials, reuses a broad token, or forwards opaque requests without preserving audience and actor context, the downstream service may grant more than intended or lose the ability to distinguish delegated access from direct access.
The third loss is evidence quality. A useful audit trail should show which identity requested the tool, which credential or assertion was used, which resource was targeted, and what scope applied. If those facts are not available at the proxy, or are not propagated into the MCP server and tool logs, teams may have logs of “a model request” but no defensible proof of governed tool use.
That is why the proxy should not be treated as a substitute for OAuth 2.0 token exchange or other delegation-aware flows that preserve who is acting and for what target.
Why this shows up as a control-plane gap, not just a logging gap
This pattern usually fails in three places at once: authorisation, reachability, and attribution. The platform may still enforce model access, but the tool layer can remain reachable through credentials the proxy never inspects. That means the real control boundary is not where the team thinks it is.
It also creates false confidence during reviews. A proxy dashboard can show allowed prompts, blocked prompts, and usage volume while leaving the higher-risk question unanswered: could this actor reach this tool with this scope? Without binding tool calls to target-specific access tokens and logged identity context, governance becomes an inference exercise rather than a verified control.
That is why the relevant standard is not “did the request pass through a proxy?” but “can we prove the downstream action was authorised, bounded, and attributable?” If the answer is no, the proxy is only a filtering layer, not governed MCP access.
The broader machine-to-machine trust model is captured in RFC 8707: Resource Indicators for OAuth 2.0, which is directly relevant when a tool call must be scoped to a specific resource rather than a generic bearer capability.
Risk and Threat Considerations
When the proxy is mistaken for the control plane, the main risk is over-privilege with weak attribution. An attacker, or even an over-broad internal workflow, can potentially reach tools that were never meant to be exposed through the proxy’s visible policy layer, especially if the proxy forwards broad credentials or hides the true actor.
Failure mechanism: The proxy governs the front door, but downstream tool authorisation still depends on separate credentials, token exchange, or server-side checks that are not visible in the proxy policy path. That split lets requests appear compliant while the actual tool action is unaudited or insufficiently scoped.
Impact: Teams can lose containment, accountability, and forensic confidence at the exact point where mcp tool access becomes operationally meaningful. In a compromise, the attacker may gain tool reach without a clean record of who invoked the action, which credential was used, or what resource boundary was enforced.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5, NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API2 — Broken Authentication | LLM proxy gaps can hide or weaken authentication to tool endpoints. |
| Recommendation — Bind tool calls to authenticated principals and reject requests without verifiable downstream identity. | ||
| NIST SP 800-53 Rev 5 | IA-9 — Service Identification and Authentication | MCP tool access often relies on service-to-service identity beyond the proxy. |
| AU-2 — Event Logging | Governed tool use needs evidence of actor, credential, and target at the action boundary. | |
| AC-6 — Least Privilege | Proxy-only governance can leave downstream tools reachable with excess scope. | |
| Recommendation — Authenticate each tool-facing service interaction with distinct machine credentials. Log downstream tool calls with actor, scope, and resource context. Constrain tool credentials and scopes to the minimum required for each action. | ||
| NIST CSF 2.0 | PR.AA-05 — Managed Access Control | The question is about enforcing access at the actual MCP tool boundary. |
| Recommendation — Enforce access decisions where tools are invoked, not only at the proxy. | ||
| NIST Zero Trust (SP 800-207) | SC-2 — Device Authentication | The proxy does not replace strong identity validation for calling services. |
| Recommendation — Validate each calling component before granting access to downstream resources. | ||
Practitioner Guidance
What to prioritise: Treat the MCP server and its authorisation layer as first-class governance points. If the proxy cannot bind the end user or workload to the downstream tool call, do not assume tool access is governed just because model traffic is proxied.
What to verify: Check that every tool invocation can be traced to a specific identity, a specific delegated credential, and a specific target resource. If the only durable evidence is proxy-level prompt metadata, the governance story is incomplete.
Decision rule: If the proxy cannot preserve actor, audience, and scope through to the tool boundary, use it only as an ingress control and move authorisation enforcement closer to the MCP server or resource server.
Practitioner takeaway: Governed MCP access is proven at the tool boundary, not at the LLM proxy, so the control design must preserve identity, delegation, and auditability end to end.