The meeting that surfaces this risk is usually about procurement. A platform team has connected its internal planning agent to a partner's agent over A2A, the pilot works, and someone asks: what can the partner's agent make ours do? Nobody can answer, because the integration was designed around what the partner's agent does for us, not the reverse.
Google announced A2A on April 9, 2025, with support from more than 50 technology partners, as an open protocol for agents to collaborate across vendors, advertising capabilities in a JSON document called an agent card [2]. The specification has since reached a 1.0.0 release [1]. It is a messaging and discovery protocol, and its most important security sentences are the ones that hand decisions back to you. Our position: a conforming A2A deployment is secure only if every hop re-decides authority from its own policy. Below are the questions a review board should ask, answered from the specification and the public research.
Does a signed agent card tell us who we are talking to?
Not by itself. An A2A server publishes a card describing its identity, capabilities, skills, endpoint and authentication requirements, found at a well-known URI, through curated registries, or by direct configuration [1]. Cards "MAY be digitally signed" with JSON Web Signature, canonicalized with RFC 8785 first, and clients "SHOULD verify at least one signature before trusting an Agent Card" [1]. Verification fetches the public key using the kid and jku values, or from a trusted key store, and expired or revoked keys must not be used [1].
A signature checked against a key fetched from a URL the card itself names proves the card was not altered since someone holding that key signed it. It does not prove that someone is the organization you meant to work with. Identity comes from where you got the key: a trust store you maintain, a key pinned when the partnership was set up, or a registry you operate. An unsigned card, or one verified only against its own jku, is a self-description.
A card becomes usable for consequential delegation only after its signature verifies against a key you already trust and the skill requested is on your allowlist for that provider. An unsigned card is untrusted, and a key taken only from the card proves integrity, not identity.
There is a second layer. A server can offer an extended card to authenticated clients, with additional skills or organization-specific details, and clients retrieving it should replace their cached public card for the session [1]. The capabilities your agent sees after authenticating may differ from what anyone reviewed at approval. Allowlist skills from the card your agent actually uses.
The partner authenticates every request. Isn't that authorization?
No, and the specification says so. Clients discover the server's required schemes from the card, obtain credentials "through an out-of-band process," and send them on every request; servers must authenticate every incoming request [1]. Authorization is then "based on the authenticated identity and its own policies," and "Authorization logic is implementation-specific" [1]. Section 13.1 requires authorization checks on every operation and results scoped to the caller's boundaries, with models that are agent-defined, not prescribed [1].
That is not a flaw. It is the honest scope of a protocol. It also means a multi-agent system's security is decided almost entirely by policies each implementer writes, and a conforming deployment can still authorize far too much.
The person signed in at the first hop. Does that authority carry down the chain?
Only as content. A person asks a planner, the planner hands part of the task to a worker, the worker calls a remote agent. Each receiver can verify only the credential in front of it. The person's constraints, which customer and which limit, travel as text in a message unless something re-derives them.
The specification is explicit about one version of this. An agent needing further authorization mid-task can move the task to an auth-required state and push the request back to its client, and a client that is itself an agent can pass it further up [1]. The protocol "does not define the scope, representation, validity, or revocation semantics" of the resulting authorization, and agents "MUST NOT treat the TASK_STATE_AUTH_REQUIRED state transition, by itself, as authorization for any particular operation" [1]. Credentials exchanged in band can be exposed to every agent in the chain, so the specification recommends binding them to the originating agent and encrypting sensitive ones [1].
OAuth token exchange shows why recording a chain is not enforcing it. RFC 8693 lets a token carry nested act claims, the outermost naming the current actor, but only the top-level claims and the current actor are used for access control; prior actors are informational [5]. A downstream service can see that a person was involved several hops ago. It cannot treat that as the person's authorization without its own decision.
The planner sees a signed-in person; the worker sees the planner's token with the person only as a note; the remote agent sees the worker's token and applies its own grants. Meanwhile the remote agent's response flows back into your worker's context, where it can be read as instructions.
So what can the partner's agent make ours do?
Most A2A threat models have the server protecting itself from clients. Unit 42's research, published October 31, 2025, looks the other way [3]. In agent session smuggling, a malicious remote agent uses an established, stateful session to send covert instructions to the client agent, hidden among ordinary requests and responses. The proof of concept used a financial assistant built on Google's Agent Development Kit as the client and a research assistant as the malicious remote. In one scenario, harmless-looking clarification questions led the client to disclose its chat history, system instructions, tools and tool schemas. In another, hidden instructions in the remote's replies led the client to call its buy_stock tool, executing an unauthorized trade of 10 shares for the victim user [3].
Unit 42 says the research does not reveal a vulnerability in A2A itself and that it has not observed the attack in the wild; the risk comes from implicit trust between agents [3]. It recommends human approval for sensitive actions through a channel the model cannot influence, signed agent cards, grounding the remote agent's instructions against the original user request, and showing users tool invocations and remote instructions [3]. Habler and colleagues reach a compatible view from the other side, applying the MAESTRO threat-modeling framework to A2A and assessing risk across agent card management, task execution integrity and authentication [4].
Which of these does the specification cover, and which are ours?
Picture a fictional insurer whose claims planner delegates repair estimates to a body-shop network's agent. The network's card came from a public registry and is unsigned, its extended card adds a skill nobody reviewed called finalize settlement, and the integration forwards the claimant's portal token in band so the estimate agent can read uploaded photos. Each of those choices is a row below, and none of them breaks the protocol.
| Risk | What the specification says | What you have to do |
|---|---|---|
| Impersonated or tampered card | Signing is optional; clients should verify at least one signature [1] | Verify against keys you pin or hold in a trust store, never against a key the card alone points to |
| Unreviewed skills | Extended cards may add skills for authenticated clients [1] | Allowlist skills per provider from the card your agent actually uses |
| Transitive authority | Authorization is implementation-specific; the auth-required state is not itself authorization [1] | Re-decide at every hop what this caller may do for which person, from your own policy |
| Credential exposure along a chain | In-band credentials can reach every agent; bind them to the originating agent [1] | Keep credentials out of band, scoped to one audience, and never forward a user's token to a remote agent |
| Remote output steering your agent | Out of scope for the protocol; demonstrated by Unit 42 [3] | Treat remote responses as untrusted data, and make consequential tools ask a person |
| Push notification abuse | Agents should validate webhook URLs to prevent SSRF and reject private ranges [1] | Allowlist webhook destinations and authenticate every notification you receive |
| Runaway delegation | Rate limiting on all operations is recommended [1] | Cap delegation depth and fan-out, and add circuit breakers so one failure cannot cascade [6] |
How would we know it was happening?
Each message in a smuggling session looks reasonable on its own, so neither agent's view alone shows it. The signal is the relationship between a remote agent's output and what your agent does next. Log every cross-agent message with the task, the peer's verified identity and the card version in use, and link each tool call your agent makes to the most recent remote message in its context.
- A consequential tool call, such as a payment, trade or outbound message, that follows a remote response and was not part of the original user request. That is the pattern Unit 42 demonstrated [3].
- A remote agent asking about your agent's instructions, tools or schemas, especially over several turns, which matches the disclosure scenario [3].
- A card whose signature, key or skill list changed since review, or an extended card that adds skills. Hold the integration until someone re-approves it.
- Delegation depth or fan-out above your cap, or a peer whose request rate jumps: early signs of a loop or a cascading failure.
Can a gateway do this for us?
Partly. Intertrace's gateway covers A2A messages alongside model, MCP and tool traffic, deriving tenancy from the calling agent's runtime key rather than anything in the message. Decision fusion treats hidden instructions and instruction-override language as structural signals that can block alone, which applies to text a remote agent sends back. The tool calls your agent then attempts are classified from their arguments, and roles keep payments, outbound messages and admin changes asking a person, with every decision recorded by rule and layer. Pinning partners' card keys and allowlisting their skills stay part of each integration.
What should we require before go-live?
- A list of every A2A peer, in both directions, with the most consequential tool reachable in the same session as each peer's messages.
- A pinned signing key or trust anchor per external peer, and refusal of cards that do not verify against it.
- A per-peer skill allowlist, reviewed from the extended card your agent actually receives.
- Authorization re-decided at every hop from your own policy, bound to the person and resource the action is for. As OWASP puts it, "A valid message signature does not grant permission to perform the requested action" [6].
- Credentials kept out of band and audience-scoped, and no user token forwarded to another organization's agent.
- Remote responses marked untrusted in your agent's context, with payments, outbound messages and admin changes asking a person through a channel the model cannot write to.
- Caps on delegation depth and fan-out, rate limits per peer, and a log of every cross-agent message with the chain that produced it.
