MCP v2 improves agent access control but not audit accountability

At a glance

What this is: MCP v2 makes agent requests cheaper to authorize and inspect, but it still cannot standardise who the human decision-maker was.

Why it matters: IAM, NHI, and autonomous-agent programmes all need audit records that bind person, agent, and account together, because authorization without attribution leaves governance gaps.

By the numbers:

• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.

👉 Read Cakewalk's analysis of MCP v2, agent access control, and audit accountability

Context

MCP is the protocol layer that lets AI agents call tools and systems, but protocol-level authorization is not the same thing as identity governance. The core problem in this article is attribution: the request can identify the agent and the account, yet still fail to identify the person who decided the action should happen.

For IAM and NHI teams, that distinction matters because approvals, audit trails, and delegated access controls all depend on linking a decision to a responsible human or policy owner. MCP v2 improves request inspection and per-call checking, but it does not solve delegated accountability on its own.

The article is therefore about a governance gap, not a transport improvement. It is a typical failure mode for emerging agentic workflows: the system can tell you that something was allowed, but not who meaningfully caused it.

Key questions

Q: What breaks when MCP approvals are not bound to the original requester?

A: The approval can be completed by the wrong person, turning a delegated decision into an unintended access grant. In agent workflows, that means the account that finished the approval may not be the one that should own the resulting action, which undermines both accountability and audit integrity.

Q: Why do MCP-based agent workflows still need external audit controls?

A: Because the protocol can show which agent acted and which account it used, but not which human decided the action should happen. External audit controls are needed to correlate delegation, approval, and execution across systems so the organisation can reconstruct intent after the fact.

Q: How do security teams know whether MCP server governance is working?

A: They should be able to answer four questions at any time: what servers exist, which are official, what credentials they can use, and what systems they contact. If those answers are unclear, governance is not working. The signal is not just fewer alerts, but clear attribution and scoped access across the fleet.

Q: Who is accountable when an MCP server authorises the wrong action?

A: Accountability sits with the teams that designed and operated the consent, token validation, and scope controls, because MCP makes authorisation decisions part of the system boundary. In regulated environments, the question is not only who clicked approve but who allowed client identity, audience, and delegation checks to remain incomplete.

Technical breakdown

Why MCP v2 is stateless but not identity-complete

Revision 2026-07-28 removes the transport handshake and pushes more metadata into each request, which makes routing and per-call inspection easier. That is a protocol efficiency change, not an identity resolution model. The request can carry the agent name and the OAuth token for the account, but the protocol still has no standard field for the person whose intent triggered the action. In practice, that means the wire format can answer what ran and under which credential, while leaving governance systems to reconstruct who decided. The gap is structural because the missing subject is not a parsing problem, it is an attribution problem.

Practical implication: treat MCP request metadata as evidence of execution, not proof of human authorisation.

How elicitation and approval flows can be abused

MCP’s elicitation step is the one place where the protocol asks a person to answer mid-task, usually for approval. The phishing-style attack in the specification works because the approval is bound to the flow, not necessarily to the original requester, so a second person can complete the approval and transfer effective access. The server must verify that the person who finishes the approval is the same person who started it. Without that check, approval becomes a reusable access grant rather than a delegated decision.

Practical implication: bind approval completion to the original initiator, not just to a signed-in account.

Why MCP Apps create audit ambiguity at the point of action

MCP Apps let a person interact with rendered interfaces inside the agent workflow, but the resulting tool call can look identical whether the agent clicked or the human clicked. The server receives a normal action message, while the human decision lives only inside the host unless another control captures it. That makes the audit trail ambiguous by design unless the gateway or host adds its own attribution layer. The protocol standardises message shape, not the chain of intent behind the message.

Practical implication: instrument the host or gateway to preserve decision provenance before the tool call leaves the environment.

NHI Mgmt Group analysis

MCP improves authorization fidelity, but not accountability fidelity. The protocol now makes it cheaper to evaluate whether a request is allowed, yet the human decision-maker still has no standardised place in the message. That separation is the central governance issue for agentic systems, because authorisation without attribution cannot satisfy audit, legal, or operational ownership requirements. Practitioners should treat MCP as an execution layer, not a complete accountability model.

The missing field is not a minor logging gap, it is a broken governance assumption. Identity programmes were designed on the assumption that a delegated action can be tied back to a responsible person with durable evidence. MCP Apps and approval flows show that assumption failing at runtime, because a person can trigger or complete a flow without the protocol preserving the decision chain. The implication is that governance must be assembled above the protocol, not expected from it.

Approval-based agent control breaks when the approval can be detached from intent. The article’s phishing example is not just a social-engineering story, it is a demonstration that a valid approval can still represent the wrong human decision. That undermines any control model that treats signed-in consent as sufficient provenance. For IAM and NHI teams, the practitioner conclusion is clear: approval state and decision provenance are different security objects.

Stateless transport creates a stronger need for external identity correlation. When every request is self-contained, gateways, hosts, and policy engines become the places where person, agent, and account must be stitched together. That shifts MCP governance toward the same discipline used in NHI lifecycle control, where the authoritative record is assembled from multiple systems rather than trusted from one protocol alone. Teams should design for cross-system provenance, not protocol completeness.

Named concept: decision provenance gap. This article defines the gap between an allowed agent action and the human who meaningfully caused it. The protocol can prove that a tool was called and a token was accepted, but not who decided the call should happen. Practitioners should expect this gap to widen as agentic workflows move from chat interfaces into operational systems.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, according to AI Agents: The New Attack Surface report.
• A separate finding from the same research shows that only 52% of companies can track and audit the data their AI agents access, leaving 48% with a compliance and investigation blind spot.
• For a deeper control lens, OWASP Agentic Applications Top 10 helps teams map these failures to runtime agent risk and tool misuse.

What this signals

The governance issue exposed here is not limited to MCP. Any agentic workflow that can act on delegated credentials will eventually need a provenance layer that survives across hosts, gateways, and downstream SaaS systems, because the protocol itself will rarely be the authoritative source of accountability.

Decision provenance gap: this is the operational blind spot where a valid agent action no longer tells you who meaningfully caused it. As AI agents move closer to business systems, IAM and NHI teams will need controls that correlate initiation, approval, and execution rather than trusting one message or one log source.

The shift aligns with the broader agent-risk picture described in the OWASP Agentic AI Top 10 and the NIST AI Risk Management Framework, where governance has to extend beyond access checks into traceable decision ownership. Teams that do not redesign for that layer will keep seeing allowed actions that still fail audit scrutiny.

For practitioners

• Bind approvals to the original initiator Require the person who completes an MCP approval to match the person who started it, and reject flow completion when those identities differ. Preserve the original requester identity in a separate immutable record so the approval cannot be repurposed by a second party.
• Capture decision provenance outside the protocol Log the delegating user, the agent identity, the target app, and the policy decision in a gateway or host control that sits before tool execution. Treat the MCP message as execution evidence and the gateway record as the authoritative accountability record.
• Separate consent events from action authorization Do not treat an initial click, browser open, or accept gesture as final approval. Wait for the server-side outcome of the approval flow and only then allow the agent to proceed with the requested tool call.
• Review agent audit trails for missing human attribution Test whether your logs can answer who started the request, who approved it, and which account executed it. If any one of those is missing, the audit trail is incomplete for governance and incident reconstruction.

Key takeaways

• MCP v2 improves per-request authorization, but it still leaves human decision ownership outside the standard.
• The core risk is not just access abuse, it is approval detachment, where the wrong person can complete a valid flow.
• Practitioners need an external provenance layer that binds initiator, approver, agent, and account into one audit record.

Key terms

• Decision Provenance: Decision provenance is the ability to explain what signals, data, and reasoning context led to a system’s choice. For autonomous or agentic systems, it is critical because review teams need to know not only what happened, but why the decision was made and where human authority still applies.
• Elicitation: Elicitation is the MCP mechanism that pauses a task and asks a person for information or confirmation. It is the protocol’s only built-in human checkpoint, but it still requires external controls to ensure the responder is the same person who started the flow and that the answer is recorded accurately.
• Agent Activity Audit Trail: An agent activity audit trail is the full record of what an AI agent and its tools did, when they did it, and under which identity or policy. It supports compliance, incident investigation, and control validation by preserving evidence in a form that can be exported and reviewed later.
• MCP Gateway: The control layer that relays assistant intent to tools and data sources through the Model Context Protocol. In practice, it becomes a policy boundary, not just a transport layer. If it trusts model output too early, it can turn unverified reasoning into real-world execution or disclosure.

What's in the full article

Cakewalk's full analysis covers the operational detail this post intentionally leaves for the source:

• The exact MCP approval flow and why the same flow can be completed by the wrong person.
• The request and header changes introduced in revision 2026-07-28 for per-call inspection.
• The difference between protocol-level authorization and externally assembled audit provenance.
• The gateway pattern Cakewalk describes for correlating person, agent, app, and policy decisions.

👉 Cakewalk's full post covers the approval flow, stateless request changes, and the audit gap in detail.

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.