Identity propagation for MCP tools: why agents need user context

At a glance

What this is: This is an analysis of why MCP tools are identity-blind and how user context can be carried through an agent request with signed JWTs.

Why it matters: It matters because IAM, NHI, and agentic AI teams need auditability and per-user authorisation when agents mediate access to tools, data, and actions.

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

Context

MCP identity propagation is a governance problem as much as a technical one. When an agent calls a tool, the tool often sees only the agent process, not the human or workflow that initiated the request. That breaks attribution, weakens authorisation decisions, and leaves IAM teams with audit logs that describe activity but not accountability.

The core issue is that most agent integrations were designed around convenience first and identity second. Once tools are allowed to query data, list resources, or take operational actions, the programme has to answer a basic question: who is really acting here, and under what authority? Without that answer, least privilege becomes approximate and investigation becomes slow.

This article is an example of a common agentic AI pattern: the identity problem is not inside the model, but at the boundary where the agent reaches tool access. That makes it relevant to NHI governance, agentic AI controls, and broader IAM lifecycle design.

Key questions

Q: How should security teams make MCP tool calls attributable to a specific user?

A: Pass a signed identity token from the login layer into the agent request and validate it at the MCP server before any tool runs. The token should bind the caller to a specific audience, expire quickly, and carry only the claims needed for authorisation and audit. That makes the tool call attributable to a verified user, not just to an agent process.

Q: Why do MCP-based agent workflows create audit and authorisation gaps?

A: Because the tool often sees the agent, not the human who triggered the action. Without propagated identity, logs cannot answer who asked for the action, who approved it, or whether the caller was entitled to it. That weakens least privilege, complicates investigations, and pushes teams toward broad access patterns that are hard to govern.

Q: What breaks when an agent can call tools without user context?

A: Per-user filtering, scoped authorisation, and clean audit attribution all become unreliable. The system may return too much data, apply one shared permission set to everyone, or record only that an agent executed a task. In practice, that creates hidden overprovisioning and makes incident review much harder.

Q: Who is accountable when an agent executes an MCP tool action?

A: The accountable party should be the verified user whose identity was bound to the request, with the agent treated as the execution layer. If the organisation cannot prove that binding, accountability shifts from people to an opaque workflow, which is a governance failure. Offboarding and role changes must also remove the upstream path that feeds the agent.

Technical breakdown

Why MCP tools are identity-blind by default

MCP gives agents a standard way to call tools, but the tool layer does not automatically inherit the identity of the person who initiated the request. In practice, that means the server sees a generic agent call unless the environment explicitly passes user context forward. The result is a broken trust chain: authorisation can no longer distinguish between two people using the same agent workflow, and audit records lose the human actor. This is an identity propagation problem, not a model reasoning problem.

Practical implication: treat tool access as a user-scoped identity problem, not an agent-only integration.

How JWT-based identity propagation works in agent workflows

A signed JWT can carry verified identity claims from the login layer into the agent and then to the MCP server. The token typically includes a subject claim for the user, role claims for authorisation, audience restriction for the target gateway, and expiry for short-lived use. The server validates signature, audience, and time before executing the tool, which avoids building a separate user database on the tool side. This is a standard federation pattern adapted for agent-mediated access.

Practical implication: validate identity at the tool boundary before any action is executed.

What identity propagation changes for audit and authorisation

Once identity is carried through the request, logs can show who initiated the action, not just that an agent executed it. That matters for per-user filtering, rate limiting, data access scoping, and incident response. It also reduces the temptation to hard-code broad permissions into the agent because the tool can make decisions based on the caller's verified identity. In effect, identity propagation turns tool calls into governed access events instead of anonymous automation.

Practical implication: redesign audit and access controls so every tool call is attributable to a verified user.

NHI Mgmt Group analysis

MCP identity blindness is a governance gap, not a protocol quirk. When a tool cannot see who initiated the request, the control plane loses the ability to enforce least privilege at the human-to-agent boundary. That creates broad access by default, because the system must either overtrust the agent or underserve legitimate users. The practical conclusion is that identity context must travel with the request, or authorisation becomes guesswork.

Identity propagation restores accountability, but only if the token is bound tightly to the session. Short-lived, audience-restricted JWTs preserve the chain from login to tool invocation and make replay much harder. Without those constraints, the same mechanism can become a portable credential that outlives the intended interaction. The practitioner takeaway is to treat the agent path as a federated access flow, not a convenient message wrapper.

Agentic tool use exposes a named concept: identity context loss. This is the point where the user, the agent, and the tool each see a different version of authority, which makes audit, authorisation, and offboarding drift apart. In that state, access reviews become incomplete because the record no longer reflects the real actor behind the request. Teams should recognise identity context loss as a structural failure mode in agent integrations.

Lifecycle governance becomes more important when the agent mediates every request. If user roles, offboarding status, or access changes are not propagated quickly, the agent can continue to operate with stale authority even after the underlying human entitlement should have changed. That widens the gap between policy and execution. The practical conclusion is that agent workflows must inherit the same joiner, mover, and leaver discipline as the rest of IAM.

Agentic AI security and NHI governance now overlap at the request boundary. An MCP tool call is not just an AI event or an IAM event, it is a delegated identity event that spans both domains. That means IAM leads, PAM teams, and NHI owners need shared controls for attribution, short-lived access, and audit integrity. The practitioner conclusion is to design the boundary once, then enforce it consistently across agents and downstream tools.

From our research:

• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which is why identity propagation and audit integrity cannot be bolted on after deployment.
• For a broader view of how lifecycle and access drift create exposure, see Top 10 NHI Issues and apply the same discipline to agent-mediated tool access.

What this signals

Identity context loss: this is the operational risk to track as agent workflows scale. With 80% of organisations reporting AI agents already acted beyond intended scope in the SailPoint research, the boundary between delegated action and uncontrolled access is no longer theoretical. IAM and NHI programmes should assume the audit problem will surface before the control problem is visible.

For practitioners, the next planning step is to bring agent tool calls into the same governance model used for other non-human access paths. That means lifecycle events, role change handling, and offboarding must reach the identity token that feeds the agent, not just the human directory record. The same discipline that governs service accounts now has to govern agent-mediated access paths too.

For practitioners

• Map every agent tool call to a verified user identity Require the agent platform to pass a signed subject claim into the downstream tool and reject any request that lacks a verified caller, audience binding, or expiry.
• Enforce short-lived, audience-restricted tokens Use tokens that expire quickly, are tied to one MCP gateway, and cannot be replayed against unrelated services or alternate execution paths.
• Separate agent convenience from authorisation logic Keep policy checks at the boundary where the tool is called, so the agent can request actions without being trusted to decide entitlement on its own.
• Extend offboarding and role-change reviews into agent workflows When a user changes role or leaves, revoke the upstream identity path that feeds the agent as part of the same lifecycle event, not as a separate cleanup task.

Key takeaways

• MCP tools are only as governable as the identity context carried into each request.
• Agent-mediated access becomes risky when audit trails cannot distinguish the human actor from the execution layer.
• Identity propagation, short-lived tokens, and lifecycle-aware revocation are the controls that make agent tool use defensible.

Key terms

• Identity Propagation: Identity propagation is the process of carrying a verified caller identity from the authentication layer into downstream systems that act on the request. In agent workflows, it ensures tools can authorise and audit the human behind the action instead of treating the agent as the only actor.
• MCP: Model Context Protocol is an open protocol for connecting AI agents to tools and data sources. In practice, it standardises tool access, but it does not by itself solve identity, authorisation, or audit attribution. Those controls have to be added at the request boundary.
• Short-Lived Token: A short-lived token is a credential that expires quickly and is valid only for a narrow use case or session. In agentic environments, it reduces replay risk and limits how long a delegated identity can be misused if the request path is intercepted or reused.
• Audit Attribution: Audit attribution is the ability to link a system action back to the specific identity that initiated it. For agent-mediated access, it must preserve the human caller as well as the agent execution path, otherwise logs tell you what happened but not who was responsible.

What's in the full article

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

• Step-by-step JWT validation flow from Teleport login through MCP request handling
• Example code showing how downstream tools extract user and role claims for authorisation
• How the proxied connection passes identity into agent requests without a separate user database
• The planned AWS extension into Bedrock AgentCore, CloudTrail, and request interception

👉 Teleport's full post covers the JWT flow, request validation, and downstream authorisation pattern.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or programme maturity, it is worth exploring.