TL;DR: MCP, A2A and ACP solve different transport problems, but none of them can express delegated authority, constraint, revocation or approval, and a six-dimension gap analysis scores every protocol at 2 out of 12 or worse, according to Agentic Fabriq. The practical lesson is that protocol maturity is not governance maturity, and the missing layer must sit above the standards themselves.
At a glance
What this is: This analysis separates MCP, A2A and ACP into distinct protocol layers and finds that none of them can carry governance semantics such as delegated authority, approval or revocation.
Why it matters: It matters because IAM and NHI teams cannot treat protocol standardisation as a substitute for enforceable delegation, auditability and withdrawal of access.
By the numbers:
- A six-dimension governance taxonomy scores five agent protocols at 2 out of 12 or worse, with voting, dissent preservation and human escalation absent from all five.
Context
Agent protocol stacks are becoming part of identity infrastructure, but the security model they expose is still narrower than the governance model enterprises need. The core issue is delegated authority: who is acting for whom, under what limits, and how that authority is revoked when the task ends.
This article separates transport from governance. MCP carries agent-to-tool calls, A2A carries agent-to-agent collaboration, and ACP carries agent-to-money flows, but none of them natively expresses approval, constraint, or revocation across the whole delegation chain.
That gap is not theoretical. The article argues that even when protocols can move a governance decision as data, they cannot interpret or enforce it, which means the control plane still has to live above the protocol layer.
Key questions
Q: What breaks when delegated agent authority is not tied to an authenticated device?
A: The trust chain loses its anchor. Without device binding, it becomes much harder to distinguish a valid delegated action from one that is replayed, reused, or taken outside the intended context. That weakens accountability and makes the inherited authority harder to contain or revoke.
Q: Why does protocol adoption not prove governance readiness for AI agents?
A: Adoption shows that teams are installing the standards, not that those standards can enforce policy. A protocol can be stable, widely deployed and technically rigorous while still being unable to express approval, dissent, revocation or human escalation. Governance readiness depends on whether the identity control plane can bind action to authority, not on whether the transport layer is mature.
Q: Where should approval for agent actions be enforced?
A: Approval should be enforced in the control plane that every hop must pass through, not inside the protocol itself. That lets you apply policy consistently across tool calls, peer-agent handoffs and payment steps. If approval lives only in the message format or a single platform feature, a downstream hop can ignore it or lose the context entirely.
Q: What is the difference between protocol transport and governance semantics?
A: Transport moves messages between systems, while governance semantics define who may act, under what limits, and how that authority is revoked. MCP, A2A and ACP address the first problem well enough for their own layers, but they do not standardise the second. Practitioners need both, and the governance layer must be enforced separately from the wire protocol.
Technical breakdown
Why MCP, A2A and ACP solve different layers
MCP is an agent-to-tool protocol, A2A is agent-to-agent, and ACP is agent-to-money. That division matters because a protocol can be mature and still be scoped only to transport, discovery or transaction orchestration. The article’s key point is that layer clarity reduces confusion, but it does not create governance semantics. A protocol can describe a request, a task or a payment, yet still be blind to whether the caller had authority, whether limits applied, or whether that authority should expire. The result is clean interoperability with incomplete control semantics. Practical implication: treat protocol choice as an architecture decision, not as a governance design decision. Read AI Agents vs Agentic AI.
Practical implication: Map each protocol to its actual boundary and enforce delegation policy outside the protocol itself.
Why authorization context disappears across protocol hops
The article’s most important technical observation is that a delegated action can cross multiple systems while losing the original authority context. MCP can validate its own token and prevent passthrough, but that means the second hop sees the tool server’s identity rather than the originating human’s. A2A can move a task between agents, but it does not define who authorised the task or how that decision is carried forward. Once the protocol boundary strips or obscures the originating principal, downstream systems cannot reliably enforce least privilege, approval or revocation. Practical implication: preserve human and agent identity correlation outside the protocol using your own control plane. See the Agentic AI Identity Guide.
Practical implication: Require identity correlation to survive every hop, even when the protocol does not carry it.
What governance primitives the stack does not standardise
The article identifies four missing primitives that matter to identity governance: delegated authority, constraint expression, revocation semantics and approval as protocol state. Those are not minor omissions. They are the mechanisms that let a system answer who may act, under what limits, how to undo that authority, and when a person must be involved. The gap analysis cited in the article shows that the current protocols can transport governance messages as opaque payloads, but cannot validate or enforce them. In other words, the standards describe motion, not restraint. Practical implication: implement approval, expiry and revocation in the orchestration layer, not in the wire protocol.
Practical implication: Build a control layer that enforces approval, expiry and revocation before actions leave the agent boundary.
Threat narrative
Attacker objective: The objective is to move an action through valid protocol channels while escaping governance checks that should have constrained, audited or revoked it.
- Entry begins when an agent receives a valid protocol-level path to a tool, peer agent or payment rail without any embedded statement of delegated authority.
- Escalation occurs when that request crosses another boundary and loses the original authority context, so downstream systems only see a technically valid call, not its policy limits.
- Impact follows when the control plane cannot prove who authorised the action, what constraints applied, or whether the authority was withdrawn after use.
Breaches seen in the wild
- Smithery.ai MCP hosting breach 2025: A Smithery.ai build flaw gave GitGuardian a live fly.io token controlling 3,000+ hosted MCP servers and the API keys their clients sent.
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
Protocol maturity does not equal governance maturity: The article correctly separates transport standardisation from authority control. That distinction matters because many teams read adoption numbers as if they were evidence of governance readiness, when they are only evidence of deployment. The missing layer is not another protocol feature; it is a governance function that sits above the wire format. Practitioners should stop treating interoperability standards as if they already solve accountability.
Delegated authority is the real unresolved identity problem: The article’s strongest insight is that agent protocols can move tasks and tool calls, but they do not natively carry a durable statement of who authorised the action, under which limits, and how that authority is withdrawn. That is a broken governance premise, not a configuration gap. Identity programmes that assume action can be reviewed after the fact will miss the point if the authority trail was never expressed in the first place. The implication is a redesign of delegation semantics, not a search for a better protocol.
Approval has become an external control plane requirement: MCP, A2A and ACP each make different transport choices, but none of them can make approval an intrinsic protocol state. That leaves enterprises to enforce approval, revocation and constraint in their own orchestration layer. The important shift is architectural: teams must place governance where all hops must pass, not where a single protocol happens to expose an extension mechanism.
Identity correlation becomes the governing asset in multi-hop agent systems: Once a task crosses agent, tool and payment boundaries, the system needs a durable link between the human principal and the acting agent. Without that link, audit and escalation lose meaning because the request may still succeed while the provenance disappears. agent identity governance is therefore not an adjacent concern, it is the control surface that determines whether delegated action remains attributable.
Named concept, governance blind spot: The article exposes a protocol-to-governance mismatch that we would call protocol restraint debt. The stack can already carry capability, but it has not standardised the restraint needed to prove consent, bound scope and withdraw authority. The practical conclusion for practitioners is to design for restraint above the protocol layer, not to wait for the protocol community to add it later.
From our research library:
- 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to the Ultimate Guide to NHIs.
- Read next: AI Agent Authorisation Guide
What this signals
Governance programmes that rely on protocol adoption as a proxy for control maturity will underestimate the real risk in agent systems. The control question is not whether the stack can move a task, but whether the organisation can still prove who authorised it after the task crosses multiple boundaries.
Protocol restraint debt: this is the growing gap between what agent protocols can transport and what identity governance needs them to express. Teams should expect more pressure to build policy at the orchestration layer, because the standards themselves are still optimised for capability transfer rather than enforceable restraint.
Agentic systems will keep composing MCP, A2A and payment protocols, but the programme risk moves to the layer above them. The next governance decision is whether authority, revocation and approval are tracked as first-class control states or remain implicit assumptions that disappear at the first hop.
For practitioners
- Define a delegation control plane Centralise who may authorise agent actions, what constraints apply, and when that authority expires, instead of scattering those decisions across protocols and tools. See the AI Agent Authorisation Guide.
- Preserve principal correlation across hops Require every agent-to-tool and agent-to-agent transaction to carry a durable link between the human requester and the acting identity, even when the protocol does not standardise it.
- Enforce approval outside the protocol Treat approval as a control-plane state that must be checked before any cross-boundary action executes, because the wire protocol will not do that validation for you.
- Limit protocol trust to the layer it actually covers Use MCP for tool reach, A2A for peer collaboration, and ACP for payment flows, but keep governance decisions in your orchestration and policy services.
- Test revocation at the point of use Simulate withdrawal of authority after a task starts and verify that downstream systems can still refuse or stop the action before completion.
Key takeaways
- Agent interoperability is advancing faster than governance semantics, leaving delegated authority and revocation outside the protocol layer.
- The article’s gap analysis shows that current agent protocols can carry tasks and transactions, but not the policy decisions that make those actions safe.
- Practitioners should move approval, constraint and withdrawal controls into their own control plane rather than expecting protocol standards to provide them.
Related NHI Mgmt Group resources: Agentic AI Identity Guide · AI Agent Authorisation Guide · OWASP Agentic Applications Top 10 · AI Agents vs Agentic AI
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 and risk surface, while NIST AI RMF, NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | The article is about authority, delegation and constrained action across agent protocols. |
| ASI07 — Insecure Inter-Agent Communication | A2A-style handoffs lose governance context across agent boundaries and message hops. | |
| Recommendation — Map delegated agent actions to ASI03 and enforce privilege boundaries above the protocol layer. Apply ASI07 controls to preserve trust context and policy metadata across agent-to-agent exchanges. | ||
| NIST AI RMF | GOVERN — AI Governance and Accountability | The article is fundamentally about who is accountable for delegated agent action and how that is controlled. |
| Recommendation — Establish governance ownership for agent authority, approval and revocation before deploying agent protocols. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article centres on how access and delegated authority should be authorised and withdrawn. |
| Recommendation — Tie agent permissions to explicit authorisations and revoke them when task scope ends. | ||
| NIST Zero Trust (SP 800-207) | Access enforcement point — Access enforcement point | The article argues that enforcement must sit above the protocol at a shared control point. |
| Recommendation — Place policy enforcement at a chokepoint that all agent hops must traverse. | ||
Key terms
- Delegated Authority Model: A delegated authority model defines who is allowed to approve, review, or execute control-related decisions across the enterprise. It helps ensure requests reach the correct responsible party, especially when control owners, managers, and process owners sit in different teams, regions, or systems.
- Protocol Governance Semantics: Protocol governance semantics are the rules that state who may act, under what constraints, and how that authority is withdrawn. A transport protocol can move messages without defining those semantics, which is why mature interoperability does not automatically deliver control.
- Identity correlation: Identity correlation is the process of linking multiple account records to one governed subject. It lets IAM and IGA teams understand that separate usernames, principals, or emails may belong to the same employee or workload, which is essential for access review, offboarding, and entitlement analysis.
- Control-plane enforcement: The ability of an identity or security programme to apply policy at runtime rather than merely documenting policy. In practice, it means access can be granted, denied, reviewed, and revoked in a way that is measurable, auditable, and consistent across the environment.
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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on October 22, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org