A2A is joining the Agentic AI Foundation. Mazin Gilbert announced it this morning and Ina Fried has the story at Axios. MCP defines how an agent reaches a tool. A2A defines how one agent hands a task to another and gets a result back. As of today both sit under the same open governance, with a steering committee that includes AWS, Cisco, Google, IBM Research, Microsoft, Salesforce, SAP and ServiceNow.
This is a genuinely good day, and I do not want to undersell it. An interoperable agent-to-agent transport under neutral governance is the precondition for everything I am going to describe below. Google could have kept it, and chose open governance instead. The teams who built A2A to v1 and the TSC now stewarding it have done the hard, unglamorous work that makes a layer everyone can build on.
We build on that layer. Agent Mesh and cA2A both assume A2A rather than replace it, in the same way our confidential MCP work assumed MCP. So this edition is about what we have been putting on top, why it is needed for sovereignty specifically, and what it still cannot do.
The short version: a sovereignty claim has to survive three layers, and the transport is only the ground it stands on.
Here is the test that shows why the layers above the transport have to exist.
A resource owner permits processing in France only. A lead agent delegates summarisation to a sub-agent. The sub-agent calls a model endpoint that is EU-branded but served from a region outside France.
Every component behaved as configured. The deployment was compliant. The data flow was not.
I wrote that as the acceptance test in an RFC last week, and I want to spend this edition on why it is hard, because it is the clearest example I know of the difference between a system that is governed and a system that says it is.
The project
Agent mesh is the part of the Agent Governance Toolkit that handles what happens when agents stop working alone. One agent hands work to another. That one hands part of it onward. The toolkit is at roughly 5,900 stars and 1,000 forks, and most of the interest I get on it now is about this layer rather than the single-agent one.
The reason is that the second hop is where most governance quietly stops working.
Everything you established about the first agent was established about the first agent. Its identity. Its policy. Its permitted region. The moment it delegates, you are relying on those properties surviving a transfer, and in most systems today nothing carries them across. The sub-agent inherits a task. It does not inherit the constraints under which the task was authorised.
Declared is not verified
Residency is the sharpest version of this because it looks solved and is not.
The way it is modelled today, in the toolkit and nearly everywhere else, is as declared metadata. A policy carries a list of processing regions. An agent’s claims carry a data residency field. Both are strings that somebody typed.
A declared region string is unverifiable. Nothing binds it to evidence, and nothing carries it across more than one hop. So an agent can satisfy every check the design specifies and still route data out of its permitted jurisdiction through a sub-agent, with no record that it happened.
I want to be precise about why that is worse than having nothing. An unverifiable residency claim creates documented, auditable confidence in a property nobody checked. You end up with a compliance artifact that is exactly as strong as the honesty of whoever filled in the field, presented with the visual authority of a control.
The two properties that matter here are easy to state and hard to build:
Residency is only meaningful if it survives delegation. A constraint that applies to the first agent and evaporates at the first handoff is not a constraint, it is a label on the front door.
Delegation is only safe if residency composes. Across a chain, a constraint has to intersect at every hop and must never widen. The child can hold less than the parent. It can never hold more.
The same monotonicity already gets enforced for capabilities in a lot of systems. Almost nobody enforces it for geography.
Why detection does not close this
The cheaper answer is to check afterwards, and it is where most of the industry sits.
The best published agentic attack detector I am aware of is Uber’s ADR, which reports catching 67% of attacks at zero false positives on its own benchmark. That is genuinely state of the art and it still misses roughly one in three.
A residency violation caught 67% of the time is not a control a regulator will accept. Detection and evidence compose. Neither substitutes for the other, and a system that only detects is a system that finds out.
What cA2A is for
This is the project I have never written about here, which is an odd gap given that it exists for exactly the problem above.
A2A makes a deliberate and, I think, correct design choice: it specifies the transport and the Agent Card, and it leaves the runtime credential layer to implementers. A transport should not be in the attestation business. Putting hardware attestation into a wire protocol would have made it heavier, slower to adopt, and wrong for the majority of deployments that do not need it.
That choice is what creates the space we work in. The common answers implementers reach for are mTLS and OAuth scopes, which secure the pipe and assert an identity. They are the right default. They do not attenuate authority across a chain, attest runtime integrity, or seal a payload to a measurement, because they were never meant to.
cA2A is a confidential profile that fills that slot, the same way our confidential MCP work sat on top of MCP rather than beside it. It composes four things:
Attenuated delegation, where each hop’s scope is a provable subset of its parent. Runtime attestation, so a peer proves it is running measured code before it is trusted with a task. A sealed channel, so the payload is readable only inside the verified peer. And a provenance record per hop, chaining into a graph a third party can verify offline without trusting either operator.
The refusal path ships as an example in the repo: an agent asks for authority nobody delegated to it, is refused, and hands over a record a third party can check offline without trusting the operator that produced it.
What it does not do yet
I would rather you read this from me than discover it.
cA2A is alpha. The published runtime is 0.1.0a1. The delegation semantics are real and tested, but they live mostly in a sibling project, and the runtime peer path is under construction.
The sealed channel is implemented as encryption and is not yet bound to a hardware-verified measurement on a live call. Until that lands, do not assume a payload is confined to a specific attested measurement. The reference transport runs in software mode by default, where assurance is explicitly none. Mutual attestation on real silicon in both directions is still outstanding.
Until this morning the delegation credential had no validity period at all. It signed who issued it, to whom, for what scope, at what depth, and under which parent, and said nothing about when the grant started or ended. So chain verification could check structure and scope narrowing and could not decide whether a grant covered the moment it was being used.
I am leaving that in rather than quietly editing it out, because how it got fixed is the more interesting fact. It was filed against us on 13 August by somebody outside the project, and closed on 17 August by a different person outside the project, who added not_before and not_after, enforced them per hop, and wrote the conformance cases for expiry and not-yet-valid. That is in main and not yet in a release, so the published 0.1.0a1 still has the gap.
Three people outside the project have landed commits on this repo in the last week, and a fourth filed the issue that produced one of them. The repo has three stars. I would rather have the four people.
And the limit that constrains all of this, which I think is the most important sentence in the RFC:
Hardware attestation proves what code is running. It does not prove where the machine is. There is no trustworthy geography in an SEV-SNP or TDX report, because nothing in the silicon knows what country it is in.
So the honest ceiling on attested residency is not proof of location. It is a split claim: what is running, rooted in hardware and verifiable offline against a vendor root with no trust in the operator, and where it is running, rooted in a signed statement from an identified operator who can be held to it afterwards. The second half is operator trust, not hardware trust. An operator with physical control of the machine can defeat it.
What that buys is non-repudiation rather than prevention. Somebody accountable signed a statement, bound to a specific attested instance, and cannot later say they did not. I think that is the strongest claim available, and any project telling you it has cryptographic proof of location is telling you something that is not true.
Three layers, one claim
I have been building these as separate things for long enough to see that they are one thing.
Agent OS is the kernel layer. It governs a single agent: what it is allowed to do, evaluated and enforced at the runtime rather than asked of the model, and written down as it happens. A kernel is the right metaphor because the point is that the governed program does not get to opt out.
Agent Mesh is the layer above, where agents stop working alone. One agent hands work to another. Constraints have to survive that handoff, and they have to narrow rather than widen at every hop.
cA2A is the layer that crosses organisations. Inside your own mesh you can plausibly trust your own operator. Across trust domains you cannot, so the payload has to be sealed to a peer whose code you verified, and the record has to be checkable by a third party who trusts neither of you.
Sovereignty is the claim that needs all three at once. A jurisdiction constraint is meaningless if the runtime does not enforce it, useless if it evaporates at the first delegation, and unprovable if the only evidence is a log written by the party whose behaviour is in question. That is the whole argument: sovereign verifiability is not a deployment region, it is a property that has to hold at the kernel, across the mesh, and between organisations, and be checkable afterwards by someone who trusts nobody.
Almost every sovereignty story on the market today is layer zero, which is a region on a purchase order.
The question
I am fairly confident about the properties: attested rather than declared, composing transitively, failing closed before data moves, verifiable offline by someone who trusts nobody.
I am much less confident about the geography half, because it is the one part that cannot be rooted in hardware.
So: if you cannot prove where a machine is, and you can only prove who signed a statement about where it is, is attested residency worth building at all, or does a signed operator statement bound to an attested instance just relocate the trust problem somewhere it is easier to ignore?
I think it relocates it somewhere it is at least attributable, which is not nothing. Tell me where that is wrong.
The RFC is open at microsoft/agent-governance-toolkit#3658. cA2A is at github.com/agentrust-io/ca2a, alpha, with its limits written down in LIMITATIONS.md rather than in a footnote. The validity-window fix is PR #110, landed this morning, against issue #108.
