The Agent Governance Standards Landscape

A Wave, Forming Fast

In the space of roughly a year, agent standardization went from absent to crowded. There is now a protocol for agents to discover and talk to one another, a protocol for how they connect to tools and data, an emerging payment rail for machine-native transactions, a security risk taxonomy specific to agentic systems, and a national risk-management framework being pointed at AI. Each is serious work by serious bodies, and each solves a real problem.

Step back from any one of them and a pattern comes into focus. The wave is converging on capability and interoperability — how agents connect, communicate, transact, and where they are technically at risk. What almost none of them touches is the layer above all of that: who is accountable for what the agent decided. To see why, it helps to walk the terrain standard by standard, and to place each one against the layers an enterprise agent architecture has to cover — the workforce of actors, the tools and data they can reach, the control plane they run on, and the governance and accountability that sits over all of it.

Interoperability: A2A and MCP

Two protocols anchor the interoperability push. A2A — the Agent-to-Agent protocol, now stewarded under the Linux Foundation — standardizes how independent agents discover one another, advertise what they can do, and exchange messages to collaborate across vendor and organizational boundaries. It is the connective tissue for a world where agents built by different teams and different companies need to work together. In EAA terms, A2A operates across the Capability/Tool surface and the Control Plane: it defines how the workforce interoperates. It does not define who in that workforce is authorized to act, or who answers when the collaboration goes wrong.

MCP — the Model Context Protocol — addresses the other half of connection: how an individual agent reaches tools, data sources, and services in a uniform way, so that a capability written once can be exposed to any compatible agent. MCP squarely occupies the Capability/Tool layer. It is also where a hard truth lives: the tool registry is the attack surface. Every server an agent can connect to is a door, and standardizing the doorway does not decide which doors a given actor should be allowed through. MCP makes connection clean; it does not make delegation accountable.

Transactions: x402

x402 revives the long-dormant HTTP 402 “Payment Required” status code as the basis for a machine-native payment rail — letting an agent pay for a resource, an API call, or a service inline, without a human clicking a checkout button. It answers a question the other protocols raise but do not resolve: once agents can reach tools and each other, some of those interactions cost money, and a workforce that can transact needs a way to do so. x402 sits in the Capability/Tool layer as well — it defines part of what an agent can do, specifically what it can transact. It is deliberately mechanism, not policy: it standardizes the act of payment, not the spending authority behind it. Whether a given agent should have been permitted to make a given payment, and who owns the consequences, is left to whatever governs the actor — which today is often nothing.

Runtime Risk: OWASP ASI

The OWASP Agentic Security Initiative and its Top 10 bring the discipline OWASP is known for to agentic systems: a shared, ranked taxonomy of the ways agent deployments fail in the wild — from tool misuse and excessive agency to memory poisoning and cascading multi-agent failures. It is the most governance-adjacent of the interoperability-era efforts, because it names real operational hazards rather than just plumbing. But it is fundamentally a risk taxonomy for the runtime and control plane: it catalogs how agentic systems can be attacked or misbehave. That is essential, and it is not the same as an accountability model. Knowing the ten ways a workforce can fail is not the same as knowing who owns each worker, what authority each was granted, and who answers when one of those failures occurs.

Model Risk: The NIST AI RMF

The NIST AI Risk Management Framework is the most mature governance instrument in the set, and the one written with the most care. It gives organizations a structured way to map, measure, and manage the risks of AI systems, and its language of trustworthiness has become common vocabulary. It genuinely reaches into governance framing — but it was written for models and AI systems, artifacts an organization builds, tunes, and deploys. It does not yet model a delegated-authority actor: a non-human that is handed credentials and a goal and then decides on its own. The RMF governs the model; the open question is governing the worker the model animates.

Laid side by side, the pattern is unmistakable.

Standard	What it governs	EAA layer	The gap it leaves
A2A	Agent discovery, capability advertisement, and inter-agent messaging across boundaries (Linux Foundation).	Capability/Tool + Control Plane interop	Standardizes how agents talk; not who is authorized to act or who answers for a collaboration.
MCP	How an agent connects to tools, data, and services through a uniform interface.	Capability/Tool	The tool registry is the attack surface; connection is clean, delegation is unaccountable.
x402	Machine-native payments via HTTP 402 — what an agent can transact, inline.	Capability/Tool	Mechanism of payment, not the spending authority or ownership of the consequence.
OWASP ASI Top 10	A ranked taxonomy of agentic security and failure modes in operation.	Runtime / Control Plane risk	Names how a workforce fails; not who owns each actor or answers when it does.
NIST AI RMF	Mapping, measuring, and managing the risk of AI systems and models.	Governance framing (model-level)	Written for models, not for a delegated-authority actor that decides on its own.

None of these is deficient at what it set out to do. The point is what the column on the right has in common: each leaves the same thing unclaimed.

The Layer No One Is Standardizing

Here is the synthesis, and it is the load-bearing point of this map. Every standard above is essential. Interoperability without A2A and MCP is chaos. Payments without a rail like x402 don't scale. Deploying agents without the OWASP ASI hazards in view is negligent, and running AI systems without something like the NIST AI RMF is how you get blindsided. This is not a critique of any of them.

It is an observation about their union. Not one of them models a non-human actor holding delegated authority. Interop is being standardized. Payments are being standardized. Tool access is being standardized. Model risk is being standardized. But the question that a workforce of autonomous actors forces — who is accountable for what the agent decided — is being standardized by no one. That is not a small omission at the edge of the field. It is a whole layer, and it is the one that governs the actor rather than the plumbing the actor runs on.

The reason the gap persists is the same category error the rest of this series traces: these standards, almost to a one, treat the agent as a system to connect, secure, or fund — an artifact. A delegated-authority actor is not an artifact. It is closer to a worker, and workers are governed by accountability, not by protocol. Protocols move messages and payments; they do not answer for a decision. That is why the accountability layer keeps falling between the standards rather than into any one of them.

Where This Is Heading

Standards mature in a predictable order: first the industry agrees on how things connect, then on how they are secured, and only then on who is accountable when they act. Agents are firmly in the first two phases and have barely entered the third. What follows from the map is not a prediction that these standards will fail — it is that they will need something above them. Interoperability, payment, and runtime security all assume an accountable actor underneath; as agents move deeper into production, the pressure to name and govern that actor will only grow. The standards will need a governance and accountability layer that sits above interop — one that says which agent exists, what authority it was granted, and who answers for what it does.

That layer needs a name and a shape before it can be standardized. Naming it is what the reference model is for.

The interoperability, payment, and security standards are converging fast — and all of them assume an accountable actor they do not themselves define. The Enterprise Agent Architecture is the reference model that names that missing layer: the governance and accountability of a non-human workforce holding delegated authority.

About This Series

Michael K. Saleme — Enterprise Agent Architect

Enterprise Agent Architecture is published as a position-paper and practitioner series — the canonical account of the practice, released one part at a time. This map of the standards landscape is written from inside the standards conversation, and it describes each effort on its own terms: every one is essential, and none of them is the accountability layer.

The recurring work of three decades of enterprise architecture has been the same four concerns — identity, integration, authorization, and control. The emerging agent standards are re-solving integration and, in part, control. Identity and authorization for an actor that decides on its own — the governance layer — is the part still waiting to be claimed.