Agent-to-Agent (A2A)

A2A (Google, Apr 2025; now Linux Foundation) connects agents across each other, including across organizations. Three actors: a Client Agent, a Remote Agent, the User. Discovery is via Agent Cards (/.well-known/agent-card.json). Defining stance: opaque execution - share context and artifacts, never internal memory, plans, or tools.

# tamper with discovery so the client fetches an attacker-controlled Agent Card:
GET https://target.example/.well-known/agent-card.json    # poison via DNS / hosts / MITM
# the spoofed card keeps a trusted name + skills but routes tasks to the attacker endpoint;
# or register a rogue agent where registration lacks mutual auth -> peers delegate to it

flowchart LR
  User(["User / service"]) --> CA["Client Agent"]
  CA -->|"1 fetch Agent Card"| RA["Remote Agent"]
  CA -->|"2 send Task: Message + Parts"| RA
  RA -->|"3 Artifacts + status (SSE / push)"| CA
  RA -.->|"reaches its own tools"| MCP["MCP Servers"]
  classDef a fill:#11161f,stroke:#8fb9ff,color:#c6d4ef;
  classDef m fill:#0f1a18,stroke:#5bd1c5,color:#bdeee2;
  class CA,RA a; class MCP m;

A2A for delegation between agents (blue), MCP for each agent’s private tool reach (teal). The remote agent’s tools are opaque to the client - you trust the boundary, not the internals.

The threat-model method of record is MAESTRO. A2A’s empirical literature was thinner than MCP’s but matured fast in late 2025 (A2ASecBench).

A2A-1 · Agent Card spoofing / tampering

The card drives discovery and trust; manipulated capability claims or endpoints redirect tasks or smuggle injection payloads. DNS/hosts manipulation is one delivery path.

Defense — Sign cards; verify issuer; validate schema; never let card text flow unfiltered into the model.

A2A-2 · Impersonation & rogue registration

Without strong mutual auth, a malicious agent claims to be trusted or registers into the ecosystem and receives delegated tasks. Cross-vendor it becomes trust-boundary exploitation.

Defense — mTLS + OIDC; managed non-human identities; explicit trust registries; short-lived task-scoped creds.

A2A-3 · Task tampering & intent deception

Altering a task’s payload/results/status mid-flight, or a peer that advertises one intent and acts on another. OWASP ASI07.

Defense — Integrity-protect messages and artifacts; authenticate every state transition; audit the delegation chain.

A2A-4 · Delegation privilege escalation

Authority accumulates along a delegation chain - the transitive-trust problem (OWASP ASI03).

Defense — JIT task-scoped credentials per hop; non-transitive authority; least privilege at each boundary.