A2A — Agent2Agent, when your vendors AIs start talking

There's a category of risk that doesn't show up on any questionnaire because it lives in the space between your vendors. A protocol shipped in the last year that makes that space much busier, and almost nobody who owns third-party risk at a regulated institution has been told to look at it. This is that briefing.

What happened

Agent2Agent (A2A) is an open protocol for letting AI agents built by different companies discover each other, hand off tasks, and coordinate work — the way REST APIs let applications talk, but for autonomous agents. Google announced it in April 2025, then contributed it to the Linux Foundation in June 2025, where it's now an independent project under the Apache 2.0 license with founding backers including AWS, Cisco, Google, Microsoft, Salesforce, SAP, and ServiceNow (Linux Foundation). By April 2026 the Foundation reported more than 150 organizations supporting it, with the v1.0 specification adding cryptographically signed "Agent Cards" and payment-authorization support (Linux Foundation, one-year update).

Mechanically, an A2A agent publishes an Agent Card — a JSON file, typically at `/.well-known/agent-card.json`, that advertises the agent's identity, its skills, its endpoints, and the authentication schemes it accepts (Tyk). Another agent reads that card, authenticates, and delegates work. Your vendor's support agent can now, in production, call a second vendor's document-analysis agent, which calls a third vendor's data-lookup agent — to answer one customer question.

Why it matters

Your third-party risk program is built on a quiet assumption: that a vendor is a company, and when you diligence "the vendor," you've diligenced the thing that touches your data. A2A breaks that assumption. The vendor you contracted with is now a coordinator that can, at runtime, pull other agents into the work — some from companies you've never assessed, some spun up dynamically for a single task.

Two properties make this an oversight problem, not just an architecture curiosity:

The protocol pushes trust decisions down to the implementer. A2A standardizes how an agent declares its identity and accepted auth schemes (the security schemes follow familiar OpenAPI-style types — API key, bearer token, OAuth2, OpenID Connect, mTLS). But the specification does not mandate how a receiving agent verifies that an Agent Card is authentic. Security researchers modeling these protocols have flagged agent impersonation, card tampering, and replay as live risks when implementers don't add their own controls (SecureW2; threat-modeling analysis, arXiv). Translation for a risk officer: whether the chain of agents behind your vendor is trustworthy is a decision your vendor's engineers made, and it's probably not in your contract.

The surface is dynamic. A traditional subprocessor list is a document — a snapshot you can request and file. An A2A agent mesh is a runtime behavior. Which agents get called can change per request, per task, per business decision your vendor makes on a Tuesday. Your annual questionnaire captures a moment; the surface moves continuously.

This is the same structural gap the agent-identity and MCP-as-vendor posts in this series circle from other angles: the unit you diligence (a company) and the unit that actually touches your data (a fluid set of software identities) have come apart.

What it means for you

If you're a credit union or community bank — Start from the fact that already shapes your world: the NCUA cannot examine your third-party technology vendors, even the ones running AI-driven services (GAO-25-107197, May 2025; GAO has recommended a legislative fix since 2015, and it still isn't enacted). The diligence burden lands on you, structurally, with no examiner backstopping the vendor. A2A widens what "the vendor" even means. The good news is your governing framework already scales to this: NCUA's vendor due diligence is explicitly proportional (07-CU-13 / SL 07-01) — "reasonable alternative procedures," less analysis for non-complex, non-core relationships. You don't have to diligence every agent in a mesh. You have to know the mesh exists for your core and high-risk vendors, and ask one question: when your product acts on our members' data, does it call other companies' AI to do it, and who are they? Get the answer in writing.

If you're an RIA or broker-dealer — Your Reg S-P amendments are live (all smaller entities as of June 3, 2026; the industry's extension request was denied), and 17 CFR 248.30(a)(5) requires written policies for ongoing "oversight, including through due diligence and monitoring, of service providers." Reg S-P compliance is a named SEC Division of Examinations FY2026 priority. "Ongoing oversight" and "a vendor whose AI subcontracts to other vendors' AI at runtime" are on a collision course. Your do-this-Monday move: add one line to your service-provider oversight questions — Does your service use agent-to-agent protocols (such as A2A) to route our data or requests to other providers' AI systems? If so, which, and how are those connections authenticated? You are not expected to audit the protocol. You are expected to have asked, and to have the answer on file when an examiner asks how you oversee providers.

How to get ahead of it

The prepared move here is cheap and it's mostly a vocabulary upgrade to work you already do.

1. Add the mesh question to your standard vendor set. One question, asked of every AI-touching vendor: does your product call other companies' AI agents to do its work, and if so, who and how are they authenticated? File the answer.
2. Flag your core and high-risk vendors first. Proportionality is your friend. The member-facing loan platform and the RIA's portfolio tools get the question; the office-plant subscription doesn't.
3. Write the finding down even when the answer is "no." "Vendor confirmed no agent-to-agent routing as of [date]" is exactly the kind of dated, attributable line an evidence binder is made of. A "no" today with a signature beats a "probably not" you're reconstructing from memory at exam time.
4. Re-ask on a cadence. Because the surface is dynamic, a one-time answer decays. Annual re-confirmation, tied to your existing vendor review cycle, turns a moving target into a governed one.

What to watch out for

The overreaction: treating A2A as a threat to block. You can't, and you don't need to — it's becoming plumbing across the major cloud and SaaS platforms your vendors already run on. A policy that says "we prohibit agent-to-agent protocols" is unenforceable theater that an examiner will see through.

The snake oil: any tool that promises to "monitor your entire agent mesh" or "give you full visibility into A2A traffic" across vendors you don't control. You can't observe the inside of your vendor's runtime from the outside. What you can do is require disclosure and document it — that's oversight, and it's what the rule actually asks for. Be suspicious of anything selling you a dashboard for a network that isn't yours.

The false comfort: "v1.0 added signed Agent Cards, so it's secure now." Signing proves an agent is who it says it is. It says nothing about whether that agent — or the three it calls next — should have your data. Authentication is not authorization, and it is not diligence.

The bottom line

A2A is real, backed by essentially every major platform, and already in production — which means the "AI vendor" you assessed last year may now be a front door to a set of agents you've never heard of. You don't need to police the protocol. You need to know, in writing, which of your vendors use it and who's on the other end, and to re-ask as the surface moves. That inventory-plus-attribution is exactly what a Discover scan is built to capture — the vendors, the connections behind them, and a dated record you can hand an examiner.

Request your Discover scan — we run it with you, and the agent-mesh questions are already in the workbook.