Most write-ups about agent attacks list ten categories side by side. That's not how a real compromise happens. Real compromises are sequences — a quiet foothold, a moment of misplaced trust, then a consequential action using permissions the agent already had. This is that sequence, told as one continuous story, with the stoppable moment marked at each stage.
Scope note: for a category-by-category catalog of individual attack types, see AI Agent Attack Simulation →. This guide is the narrative version — how those categories actually combine into a real incident.
Prompt injection, retrieval poisoning, tool abuse, permission escalation — these are useful categories for testing, but a real attacker doesn't pick one and stop. A real compromise is a sequence, where each step sets up the next, and the action that actually causes damage at the end often looks completely unremarkable in isolation. Understanding the sequence is what makes the individual categories make sense.
The attacker rarely talks to the agent directly. Instead, they plant content somewhere the agent will encounter it as part of its normal job: a document it will be asked to summarize, an email in a shared inbox it monitors, a support ticket it will triage, a webpage it will browse. The content looks completely ordinary to a human reviewer — the malicious instruction is buried in formatting, metadata, or phrasing that reads as routine.
The user who triggered the agent's task never typed anything suspicious. They asked it to "summarize this document" or "check the new support tickets." The attack arrived through the side door, not the front door.
Could have stopped here: treating retrieved content with the same scrutiny as direct user input, scanning documents for injection patterns before they ever enter the prompt.
This is the part that doesn't look like an attack at all. The agent retrieves the planted document, and because nothing in its architecture structurally separates "instructions from the system" from "instructions hidden in retrieved content," it folds the planted instruction into its working context as if it were a legitimate part of the task.
No alarm fires. No anomalous API call happens yet. The agent is simply now operating with a corrupted understanding of what it's supposed to do next — and it got there through a completely normal-looking retrieval step.
Could have stopped here: explicit context isolation — structurally separating system instructions from retrieved content so the model can't treat the two as equally authoritative.
Here's the part that surprises people: the attacker almost never needs to escalate the agent's permissions. The agent already has email access because part of its job is sending email. It already has database query access because part of its job is looking up records. The corrupted context from Stage 2 just redirects an existing, legitimate capability toward a target the operator never intended — the email goes to an external address instead of the internal team, the query pulls a record the requesting user shouldn't see.
This is why excessive agency is the single biggest amplifier of real-world damage. The attacker isn't breaking in through a new door — they're walking out the door the agent already had open.
Could have stopped here: approval gates on consequential actions, and permission scopes narrow enough that even a fully manipulated agent can't reach anything beyond its actual task.
In systems with multiple agents working together, the corrupted output from Stage 3 doesn't have to stay contained. If a planning agent passes its (corrupted) plan to an execution agent, and the execution agent treats anything from the planning agent as inherently trustworthy, the compromise propagates without a second injection ever being needed. One foothold becomes a chain.
Could have stopped here: not extending implicit trust between agents just because they're part of the same orchestrated system — every hand-off deserves the same scrutiny as external input.
Every stage above shares the same structural weakness: something was trusted because of where it came from, not because of what it actually was. Retrieved content was trusted because it came through the "normal" retrieval pipeline. The corrupted context was trusted because it was already inside the system. The action was permitted because the agent already had that capability. The hand-off was trusted because it came from another agent in the same workflow.
None of these are exotic technical exploits. They're trust assumptions, exploited systematically.
The HexTyx AI Security Assessment doesn't just test individual attack categories — it simulates the full foothold-to-action sequence against your live system.
Teams test the prompt and the model's refusal behavior but never test what happens when a malicious document quietly enters through retrieval.
"The agent might need this eventually" thinking leads to broad permission grants that turn Stage 3 from theoretical into trivial.
Nobody explicitly designs inter-agent distrust — it has to be added deliberately, and most teams never get around to it.