Traditional web attacks target humans: something must look convincing enough to click. An agent trap inverts the audience. It does not need to look convincing to anyone, because the reader is a model that will read the whole page, including the parts a human would never see.
That changes what an attack looks like. A trap can be invisible text, an HTML comment, white-on-white, a hidden element, or a plausible-looking config block. None of it needs to survive human scrutiny, because no human is scheduled to look.
Where they get placed
Anywhere an agent is likely to go unattended:
- Pages that answer common developer questions. If your agent browses for a fix, the trap sits in the answer.
- Package and dependency metadata. READMEs, changelogs, and post-install notes get read by agents auditing dependencies.
- Issue and PR comments in repositories an agent is asked to triage.
- Files an agent is likely to open by convention, which is why an unfamiliar
AGENTS.mdor.cursorrulesin a cloned repository deserves a read before you point an agent at it.
Why this is emerging rather than proven
The mechanism is real and demonstrated. What is not yet settled is how common deliberate, in-the-wild traps are versus accidental instruction-shaped text doing the same damage. Treat the distinction as unimportant operationally: an agent that follows instructions from a page it read is exposed either way, and the accidental version is already everywhere.
Defences
The honest answer is that content-level detection is weak, because the attacker writes the content and can rewrite it. What holds is limiting consequences:
- Assume any fetched page may contain instructions. Design so that being fooled produces a wrong summary, not an action.
- Human approval on consequential actions, especially anything triggered shortly after reading external content.
- [Least privilege](/ai-coding-dictionary/least-privilege) and [egress control](/ai-coding-dictionary/egress-control), so a successful trap has nowhere useful to go.
- Read unfamiliar instruction files before running an agent in a repository you did not write.
Related terms
Tool poisoning
Tool poisoning is a tool whose own description or schema instructs the model, rather than merely describing what the tool does. Tool definitions go into the context as trusted text, so whoever writes them is writing your prompt.
Read definition →AntipatternValidatedRAG poisoning
RAG poisoning is planting content in a corpus so it gets retrieved and shapes the answer. The attack is on the index rather than the model, and it persists until someone removes the document.
Read definition →AntipatternProvenLethal trifecta
The lethal trifecta is an agent having access to private data, exposure to untrusted content, and a way to communicate outward, all at once. Any two are usually survivable; all three make data theft a matter of someone asking.
Read definition →AntipatternValidatedSandbox escape
A sandbox escape is an agent reaching something the sandbox was meant to keep it away from. In practice it is almost never a container exploit; it is a mount, a socket, or a credential that was inside the boundary all along.
Read definition →