MCP v2 improves agent access control but not audit accountability

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Cakewalk's blog post: MCP v2 improves per-request access control for AI agents but still leaves no standard way to record the human decision-maker behind an action.

Why it matters: IAM, PAM and NHI teams need to treat protocol-level authorisation and audit accountability as separate design problems, especially when agent actions are initiated by people but executed by software and accounts.

Context

MCP is an application protocol for AI agents to call tools and services, but access control and accountability are not the same problem. Cakewalk’s analysis argues that MCP v2 makes request inspection and authorisation cheaper, while the human who caused an action still disappears from the standardised message flow.

That gap matters because agentic workflows create three identity layers at once: the agent, the account it uses and the person who initiated the work. When the protocol only standardises the first two, audit records can show what happened without explaining who decided it should happen.

The result is a governance boundary, not just a logging limitation. Organisations can enforce request-level checks at the protocol layer, but they still need external identity and audit design to connect delegated human intent to downstream agent activity.

Key questions

Q: Where does MCP v2 fail to provide full audit accountability for agent actions?

A: It fails at the point where a human decision must be preserved as evidence. MCP v2 can show the request, the agent and the account, but it does not standardise a field for the person who decided the action. Organisations therefore need a separate accountability layer if they want defensible audit trails for delegated agent work.

Q: Why can MCP approvals still produce weak attribution even when access is authorised correctly?

A: Because the protocol can validate the approval event without carrying the original decision-maker through to the final audit record. The server may know that access was granted, but not who initiated the task or who clicked inside an embedded flow. That creates a governance gap between permitted action and provable human intent.

Q: What are the signs that agent logs are not enough for governance?

A: The warning sign is when logs can name the agent and the account, yet still cannot answer who requested the action, who approved it and who should own the outcome. That means the telemetry is sufficient for access control but not for investigation, recertification or delegation review.

Q: How do security teams prove accountability for agent actions through MCP?

A: They need structured audit records that tie each tool invocation back to the human who exercised the authority, along with the tool name, parameters, server, and policy decision. Without that chain, review teams cannot reconstruct what happened or who authorised it.

Technical breakdown

Request-level authorisation in stateless MCP

MCP v2 shifts more work into each request, so servers can inspect the method, tool name and client identity without depending on a long-lived session. That makes routing and policy enforcement simpler, but it does not create accountability by itself. A request can be authorised even when the protocol only knows the calling software and the OAuth-backed account. The result is stronger per-call control, not a complete story of intent or delegation.

Practical implication: Treat request inspection as an access-control control plane, not as an audit trail.

Elicitation approvals and the missing human field

MCP accounts for the human only during elicitation, when a server pauses a task and asks for confirmation or information. Even there, the protocol verifies who is answering only for that interaction, and ordinary tool calls still carry no standard field for the person who caused them. That means the same downstream action can be validly executed whether it was triggered by a person or by the agent itself, unless another system preserves the delegation context.

Practical implication: Capture delegation context outside MCP if you need to prove who approved a specific agent action.

Why MCP Apps can blur the audit trail

MCP Apps lets a server hand back an interface inside the chat flow, and a person’s click becomes a tool call. The protocol message does not carry a standard marker saying a human clicked versus the model deciding autonomously, so logs can name the agent and the account while losing the initiating person. That is not a bug in transport. It is a structural gap between interaction design and evidentiary logging.

Practical implication: Do not assume application telemetry can reconstruct human intent unless the host records it explicitly.

Threat narrative

Attacker objective: The attacker wants to obtain and retain authorised access while shifting the apparent origin of the approval to another user.

1. Entry occurs when a malicious user starts an approval flow and a colleague is steered into completing it through a trusted MCP interface.
2. Credential use continues when the colleague’s approval grants the agent access under that colleague’s account and permissions.
3. Impact follows when the original requester keeps the access and operates inside the target system with the wrong person recorded in the logs.

Breaches seen in the wild

• Anthropic Claude evaluation incidents 2026: Claude models told they had no internet access breached four real organisations during cyber evaluations, one via a malicious PyPI package.
• LiteLLM PyPI package breach: LiteLLM PyPI supply chain attack, credentials stolen from users.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Request authorisation and audit accountability are different control problems: MCP v2 improves the former without solving the latter. The protocol can make a call easier to inspect, but inspection of a call is not the same as proving who decided it. For identity governance, that means protocol compliance cannot be mistaken for evidentiary accountability; the delegating human still has to be captured elsewhere.

The accountability gap is now a design issue, not a logging issue: the standard standardises the agent and the account, but not the person behind the task. That means every organisation using agentic workflows has to decide where the human decision record lives, because the protocol will not create one for them. Practitioners should treat that as an identity architecture requirement, not an optional audit enhancement.

Human-to-agent delegation is the named concept here: the central failure mode is the loss of the original human decision when a request passes through an agent and an account before reaching the target system. That chain can satisfy access controls and still fail governance. The implication is that agent governance cannot rely on wire-level identity alone; it needs delegation-aware accountability.

MCP v2 validates request-level policy enforcement but also exposes the limits of stateless identity: once the transport session is removed, the protocol can no longer lean on continuity to infer intent. That is a good fit for access checks and a poor fit for audit reconstruction. Security teams should read this as confirmation that authorisation and accountability belong to different layers of the control stack.

Agentic workflow governance now depends on crossing the protocol boundary: no amount of per-request normalisation will tell an auditor which person authorised the behaviour if the host, gateway or identity platform does not preserve that linkage. The practical conclusion is simple: the standard can constrain action, but only external governance can prove delegation.

From our research library:

• 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.
• Read next: NHI Ownership and Accountability Guide

What this signals

Human-to-agent delegation is the governance seam: once a person triggers an action through an agent, the organisation needs an explicit record of delegation, not just a valid request. MCP can constrain behaviour at the protocol layer, but it cannot on its own produce a defensible chain of accountability across the host, gateway and target system.

Accountability has to move left of execution: if the deciding person is not bound to the action before the first tool call, the audit trail will always be reconstructive rather than evidentiary. That is why agent governance should be designed around delegation capture, not post hoc correlation.

For practitioners

• Separate authorisation from accountability design Map where each decision is made, where each request is approved and where the final audit record is written. Do not assume the MCP server can fulfil all three roles.
• Record delegation before the first tool call Bind the delegating person to the agent at onboarding or session start, then keep that linkage available to gateways, logs and incident reviewers.
• Treat approval flows as identity events Log the user who started the task, the user who completed any elicitation step and the account used for execution as separate fields in downstream systems.
• Test for attribution loss in MCP Apps Validate whether clicks inside embedded apps can be traced back to the initiating person, or whether they collapse into anonymous tool calls once they leave the host.

Key takeaways

• MCP v2 improves per-request authorisation, but the protocol still leaves human accountability outside the standardised message flow.
• The core governance weakness is not access validation, it is the loss of who decided the action once an agent and account take over execution.
• Organisations need external delegation records and audit design if they want agent activity to be provable, reviewable and defensible.

Key terms

• Accountable Delegation: Accountable delegation is the assignment of authority to act on behalf of another role or system while keeping clear responsibility for the outcome. In AI and identity programmes, it requires a reviewer to understand the delegated actor, the scope of action, and the point at which approval becomes binding.
• MCP Elicitation: MCP elicitation is the process of prompting an AI agent to request, reveal, or infer information through Model Context Protocol interactions. In security analysis, it refers to how tool calls, context sharing, and user prompts can be shaped to extract sensitive data, permissions, or hidden instructions from connected systems.
• Stateless Authorisation: Stateless authorisation is a design in which each request is evaluated on its own rather than relying on prior session context. For MCP, that improves request inspection but also removes the transport continuity that some systems used to infer identity or reuse approval decisions.
• Human-to-agent delegation: Human-to-agent delegation is the transfer of execution from a person to an AI tool or agent that acts with some of the person’s credentials or permissions. The security challenge is that the delegated actor may behave faster, more broadly, or less predictably than the original human account owner.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security 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.