Prompt injection explained: why AI agents that read web pages, email and documents can be hijacked, and which defenses work

Prompt injection happens when text an AI system reads contains instructions, and the model follows them as if they came from you. A chatbot that only talks back has little to lose. An agent that can browse, read your inbox, run commands and call tools is a different matter. A hidden line in a web page, an email, a GitHub issue or a README can redirect everything the agent is allowed to do. That makes prompt injection the defining security problem for coding agents and every other kind of agent.

This explainer draws on the OWASP Top 10 for LLM applications, NIST's agent-hijacking research, Simon Willison's writing, Google DeepMind's CaMeL paper, and Anthropic's and OpenAI's own guidance, checked on October 12, 2026.

The short version

• What it is: untrusted content that the model treats as instructions. OWASP lists it as LLM01:2025, the top risk for LLM applications.
• Why it's hard: the model receives your request and the content it reads as one stream of text, with no reliable boundary between them.
• When it's dangerous: when an agent has what Simon Willison calls the lethal trifecta: access to private data, exposure to untrusted content, and a way to send data out.
• What doesn't work on its own: prompt-based guardrails, detection filters and model training. All of them help, and none is a guarantee.
• What does work: designs that hold even when the model is fooled. Remove one leg of the trifecta, keep untrusted content away from tool decisions (as Google DeepMind's CaMeL does), use least privilege and sandboxing, and require human approval for consequential actions.

What is prompt injection?

Willison coined the term on September 12, 2022, naming it after SQL injection, because both come from mixing trusted instructions with untrusted input. OWASP defines it as inputs that alter a model's behavior or output in unintended ways. Those inputs can be invisible to people, as long as the model reads them.

There are two kinds:

• Direct injection: the person typing into the model tries to override its rules. Jailbreaking is a form of this.
• Indirect injection: the attack arrives in content the model processes on someone else's behalf, such as a web page, a document, an email, a code comment or a tool result. This is the kind that matters for agents. NIST's Center for AI Standards and Innovation (CAISI) calls it agent hijacking.

OpenAI describes it as "a type of social engineering attack specific to conversational AI." Its example: an attacker hides instructions in an apartment listing so that an AI researching apartments recommends it, whatever the user actually wanted.

Why can't the model just ignore instructions in the data?

A language model reads everything in its context window as one sequence of tokens. Your request, the system prompt and the text of a web page all arrive the same way. Models are trained to follow instructions, and nothing in the architecture marks one span as "data only." NIST's CAISI puts it directly: current agents are vulnerable because they mix trusted developer instructions with untrusted data in a single input.

Vendors are training models to tell the difference, and it helps. But a learned behavior is probabilistic, so it can't serve as a guarantee. That's why OWASP says that, given how generative models work, "it is unclear if there are fool-proof methods of prevention."

When does an injection become dangerous?

Willison's lethal trifecta (June 16, 2025) is the most useful test. An agent is exposed to data theft if it combines:

1. access to your private data;
2. exposure to untrusted content, meaning anything an attacker could write;
3. the ability to communicate externally, such as sending email, making web requests, opening pull requests or even rendering an image URL.

If all three are present, an injected instruction can tell the agent to collect your data and send it out. The same reasoning covers damaging actions. If untrusted text can reach an agent that can run commands, publish packages or move money, the text can try to make it do those things.

Has this actually happened?

Yes, repeatedly. A selection of documented cases:

Our case against unattended agents covers several of these in detail. Microsoft's lesson from Semantic Kernel applies to every agent framework: "Any tool parameter the model can influence must be treated as attacker-controlled input."

How well do models resist it today?

Better than before, but not well enough to rely on. Three data points, each with its own limits:

• NIST CAISI (published January 17, 2025, updated December 19, 2025): on the AgentDojo benchmark, red-teaming the upgraded Claude 3.5 Sonnet raised the attack success rate on held-out workspace tasks from 11% (the strongest existing attack) to 81% (the strongest new one). Over 25 attempts per attack, average success rose from 57% to 80%. The point: models that resist known attacks can still fall to new ones, and attackers can keep retrying.
• NIST CAISI and Gray Swan (March 23, 2026): a public red-teaming competition with more than 400 participants made over 250,000 attack attempts against 13 frontier models in tool-use, coding and computer-use scenarios. At least one attack succeeded against every model. CAISI didn't name the models in its post.
• Anthropic, vendor-reported (November 24, 2025): for Claude Opus 4.5 in its Chrome extension, Anthropic reported a 1% attack success rate against an internal adaptive "Best-of-N" attacker given 100 attempts per environment. Anthropic itself says 1% "still represents meaningful risk" and that "no browser agent is immune to prompt injection."

These numbers come from different evaluators, models and test setups, so they can't be compared directly or combined into a ranking. They all point the same way: training and detection lower the odds, and an attacker only needs to succeed once.

Which defenses actually work?

Defenses fall into two groups: those that try to stop the model being fooled, and those that limit the damage when it is. Willison has long argued that a filter which catches "95% of attacks" would be a failing grade in web security. The second group is the one you can count on.

1. Break the lethal trifecta

The simplest structural fix is to remove a leg. An agent that reads untrusted web pages shouldn't also hold your private data and an open network connection. Common patterns:

• run research agents with no access to secrets;
• block outbound network traffic except to an allowlist;
• give an agent that handles your inbox no way to send data out without your approval.

2. Isolate untrusted content: dual LLM and CaMeL

Willison's dual LLM pattern (April 25, 2023) splits the work between two models:

• a privileged model that takes instructions from you and can use tools, but never sees untrusted text;
• a quarantined model that reads the untrusted content but has no tools.

Ordinary code passes the quarantined model's output along as opaque variables, so injected text never reaches the model that makes decisions.

Google DeepMind's CaMeL ("Defeating Prompt Injections by Design," Debenedetti et al., first posted March 24, 2025) goes further. It turns your request into a program before any untrusted data is read, so retrieved content can't change what the agent does. It then attaches capabilities to every value, which let security policies block data from flowing anywhere it isn't allowed when a tool is called. On the AgentDojo benchmark, the authors report that CaMeL solved 77% of tasks "with provable security," against 84% for an undefended system. That small drop in capability is the cost of a guarantee that doesn't depend on the model behaving.

3. Constrain what the model can say and do

OpenAI's agent-safety guidance for developers recommends:

• passing untrusted input through user messages, never developer messages;
• using structured outputs (fixed schemas and enums) between steps, which "eliminate freeform channels that attackers can exploit to smuggle instructions or data";
• extracting only specific, validated fields from external content.

OWASP's list of mitigations is similar: constrain model behavior, validate output formats, filter inputs and outputs, enforce least privilege, require human approval for high-risk actions, separate and label external content, and run adversarial tests.

4. Least privilege, sandboxes and approvals

Assume the model will sometimes be fooled, and make sure the damage stays small:

• give the agent narrowly scoped tokens and only the tools the task needs;
• run it in an OS sandbox or container with network egress limits;
• require confirmation before it sends, publishes, pays or deletes anything.

OpenAI's guidance says to "always enable tool approvals" for MCP tools. Our MCP explainer covers why every connected server widens what an agent can reach.

5. Train and monitor, as an extra layer

Anthropic and OpenAI both describe training models to ignore injected instructions, classifiers that scan untrusted content, and red-teaming. These measures lower the attack success rate. Both companies also describe the problem as unsolved, so treat these measures as an extra layer, not a security boundary.

What should you do?

If you use agents:

• don't give a browsing or email agent more access than the task needs;
• give specific instructions rather than "do whatever is needed," as OpenAI also advises;
• read the details before approving any send, purchase or publish step;
• be wary of "always allow."

If you build agents:

• map each agent against the lethal trifecta;
• treat every tool argument as attacker-controlled;
• keep untrusted text out of system and developer prompts;
• put boundaries outside the model: sandboxing, egress limits, scoped credentials and approvals.

If you're still working out what makes software "agentic" in the first place, start with what agentic really means.

What's confirmed, reported and uncertain

• Confirmed (primary sources):
  • OWASP's LLM01:2025 definition and mitigations
  • NIST CAISI's agent-hijacking results and the March 2026 competition findings
  • CaMeL's design and its reported AgentDojo numbers
  • Anthropic's and OpenAI's published defenses and their statements that the problem isn't solved
  • Microsoft's Semantic Kernel CVEs and fixes
• Reported by researchers: the GitHub MCP, Clinejection, Snowflake Cortex and Claude Code auto-mode attack chains, with vendor fixes where noted.
• Uncertain:
  • how well any defense holds against attackers who adapt to it; the CaMeL authors and NIST both stress that evaluations must keep evolving
  • whether model-level robustness will ever be strong enough to serve as a security boundary