MCP changes identity and authorization for AI agent workflows

At a glance

What this is: This is Cerbos’s analysis of how MCP changes AI agent identity and authorization by introducing delegated access, long-lived sessions, and runtime policy enforcement.

Why it matters: It matters because IAM, PAM, and NHI teams now have to govern AI actions as runtime authorisation events, not just static integrations or one-time logins.

Context

MCP creates a standard way for AI systems to discover and invoke tools, but that convenience exposes a governance gap that classic API security models do not fully cover. The core issue is not whether an AI can call a tool, but how identity, consent, and scope are preserved when the caller is an agent acting on behalf of a user.

For identity programmes, the shift is from static integration to runtime authorisation. Session continuity, delegated tokens, and contextual policy checks become part of the control plane because an AI workflow can span many tools, many steps, and many decisions before a human ever sees the outcome.

Cerbos frames this as a practical security problem, not a protocol debate. Once an AI agent can initiate actions, policy has to decide what the agent may do, when it may do it, and under which user context the action is legitimate.

Key questions

Q: What breaks when AI agents use MCP without strong scope enforcement?

A: Least privilege breaks in practice because the agent can execute far more than the business task requires. When tool permissions are broad, the difference between legitimate use and abuse becomes narrow, and a normal workflow can become a data exposure or unauthorized action path without any obvious boundary crossing.

Q: Why do MCP-based AI workflows need runtime authorization checks?

A: They need runtime checks because the right to call a tool can change as the session evolves, the task expands, or the risk of an action rises. A one-time login does not tell you whether a later delete, export, or privilege change is still legitimate. Runtime policy keeps the decision tied to current context, not stale approval.

Q: How do security teams know if MCP access policies are too coarse?

A: If a single role or policy grants access to broad datasets or multiple tools when the task needs only one resource, the policy is too coarse. The signal is overpermission, not just denied requests. Good MCP governance should show client-specific consent, narrow scopes, and auditable request context.

Q: How should teams govern AI agents that use MCP?

A: Treat each connected agent as a non-human identity with an owner, a scope, and a review cycle. The practical control set is familiar: least privilege, secret rotation, access expiration, and auditability across the systems the agent can reach.

Technical breakdown

How MCP changes the trust boundary for AI tool access

MCP standardises the interface between an AI client and external tools, but it also changes where trust is enforced. Instead of one application calling one API with a fixed service identity, the protocol supports a user, an AI client, and a resource server in one chain. That makes identity propagation, consent, and delegated scope part of the protocol design, not an afterthought. The important technical shift is that the AI does not simply authenticate once and act forever. Each tool invocation can require contextual authorisation, and the server must understand who the original user is, what the agent is allowed to do, and whether the current session still matches that intent. Practical implication: treat MCP as a runtime trust boundary, not just a transport layer.

Practical implication: enforce per-action authorization at the MCP server boundary, not at initial connection time.

Why session continuity matters in MCP authorization

MCP is built for long-lived, stateful interactions, including streaming outputs and reconnectable sessions. That is very different from traditional request-response APIs, where each call is isolated and easy to audit in a single transaction. In an AI workflow, a tool call may span multiple operations, pause mid-stream, and resume later, which means the authorization decision must survive disconnects, reconnects, and partial completion. If the session context is lost, the system risks either over-permitting a resumed task or blocking a legitimate one because it cannot reconstruct the user context. This is why session state and token design are inseparable from access control in MCP. Practical implication: bind policy decisions to session context and re-evaluate them when the agent resumes or changes task scope.

Practical implication: bind policy decisions to session context and re-evaluate them when the agent resumes or changes task scope.

Why runtime policy checks beat blank-check tokens for AI agents

The article’s central authorization point is that an AI agent should not receive a broad credential that can do whatever the user can do. That model collapses least privilege into a single token and makes misuse, prompt abuse, or accidental damage much easier. Instead, the control pattern is delegated and scoped access, often short-lived and tied to a specific transaction. This is where policy engines matter: they can allow, deny, or require step-up for each action based on identity, resource, time, and risk context. In practical terms, the policy is the guardrail that keeps an MCP-connected agent inside its intended task boundary. Practical implication: move from coarse credential issuance to action-by-action policy enforcement with explicit scope limits.

Practical implication: move from coarse credential issuance to action-by-action policy enforcement with explicit scope limits.

Threat narrative

Attacker objective: The objective is to use AI-mediated access to perform actions the user did not explicitly intend or to cause operational damage through over-scoped authorization.

1. Entry occurs when an AI assistant or coding agent connects to an MCP server and gains a delegated path to tools and data sources.
2. Escalation occurs if that delegated access is too broad, poorly scoped, or not re-checked as the session progresses through multiple tool calls.
3. Impact follows when the agent executes destructive or high-risk actions, such as database changes or bulk operations, under authority that exceeds the intended task.

Breaches seen in the wild

• AI agent retail card theft campaign 2026: AI agents breached 27+ retailers for about $25 each, used cloud keys and a Secrets Manager dump, and stole 600,000+ payment cards.

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

NHI Mgmt Group analysis

Runtime authorization, not protocol adoption, is the real MCP question: MCP standardises how AI agents reach tools, but it does not by itself solve who may do what, when, and under which user context. The security boundary has moved from integration plumbing to per-action policy enforcement, and that is where IAM teams now carry the risk. The practical conclusion is that MCP success depends on authorization architecture, not connector count.

Delegated access must be treated as a constrained identity state, not a convenience feature: An agent acting on behalf of a user is not equivalent to the user. The permissions exchanged in that moment should be narrow, contextual, and time-bound because the agent’s operational latitude is wider than the user’s immediate intent. Practitioners should stop thinking in terms of app-to-app trust and start thinking in terms of task-scoped authority.

Session continuity creates an identity governance gap that traditional request models do not have: MCP sessions can survive disconnects, resume later, and carry forward partial work. That means the authorisation decision has to outlive the first approval moment without becoming a standing privilege. The implication is that governance has to track not just access granted, but access still valid for the current task state.

Zero standing privilege becomes a runtime control pattern for AI agents: The old assumption that access can be granted once and relied on until revoked does not fit AI workflows that make many micro-decisions in one session. Access review cadences, static roles, and blank-check tokens all assume a stable operator behind the action. When the actor is an AI agent, the governance model has to assume ephemeral, continuously re-evaluated authority instead.

Identity blast radius is the concept MCP makes visible: Once one agent can call many tools through one delegated path, the blast radius of a mis-scoped token expands across the connected workflow. That is why policy engines, step-up checks, and audit trails matter together. Practitioners should measure MCP risk by how far a single delegated action can propagate, not by whether the protocol itself is standardised.

From our research library:

• Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security, according to the 2026 Infrastructure Identity Survey.
• Read next: Agentic AI Identity Guide

What this signals

Identity blast radius will become a design metric for MCP programmes: The more tools an agent can reach through one delegated path, the more important it becomes to measure how far a single approval can travel. MCP makes that blast radius visible, which means access scope and session state need to be designed together, not separately.

Policy engines become the practical control point for agentic access because they can re-evaluate each action against current context. That matters when a session can resume, branch, or escalate after the original approval moment, because static roles cannot express task-bound authority cleanly.

For practitioners

• Define task-scoped agent authority Map every MCP connection to a specific user intent, allowed resource set, and expiry condition so the agent cannot reuse authority outside the task it was given.
• Enforce per-action policy checks Evaluate each tool invocation at the MCP server boundary using contextual rules for identity, resource sensitivity, and action risk instead of relying on initial login approval.
• Require step-up for destructive actions Pause high-impact actions such as deletes, bulk updates, or privilege changes and require a human confirmation or re-authentication before execution continues.
• Log agent sessions end to end Record the original user, agent identity, tool invoked, decision outcome, and any resumed session state so audits can reconstruct how authority was used.
• Reduce token breadth and lifetime Issue short-lived delegated credentials with the smallest practical scope so a compromised or misused agent has less time and less reach.

Key takeaways

• MCP changes the control problem by moving AI integrations from static access to delegated runtime authorisation.
• The main risk is not the protocol itself, but the assumption that an AI agent can hold broad, reusable permission safely.
• Practitioners should design for task-scoped access, step-up checks, and auditability before MCP connections go live.

Key terms

• Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.
• Delegated Access: Delegated access is permission granted to one identity to act on behalf of another user, service, or system. In NHI environments, this usually appears in OAuth-connected apps and automation tooling. It is powerful, but it must be tightly scoped and reviewed because it can persist long after the original business need ends.
• Session Continuity: Session continuity is the ability to preserve a user's authenticated state as they move between devices or locations without forcing a full re-login. In clinical environments, it reduces interruptions while still allowing lock, timeout, and revalidation controls to protect the session when risk changes.
• Runtime Authorisation: Runtime authorisation is the practice of deciding access while a task is in progress, rather than only at provisioning time. It matters for NHIs because credentials and entitlements can change risk mid-session, especially when automation or AI agents interact with sensitive systems.

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.