Security teams should treat each MCP boundary as a separate trust decision. A token issued for one server must only be accepted by that server, and it should never be forwarded upstream. When a server needs another API, it should obtain its own credential. That preserves audience binding, prevents token laundering, and keeps attribution clear when actions are reviewed later.
Why Trust Boundaries Matter in MCP
MCP deployments work best when the server boundary is treated as a real security boundary, not just a routing hop. A client token that reaches one MCP server should stay there, because that server is the only party that can safely act on the client’s delegated authority. If the server needs to call an upstream API, it should present its own credential and its own identity.
That model keeps the trust decision aligned with the component that is actually executing the action. It also reduces the chance that a downstream service can reuse a token outside its intended audience, which is where confused deputy problems, token laundering, and attribution drift usually begin.
For teams designing the boundary, the key question is not whether the call chain is technically possible, but whether each hop has a separately justified trust relationship. In practice, that means one audience, one accepting party, and one credential path per trust domain.
How to Structure Authentication and Upstream Access
The cleanest pattern is to authenticate the client to the MCP server, then let the server authenticate independently to any upstream dependency it needs. That preserves MCP authorization expectations around audience-bound tokens and avoids token passthrough across trust domains.
When the server calls an upstream API, it should do so with a credential that was issued for that API, not with a token borrowed from the original client. That may be an OAuth client credential, a workload credential, or another server-side secret, but the design principle is the same: the upstream system should see the MCP server as the caller, not the original user token.
This separation also makes policy easier to reason about. The MCP server can enforce its own authorization logic for tools and functions, while the upstream API can enforce its own scopes, audience checks, and rate limits. If those decisions are collapsed into a single token, the server becomes a trust amplifier instead of a controlled mediator.
What Breaks When Tokens Cross the Boundary
The main failure mode is audience confusion. A token that is valid for the MCP server may be structurally acceptable to another service, but semantically wrong for it. Once that token is forwarded upstream, the receiving API may no longer know whether it is serving the original user, the MCP server, or a downstream tool chain.
That is why security teams should avoid treating pass-through as a convenience feature. A token that survives multiple hops can create excessive blast radius, especially if the upstream API accepts broad scopes or if the server can call many tools on the user’s behalf. The result is usually more privilege than intended, and less confidence in audit trails.
Clear separation also helps incident review. If a server acquires and uses its own credential, investigators can distinguish client intent from server-side action. If the same bearer token is reused end to end, attribution becomes ambiguous and containment is harder because the token may have been valid in places the client never intended.
Risk and Threat Considerations
Token forwarding across MCP boundaries creates a trust-bypass path. A downstream server or upstream API may inherit authority it was never meant to hold, which can turn a narrow delegated action into broad unauthorized access or unintended tool use.
Failure mechanism: The server reuses a client token outside its original audience, so the token can be accepted by an upstream service that was never the intended recipient. That breaks boundary separation and can enable confused deputy behaviour, privilege inflation, or audit ambiguity.
Impact: An attacker who steals or manipulates one token can often reach more systems than intended, while defenders lose the ability to tell which component actually initiated the action. Containment, review, and revocation all become harder when identity and audience are blurred.
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 |
|---|---|---|
| OWASP API Security Top 10 | API2 — Broken Authentication | MCP token handling hinges on API authentication boundaries and audience restrictions. |
| API5 — Broken Function Level Authorization | Each MCP server action must be authorized independently from upstream API access. | |
| Recommendation — Require audience-bound tokens and reject credentials forwarded beyond their intended API. Enforce function-level checks so the server cannot reuse client authority for broader actions. | ||
| NIST SP 800-53 Rev 5 | IA-9 — Service Identification and Authentication | Remote MCP servers and upstream APIs authenticate as services, not as the original client. |
| AC-6 — Least Privilege | Separating credentials across MCP boundaries limits downstream blast radius. | |
| Recommendation — Authenticate services separately and bind credentials to the specific service relationship. Issue each server the minimum credential scope needed for its own upstream calls. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture | MCP boundaries require explicit verification at each hop rather than inherited trust. |
| Recommendation — Verify each hop independently and never carry trust forward by default. | ||
Practitioner Guidance
What to prioritise: Define the MCP server as the trust boundary and require a separate credential for every upstream API it calls. If a design depends on forwarding the original token to make the integration work, treat that as an exception that needs explicit review.
What to verify: Confirm that each token is audience-bound, that the upstream API rejects client tokens issued for the MCP server, and that server-side credentials have the narrowest scope needed for the specific API action. Also verify that logs distinguish the original client request from the server’s upstream call.
Common mistake: Teams often secure the initial client-to-server hop and then assume the rest of the chain is covered. In MCP, the second hop is where boundary failure usually appears, because the server can silently become a proxy for far more authority than the client should have.
Practitioner takeaway: Treat every MCP hop as a new trust decision, not a continuation of the same one. The safest deployment is the one where each component proves its own identity and carries only the authority needed for its own boundary.
Related resources from NHI Mgmt Group
- How should security teams implement OAuth-based authentication for MCP servers in remote tool integrations?
- How should security teams handle Dynamic Client Registration in remote MCP deployments?
- How should security teams govern MCP servers that wrap REST APIs?
- How should security teams migrate MCP servers away from session-based trust?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 30, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
