Topic starter
25/06/2026 10:31 pm
TL;DR: Teleport reports that MCP tools cannot tell who triggered an agent request, so teams either overprovision access or accept weak audit trails. Propagating user identity through short-lived JWTs restores attribution and authorization, but it also exposes how many agent workflows still assume the caller is known only after execution.
Editorial analysis by NHI Mgmt Group, based on content published by Teleport: “Your AI Agent Needs to Know Who You Are”.
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: MCP tools create an identity continuity problem because the tool can see the agent request but not necessarily the human authority behind it.
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
👉 Read Teleport's analysis of identity propagation for MCP tools →
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
25/06/2026 11:04 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Identity propagation for MCP tools: why agents need user context