MCP identity patterns are outgrowing current IAM assumptions

At a glance

What this is: This discussion frames four MCP usage patterns and shows that identity and authorization must change as AI agents move from user-in-the-loop interactions to autonomous and chained execution.

Why it matters: It matters because IAM teams need to govern non-human identities, delegated authority, and downstream identity propagation before MCP-based workflows create unbounded access paths.

👉 Read SGNL's summary of the four MCP use cases and identity questions

Context

Model Context Protocol creates a new identity problem because the tool connection is no longer just a transport layer. Once an AI agent can ask for access, act on behalf of a user, or chain requests through other MCP servers, the security model has to decide whose authority is being exercised at each step and how long that authority should last.

For IAM and NHI practitioners, the important shift is that MCP turns authorization into a runtime decision problem. The discussion's four use cases, interactive, delegated, autonomous, and chained, map cleanly to different governance models, but most enterprises still treat them as variations of the same login pattern. That is the wrong starting point for NHI governance.

Key questions

Q: How should security teams govern AI agents that use MCP to call tools and data sources?

A: Treat each agent as a non-human identity with its own scope, owner, and expiry. Define whether the agent is interactive, delegated, autonomous, or chained, then apply different authorization rules to each mode. The key control is to bind every action to a principal and purpose that survive beyond a single login session.

Q: What is the difference between delegated and autonomous MCP use cases?

A: Delegated use means a user assigns a task and then may disappear, so the agent acts under task-specific authority. Autonomous use means the agent has a durable charter and can operate continuously without a human owner in the loop. The first is temporary delegation, while the second is enduring software authority.

Q: Why do chained MCP workflows create extra identity risk?

A: Chained workflows multiply trust boundaries because each MCP server may forward the request to another server. If the originating identity is not preserved, downstream authorization loses context and may overgrant access or reject valid work. Identity propagation is essential so every hop can evaluate origin and scope.

Q: When should organisations require user interaction instead of autonomous agent action?

A: Require user interaction when the action is ambiguous, high impact, or outside a clearly bounded charter. If the task can affect money, access, data exposure, or external commitments, keep the human available for confirmation. That reduces the risk of model-driven overreach and gives the control plane a clear decision point.

Technical breakdown

Interactive MCP sessions and user-present consent

In the interactive pattern, a user stays available while an AI agent communicates with one or more MCP servers. That allows the system to rely on elicitation, challenge questions, and step-up approval in ways that resemble conventional web authentication. The security property here is not autonomy but bounded delegation under active supervision. The identity question is still complex, because the MCP server may need to know whether it is authorizing the human, the agent, or both. The control objective is to keep the user in the decision loop whenever the action is sensitive or ambiguous.

Practical implication: Treat interactive MCP access like high-friction authorization, not like a persistent service account workflow.

Delegated and autonomous agents as non-human identities

Delegated and autonomous use cases both require the agent to be treated as its own principal, which means standard user-centric IAM patterns stop being sufficient. In delegated mode, the user assigns a task and then disappears, so the agent needs scoped authority that matches the task charter. In autonomous mode, the charter is durable and the agent may operate continuously without a human owner in the loop. That is where NHI governance becomes essential: policy has to describe what the agent may do, for how long, and under what evidence of intent or supervision.

Practical implication: Model AI agents as NHIs with explicit scopes, expiry, and audit requirements rather than as borrowed user sessions.

Chained MCP calls and identity propagation

Chained or transitive use cases are the hardest because one MCP server becomes a client to another server downstream. If the originating identity is not preserved, the downstream authorization decision loses context and may overgrant access or block legitimate work. This is a classic provenance problem: every hop can blur who initiated the action, what the agent was allowed to do, and which policy should apply. The control challenge is to carry identity and authorization context end to end without collapsing it into a generic machine token.

Practical implication: Require identity propagation across MCP hops so downstream services can evaluate origin, delegation, and scope at each step.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Identity loss across MCP hops is the central governance failure mode. The article correctly shows that chained use cases can break traditional trust boundaries when the downstream server cannot distinguish originator, intermediary agent, and final caller. That is not just an implementation detail. It is the point at which authorization becomes guesswork. NHI programmes should treat identity propagation as a hard requirement, because context-free tokens erase the evidence needed for safe access decisions.

Autonomous agents need NHI policy, not human-session mimicry. A durable agent charter is fundamentally different from a user session because the agent is expected to keep working when no human is present. That makes expiry, scoping, and review mandatory governance controls, not optional hardening. The field should stop pretending that human identity patterns can be stretched to cover autonomous software. Practitioners should define agent-specific authority models now, before those agents become operational dependencies.

Delegation must be explicit or it will become overreach. The concert-ticket and sell-the-car example is a useful illustration of why natural-language intent is not enough to authorize action. Agents can infer plausible subtasks that are still outside the business charter. That means enterprises need policy boundaries that translate intent into enforceable scope, especially when the user is absent. The practical conclusion is simple: task framing must be constrained by policy, not by model creativity.

MCP is exposing the runtime authorization gap in modern IAM. The protocol is not creating the trust problem so much as surfacing one that already exists in agentic workflows. Current IAM often assumes a stable human principal, a single session, and a clear owner for every request. MCP breaks all three assumptions. That makes the category a forcing function for NHI governance, where authority must be evaluated continuously instead of inherited from the initiating user.

Runtime identity context is becoming the new control plane for agentic systems. Once agents can call tools, call other agents, and act without supervision, the important security question is not whether authentication succeeded at login. It is whether every action can still be tied back to a valid principal, purpose, and scope. Practitioners should therefore design around provenance, not just authentication events. Without that, access reviews and incident investigations will be incomplete by design.

From our research:

• 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, according to AI Agents: The New Attack Surface report.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation, according to SailPoint's research.
• The governance gap becomes more acute as agent deployment scales, which is why the Ultimate Guide to NHIs remains the clearest baseline for lifecycle control.

What this signals

Identity propagation will become a procurement requirement, not an architectural nicety. If downstream services cannot see where a request originated, the system cannot reliably enforce task scope or investigate misuse. That means practitioners should ask vendors how they preserve origin, intermediary, and acting principal context across MCP chains before allowing production workloads into the platform stack.

With 98% of companies planning to deploy more AI agents within 12 months, per AI Agents: The New Attack Surface report, MCP governance will be judged by whether teams can still assign accountability after automation scales. The programme risk is not just more agents. It is more ambiguous authority.

Ephemeral agent trust debt: every delegated or autonomous action that lacks durable scope, owner, and review creates future remediation work. The longer teams rely on inherited human session patterns, the harder it becomes to prove why an agent was allowed to act. Practitioners should move that burden into policy now, before operational dependence hardens around weak assumptions.

For practitioners

• Define distinct policy models for each MCP use case Separate interactive, delegated, autonomous, and chained workflows in policy so the same authorization logic is not reused everywhere. Each mode should have its own scope, approval path, and expiry rules.
• Require explicit agent identity binding Bind every autonomous or delegated agent to a named non-human identity with owner, purpose, and review cadence. Do not let tool access rely on an inherited human session or an untracked service token.
• Preserve originating identity across MCP chains Pass origin, intermediary, and acting principal context to downstream MCP servers so each hop can make a scoped decision. If the platform cannot preserve that chain of custody, treat the workflow as high risk.
• Set charter limits for delegated tasks Translate natural-language intent into a bounded task charter, then block any subtasks that fall outside that charter even if the model treats them as plausible next steps. Review exceptions through an explicit approval process.
• Audit agent actions as NHI events Record who initiated the task, which agent executed it, what downstream tools were called, and which identity was presented at each step. Use those records for access reviews and incident response.

Key takeaways

• MCP makes identity context part of the security control, not just an authentication detail.
• Delegated and autonomous agents need explicit NHI governance because human session patterns do not map cleanly to durable software authority.
• Chained tool use is the clearest test of whether an organisation can preserve provenance, scope, and accountability across AI-driven workflows.

Key terms

• Model Context Protocol: An open protocol that lets AI agents connect to tools and data sources through a standard interface. In security terms, it shifts the question from simple API access to whether the agent's identity, scope, and intent can be enforced across multiple tool calls and chained requests.
• Non-Human Identity: A machine or software principal that needs access controls, ownership, and lifecycle management. This includes service accounts, tokens, bots, certificates, workloads, and AI agents. NHI governance focuses on what the principal may do, how long it may do it, and how that activity is audited.
• Delegated authority: Permission that a user grants for an agent to act on the user's behalf for a specific task or period. The security challenge is to keep the delegation narrow enough that the agent cannot infer broader business intent and overstep the original charter.
• 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.

Deepen your knowledge

MCP identity governance is a core topic in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are working through delegated or chained agent access, it is worth exploring.

This post draws on content published by SGNL: The four MCP use cases, a summary of an IIW discussion on identity and authorization. Read the original.