A proxy JWT is only meaningful inside the local control plane, while a real MCP access token is accepted by the remote resource server. Keeping those two credentials separate lets the system authenticate the workload without letting the agent hold a portable credential that can be replayed elsewhere.
Why a proxy JWT is not the same thing as a usable MCP access token
A proxy JWT is a local credential representation used inside the control plane to identify or route work, while the MCP access token is the credential the resource server actually accepts. That separation matters because a token that is only valid locally should not be able to cross trust boundaries and act as a portable bearer credential.
The design choice is less about naming and more about authority. If a token can be replayed against the remote endpoint, it behaves like an access token; if it only helps the proxy make a local decision, it is part of the internal mediation layer and should not be treated as a directly reusable secret.
In practice, this distinction keeps workload authentication and downstream authorization from collapsing into one credential. The proxy can validate context, apply policy, and exchange or forward only what the resource server is meant to see, instead of handing the agent a token that can outlive the session or be reused outside the intended path.
What changes in the trust model and token handling
The trust boundary shifts from “the agent holds a credential” to “the proxy vouches for the agent under controlled rules.” That usually means shorter-lived internal assertions, tighter audience restrictions, and explicit token exchange or passthrough rules rather than opaque reuse of the same artifact everywhere.
Guide to SPIFFE and SPIRE is useful here because it frames how workloads can be authenticated without turning every internal assertion into a broadly replayable credential. The same pattern appears when teams separate workload identity from external access tokens and keep each artifact bound to its proper trust domain.
Token and Session Security Guide reinforces the operational side of that split: validation, lifetime, revocation, and replay resistance are different concerns depending on whether the token is local-state only or accepted by a remote server.
That is also why audience and resource binding matter. A local proxy token can be intentionally narrow, whereas a real MCP access token should be accepted only by the intended resource server and only for the intended scope.
How to tell which credential belongs where
Ask one practical question: where will this credential be honored? If it is only meaningful to the local proxy, it should not be accepted by the remote MCP server. If the remote server will honor it, it needs the controls expected of a real access token, including explicit scope, expiry, and validation rules.
Model Context Protocol: Authorization specification matters because it describes MCP servers as OAuth 2.1 resource servers and emphasizes audience-bound tokens rather than token passthrough. That is the cleanest way to preserve the boundary between local mediation and remote authority.
RFC 6749: The OAuth 2.0 Authorization Framework provides the base model for access tokens as presentation credentials to a protected resource, which is the right mental model for the remote MCP token side of the comparison.
RFC 8707: Resource Indicators for OAuth 2.0 is relevant when the system needs the token to be bound to a specific audience, because that prevents a credential issued for one resource from being reused against another.
Risk and Threat Considerations
The main risk is accidental credential portability. If the proxy JWT is treated like a real access token, a local assertion can escape its intended boundary, and an agent or intermediary can replay it against a server that should never have accepted it.
Failure mechanism: Poor separation between proxy assertions and server-accepted tokens creates bearer-token reuse, audience confusion, and a larger replay surface, especially when logs, traces, or agent memory expose the artifact.
Impact: An attacker or compromised agent can pivot from local mediation to remote resource access, bypass intended control points, and reuse the same credential beyond the session or trust domain where it was issued.
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 surface, NIST SP 800-53 Rev 5 sets the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API2 — Broken Authentication | Token confusion can let the wrong credential be accepted by the resource server. |
| Recommendation — Enforce audience-bound access tokens and reject proxy-only assertions at the API boundary. | ||
| NIST SP 800-53 Rev 5 | IA-9 — Identification and Authentication (Service Organizations) | The question concerns machine-to-machine authentication and token acceptance by a remote service. |
| IA-5 — Authenticator Management | Token lifetime, validation, and revocation are central to distinguishing proxy JWTs from real access tokens. | |
| Recommendation — Use service authentication controls to keep internal assertions separate from accepted access tokens. Manage token issuance, expiry, storage, and revocation so local assertions cannot be replayed. | ||
| ISO/IEC 27001:2022 | A.5.16 — Identity management | The answer depends on governing which credential represents authority at each trust boundary. |
| A.8.5 — Secure authentication | Remote acceptance of the credential depends on secure token validation and binding. | |
| Recommendation — Define which credential type is authoritative at each boundary and prevent role confusion. Require secure authentication checks that distinguish proxy assertions from reusable access tokens. | ||
Practitioner Guidance
What to verify: Confirm that the proxy JWT is rejected by the remote MCP server and that only the real MCP access token is accepted there. The acceptance test should prove audience binding, expiry enforcement, and replay resistance, not just successful login.
Decision rule: If a credential can be replayed outside the proxy boundary, treat it as a real access token and apply the full token lifecycle, scope, and revocation discipline. If it cannot, keep it as an internal assertion and avoid exposing it to the agent or downstream logs.
Practitioner takeaway: The safest design is not “one token everywhere,” it is “one artifact for local mediation, one artifact for remote authority,” with a hard control boundary between them.
Related resources from NHI Mgmt Group
- What is the difference between OAuth Token Exchange and AuthZEN in delegated MCP access?
- What is the difference between access token abuse and refresh token abuse?
- What is the difference between MCP access and ordinary app integration?
- What is the difference between stored credentials and OAuth-based MCP access?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 10, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org