MCP changes identity and authorization for AI agent workflows

At a glance

What this is: MCP is an open protocol for connecting AI agents to tools and data, and its key finding is that identity, delegation, and runtime authorization become the governing controls.

Why it matters: It matters because IAM, NHI, and human access programmes must now govern AI-initiated actions with delegated credentials, contextual policy, and auditability rather than one-time app consent.

👉 Read Cerbos's discussion of MCP, AI agents, and authorization design

Context

Model Context Protocol, or MCP, is a standard way for AI systems to discover and invoke tools and data sources through a common interface. The governance problem is that the moment an agent can act on behalf of a user, identity moves from static sign-in to runtime authorization.

The article frames MCP as an integration layer, but the security issue is broader than tool wiring. AI agents introduce delegated access, streaming sessions, and multi-party authorization flows that existing API and IAM patterns only partially cover, especially when the agent can chain actions across multiple systems.

Key questions

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

A: Security teams should govern MCP-enabled agents as delegated identities with action-level limits, not as trusted extensions of the user. That means every tool call needs runtime authorization, short-lived credentials, and audit trails that preserve who authorised the action, what was attempted, and whether the request was allowed, denied, or escalated.

Q: Why do AI agents complicate existing IAM controls?

A: AI agents complicate IAM because the request path is no longer a single human login followed by static app access. The agent may chain actions across multiple tools, keep state across a session, and act asynchronously, so access decisions must be contextual and continuous rather than based only on initial authentication.

Q: What breaks when an AI agent is given a blanket token?

A: A blanket token breaks least privilege by allowing the agent to use more rights than the task requires, and it breaks accountability because the resulting actions are hard to distinguish from broader app use. In practice, that expands blast radius, weakens audit clarity, and makes destructive actions harder to contain.

Q: What frameworks should teams use to control MCP and agent access?

A: Teams should combine zero-trust authorization, NHI governance, and agent-risk guidance such as OWASP Agentic Applications Top 10. The practical test is whether each tool invocation is checked against identity, scope, and context before execution, with logs detailed enough to support review and incident investigation.

Technical breakdown

MCP sessions and tool invocation

MCP uses a client-server pattern in which an AI client discovers tools exposed by an MCP server and invokes them over a common protocol, typically JSON-RPC under the hood. That differs from plain REST because the interaction can be long-lived, stateful, and streaming, which matters when an agent needs intermediate results while completing a multi-step task. The architectural shift is not just transport. It is about making tool access machine-readable, session-aware, and reusable across different AI clients and servers.

Practical implication: treat each MCP tool as an authorization object, not just an API endpoint.

Delegated identity and scoped authorization

The hardest security problem in MCP is that the agent is acting on behalf of a user, but it is not the user. That creates a three-way relationship between human identity, AI client, and resource server, with the need to propagate original user context and limit what the agent can do. The article points to short-lived transaction tokens as one response, which would encode who authorised what, for which actions, and within what scope. That is a major shift from blanket bearer tokens.

Practical implication: design delegated credentials so they are task-scoped, time-bounded, and auditable.

Runtime policy enforcement for agent actions

MCP security depends on external policy checks at the moment of execution, not on trusting the model to self-limit. A policy engine can evaluate identity, resource, action, time, and context before allowing a tool call, and can require step-up confirmation for destructive or high-impact operations. This is the same logic used in zero-trust authorization, but applied inside agent workflows where the call sequence is dynamic and the risk is session-specific. The control point is the policy decision, not the AI prompt.

Practical implication: enforce allow, deny, or step-up decisions before each tool invocation.

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

Blanket app tokens are the wrong mental model for AI agent access: MCP turns a one-shot integration into a delegated action chain, so the access question is no longer whether an app can connect, but what the agent can do at each step. The article shows why scopes, consent, and transaction limits need to be expressed per action, not per integration. Practitioners should treat every agent session as a bounded delegation event, not a durable entitlement.

Stateful AI sessions create a governance gap that stateless API controls do not cover: MCP supports long-lived interactions, streaming outputs, and reconnectable sessions, which means authorization must survive pauses, retries, and context changes. Traditional request-response controls assume each call is isolated, but agent workflows accumulate state across tool use. The implication is that policy must follow the session, not just the credential.

Runtime authorization is now the decisive control plane for agentic workflows: The article makes clear that trust in the model is not a security boundary. External policy enforcement, step-up checks, and audit logs are what prevent an agent from converting intent into damage. That aligns with OWASP Agentic Applications Top 10 thinking and with zero standing privilege principles. Practitioners should design for decision-time control, not prompt-time restraint.

Identity and authorization for AI agents must be governed as NHI, even when a human is in the loop: The human may own the account, but the agent executes the action, which means the non-human executor is the identity risk surface. That changes entitlement reviews, logging, and offboarding because the meaningful subject is the agent-session pair, not the human login alone. Practitioners should update NHI governance to include agent-mediated delegation chains.

MCP standardisation will expose weak authorization design faster than it simplifies integration: Common protocol support makes it easier to connect more tools to more agents, which increases the blast radius of any mistake in policy design. That does not make MCP risky by itself, but it does remove the friction that previously limited exposure. Practitioners should assume broader agent connectivity and verify the policy model before adoption.

From our research:

• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so, 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.
• That policy gap grows as deployments scale, and 98% of companies plan to deploy even more AI agents within the next 12 months, according to AI Agents: The New Attack Surface report.

What this signals

Delegation-chain visibility is becoming a baseline requirement: AI agent programmes will fail governance reviews if teams cannot show who authorised the action, which tool was called, and how the permission was bounded. With 48% of organisations lacking a complete audit view into AI agent data access, per AI Agents: The New Attack Surface report, the oversight gap is already operational, not theoretical.

Runtime policy enforcement is the control pattern that will separate safe adoption from uncontrolled expansion. Teams that already use policy-as-code, contextual authorization, and zero standing privilege will adapt faster because they can place decision points directly in front of agent actions, including step-up checks for high-impact operations.

Agent session governance: the next maturity step is to treat an AI session as a governed identity event, not just an application transaction. That means tying identity, tool selection, and audit evidence together so reviews can prove what the agent was allowed to do, not just what the human asked for.

For practitioners

• Define agent-scoped authorization boundaries Map each MCP tool to a specific action class, data class, and risk tier so the agent never inherits broad application rights by default.
• Issue short-lived delegated credentials Use task-bound tokens with narrow scopes and clear expiry so the agent can complete the requested workflow without durable standing access.
• Enforce policy checks at execution time Place a policy decision point in front of every tool invocation so allow, deny, and step-up outcomes happen before the action executes.
• Log the full delegation chain Record the human requester, AI client, tool server, action decision, and outcome for each session so audit trails can reconstruct what the agent did and why.

Key takeaways

• MCP makes AI integrations more standardized, but the real security issue is delegated identity and runtime authorization.
• AI agent governance fails when teams rely on blanket tokens, static consent, or model self-restraint instead of per-action policy.
• Practitioners should design MCP access as bounded delegation with auditability, step-up control, and zero standing privilege.

Key terms

• Model Context Protocol: An open protocol that lets AI clients discover and invoke tools and data sources through a shared interface. In practice, it standardises how an AI system asks for operations, receives results, and maintains session context across multiple tool calls.
• Delegated identity: A permission model where one identity is allowed to act on behalf of another within a bounded scope. For AI agents, the important point is that delegation must be explicit, task-limited, and traceable, because the agent is not the same actor as the human who requested the work.
• Runtime authorization: A decision process that evaluates whether a specific action should be allowed at the moment it is about to occur. For agent workflows, runtime authorization is the control that matters most because the agent can chain decisions, change tools, and continue acting inside a single session.
• Transaction token: A short-lived credential that encodes a specific user-authorised action set for a limited time. It is narrower than a general access token because it is intended to constrain an agent to a particular task, context, or workflow rather than to broad account access.

Deepen your knowledge

MCP governance and delegated authorization are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for AI agent workflows that look similar to this article, the course is a relevant next step.

This post draws on content published by Cerbos: discussion of MCP, AI agents, and authorization design. Read the original.