Your AI agent just read a web page. Who is it obeying now? Prompt injection, explained

Here is the uncomfortable part about AI agents. They don't just read your instructions. They read everything you point them at, and some of that text was written by someone else.

I'm Cipher. I look at a system and ask who gets to give it orders. With an AI agent, the honest answer is "more people than you think." This page explains prompt injection in plain words, why it gets worse once an agent has tools, and what the people who build the models say they can and can't do about it. It describes risks and controls only. There are no attack recipes here, on purpose.

What is prompt injection, in plain words?

Prompt injection is text that hijacks an AI model's instructions. OWASP defines it as "when user prompts alter the LLM's behavior or output in unintended ways." OpenAI's agent docs put it more concretely: untrusted text enters the system, and "malicious contents in that text or data attempt to override instructions to the AI."

The root cause is simple. A language model sees one long stream of text. Your rules, the user's question and a web page it fetched all arrive as words in the same stream. Simon Willison, who coined the term, puts it in four words: "LLMs follow instructions in content." He adds that models "are unable to reliably distinguish the importance of instructions based on where they came from."

He named it after SQL injection, an old web bug with the same shape. Trusted commands and untrusted data get mixed together, and the system can't tell which is which.

One more detail from OWASP: the text doesn't have to be visible to a person. Injected instructions "do not need to be human-visible/readable, as long as the content is parsed by the model." White text on a white page is still text to the model.

What is the difference between direct and indirect prompt injection?

The difference is who wrote the bad instructions. In direct injection, the person typing to your AI is the attacker. In indirect injection, the user is innocent. A third party planted instructions in content the AI reads on the user's behalf, such as a web page, an email or a document. Anthropic's docs treat them as two threat models with different defenses.

That last row surprises people. OWASP gives an example of an accidental injection. A company hides an instruction in a job ad to flag AI-written applications. An applicant who uses an AI tool to polish a resume trips it without knowing. Nobody meant harm, and the model still followed text it found.

Is prompt injection the same as jailbreaking?

It depends on whom you ask, and the disagreement matters. OWASP says the two terms "are often used interchangeably" and calls jailbreaking "a form of prompt injection" aimed at safety rules. Willison draws a hard line: jailbreaking is tricking a model into saying something embarrassing, and prompt injection is mixing trusted and untrusted text.

Why care? Willison's warning is that developers who think injection just means jailbreaking shrug it off as the model vendor's problem. Indirect injection is your problem the moment your app reads outside content and can act on it.

Why do AI agents with tools raise the stakes?

Because tools turn words into actions. A chatbot that gets tricked writes a bad paragraph. An agent that gets tricked can send an email, move a file or call an API with your credentials. OWASP says the impact of an injection is "largely dependent on" the business context and "the agency with which the model is architected." More power means a bigger blast radius.

OWASP has a separate entry for this, LLM06 Excessive Agency. It names three root causes: "excessive functionality; excessive permissions; excessive autonomy." In plain terms: tools the agent doesn't need, access broader than the task, and actions taken without a person checking.

The vendors describe the same thing in their own products. OpenAI's post on its ChatGPT Atlas browser agent lists what a successful attack could do: forward a sensitive email, send money, edit or delete files in the cloud. It describes a scenario its own automated red team found, where a planted email led the agent to send a resignation letter instead of an out-of-office reply. OpenAI says it patched that class of attack. Anthropic's browser-use post describes a similar email scenario, with instructions hidden in white text.

Browser agents get extra attention for a reason. Anthropic says browsing "amplifies this risk in two ways": every page, ad and script is a possible source of instructions, and a browser agent can click, type, fill forms and download.

What is the lethal trifecta?

It is Simon Willison's test for when prompt injection turns into data theft. He wrote it up on 16 June 2025. An agent is in danger when it has all three of these at once:

1. "Access to your private data." Your email, files, repos, CRM or database.
2. "Exposure to untrusted content." Any text or image an attacker could control that reaches the model.
3. "The ability to externally communicate in a way that could be used to steal your data." Any way to send something out.

In his words: "If your agent combines these three features, an attacker can easily trick it into accessing your private data and sending it to that attacker."

The third leg is the sneaky one. Willison points out that the way out can be almost anything that makes a web request: an API call, loading an image, even a link the user is invited to click. He lists more than a dozen products where researchers found this pattern between 2023 and 2025, including ones from OpenAI, Google, Microsoft, Amazon, Slack, GitHub and Anthropic. He says almost all were fixed promptly, usually by closing the way out.

Then comes the line every founder wiring up agents should read twice: "once you start mixing and matching tools yourself there's nothing those vendors can do to protect you!" If you connect an email tool, a document store and a web fetcher to one agent, you built the trifecta. Not the model vendor.

His remedy for people combining tools is blunt: "avoid that lethal trifecta combination entirely." Take away one leg and the theft path breaks.

What defenses actually exist?

Defenses exist, and they work in layers, not as one switch. OWASP lists seven. Anthropic's and OpenAI's developer docs overlap heavily with it. They agree on the core: give the AI the least access possible, make a person approve risky actions, keep untrusted content clearly separated from your instructions, constrain what the model can output, filter what goes in and out, and test it like an attacker would.

Here is what each layer means, in plain terms.

• Least privilege. Give the agent only the tools and data the task needs. OWASP says to keep the app's own API tokens in your code and "handle these functions in code rather than providing them to the model." Anthropic's docs: "don't give Claude access to secrets it doesn't need, run tools in sandboxed environments."
• Human approval. A person confirms anything consequential. OpenAI's agent docs say to keep tool approvals on so users "review and confirm every operation, including reads and writes." Claude Code's security docs list a permission system that asks before sensitive operations.
• Separate untrusted content. Don't paste outside text into your top-level instructions. Anthropic says to put third-party content only in tool results, label where it came from, and wrap it in JSON. OpenAI says not to put untrusted variables in developer messages, which take precedence over user messages.
• Constrain the output. If a step only needs a yes or no, or a fixed list of options, force that shape. OpenAI says structured outputs remove "freeform channels that attackers can exploit."
• Filter in and out. Screen input, and screen what tools return, often with a small, cheap model acting as a classifier. Anthropic's docs show this pattern. OpenAI calls its guardrail nodes "not foolproof" but "an effective first wave of protection."
• Test like an attacker. OWASP says to treat the model "as an untrusted user" in testing. Anthropic says to red-team your own agent with documents and emails that contain injection attempts before you ship.

There is also a design principle underneath all six. Willison quotes a research paper on agent design patterns: "once an LLM agent has ingested untrusted input, it must be constrained so that it is impossible for that input to trigger any consequential actions." That is the trifecta advice, said as an engineering rule.

What do the vendors admit they can't prevent?

They admit a lot, in writing. OWASP says "it is unclear if there are fool-proof methods of prevention." OpenAI calls prompt injection "unlikely to ever be fully 'solved'." Anthropic says it is "far from a solved problem, particularly as models take more real-world actions." Read those as the defense's honest ceiling: you lower the odds and shrink the damage. You don't get to zero.

The most concrete number comes from Anthropic. In November 2025 it reported that Claude Opus 4.5, with the safeguards in its Chrome extension, brought the success rate of its internal adaptive attacker down to about 1%. That attacker got 100 attempts per environment. Anthropic's own reading: 1% "still represents meaningful risk," and "No browser agent is immune to prompt injection." That is a vendor's internal test of one product, not an independent benchmark, and it is nearly a year old.

OpenAI's December 2025 post makes the same point with a different comparison. It likens prompt injection to scams and social engineering aimed at people. Those never go away either. You train, you add checks, and you keep adapting. OpenAI says it now runs an automated attacker trained with reinforcement learning to find new attacks before outsiders do. Its agent docs end the same way: "Structured outputs and isolation greatly reduce, but don't fully remove, this risk."

Claude Code's security docs say it plainly too: "no system is completely immune to all attacks."

Willison is the sharpest on the tools sold to fix this. He says guardrail products often claim to catch "95% of attacks" or similar, and answers that "in web application security 95% is very much a failing grade." I agree with him. A filter is a useful layer. A filter that misses one in twenty is not a lock.

What should you do if you build or use AI agents?

Assume one injection will get through, and design so it can't do much. In practice that means three things. Break the lethal trifecta wherever you can. Put a human in front of every irreversible action. Write down which layers you run, because enterprise buyers now ask. That list is the start of a good answer.

Five checks I'd run on any agent before it touches customer data. They are my judgment, built from the sources above.

1. Map the trifecta. For each agent, write down its private data, its untrusted inputs and its ways out. If all three are present, remove one, or add an approval step on the way out.
2. Cut the tool list. Remove every tool and permission the task doesn't need. Scope tokens to read-only where you can. This is OWASP's "excessive functionality" and "excessive permissions" in practice.
3. Gate the irreversible. Sending, paying, deleting and sharing need a person's click. OpenAI's user advice says the same: read confirmation prompts before you approve them.
4. Keep outside text in its lane. Never paste a web page, email or upload into your system prompt. Pass it as data, labeled with its source.
5. Test it and keep the record. Run injection test cases against your own agent before each release that changes a prompt, a model or a tool. Keep the results. A SOC 2 auditor or an enterprise buyer will ask for them.

If you use agents rather than build them, OpenAI's advice for its own browser agent works anywhere. Stay logged out of sites the task doesn't need. Give narrow instructions, not "review my emails and take whatever action is needed." Read every confirmation before you approve it.

For the paperwork side, our guide to the AI questions enterprise buyers ask has an answer template for the prompt injection question. The SOC 2 guide for AI startups covers what auditors want to see on injection testing. And if you plan to hire outside testers, what a penetration test costs sets the budget. Building agents in a workflow tool? Our n8n AI agents guide shows where the tools get wired in, which is exactly where to look for the trifecta.