← Concepts
The unclaimed layer

Who operates this agent, and how would you check?

Agent protocols answer what an agent can do and, increasingly, that a process is who it claims to be. None answers which organization is behind it, what that organization authorised, or how a stranger would verify either. The operator is a display string, and a string cannot be wrong.

Three questions, and only two are being answered

Ask anything of an agent belonging to another company and three questions have to be settled before work starts. What can it do. Is this process really the thing it claims to be. And whose authority is it carrying — which organization stands behind it, and what did they actually permit.

The first is well served. Capability description and message exchange are what the open agent protocols do, and they do it across vendors: Google’s A2A and Anthropic’s Model Context Protocol now sit under the same neutral foundation governance, which is the right structure for a wire format and the reason either is worth building on.

The second is being solved hard, in the place it belongs. The cloud providers are issuing cryptographic workload identity to agents — attested, short-lived, automatically rotated — so a caller can prove the process on the other end is the one it claims.

The third is unclaimed. Not badly done: unclaimed. There is no widely deployed answer to which organization is behind an agent, in a form a stranger can check.

What an agent card says about its operator

A2A’s Agent Card, served at a well-known path on the operator’s own domain, carries a provider block: an organization name, a URL, a contact address. The organization field is free text, and the specification is right that it is — A2A is a communication protocol, and the organizational layer is outside its scope.

Follow the consequences anyway. Two cards naming the same company cannot be known to mean one company, because there is no identifier to compare and string equality is not entity equality the first time a name is reused or a business renamed. Nothing binds the string to anything, so nothing can contradict it — and a field that cannot be false carries no information. And the operator’s name tells you nothing about what they authorised, who inside that organization is accountable, or whether they have said anything about this agent at all.

The URL beside it is usually a homepage. Fetching it tells you what a company says about itself in marketing copy, which is not a record of who asserted the organization, when, and on whose authority.

Process identity is not organizational authority

It is tempting to read cryptographic agent identity as having settled this. It has not, and the distinction is worth stating precisely, because everything downstream depends on it.

Workload identity answers a question about a process: this binary, in this environment, holds a key attesting it is what it claims. That is necessary, it is hard, and the people building it are building it properly. It does not answer which legal entity is accountable for what that process does, what that entity delegated to it, or how somebody outside both companies would check the delegation without being handed credentials by one of them.

A staff badge proves the person at the door is who the badge says. It does not say what they may sign, and it is not evidence at all to a counterparty who has never heard of the company that issued it.

The fix is a field that already exists

The provider block on an agent card has a URL. It has simply never had anything dereferenceable in it. Point it at an identity URI — a permanent, extension-free address for the organization, served at the operator’s own domain — and a client that follows it gets a record: who asserted this organization, on what date, when the assertion stops claiming to be current, and which charter its roles are declared under.

That requires no change to any protocol and nobody’s permission. The field is already in the specification, the path is served by the operator, and a reader who does not care can ignore it exactly as they do today.

It also cannot be centralised, which is the point. Recognition is structural — any host following the rule is recognised, including hosts that have never heard of whoever wrote it down. There is no registry to join and no gatekeeper to ask, because a fact lives at its asserter’s own host or it is not a fact worth trusting.

Why the unclaimed layer is the one worth building

The layers below this one have large, well-capitalised owners and open governance, and competing there is a losing trade. The organizational layer has neither an owner nor a standard, and it is the layer every cross-company agent transaction eventually needs: an agent economy where nobody can check who is behind a counterparty settles into a handful of walled gardens, because inside a garden the operator is known by construction.

The test of whether this layer is real is not how much software exists. It is whether an organization with no relationship to whoever wrote the specification can find it, implement it against their own domain, and be understood by a second organization that also has no relationship to the author. Everything before that is a demonstration.

DEFINED AT · The institutional definition — GDA Group
ACROSS THE GROUP · Flashy ID — whose authority an agent carries · Flashy Group — the network the stack runs
RELATED · Agent-to-agent communication · What is agent identity? · What are agent permissions? · Machine-readable organizational trust · The naming standard · Audit a domain’s claims
This is how the mesh behaves when you run it. Onboard an Agentic Autonomous Organization free in a couple of minutes.
All conceptsGet started free