Identity propagation for MCP tools: why agents need user context

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Teleport's blog post: Identity propagation through MCP tools works by carrying user context in short-lived JWTs, which is necessary to preserve authorization and auditability when agents invoke tools.

Why it matters: IAM and NHI teams need this pattern because agent-mediated tool calls otherwise erase the link between person, agent, and action, which weakens least privilege, logging, and accountability.

👉 Read Teleport's analysis of identity propagation for MCP tools

Context

MCP identity propagation is the practice of carrying the initiating user's identity through an agent call so the downstream tool can enforce authorization against the real caller, not just the agent runtime. Without that link, tool access becomes detached from the user context that security policy depends on.

Teleport's analysis focuses on a governance gap that is easy to miss in agentic workflows: the MCP tool sees an authenticated process, but not necessarily the human whose rights should govern the action. That breaks the usual IAM assumption that identity is available at decision time, not reconstructed after the fact.

Key questions

Q: How should security teams control MCP tool calls after authentication succeeds?

A: They should enforce a separate runtime authorization decision for each call_tool request, rather than trusting the login event or token scope alone. The control should evaluate the tool, the target resource, the workflow context, and the delegating identity before any write action executes. That is the point where blast radius can still be reduced.

Q: Why does identity propagation matter for MCP audit trails?

A: Because an audit trail that only shows agent activity does not tell you who requested the action or whether that person was entitled to it. Identity propagation restores accountability by binding tool execution to the initiating principal, which makes investigations, certification, and policy enforcement materially stronger.

Q: What breaks when MCP tools do not have session context for the requesting user?

A: Without session context, MCP tools cannot reliably enforce organisation scoping, permissions, or role-based decisions. Teams also lose the ability to personalise actions safely, such as limiting data access to the requester’s tenant. In practice, this turns powerful tools into shared interfaces with weak attribution, which increases accidental overreach and compliance exposure.

Q: How do IAM and NHI teams govern agent access across the request chain?

A: They should treat the human identity, the agent session, and the downstream tool as one governed path with shared lifecycle rules. That means role changes, revocation, logging, and recertification must reach the agent-mediated access point at the same time they reach the primary identity record.

Technical breakdown

Why MCP tools are identity-blind by default

MCP standardises how agents call tools, but the protocol does not inherently carry a user identity that the tool can trust. The result is a caller ambiguity problem: the tool can see an authenticated request, yet it cannot tell whether that request came from a developer, a power user, or someone who should have no access at all. That ambiguity forces the environment to treat the agent as the subject unless identity is propagated separately. In IAM terms, the policy decision loses its real principal and becomes detached from user context.

Practical implication: Design MCP integrations so authorization is evaluated against the initiating user, not the agent process.

How short-lived JWTs preserve user context through the agent

The article uses JSON Web Tokens to move identity through the agent path. A login issues a signed token with claims such as subject, roles, audience, and expiration. The MCP server validates the signature and token audience before execution, which means the tool can trust the asserted identity without querying a separate user store. Short TTLs matter because they reduce replay value and align token validity with the specific task session. This is essentially federation logic applied to agent-mediated access, with the token acting as the transferable proof of caller context.

Practical implication: Use short-lived, signed tokens with audience checks so downstream tools can authorize the actual user per request.

What attribution changes inside the tool and audit trail

Once the token is validated, identity can be injected into the tool as an input parameter and used for authorization, filtering, and logging. That changes both control and evidence. The tool can return only the caller's own records, and the audit log can record who asked for the action instead of merely noting that an agent acted. This is more than better logging. It converts agentic execution from anonymous orchestration into a governed access path where the identity lineage remains visible across the request chain.

Practical implication: Require downstream services to consume verified caller claims for both authorization decisions and audit records.

Threat narrative

Attacker objective: The objective is to force access decisions and logging to treat the agent as the only visible caller, which erodes authorization precision and accountability.

1. Entry occurs when a user authenticates into the MCP flow and the agent inherits the request path without native user context.
2. Credential access is not the issue here; the failure is that the downstream tool cannot distinguish the initiating principal from the executing agent.
3. Impact follows as overprovisioned access, weak filtering, and audit logs that record only agent activity rather than accountable user actions.

Breaches seen in the wild

• CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Identity propagation is now a control-plane requirement, not an implementation detail. MCP-style agent workflows make the caller identity problem explicit because the tool execution layer otherwise sees only the agent. That shifts identity from a login concern into a runtime authorization concern, which is where IAM and NHI governance meet. Practitioners should treat user context as part of the access decision itself, not as optional metadata.

Caller blindness creates a governance gap that least privilege cannot solve on its own. If the downstream tool cannot tell who initiated the request, then least privilege gets approximated by broadening access for everyone or throttling functionality until it becomes generic. That is not a policy refinement, it is an identity loss problem. The practical implication is that authorization must follow the initiating identity through the agent path.

Verified identity claims are the right boundary for agent tool use. Signed, short-lived tokens can preserve the link between human, agent, and tool without requiring a bespoke identity store at every endpoint. That matters because agentic systems often need context-aware actions such as per-user filtering, personalisation, and scoped retrieval. The control point is the validated claim set, not the agent runtime itself.

Auditability collapses when the request chain stops at the agent. Security teams cannot investigate or certify actions if logs only prove that an agent called a tool. Identity propagation restores evidentiary value because logs can name the initiating principal and the roles in force at the time of execution. The implication is simple: if the tool cannot record the caller, the governance model is incomplete.

Agent caller lineage: MCP introduces a new identity continuity problem in which the human trigger, the agent execution context, and the downstream tool all need to remain attributable across one request path. That lineage is what turns agentic access into governed access. Practitioners should define it as a first-class control objective in agent programmes.

From our research library:

• 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
• Read next: AI Agent Observability, Audit and Incident Response Guide

What this signals

Caller lineage becomes the control that decides whether agentic access is governable. As MCP usage grows, organisations will need to prove which user initiated a tool call, not just that the call was authenticated. That proof needs to survive across the agent boundary, otherwise access reviews and incident investigations lose the evidence they depend on.

Identity propagation also exposes a design choice many teams have been postponing: whether the authoritative identity lives in the upstream session, the token handed to the tool, or the tool's own local policy layer. The cleanest model is to validate once, propagate a signed claim, and make downstream enforcement consume that claim rather than re-create identity later.

24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026. That figure reinforces the broader warning here: as MCP expands, identity and secrets handling will need to be governed together, not as separate implementation concerns.

For practitioners

• Establish caller-bound authorization Require every MCP tool call to validate the initiating user's identity and roles before execution, rather than trusting the agent process alone.
• Use short-lived signed tokens Issue JWTs with narrow expiration windows, audience binding, and signed claims so the downstream service can trust the caller context without a separate user store.
• Inject verified identity into tool parameters Pass the validated subject and role claims into downstream functions so filtering, quotas, and access checks are performed per user.
• Rewrite audit logs around the initiator Record the human principal, agent path, and tool action together so investigations can reconstruct who asked for the operation and under what authority.
• Align agent governance with IAM lifecycle Ensure offboarding, role changes, and access reviews affect MCP-connected tool access at the same time they affect the user's primary identity record.

Key takeaways

• MCP tools create an identity continuity problem because the tool can see the agent request but not necessarily the human authority behind it.
• Short-lived signed JWTs let teams preserve caller context through the agent layer without building a separate identity store for each tool.
• Auditability and least privilege both improve when the downstream service receives verified identity claims and uses them for authorization and logging.

Key terms

• Identity propagation: The preservation of origin and acting principal information as a request moves through multiple services. In MCP chains, this is what allows downstream systems to make a trustworthy authorization decision instead of relying on a stripped-down token with no task context.
• Caller Context: Caller context is the set of identity claims, roles, and scope information that explains who initiated a request and what authority they had at that moment. For agent-mediated access, it is the difference between governing a known user action and reacting to an opaque tool invocation after the fact.
• Short-Lived JWT: A short-lived JWT is a signed token with an expiration window tight enough to limit replay and stale access. In agentic workflows it acts as a transferable proof of user identity, allowing downstream tools to trust the caller without maintaining a separate identity store.
• Audit Attribution: The ability to prove who requested an action, which actor executed it, and what resource was affected. In AI agent governance, attribution must be richer than a single username because accountability breaks when the human and the agent share one visible identity.

What's in the full article

Teleport's full blog post covers the operational detail this post intentionally leaves for the source:

• Step-by-step JWT validation flow for MCP connections, including signature, audience, and expiry checks
• Example request and response payloads showing how verified identity is injected into tool parameters
• Implementation notes for using Teleport roles to scope access decisions inside downstream MCP tools
• Planned extension into AWS with Amazon Bedrock AgentCore and CloudTrail attribution

👉 Teleport's full post shows the JWT flow, authorization checks, and agent-to-tool identity handoff in detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.