Notifications
Clear all
Topic starter
25/06/2026 10:31 pm
TL;DR: MCP tools cannot distinguish the human who triggered a request from the agent that executed it, which pushes teams toward overprovisioning or weak audit trails, according to Teleport. Propagating identity through JWTs restores attribution and authorization, but it also exposes how many current agent workflows assume the caller is known only after the fact.
NHIMG editorial — based on content published by Teleport: Your AI Agent Needs to Know Who You Are
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
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
👉 Read Teleport's analysis of identity propagation for MCP tools →
MCP identity propagation: what it means for IAM teams?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
25/06/2026 11:04 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Identity propagation for MCP tools: why agents need user context
