Slide 17 of 28
Part 3 — Attack ScenariosSlide 17
Slide 17 · The Pattern
Six scenarios, one pattern: the attack enters before the agent makes a decision
Every AG04 attack exploits the same window: the gap between what the agent was designed to trust and what it actually receives.
The universal attack structure

Every scenario in this module follows the same structure:

Step 1 — Identify a trusted source. The attacker finds something the agent depends on and trusts: a registry, an MCP server, a prompt template, a tool descriptor, a knowledge source, an agent card.

Step 2 — Compromise or impersonate it. The attacker either takes over the legitimate source or creates a convincing substitute.

Step 3 — Wait. The agent eventually loads, fetches, or connects to the compromised source — as part of its normal operation. No further attacker action is required.

Step 4 — Collect. The agent executes the attacker's payload autonomously, trusting it as if it came from the legitimate source it was designed to use.

Why traditional defenses don't stop this

Signature verification, HTTPS, authenticated registries — all of these protect the channel and verify the source's identity. They do not protect against a legitimate, authenticated source that has been compromised. The Amazon Q extension was signed and distributed from the official marketplace. The Postmark impersonator had a valid npm account. The GitHub issue that drove the MCP descriptor attack was a real issue on a real repository.

The attacks passed all traditional trust checks. The supply chain itself was the attack surface.

Going into Part 4

The mitigations for AG04 can't just verify that a source is who it claims to be. They must also verify the integrity and content of what the source provides, and limit what the agent can do with it even if that content is malicious. That combination — provenance + containment + continuous validation — is the architecture of Part 4.

← Back Part 4: Prevention and Mitigations →