A2A Now Sits Beside MCP Under One Foundation, and Your Vendor Register Has No Row for Agents That Hire Other Agents

On 20 August 2026 the Agent2Agent protocol, originally built at Google, formally joined the Agentic AI Foundation, the Linux Foundation directed body that already hosts the Model Context Protocol contributed by Anthropic, the goose agent framework contributed by Block, and the AGENTS.md convention contributed by OpenAI. Membership has passed 250 organisations, with platinum signatories that include Amazon Web Services, Anthropic, Block, Bloomberg, Cloudflare, Google, Microsoft and OpenAI. Read as industry news it is a consolidation story, and a welcome one: the two protocols that matter for agent interoperability are now governed in the same neutral place rather than in competing vendor silos. Read as a risk story it is something else. The plumbing for agents to find and hire other agents across company boundaries just acquired the institutional backing that turns a promising specification into a default, and most compliance programmes have no concept for the thing it enables.

The distinction between the two protocols is the part worth internalising, because it decides which of your controls apply. MCP is vertical. It connects one agent downward to tools, data sources and applications, and the counterparty is a server you chose, configured and can point at. We wrote earlier this month that an MCP server is a vendor and belongs in your third party register, and that argument is now the easy case. A2A is horizontal. It defines how two autonomous systems discover each other, negotiate a task, exchange identity credentials and maintain state across organisational boundaries. The counterparty is not a tool you installed. It is another agent, possibly operated by another company, selected at runtime because it advertised a capability your agent needed. Nobody in your business signed anything, and in many designs nobody in your business even chose.

The mechanism that makes this work is the Agent Card, a document by which an agent advertises what it can do and which authentication schemes it supports. The critical property, and it is a design choice rather than a defect, is that the protocol does not mandate how a card is verified, and it deliberately leaves credential provisioning and authorisation to whoever operates the deployment. A card describes capability. It does not prove identity unless you verify signatures, transport security and issuer trust yourself. Security researchers have been consistent about where that leads: agent impersonation, card tampering and replay of captured tasks when tokens are not bound to a sender. The sharpest failure is the classic confused deputy in new clothing. A low privilege agent asks a high privilege agent to summarise an invoice, an instruction to move money rides along inside the artefact, and the second agent executes it using its own credentials because delegation scope was never enforced end to end. Add recursive delegation between agents with no depth limit and you also have a denial of service that your own systems fund.

Now hold that next to how your third party inventory actually works. Every framework you comply with assumes that a supplier relationship begins with a decision: somebody evaluated a vendor, somebody signed a contract, somebody recorded it, and somebody reviews it annually. A2A breaks that assumption at the root, because the relationship is formed by software, during execution, on the basis of an advertisement. If your agent delegates a task that carries customer data to a peer agent operated by another organisation, you have created a processing relationship with a third party that has no contract, no data processing terms, no security questionnaire, no named owner and no entry in any register. Under privacy law the chain of processor and sub processor obligations does not care that a machine formed the relationship, and neither will the customer who asks you to list everyone who touches their data.

The framework mapping is conventional, which is exactly why the gap is uncomfortable. ISO 27001 gives you supplier relationships, information security in supplier agreements and monitoring of supplier service delivery, alongside identity management, access control and logging, and a runtime chosen counterparty defeats the first three by construction. The SOC 2 common criteria expect vendors and business partners to be identified, assessed and monitored, and expect logical access to be provisioned and reviewed against defined authorisations. ISO 42001 is the most directly engaged of the three, since it requires an inventory of AI systems, a recorded purpose and a named owner for each, and an impact assessment before deployment, and an agent that can recruit external agents is squarely in scope. If any of this runs near a payment page, PCI DSS expectations on inventory, access and script integrity follow it. Be clear eyed about the platforms: Vanta, Drata, Secureframe, Sprinto, Thoropass and Hyperproof can confirm your vendor reviews ran on schedule and your policies are approved, and none of them can tell you that at 3am your support agent delegated a customer record to a peer agent it discovered ninety seconds earlier. Our compliance readiness tool and the supplier and access control templates in our policy templates library both assume the list of third parties is something a human maintains.

There is a strong counterargument and it deserves airtime. Neutral governance is genuinely better than the alternative. Having A2A and MCP under one foundation, with the major cloud providers and model labs as signatories, is the condition under which security expectations can be written once and applied broadly, rather than being negotiated vendor by vendor. The published roadmap points that way, with an inter agent trust chain specification for A2A, continued work on the next MCP specification, and a security conformance programme intended to let agent platforms certify against gateway standards. That is the right work. The problem is timing. Specifications land on a committee calendar, and agents are being wired together on a sprint calendar. Between those two dates the control has to be yours, and the honest reading of the protocol design is that it was always going to be yours, because the specification says so.

What that control looks like in practice is not exotic. Route outbound agent to agent traffic through a gateway rather than allowing arbitrary egress from an agent runtime, so that every counterparty is resolvable, allowlisted and logged. Require signed agent cards and verify the issuer, rather than trusting a capability advertisement on presentation. Issue a scoped, short lived credential per delegation, minted for that task with the caller identity carried through, instead of letting a downstream agent act with its own standing privileges. Cap delegation depth, task budget and wall clock time, because unbounded recursion is a documented failure mode rather than a hypothetical one. Log the entire delegation chain and not just the first hop, since an audit trail that stops at your own boundary cannot answer the only question an assessor or a regulator will ask, which is where the data actually went. Treat any artefact returned by an external agent as untrusted input, because instructions smuggled inside content are the delivery mechanism for the privilege escalation described above.

The exercise for this week takes an afternoon and leaves you with something durable. First, ask your engineering leads a direct question and write down the answer: does any agent we run today have the ability to call an agent operated by another organisation, and if so, who is on the other end. Second, add a row type to your third party register for runtime discovered counterparties, with fields for the capability requested, the data class involved, the credential used and the named internal owner, because a register that cannot express the relationship will keep reporting zero. Third, put a one page interim position in writing: no agent delegates to an external agent that is not on an approved list, no delegation carries customer or payment data without a documented approval, and every agent with outbound delegation capability goes on the AI system inventory before it runs. Fourth, log the 20 August governance change in your change register with the date attached, since a shift in who governs a protocol you depend on is a supplier change even when no invoice moves. Fifth, ask your agent platform vendors five written questions and keep the replies: do you support A2A today, how are agent cards verified, how is delegation scope enforced, what does the delegation audit log contain and how long is it retained, and can an administrator enumerate and block external counterparties. The consolidation announced this month is good news for the ecosystem. It is also the moment the agent economy stopped being a research topic and became a supply chain, and supply chains are governed with registers, contracts and logs rather than with enthusiasm.