Client-held tokens can be reused directly against the underlying service, while brokered tokens stay inside the control plane and are exchanged internally for downstream use. The first model gives the client a usable credential; the second keeps custody and enforcement with the mediator.
Why client-held and brokered tokens are different in MCP
The difference is custody and where enforcement lives. A client-held token is a reusable credential the client can present directly to the downstream service, so the token itself becomes part of the client’s trust boundary. A brokered token stays inside the mediator’s control plane, which can shape when, how, and to whom downstream access is issued.
That distinction matters because it changes who can replay, scope, observe, revoke, and audit the credential. In a client-held model, the client has more direct operational control but also more exposure if the token leaks or is overbroad. In a brokered model, the mediator keeps tighter control over delegation and can reduce the blast radius of a compromised client workflow.
The key question for practitioners is not simply “who holds the token,” but “where is authority enforced.” If the client can reuse the token outside the intended path, the model behaves more like bearer credential distribution. If the control plane exchanges tokens internally and issues only downstream-specific credentials, the design supports stronger mediation and narrower use.
What changes operationally when tokens are held by the client versus the broker
Client-held tokens are simpler to reason about at the integration layer because the caller presents a usable credential directly to the service. That simplicity can help in thin-client or direct API workflows, but it also makes token lifetime, audience restriction, and storage hygiene much more important. Brokered tokens add an extra hop, but that hop is where policy, audience binding, and delegation decisions can be applied before anything reaches the downstream system.
In practice, the brokered model is better when the control plane must mediate access across multiple tools, services, or agents, because it can prevent a client from carrying an all-purpose credential across contexts. The client-held model is better when the downstream service itself is the intended trust boundary and the token is intentionally meant to be presented as-is. The trade-off is architectural: direct usability versus centralized enforcement.
That is why MCP authorization guidance emphasizes resource-bound tokens and no token passthrough in the control plane. Model Context Protocol: Authorization specification describes the brokered approach as an OAuth-based mediation pattern, while bearer-style passthrough behaves more like client-held credential reuse.
For deeper context on the protocol and its security patterns, MCP Security Guide ties the token model to practical authorization, audience restriction, and gateway controls.
Why the token model changes risk, delegation, and auditability
Client-held tokens expand the places a credential can be copied, cached, or reused, which increases replay and leakage exposure. Brokered tokens reduce that exposure by keeping the higher-value credential inside the mediator and issuing downstream access only when needed. That improves revocation leverage and makes it easier to enforce least privilege at the point of delegation.
RFC 8707: Resource Indicators for OAuth 2.0 is relevant because audience restriction is one of the main ways to keep a token from becoming broadly reusable. When a broker issues or exchanges tokens with a narrow audience, stolen credentials are less likely to work outside the intended resource. RFC 9449: OAuth 2.0 Demonstrating Proof of Possession (DPoP) adds another layer by binding a token to the presenter, which is especially useful when a direct client-held credential would otherwise be easy to replay.
Brokered designs also make auditability more meaningful because the control plane can log the delegation decision separately from the downstream use. That creates a clearer record of who asked for access, which downstream resource was targeted, and what policy produced the token that was actually used.
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 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Token custody and rotation affect credential lifecycle and reuse risk. |
| IA-9 — Service Identification and Authentication | MCP token handling is machine-to-machine access between clients, brokers, and services. | |
| Recommendation — Rotate and revoke tokens on strict lifetimes, and bound their reuse to the intended presenter and audience. Authenticate services and APIs with scoped machine credentials rather than broad reusable bearer tokens. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture | Brokered tokens align with least-privilege, continuous verification, and constrained trust zones. |
| Recommendation — Place authorization at the control boundary and issue only the minimum downstream access needed. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | Token passthrough and replay risks map directly to API authentication weaknesses. |
| API5 — Broken Function Level Authorization | Brokered versus client-held tokens changes who can invoke downstream actions and with what scope. | |
| Recommendation — Prevent token replay by binding credentials to the intended client, resource, or transport. Enforce function-level authorization at the mediator and downstream service, not just at token issuance. | ||
Practitioner Guidance
What to verify: Determine whether the token can be replayed directly against the underlying service or only exchanged by the mediator. If the same credential can move across services, treat it as a broader blast-radius problem, not just an MCP configuration detail.
Decision rule: Use client-held tokens only when the downstream service is the intended trust boundary and the token is tightly scoped, audience-bound, and short-lived. Prefer brokered tokens when you need centralized policy enforcement, per-request delegation, or stronger separation between the client workflow and the service credential.
Common mistake: Treating “brokered” as a cosmetic proxy pattern while still allowing broad passthrough semantics. If the mediator cannot narrow scope, constrain audience, or meaningfully revoke downstream access, the design has not really changed the security model.
Practitioner takeaway: The security difference is not token format, it is custody and enforceability, so choose the model that matches where you want access decisions to be made and where you can actually contain misuse.
Related resources from NHI Mgmt Group
- What is the difference between client identity and permission scope in MCP governance?
- What is the difference between authenticating an MCP client and authorising its tool use?
- What is the difference between Dynamic Client Registration and Client ID Metadata Documents for MCP clients?
- What is the difference between an MCP client and an MCP server in enterprise AI governance?