Use federation or token exchange instead of issuing a separate static credential. The goal is to let the server act with a backend-specific token that still reflects the original subject, so the trust boundary is explicit and revocation stays manageable.
Why a Different Trust Domain Changes the MCP Design
When an MCP backend sits outside the client’s trust domain, the core issue is not just connectivity. The server should not inherit broad, long-lived access simply because it is reachable. Federation or token exchange keeps the backend relationship explicit, preserves the original subject, and makes the trust boundary visible in the credential flow.
That matters because a backend in another domain often has different operators, different policy, and different revocation needs. A separate static credential hides those differences and turns one integration point into a standing trust relationship, which is usually too much privilege for too long.
Why Token Exchange Is Safer Than a New Static Secret
Token exchange gives the backend a credential that is scoped for the specific target and session instead of a reusable secret that can be copied into other systems. In practice, the backend receives a token that can carry audience, expiry, and delegation context, so the receiver can validate who the original subject was and what it is allowed to do.
This is especially useful when the upstream client and downstream backend are run by different teams or even different organisations. MCP Security Guide covers the authorisation model, token passthrough, and the confused-deputy risks that appear when MCP servers bridge trust domains. The same pattern is reinforced in Model Context Protocol: Authorization specification, which treats the server as an OAuth 2.1 resource server and favours audience-bound tokens over token forwarding.
That approach also maps cleanly to broader workload-identity practice. The backend can be authorised without turning the integration into a permanent credential-sharing arrangement, which keeps rotation, expiry, and revocation manageable when one side changes policy or loses trust.
What Organisations Should Put in Place Operationally
The practical goal is to make the trust boundary explicit in the authentication flow and in the operational ownership model. If the backend is in another domain, organisations should decide who issues the token, who can revoke it, what the token audience is, and what claims the backend must verify before accepting the request.
Where the backend needs to call further services, constrain that second hop separately rather than assuming the original token should be reused everywhere. If the original subject needs to be preserved across the boundary, the chain should be auditable and narrow, not implicit.
- Use federation when the backend can trust the upstream identity provider or token issuer.
- Use token exchange when the backend needs a backend-specific token with a limited audience.
- Avoid issuing a separate static secret unless there is no viable delegated-authentication path.
- Require clear expiry and revocation handling so trust changes can be enforced quickly.
Risk and Threat Considerations
Cross-domain MCP access becomes risky when organisations treat a remote backend like a local component and hand it a durable credential. That can create a hidden standing privilege, weak revocation, and a confused-deputy condition if the backend can act beyond the caller’s intended scope.
Failure mechanism: A static credential or overly broad bearer token can be replayed, reused, or forwarded outside the intended trust boundary, especially when the backend is operated by a different team or vendor.
Impact: Compromise can spread across domains, revocation can become slow or incomplete, and the backend may be able to access downstream systems with more authority than the original request justified.
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 Zero Trust (SP 800-207) and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API2 — Broken Authentication | MCP trust-domain separation depends on correct token handling and audience checks. |
| Recommendation — Enforce backend-specific authentication and reject token reuse across trust domains. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Short-lived delegated credentials need rotation, revocation, and lifecycle control. |
| IA-9 — Service Identification and Authentication | The backend authenticates as a service or workload across a distinct trust boundary. | |
| Recommendation — Manage delegated tokens so they can be rotated, expired, and revoked promptly. Use service-to-service authentication with scoped credentials for the backend. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture | A different trust domain calls for explicit trust verification and least-privilege exchange. |
| Recommendation — Verify each request explicitly and limit access to the minimum required scope. | ||
| CIS Controls v8 | 5 — Account Management | Delegated access across domains must be governed and revocable. |
| Recommendation — Inventory and revoke cross-domain credentials under formal account management. | ||
Practitioner Guidance
What to verify: Confirm that the backend validates audience, issuer, and expiry, and that the token it receives is scoped to the exact trust relationship rather than copied from the client unchanged.
Decision rule: If the backend is outside the trust domain, prefer delegated access with short-lived credentials over any design that depends on a shared static secret or unconditional token reuse.
Practitioner takeaway: The right design is the one that lets you revoke trust at the boundary without breaking unrelated access paths, because that is what keeps cross-domain MCP integrations governable at scale.
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