The downstream service can no longer reliably tell what the original client was allowed to do, which makes authorisation decisions inconsistent. Session state may also become ambiguous when proxies sit in the path. That creates policy drift across infrastructure that looks identical from the user side.
Why This Matters for Security Teams
When MCP runs behind gateways without a defined auth propagation model, the gateway becomes more than a transport hop. It becomes the point where identity, intent, and authorisation can be lost, rewritten, or inferred incorrectly. That is especially dangerous in agentic environments, where the client is not a person clicking a button but an autonomous software entity with tool access and execution authority. Current guidance from the OWASP Agentic AI Top 10 and NHIMG’s OWASP Agentic Applications Top 10 treats this as a governance issue, not just an integration issue, because the security boundary must follow the workload identity and the runtime decision, not the proxy chain.
Without explicit propagation, the downstream MCP service may see only the gateway identity, a partial session, or a generic service token. That breaks intent-based authorisation, weakens auditability, and makes JIT credentials harder to enforce because the service cannot reliably match a request to the original task. In practice, many security teams encounter this only after an agent has already crossed a trust boundary that looked consistent from the outside.
How It Works in Practice
The operational fix is to treat auth propagation as a first-class design requirement for MCP, not an optional gateway feature. The downstream service needs enough cryptographic and contextual evidence to decide what the agent is trying to do, whether that action is within scope, and whether the current token or assertion is still valid. That usually means pairing workload identity with short-lived credentials, then forwarding a signed representation of user intent or delegated authority through the request path.
A practical pattern is:
- Use workload identity for the agent or tool runner, so the service can verify what the caller is.
- Propagate delegated context, such as subject, scope, task, and expiry, so the service can verify what the caller is allowed to do.
- Evaluate policy at request time, not at session creation, because autonomous agents can change behaviour mid-run.
- Keep secrets ephemeral and tightly scoped, since long-lived tokens are hard to justify when tool chains are dynamic.
That approach aligns with the direction described in the OWASP Top 10 for Agentic Applications 2026 and NHIMG’s analysis of Analysis of Claude Code Security, both of which emphasise that agentic systems need runtime controls, not just perimeter checks. It also maps cleanly to OWASP Agentic AI Top 10 and the broader control logic used in zero trust and policy-as-code programs. These controls tend to break down when a gateway terminates the original identity and reissues a generic service credential, because the downstream service can no longer distinguish delegation from direct trust.
Common Variations and Edge Cases
Tighter auth propagation often increases implementation overhead, requiring organisations to balance stronger delegation fidelity against gateway complexity and token handling risk. There is no universal standard for this yet, so current guidance suggests designing for verifiable context transfer rather than assuming one proxy-to-service pattern will fit every deployment.
A few edge cases matter. In mixed human-agent workflows, the gateway may need to carry both the user’s identity and the agent’s workload identity, which can expose weaknesses in flat RBAC models. In multi-hop tool chains, each hop may need its own short-lived assertion, otherwise one compromised intermediary can blur accountability across the entire chain. In high-assurance environments, JIT credential provisioning and revocation become more important than static role assignment, because the task may be complete long before the session ends.
The main tradeoff is that stronger propagation can make debugging and interoperability harder, especially across vendor gateways or legacy services that were never designed for delegated identity. That is why NHIMG treats this as an agentic governance problem, not a simple networking issue, and why the safer design is to preserve intent and expiry end to end instead of relying on ambient trust. For practitioners comparing control families, the alignment is consistent with the governance direction in OWASP Agentic Applications Top 10 and the organisational controls discussed in Analysis of Claude Code Security.
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 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A1 | Auth propagation failures enable agent privilege drift and broken delegation. |
| CSA MAESTRO | GOV-03 | MAESTRO covers runtime governance for autonomous agent decisions and delegation. |
| NIST AI RMF | GOVERN | AI RMF governance applies when autonomous systems need accountable access decisions. |
Assign ownership for agent auth flows and validate them with recurring governance reviews.
