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

**Course**: 2B — Securing & Attacking Harnesses and LLMs
**Deep-Dive**: SDD-B13 — The A2A Protocol: Agent-to-Agent Communication Security
**Duration**: ~30 minutes (spoken at ~140 wpm)
**Format**: Verbatim transcript with `[SLIDE N]` cues. Read aloud or use as speaker notes.

---

[SLIDE 1 — Title]

Welcome to deep-dive SDD-B-thirteen, the A2A protocol — agent-to-agent communication security. Module B-six introduced inter-agent trust. It named the message channel as a trust boundary, built the signed-message model, the replay protections, the blast-radius caps. But B-six left the protocol unspecified — "the message channel" was a placeholder for whatever your mesh happened to use. That placeholder now has a name. A-two-A, the Agent-two-Agent protocol, announced by Google in April twenty-twenty-five and backed by fifty-plus enterprise partners, is becoming the de-facto inter-agent wire format the way M-C-P became the de-facto agent-to-tool format. This deep-dive goes deep on the protocol that makes inter-agent communication real — and the attack surface it creates. Every attack from B-six now targets a concrete protocol artifact.

[SLIDE 2 — The thesis: A2A is a transport protocol, not a security protocol]

Here is the load-bearing distinction. A-two-A is a transport and coordination protocol, not a security protocol. It defines how agents talk. It does not, by itself, guarantee who is talking, or that the message is intact, or that the message is fresh. The security — authentication of the caller, integrity of the JSON-RPC payload, freshness of the request, authorization of the delegated action — is the implementer's responsibility, layered on top.

The Agent Card's authentication field tells you what scheme the agent expects — OAuth-two, an API key, mutual T-L-S. It does not perform the authentication. It declares it. And the places where implementers most often skimp — payload signing, delegation-depth limits, Agent Card integrity, push-notification endpoint authentication — are exactly the places the attacker enters. On the left, B-six in the abstract. On the right, the concrete protocol artifact each B-six attack now targets. The forged orchestrator message is now a forged message-slash-send JSON-RPC call. The unauthenticated peer is now an Agent Card whose authentication field was not validated. The replay is now a captured tasks-slash-push-notification-set registration replayed to redirect results to an attacker's webhook.

[SLIDE 3 — The protocol, in one slide]

The protocol, in one orientation slide. Five artifacts. Read as a builder, each is elegant. Read as an attacker, each is a target.

The Agent Card is a JSON document an agent publishes at slash-dot-well-known-slash-agent-json. It advertises a name, a list of skills, a URL — the A-two-A endpoint — the authentication schemes the agent accepts, and capabilities like streaming and push notifications. To the attacker, this is a reconnaissance document the victim published for you. The skills array enumerates the capability surface — exactly what you need to plan a tool-abuse or excessive-agency chain. The URL is the attack endpoint, handed over without scanning. The authentication field tells you which scheme to attack and which is absent.

The Task is the stateful work object. Its lifecycle is submitted, working, then one of input-required, completed, failed, or canceled. To the attacker, this is a state machine with hijackable transitions. Cancel is a denial-of-service primitive. Input-required lets any caller steer the task. Pollable states are a data-disclosure endpoint if task IDs are enumerable.

Messages and Artifacts carry natural-language and semi-structured content that downstream agents interpret. To the attacker, these are unvalidated content carriers. There is no syntax that marks a string as "data, not instruction" in natural language. A multi-hop chain of messages is a multi-hop output-as-input chain — and the signature on each hop proves only the immediate sender, not the original taint source.

The JSON-RPC methods — message-send, tasks-get, tasks-cancel, tasks-push-notification-set — are the attack endpoints. The Agent Card told the attacker where they live.

[SLIDE 4 — The Agent Card as published reconnaissance]

Zoom in on the Agent Card. Read as a builder, it is elegant — the inter-agent OpenAPI spec, letting an orchestrator discover and dispatch to a remote agent without prior integration. Read as an attacker, it is a reconnaissance document the victim published for you. Every field is useful and several are dangerous.

The skills array enumerates competencies with natural-language descriptions — the exact surface for an A-S-I-zero-five tool abuse or A-S-I-zero-three excessive-agency chain. And because the descriptions are natural language, they are also an injection vector if an orchestrator naively concatenates them into a routing prompt. The URL field is the attack endpoint. The authentication field tells you which scheme the agent will accept — and critically, which schemes it will not. An agent whose authentication field lists only OAuth-two and does not enforce mutual T-L-S is telling you that a stolen bearer token is sufficient.

The deeper problem is Agent Card integrity. The card is fetched over HTTPS, which guarantees transport integrity. But if an attacker can compromise the originating server, the DNS, or a caching layer, they substitute a malicious card whose URL points to the attacker. The orchestrator dispatches to the wrong endpoint. This is the A-two-A equivalent of a DNS rebind, and it works because most client libraries trust the URL field without verifying it against an allowlist or a signature. The fixes are: sign the Agent Card, allowlist the URL, and never trust a card whose signature you cannot verify.

[SLIDE 5 — The Task lifecycle: hijackable transitions]

Zoom in on the Task lifecycle. Four transitions the attacker reads as primitives.

Tasks-cancel: if the protocol does not authorize cancel to the task's original caller, any agent that can guess a task ID cancels a competitor's task — a denial-of-service primitive. Worse, an attacker can cancel and immediately re-submit a similar task with attacker-controlled content, racing the legitimate caller.

Input-required: when a task enters input-required, the agent is asking for more information. The protocol allows any caller to respond. If the caller is not re-authenticated against the task's original principal, an attacker supplies the additional input and steers the task. The input is incorporated; the task proceeds under the original caller's authority. This is the A-two-A form of B-six's trust-escalation attack.

Tasks-get: if task IDs are sequential or timestamp-derived, an attacker polls every ID in a range and reads every task's messages and artifacts. Data disclosure at protocol granularity. The fix is cryptographically random task IDs — one hundred twenty-eight bits minimum — and caller-bound authorization on every read.

Completed: a completed state that was not earned. If the caller does not verify the transition, it consumes incomplete or attacker-substituted artifacts. The protocol gives you the states. It does not give you a proof that the transition was earned.

[SLIDE 6 — The four core threats mapped to B6]

Now the four core A-two-A threats, mapped to their B-six controls. This is the slide that answers "B-six already covered this." B-six covered the attacks in the abstract. A-two-A names the protocol artifacts. Every fix is a B-five or B-six control applied at the A-two-A boundary.

Threat one, impersonation. The attacker publishes a malicious Agent Card or steals a valid credential. B-six assumed you knew who you were talking to — A-two-A's Agent Card discovery is where that assumption breaks. The A-two-A fix is Agent Card signing, URL allowlisting, and audience-bound tokens whose aud claim is checked.

Threat two, task hijacking. The attacker abuses the task lifecycle. B-six did not address task state machines — this is genuinely new attack surface A-two-A introduces. The fix is caller-bound authorization on every state-mutating call, random task IDs, and state-transition proofs.

Threat three, tampering. The attacker modifies a JSON-RPC payload at a proxy or middleware. B-six's control is H-M-A-C or asymmetric signatures — now applied to the JSON-RPC envelope. The A-two-A-specific fix is application-layer payload signatures that survive T-L-S termination, with canonical JSON serialization.

Threat four, replay. The attacker captures a legitimate message-send and re-submits it. B-six's control is nonces and timestamps with freshness windows. The A-two-A fix is to require a nonce and timestamp in every JSON-RPC envelope and reject any call whose timestamp is outside the window or whose nonce has been seen. Without this, the push-notification registration call is replayable — the attacker captures it, replays it with their own webhook URL, and redirects every task's results.

[SLIDE 7 — The push-notification hijack]

Zoom in on the single most A-two-A-specific attack — the push-notification hijack. The setup: tasks-push-notification-set lets a caller register a webhook to receive asynchronous task updates. The agent POSTs results to the webhook when the task completes. The attack: if task IDs are enumerable and registration is not bound to the original caller, the attacker re-registers the webhook to their own URL for the victim's task. The agent sends the completed results to attacker-dot-com-slash-exfil. The victim never receives them.

Note what the attacker did not do. They did not tamper with the task's content. They did not impersonate the agent. They did not even need to compromise anything — they just redirected where the results were delivered. This is data exfiltration at protocol granularity. The fixes: random task IDs so they cannot be enumerated, caller-bound registration so only the original caller can set a webhook, a webhook URL allowlist so arbitrary URLs are rejected, and a signed challenge the victim must verify.

[SLIDE 8 — Delegation chains: over-propagation vs attenuated tokens]

Now the hardest problem in A-two-A security — delegated authority across multi-hop chains. In a realistic mesh, the user's orchestrator calls a research agent, which calls a search agent, which calls an extraction agent. Each hop is a message-send. The question: what authority does each agent in the chain hold?

Two failure modes dominate. Over-propagation: the orchestrator passes its full credential to the research agent, because that is easier than minting a downscoped one. The research agent passes the same credential to the search agent. The search agent is compromised. The search agent now holds the orchestrator's full credential and can call any A-two-A agent the orchestrator could — not just the search it was asked to perform. This is A-S-I-zero-three excessive agency and B-six's trust-escalation attack, now operating across a delegation chain.

The fix is capability tokens — Macaroons, Sparkle delegation tokens, or custom J-W-Ts. Each hop mints a strictly weaker token: method equals message-send, task equals T-one, depth equals N. The token attenuates at each hop. The leaf agent's token, when presented to an external tool, authorizes only what the chain explicitly permitted. The leaf's compromise cannot exceed the task it was minted for. This is B-five's scoped credential and B-six's blast-radius cap, applied inter-agent. On the left, over-propagation — the credential does not attenuate. On the right, attenuated tokens — every delegation mints a weaker token.

[SLIDE 9 — The four orchestration topologies and cascade blast radius]

Now the four topologies in which A-two-A runs, evaluated for the one question that matters: when one agent is compromised, how far does the damage spread?

Orchestrator-worker. A central orchestrator dispatches to specialized workers. The orchestrator is the chokepoint — every A-two-A call passes through it, and the orchestrator can enforce compartments and scoped credentials. The cascade risk: if the orchestrator is compromised, the entire mesh is lost. Workers must re-authorize every call against the original principal, not just trust the orchestrator's identity.

Peer-to-peer, the mesh. Agents call each other directly. This is the topology with the worst cascade blast radius — every agent is a trust boundary for every other agent, and a compromise of any node propagates to every peer. This is the mesh-wide worst case B-six warned about. The defense is the same as B-six: trust compartments, signed messages, blast-radius caps.

Hierarchical. A tree — root orchestrator, mid-level supervisors, leaf workers. Authority flows down, results flow up. The cascade risk is depth-dependent. A compromised leaf is bounded to its branch. A compromised mid-level supervisor affects every leaf beneath it. A compromised root is everything. The risk is exactly the delegation-chain over-propagation from the last slide.

Market-based, the auction or contract-net topology. An agent announces a task, multiple agents bid, the announcing agent awards the task to the winner. The cascade risk is unique: the selection of the winning bidder is itself an attack surface. An attacker who can spoof bids, manipulate the selection criteria, or undercut legitimate bidders wins tasks they should not. The fix is bidder authentication, signed bids, and a selection audit log.

[SLIDE 10 — MCP vs A2A]

Resolve the most common confusion about A-two-A — its relationship to M-C-P. M-C-P is agent-to-tool. A-two-A is agent-to-agent. They are complementary, not competing. They compose in a real system: an agent uses M-C-P to call a tool — a database, an API — and A-two-A to call another agent.

The boundary between them is itself an attack surface. An agent registered as an M-C-P tool — a remote agent behind an M-C-P interface — inherits M-C-P's weaker trust model while exercising A-two-A's richer capability surface. The discipline is to identify, in the agent SBOM from SDD-B-zero-seven, which "tools" in your registry are actually remote agents, and to apply A-two-A-grade authorization to them regardless of the protocol they were registered under. M-C-P's in-process trust assumptions do not survive a network boundary.

The same point applies to framework-level protocols like Crew. Crew defines inter-agent communication in code, assuming co-deployed agents sharing a runtime. Crew's in-process delegation has no network attack surface. The moment the same delegation crosses an A-two-A boundary, every attack in this deep-dive applies. The migration from Crew-in-process to A-two-A-across-network is a trust-posture downgrade teams often miss.

[SLIDE 11 — Anti-patterns]

Four anti-patterns, each with its cure.

"We use HTTPS, so the messages are authentic." Transport security guarantees integrity between the T-L-S endpoints, not the application endpoints. A proxy, a load balancer, or a logging middleware that terminates T-L-S and forwards internally breaks the guarantee. Cure: application-layer payload signatures — H-M-A-C or asymmetric — over the canonical-JSON-serialized body, verified at the receiving agent's application layer.

Passing the full credential down a delegation chain. The orchestrator's credential, passed unchanged to a leaf agent, gives the leaf the orchestrator's full authority. A compromised leaf is a compromised orchestrator. Cure: mint attenuated capability tokens at each hop, with a max-delegation-depth that decreases at each hop.

Trusting the Agent Card's authentication field as posture. The card declares what the agent will accept. It does not prove the agent enforces it. An attacker's card can declare OAuth-two and accept anything. Cure: obtain Agent Cards from a trusted registry, verify the card's signature against the agent's long-term key, and treat the authentication field as a claim to verify, not a guarantee to trust.

Enumerable task IDs. Sequential or timestamp-derived task IDs let an attacker poll tasks-get across a range and read every task's messages and artifacts. Cure: cryptographically random task IDs and caller-bound authorization on every read.

[SLIDE 12 — What you can now do]

Close on what you can now do. Describe the A-two-A specification — Agent Cards, Task lifecycle, Messages, Artifacts, the JSON-RPC methods — as a concrete attack surface. Explain the trust model: how agents authenticate, how delegation chains propagate and over-propagate, where the protocol is silent. Identify the four core threats — impersonation, task hijacking, tampering, replay — and map each to its B-six control and A-two-A-specific fix. Articulate the M-C-P and A-two-A relationship and why the boundary between them is an attack surface. Evaluate the four orchestration topologies for cascade blast radius and design authorization that bounds propagation.

The lab: build two agents that communicate via a simulated A-two-A protocol. Then attack the channel — substitute a malicious Agent Card, replay a push-notification registration, hijack a task via input-required, exceed the delegation chain's authority. Confirm that the B-six defenses — payload signatures, nonces, scoped credentials — defeat each attack when applied at the A-two-A layer.

B-six introduced inter-agent trust. This deep-dive is the protocol that makes it concrete. C-four covers multi-agent orchestration at platform scale — this deep-dive covers the security dimensions of the same protocols.