Identity
Signed Agent Cards verify who’s asking
Delegation
Task lifecycle defines what’s handed off
Authorization
What the agent may do with the task
Audit
Who acted under whose authorization
Two layers of trust are protocol-native. Two are still left to whoever deploys the agent.
TL;DR
The governance blind spot is this: agent-to-agent protocols like A2A verify identity and handle task delegation, but leave authorization — what a verified agent may actually do — and audit — who’s accountable for it — entirely up to the business running the agent.
- Agent-to-agent protocols, chiefly A2A, are delegation-centric: built to answer which agent can perform a task, not whether it should be trusted to. [8]
- Regulators are moving faster than the protocols. Singapore’s IMDA published the first comprehensive agentic-AI governance framework in January 2026, requiring a verifiable identity and an audit trail for every agent action. [1]
- A wave of 2026 research — OIDC-A, the IETF’s agent-identity track, and invocation-bound capability tokens — is building the authorization layer A2A left out, but none of it lives inside the protocol itself yet. [4][5]
- The fix isn’t a missing feature so much as a missing layer: identity, delegation, authorization, and audit are four separate jobs. Today’s agent protocols only do the first two.
- For anyone running bo2bot messaging in production, that gap — authorization and audit — is the business’s responsibility to close, not the protocol’s.
A question A2A was never built to answer
A2A, and most of the protocols built alongside it, are excellent at one specific job: helping one agent find another, describe a task, and hand it off. That’s the delegation problem, and it’s genuinely solved — Agent Cards handle discovery, a defined task lifecycle handles handoff, and as of 2026, cryptographic signatures handle proving a card is genuine.
None of that touches a different, harder question. A signed, correctly-discovered, perfectly legitimate remote agent can still be asked — or can still ask — for something it shouldn’t be allowed to do. A2A answers which agent can handle this task? It was never designed to answer should this agent be trusted with this specific authority, right now, on someone’s behalf? Research on interoperability protocols describes this plainly as a delegation-centric design, and notes that none of A2A’s official extensions address governance directly. [8]
Regulators are already answering the question protocols didn’t
What makes this moment unusual is that the compliance side of the world moved first. Singapore’s Infocomm Media Development Authority published a Model AI Governance Framework for Agentic AI in January 2026 — the first comprehensive regulatory framework written specifically for autonomous agents. It requires every agent to carry a verifiable digital identity and an audit trail documenting which agent acted under whose authorization. [1]
NIST followed a month later, launching an AI Agent Standards Initiative in February 2026 that names interoperability, identity, and authorization as foundational requirements for trusted adoption — with an accompanying concept paper noting that agents are still commonly treated as generic service accounts, with no dedicated identity, authorization, or accountability controls of their own. [2]
The EU AI Act adds a third layer of pressure: Article 14’s human-oversight duty and Article 15’s robustness requirements already apply to autonomous agents operating in high-risk domains — and that duty falls on whoever is relying on the agent, not on the protocol carrying its messages. [3]
The research racing to fill the gap
Outside of regulation, a cluster of 2026 research is converging on the same missing piece from a different direction. OWASP’s Top 10 for Agentic Applications, developed with more than 100 industry contributors, now catalogs identity and privilege abuse, excessive agency, and goal hijacking as top-tier risks specific to autonomous systems — distinct from the prompt-injection concerns that dominated agent security conversations a year earlier. [4]
On the standards side, the OpenID Foundation and independent researchers have proposed OIDC-A — OpenID Connect for Agents — extending a well-established identity standard with agent-specific delegation chains and capability-based authorization, alongside a parallel effort inside the IETF. [5]
Reference implementations of one proposed token format report 0.049 millisecond verification latency and a 100% rejection rate across 600 simulated adversarial attempts — evidence that adding an authorization layer doesn’t have to cost agents meaningful speed. [5]
And in April 2026, Microsoft open-sourced an Agent Governance Toolkit covering all ten OWASP agentic risk categories, released under MIT license across five languages — a signal that the fix is being built as shared infrastructure rather than something each company has to invent alone. [7]
Why none of this lives inside A2A yet
A2A’s v1.0.1 release added an extension mechanism specifically so the protocol could grow new capabilities over time — the plausible seam where a governance layer could eventually attach. But its four official example extensions stop at secure identity, timestamping, and traceability; none of them define an authorization model. [8]
That’s arguably the correct call, not an oversight. A discovery-and-delegation protocol has to standardize the parts every implementer needs to agree on to interoperate at all. Authorization policy — what your organization is willing to let an outside agent do — is inherently specific to each business, each task, each risk tolerance. Baking one answer into the protocol would solve fewer problems than leaving room for many. The trouble is that leaves a gap most teams don’t realize they own until something goes wrong inside it.
What actually solving this requires
Treat identity, delegation, authorization, and audit as four separate layers, not one bundled problem. The protocol gives you the first two for free. Here’s what has to sit on top of it:
Verify identity on every request
Check the signature on every incoming Agent Card before trusting anything it declares — this part is already protocol-native, so there’s no excuse to skip it.
Scope every delegation narrowly
Use the task lifecycle to hand off exactly what’s needed, not standing access — a task should expire, not linger.
Attach a bounded authorization token to every task
Define what a remote agent may actually do with what it’s given, and make that grant expire by default rather than persist indefinitely.
Log who acted under whose authority
Every completed task should leave an audit trail tying the action back to the agent, the authorization, and the human or business ultimately accountable — precisely what Singapore’s framework now requires by regulation. [1]
For a business running bo2bot messaging in production, this is the layer you own outright. The protocol hands you identity and delegation. Authorization and audit are yours to design, and increasingly, yours to be held accountable for.
The numbers behind the urgency
Separately, industry surveys report that 40% of organizations are increasing their identity and security budgets specifically to accommodate AI agents, with roughly a third allocating a dedicated budget line for it — a sign this is being treated as infrastructure spend, not a research line item. [9]
Frequently asked questions
What is the governance blind spot in agent-to-agent protocols?
A2A and similar protocols standardize how one agent discovers and delegates a task to another, but not whether that agent should be authorized to do it, or who is accountable if it doesn’t. Identity and delegation are protocol-native; authorization and audit largely are not.
Is A2A insecure because it lacks governance features?
Not insecure so much as incomplete for regulated or high-stakes use. A2A verifies identity well, through signed Agent Cards. It leaves authorization policy to the businesses running it, since that policy is inherently specific to each deployment.
What is Singapore’s Model AI Governance Framework for Agentic AI?
Published by Singapore’s IMDA in January 2026, it’s the first comprehensive regulatory framework built specifically for autonomous agents, requiring each agent to carry a verifiable digital identity and an audit trail of which agent acted under whose authorization.
What are invocation-bound capability tokens?
A proposed authorization mechanism that fuses an agent’s identity, a bounded set of permissions, and a provenance record into a single verifiable token per task, so a receiving agent can check both who is asking and exactly what they’re allowed to do.
How should a business fill this gap today?
Treat identity, delegation, authorization, and audit as four separate layers. Use the protocol for the first two, then add a scoped, expiring authorization policy on every outbound task, and log which agent acted under whose authority for every completed one.
Closing thought
Every layer of the internet has gone through this same sequence: solve connection first, solve trust second, solve accountability last, usually only after regulation forces the question. Agent-to-agent messaging is partway through that sequence faster than most predecessors managed. The businesses that treat authorization and audit as core parts of their bo2bot messaging setup now — rather than waiting for a future protocol version to hand it to them — are the ones least likely to find out the hard way where the blind spot was.
References
- Singapore IMDA — Model AI Governance Framework for Agentic AI, cited in Trust Without Trusting: A Recomputable Trust Protocol for Autonomous Agents, January 2026
- National Institute of Standards and Technology — AI Agent Standards Initiative and NCCoE concept paper, February 2026
- European Union — Regulation (EU) 2024/1689 (EU AI Act), Articles 14 & 15
- OWASP Gen AI Security Project — OWASP Top 10 for Agentic Applications 2026
- arXiv — Authorization Propagation in Multi-Agent AI Systems: Identity Governance as Infrastructure
- Microsoft Open Source — Agent Governance Toolkit, April 2026
- arXiv — Governance Gaps in Agent Interoperability Protocols: What MCP, A2A, and ACP Cannot Express
- Elevate Consult — Agentic AI Security Solutions: OWASP 2026 Guide
