They should preserve user context end to end by using short-lived tokens, token exchange, or federation instead of shared service credentials. That lets the backend see a scoped identity tied to the originating user, which improves attribution, reduces blast radius, and makes access reviews meaningful.
Why This Matters for Security Teams
MCP servers often sit in the middle of a trust decision that security teams do not see until something breaks: a user asks an agent to take an action, the server calls a backend tool, and the backend must decide whether that action belongs to the user, the server, or both. If identity is flattened into a shared service credential, attribution disappears and access reviews become meaningless. NHI Management Group research shows that 97% of NHIs carry excessive privileges, which is exactly the kind of blast radius MCP can amplify when one credential is reused across many users. See the Ultimate Guide to NHIs and the State of MCP Server Security 2025 for the pattern that keeps repeating in real deployments.
The real issue is not just authentication at the server boundary. It is whether the backend can preserve the originating user context while still letting the MCP server act as an intermediary. That is why current guidance increasingly favors token exchange, federation, and scoped delegation over static shared secrets. The same logic appears in OWASP Top 10 for Agentic Applications 2026 and in NIST SP 800-53 Rev 5 Security and Privacy Controls, which both emphasize least privilege and traceable access. In practice, many security teams discover the identity gap only after a backend audit cannot tell which user triggered a tool call.
How It Works in Practice
The safest pattern is to treat the MCP server as a delegated actor, not as the end user. The server authenticates itself with a workload identity, then exchanges or forwards user context in a constrained token that the backend can evaluate. That preserves attribution and allows the backend to enforce user-scoped permissions rather than broad server-level access. For agentic and tool-using systems, this is closer to intent-aware authorisation than classic session-based IAM.
In practice, teams usually combine three controls:
Workload identity for the MCP server: the server proves what it is, often with federation, short-lived certificates, or an identity system such as SPIFFE.
Token exchange or delegation: the original user identity is translated into a backend token with narrower scope and a short TTL.
Backend-side policy evaluation: the tool checks who the user is, what action is being requested, and whether the server is authorized to carry that delegation.
This model is materially different from sharing one API key across all users. Shared credentials hide the originating principal, make revocation blunt, and widen blast radius if a server is compromised. Short-lived tokens also help when an MCP workflow fans out across multiple tools, because the backend can still see the chain of custody instead of only the final caller. NHI Management Group’s 52 NHI Breaches Analysis shows how often identity failures become incident-response failures when attribution is lost. The operational baseline aligns well with the OWASP Agentic AI Top 10 and the NIST control set for least privilege and accountability.
These controls tend to break down when backend tools were built for service-to-service trust only, because they cannot evaluate delegated user context without protocol changes or policy updates.
Common Variations and Edge Cases
Tighter delegation often increases implementation complexity, requiring organisations to balance clean attribution against legacy integration constraints. There is no universal standard for this yet, so teams should expect variation across APIs, gateways, and identity providers.
Some environments still need a fallback path. Legacy tools may accept only a service credential, making true end-to-end user propagation impossible without an intermediary policy layer. In those cases, best practice is to minimise the server credential’s scope, log the originating user separately, and plan a migration to token exchange or federation.
There are also cases where preserving full user identity is inappropriate. For highly sensitive workflows, a backend may need to know that a trusted MCP server requested an action without exposing the end user’s identity. That is a policy decision, not a technical default, and it should be explicit. In regulated environments, the safest approach is to require documented delegation rules, short token lifetimes, and revocation on session end. For broader NHI governance context, the Ultimate Guide to NHIs remains the clearest operational reference. Emerging guidance also points to the need for stronger agent-specific controls in the OWASP Top 10 for Agentic Applications 2026.
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, CSA MAESTRO and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A02 | Delegated tool calls need strong auth and identity context preservation. |
| CSA MAESTRO | ID-1 | MAESTRO emphasizes workload identity and controlled delegation for agents. |
| NIST AI RMF | AI RMF addresses accountability and traceability for autonomous or assisted actions. | |
| OWASP Non-Human Identity Top 10 | NHI-01 | Shared credentials and poor scoping are classic NHI failure modes in MCP servers. |
| NIST CSF 2.0 | PR.AC-4 | Least privilege and access control apply directly to delegated backend tool access. |
Document identity handoffs and ensure every agent action remains attributable to a human or workload.
Related resources from NHI Mgmt Group
- How should security teams handle SaaS offboarding when users also use AI tools?
- How should security teams govern MCP workflows that mix models, servers, and users?
- How should security teams handle identity-related support requests across Slack and ticketing tools?
- How should security teams handle fragmented identity data across multiple IAM tools?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 20, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
