Notifications
Clear all
Topic starter
26/08/2026 11:51 am
TL;DR: MCP v2 makes every request easier to inspect and authorize, but it still cannot record which person decided an agent action, according to Cakewalk’s analysis. That leaves auditability split across protocol, gateway, and identity systems, and it means governance for agentic workflows still depends on external accountability design, not the wire protocol alone.
NHIMG editorial — based on content published by Cakewalk: MCP v2 improves agent access control and still cannot say who decided
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- 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.
- Separate consent events from action authorization Do not treat an initial click, browser open, or accept gesture as final approval.
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.
👉 Read Cakewalk's analysis of MCP v2, agent access control, and audit accountability →
MCP v2 and the accountability gap in agent access logs?
Explore further
26/08/2026 11:51 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: MCP v2 improves agent access control but not audit accountability
