A2A Moved In With MCP. The Identity Layer Stayed Outside.

On 20 August 2026 Google moved A2A into the Agentic AI Foundation, so the two protocols your agent depends on now share a governing board, a roadmap and a trademark holder — and share none of the thing that would actually make them safer to combine. An MCP tool description comes from a server you chose to install; an A2A agent card comes from a URL the counterparty controls. Both land in the same context window, one of them is signed and the other's identity work is being stewarded in a different foundation entirely. The number worth watching is not the 250-member headline; it is whether one identity primitive ends up normatively referenced by both specs.

What actually landed

The Agentic AI Foundation was stood up under the Linux Foundation in December 2025 with 49 members and three donated projects: Anthropic's Model Context Protocol, Block's goose, and OpenAI's AGENTS.md. It passed 170 members in April 2026 and, at the time of the A2A announcement, counts more than 250 — with AWS, Anthropic, Block, Bloomberg, Cloudflare, Google, Microsoft and OpenAI at the top tier. Its governing board has been chaired since February 2026 by AWS's David Nalley.

A2A itself was already at the Linux Foundation and already at v1.0. What changed on 20 August is the home: the protocol now sits inside the AAIF, alongside MCP, under one board, one technical committee and one published roadmap — which, as the foundation describes it, runs through an MCP v2 specification, an A2A governance specification, a 1.0 for AGENTS.md, and a security-certification track, spread across working groups covering identity, security, observability, commerce, workflows, accuracy and regulatory alignment.

The framing everywhere is complementarity: MCP is the vertical connection from an agent down to tools and data, A2A is the horizontal one between agents that belong to different owners. That framing is correct, it has been correct for two years, and it is exactly why putting them under one roof is a smaller change than the coverage suggests. They were never competing. What they were — and still are — is two separate ways for text you did not write to reach your model.

What a foundation actually transfers

Start with the steelman, because it is strong and it is the part most of the commentary gets right. Neutral stewardship of a protocol is worth real money to anyone building on it, and the things it transfers are unglamorous and load-bearing: the trademark, so nobody can rebrand the spec out from under implementers; the repository and release process, so a single company's reorganisation cannot archive it; a patent posture; and a documented change process. MCP already runs its changes through Spec Enhancement Proposals, which means a proposal has to be written down, reviewed in public and merged rather than shipped in a release note.

That continuity guarantee is not theoretical. The agent tooling ecosystem has spent two years watching well-adopted projects get acquired, archived or quietly redirected, and "who owns this if the sponsor loses interest" is a legitimate first question about any protocol you are about to hard-code. After 20 August, both of the protocols in the standard agent stack have the same answer, and it is a durable one.

The second real benefit is scheduling. Two specs under one technical committee cannot ship contradictory answers to the same question without somebody in the room noticing, and the overlap between them is genuine: authentication, task lifecycle, streaming, error semantics and — most consequentially — how one party establishes what another party is allowed to do. Before August those conversations happened between two organisations. Now they happen inside one. That is a real improvement in the odds of convergence.

It is not, however, a technical change. No behaviour of any deployed agent changed on 20 August, no specification text moved, and nothing about the security properties of either protocol is different this week than it was last week.

One roof, two trust boundaries

Two discovery surfaces, two provenance stories, one context window.

Here is the thing the governance story does not touch. Both protocols work by putting descriptive text in front of a model so it can decide what to do next, and that text is an instruction channel whether or not anyone intended it to be. In MCP, the text is a tool's name and description, and its provenance is an installation decision an operator made — which means it can be pinned, diffed, reviewed and rolled back, and which is why tool poisoning is a supply-chain problem with supply-chain answers.

In A2A the same text arrives as an agent card: a document fetched at discovery time from a location the other party controls, describing skills your planner may then invoke. The provenance is a DNS name. The protocol does provide for signing — agent cards may carry a JSON Web Signature over a canonicalised form of the document, and richer cards can be gated behind authentication — but a signature proves the card came unmodified from whoever holds the key, and says nothing about whether the described skill does what the description claims. A verified card from a counterparty you have never audited is a verified claim by a stranger.

These are genuinely different threat models, and an agent that speaks both is exposed to both simultaneously. The one that catches teams out is the composition: an A2A partner returns a task result, that result flows into the context that selects the next MCP tool call, and the boundary that was supposed to separate "another company's agent" from "my database credential" turns out to be one context window. Nothing in the August announcement changes that, and nothing on the published roadmap is aimed squarely at it either.

The identity layer is being written in a different building

The most useful detail in this story is one nobody wrote a headline about. The identity work that would bind these two protocols together is not converging inside the AAIF — it is spread across at least two foundations. In March 2026 the MCP-Identity framework was donated by Vouched not to the AAIF but to the Decentralized Identity Foundation, where it is stewarded by that body's Trusted AI Agents working group. Meanwhile A2A carries its own signing story inside its own specification, and the AAIF has an identity working group of its own with a roadmap slot.

So the protocols consolidated and the primitive underneath them did not. This matters because agent identity is the one thing both specs need and neither can supply alone: when your agent delegates a task to a partner's agent, which then calls a tool on your behalf, somebody has to be able to say who the principal is, what authority was delegated, and how far it propagates. Today that is answered — where it is answered at all — by whatever bearer token happens to be in scope, which is the failure mode our writeup of ambient authority and the August CVE pattern both keep landing on.

That gives you a concrete thing to watch, and it is far more informative than the membership counter. Consolidation is real when a delegation primitive exists that both the MCP specification and the A2A specification normatively reference — one way to express "agent X is acting for principal Y with scope Z", carried across a protocol boundary without being re-minted as a fresh bearer credential. Until that lands, "one roof" means a shared release calendar. When it lands, it will be the largest security improvement in the agent stack since sandboxing became routine.

What the membership number tells you, and what it does not

Membership measures who wants a seat. It does not measure who ships a conforming implementation.

Fifty to two hundred and fifty members inside a year is a genuine signal, and it is a signal about distribution: this is where the vendors expect the agent interface to be decided, so this is where they want a seat. If you are betting a product roadmap on which protocol to implement, that curve is most of the answer, and it is why "should we support MCP" stopped being a question some time last year.

What it is not is a measure of interoperability. Membership is a commercial commitment, not a conformance one; there is no certification behind it today, which is precisely why a security-certification track appears on the roadmap. The gap between "supports MCP" and "supports MCP the way the other implementation does" is where integration weeks disappear, and no member count predicts it. Nor does the count say anything about concentration: a technical committee weighted toward the top tier means eight companies, most of whom sell competing agent platforms, arbitrating the interface between them. That is the normal shape of a successful standards body and it is also the reason such bodies converge slowly on exactly the questions where their members' products differ — which, here, is identity and commerce.

What to actually do

Three columns; only the third one would change how you build.

Change nothing structural because of this announcement. If you were planning to adopt A2A, the governance move slightly improves the case; if you were not, it does not make the case. Continuity risk was already low for a protocol with this much adoption.

Classify your two discovery surfaces separately in the threat model. Installed MCP servers are a supply-chain problem: pin them, review updates, and treat a changed tool description as a change to your prompt. Discovered A2A peers are an untrusted-input problem: allow-list the counterparties whose cards you will even fetch, verify signatures where they exist, and never let a card's own text decide how much authority the interaction gets.

Assume the composition is the attack. The interesting exposure is not either protocol alone but a partner agent's output flowing into the selection of your next tool call. Keep the privileged tool set out of the context that processes counterparty responses, or put a boundary between them — the reasoning in egress control applies to inbound task results just as much as to outbound requests.

Track the identity working group, not the press releases. The specific artefact to watch for is a delegation credential that both specs point at. Its arrival is the moment your architecture should change; the member count reaching 400 is not.

FAQ

Does A2A joining the AAIF mean MCP and A2A will merge?

Nothing announced suggests a merge, and they solve different problems — one connects an agent to tools, the other connects agents belonging to different owners. What one foundation makes likely is convergence on the pieces they both need, principally authentication and delegation, rather than a single unified specification.

Is an A2A agent card safe to trust if it is signed?

A signature establishes that the card was not modified in transit and came from the holder of a particular key. It establishes nothing about whether the skills described behave as described. Signature verification belongs in your client; the decision about how much authority a counterparty gets belongs in an allow-list you maintain.

Should we implement A2A now, or wait for the governance specification?

Implement if you have a concrete cross-organisation delegation to do; A2A is at v1.0 and in production use. Waiting buys you very little, since the governance work is about how the specification is changed rather than about what it currently says.

Does this change anything for a team that only uses MCP internally?

Practically, no. The change most likely to reach you is the MCP v2 track on the shared roadmap, and that would have happened either way.

Why does it matter that identity work sits at a different foundation?

Because a delegation primitive only helps if both protocols reference the same one. Work split across bodies can still converge, but it removes the single technical committee that would otherwise be forced to reconcile the two — which was the main mechanism by which consolidation was supposed to pay off.