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.
Where MCP v2 stops short on audit accountability
MCP v2 improves traceability around the request path, but traceability is not the same as accountability. It can identify the agent, the account, and the action, yet it does not by itself preserve the human decision that authorised the act. That gap matters whenever an organisation needs a defensible record of who approved delegated agent work, not just which system executed it.
The practical issue is that an audit trail needs evidence of intent, not only event telemetry. If a person instructs an agent to take a sensitive action, the record must show more than protocol-level metadata. Otherwise, an incident review can confirm what happened, but still fail to prove which human accepted responsibility for the decision.
That distinction becomes important in regulated or high-consequence workflows where approval, delegation, and accountability are separable. A protocol can capture a transaction, but if it does not standardise the decision-maker field, organisations have to add that evidence elsewhere. In practice, the accountability layer has to sit above MCP and persist the human approval, the policy basis, and the linkage to the resulting action.
Why protocol logging is not enough for defensible audits
A useful audit record for agentic work needs to answer three different questions: what the agent did, under whose authority it acted, and who decided that the action should occur. MCP v2 is strongest on the first two. The third question is where accountability becomes organisational rather than protocol-native, which means the burden shifts to logging, workflow, or governance layers outside the protocol.
That is why teams should avoid treating protocol logs as a complete control. A log entry that names an agent and a token holder can still leave an evidentiary gap if the person who approved the action is not captured as a first-class field. For audit, compliance, and dispute handling, the missing element is often the human approval record, not the transport detail.
For background on how agent activity, attribution, and audit evidence fit together operationally, see AI Agent Observability, Audit and Incident Response Guide. Where agent identity and delegated authority matter, the more general design pattern is reflected in AI Agent Authorisation Guide.
What a separate accountability layer needs to capture
An accountability layer should preserve the human decision in a way that is durable, queryable, and resistant to later dispute. At minimum, that usually means the approver, the time of approval, the policy or ticket that justified the action, and a durable link between the approval and the specific agent execution event. Without that linkage, an audit can show chronology but not responsibility.
Practically, this often means combining workflow evidence with execution telemetry. The approval record lives in the control plane, while MCP logs show the execution plane. If those records are not correlated, the organisation may still be unable to prove who authorised a destructive, financial, or privileged action after the fact.
For agent identity, delegation, and lifecycle governance, AI Agent Identity Security: The 2026 Deployment Guide is a useful companion. If your main concern is how to keep agent actions within explicit delegated authority, AI Agent Identity Security: The 2026 Deployment Guide and AI Agent Observability, Audit and Incident Response Guide together cover the identity and evidence sides of the problem.
Risk and Threat Considerations
The main risk is accountability dilution: when an agent can execute a task, and the protocol records only the agent and account, responsibility can become ambiguous after an incident or dispute. That weakens auditability, complicates non-repudiation, and makes it harder to prove that a sensitive action was intentionally approved by a human.
Failure mechanism: The human decision is stored outside the protocol, or not linked tightly enough to the execution event, so the organisation can reconstruct the action but not the accountable approver.
Impact: Investigations, regulatory reviews, and internal challenge processes may be forced to rely on incomplete evidence, which reduces defensibility and can leave high-risk actions effectively unattributed.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 addresses the attack surface, NIST SP 800-53 Rev 5 sets the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Agent actions need accountable delegation and approval records. |
| ASI09 — Human-Agent Trust Exploitation | Audit gaps arise when humans overtrust agent execution without evidence. | |
| Recommendation — Bind each sensitive agent action to explicit human approval and delegated authority. Record approvals and challenge paths for human-directed agent actions. | ||
| NIST SP 800-53 Rev 5 | AU-2 — Event Logging | The question is about preserving evidentiary records for agent actions. |
| AU-10 — Non-repudiation | The gap is missing evidence of who decided the action. | |
| AC-3 — Access Enforcement | Delegated agent actions must still be constrained by explicit authority. | |
| Recommendation — Log approvals and executions with correlation identifiers for auditability. Maintain records that support non-repudiation for delegated actions. Enforce approval-based access decisions before agent execution. | ||
| ISO/IEC 27001:2022 | A.5.28 — Collection of evidence | Audit accountability depends on preserving admissible evidence of decisions. |
| A.5.15 — Access control | Accountability depends on controlling who may authorise and execute actions. | |
| Recommendation — Retain linked approval and execution evidence for material agent actions. Define and enforce who can approve delegated agent activity. | ||
Practitioner Guidance
What to verify: Check whether every delegated agent action that matters has a durable approval record, a unique approval ID, and an immutable link to the execution event. If you cannot trace from the action back to the approving human in one query path, the audit design is not complete.
Decision rule: If the action could create financial, regulatory, privileged-access, or customer-impacting consequences, treat the approval record as mandatory evidence, not as optional workflow context. If the action is low consequence, lighter evidence may be acceptable, but the boundary should be explicit and reviewed.
Practitioner takeaway: MCP v2 can help explain what the agent did, but not by itself who should be held accountable for deciding that it should happen. The control objective is to make the human decision as durable and searchable as the machine action.