Only when the receiving service explicitly expects and validates that exact token format and the integration has been narrowly approved. In most cases, forwarding should be avoided because it breaks audience boundaries and creates unnecessary trust coupling between services. The default posture should be token exchange or server-owned authentication, not passthrough.
When forwarding is acceptable, and when it is not
Credential forwarding from an mcp server should be treated as an exception, not a default integration pattern. The only defensible case is when the downstream service explicitly expects that exact token format, the audience and trust boundary are understood, and the integration has been narrowly approved. In every other case, use token exchange or server-owned authentication instead of passthrough.
Forwarding becomes risky as soon as the MCP server starts acting as a generic token relay. That blurs who the caller is, who the token was meant for, and which service is responsible for enforcing access policy. It also makes future changes harder, because a token that works today may be silently accepted by another service tomorrow.
For the protocol side of the pattern, the strongest reference point is the Model Context Protocol authorization specification, which frames MCP servers as OAuth 2.1 resource servers with audience-bound tokens rather than open token passthrough. That model is important because it preserves the resource boundary and reduces confused-deputy behaviour. For token handling itself, RFC 6749 and RFC 9728 reinforce the need for scoped OAuth flows and resource metadata rather than unconditional forwarding.
What breaks when you forward a token blindly
Blind forwarding creates two problems at once: it expands trust and weakens accountability. If the MCP server passes a user token to multiple tools or APIs, every downstream service must now trust a token that was not issued specifically for it. That may work technically, but it is a brittle security design because the token can outlive the original intent and be replayed in places the user never approved.
It also encourages accidental privilege inheritance. A tool that only needed read access may receive a bearer credential that can do far more, especially if the token is accepted broadly or the downstream service does weak audience checks. In practice, the forwarding path can become a hidden privilege bridge between services that were supposed to remain isolated.
The safer design is server-owned authentication when the MCP server itself is the real caller, or token exchange when the user context must be preserved but reissued in a narrower form. That approach preserves identity intent, keeps the receiving service in control of validation, and makes it easier to constrain what the server can do on behalf of the user.
Related guidance in NHIMG’s MCP Security Guide and NHI Authentication Guide is useful here because both emphasise audience boundaries, token exchange, and service-to-service authentication rather than passthrough. The same principle is covered from a broader machine-identity perspective in AI Agent Identity Security: The 2026 Deployment Guide.
What a safe approval looks like in practice
A safe exception needs more than “the API works with it.” Teams should verify that the receiving service is the intended audience, that the token type is explicitly supported, and that the integration is bounded to a narrow use case. If the downstream service cannot prove it enforces audience and scope checks, the approval is too weak.
Approval should also be tied to a revocation path. If the forwarding arrangement is temporary, there must be a clear owner, an expiry date, and a plan to rotate to a narrower mechanism. This matters because forwarding arrangements tend to survive long after the original justification has faded, especially when they are embedded in agent or orchestration workflows.
For teams building MCP-based systems, NHIMG’s MCP Security Guide is the most direct implementation reference, while the OWASP Agentic AI Top 10 is useful when forwarding becomes part of agent tool access and privilege boundaries. If the integration uses bearer tokens at all, the OAuth 2.0 Authorization Framework remains the baseline for preserving scope and audience discipline.
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, OWASP Non-Human Identity Top 10 and OWASP API Security Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | MCP forwarding can blur agent and service authority boundaries. |
| Recommendation — Constrain agent credentials so tool calls cannot inherit broader privilege. | ||
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | Token passthrough depends on how downstream services validate received credentials. |
| Recommendation — Require explicit downstream validation before allowing credential forwarding. | ||
| NIST SP 800-53 Rev 5 | IA-9 — Service Identification and Authentication | MCP server-to-service credential forwarding is a service authentication issue. |
| AC-6 — Least Privilege | Forwarding can propagate unnecessary privileges across service boundaries. | |
| Recommendation — Use service-specific authentication instead of generic token relay. Limit forwarded credentials to the minimum privileges required. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | Passthrough tokens can fail if the API does not strictly authenticate the intended caller. |
| API5 — Broken Function Level Authorization | Forwarded tokens may reach functions the original caller should not access. | |
| Recommendation — Validate audience and token expectations before reusing credentials across APIs. Enforce function-level checks on every downstream request. | ||
Practitioner Guidance
What to prioritise: Treat the audience boundary as the deciding factor. If the receiving service does not explicitly expect that token format and validate it as intended, forwarding should be rejected in favour of token exchange or server-owned credentials.
What to verify: Confirm the exact downstream validation behaviour, including audience checking, scope enforcement, and whether the token can be replayed beyond the intended service. If any of those answers are vague, the integration is not narrow enough for passthrough.
Common mistake: Teams often approve forwarding because it is the fastest way to make a tool chain work. That shortcut usually creates hidden coupling, makes later hardening painful, and leaves no clean path to reduce privilege without redesigning the flow.
Practitioner takeaway: Credential forwarding is only acceptable when it is a consciously bounded exception, not a convenience pattern. If the service boundary is not explicit and enforced, the secure answer is almost always to exchange the token or let the MCP server authenticate as itself.
Related resources from NHI Mgmt Group
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 12, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org