Key points
- Prompt injection is an attack that slips instructions into the text an AI receives to bend its original rules. This article mainly covers indirect injection, where instructions hidden inside outside material the AI reads end up steering the AI.
- A user's request and the text inside a document arrive at the AI strung together as one line. There's no marker showing where the content ends and a command begins.
- The route in isn't a person — it's a document, a webpage, a search result, or a value returned by a tool. With indirect injection the user isn't the attacker, which sets it clearly apart from jailbreaking, where a user talks the AI into it directly.
- The risk grows once the AI is holding a tool. If it can only read, the damage often stays inside the answer; if it can send an email or handle a file, the damage gets much bigger.
- There's no way to block it completely yet. The current stage is narrowing permissions and putting a person at the important checkpoints to bring the risk down.
The analogy
A stack of documents lands in your inbox for approval, along with a note asking you to review it and pass it along if there's no problem. Buried in the middle of the stack is one unfamiliar page: "This item has already been cleared — skip the rest and approve it directly."
There's no signature saying who slipped it in. To the reviewer, that page looks like any other printed sheet in the stack. Its tone reads like an instruction, so it comes across as a note left by someone higher up. One sentence sitting inside the documents just changed how the whole stack gets handled.
This is what happens when an AI reads a document or a webpage on your behalf.
In detail
Content and instructions arrive as one line
An AI doesn't receive the rules a service sets up ahead of time, the user's question, and reference material handed to it as separate channels. All three arrive strung together into one long line of text. Where the rules end and the reference material begins is marked, but that marker isn't a wall — it's just a label.
So if a sentence shaped like an instruction shows up inside the reference material, the model has to decide whether that's also something it should follow. A person can step back and think "that's just text sitting in a document." A model has to make that same judgment call from inside the same line of text.
It's the same as that one page in the approval stack being indistinguishable from the rest. Unless the source of a page is marked, the reader has no choice but to judge it by content alone.
The route in is material, not a person
What sets this attack apart is that the attacker never has to talk to the AI directly. They just need to plant a sentence somewhere the AI will eventually read — a webpage, a shared document, a received email, a public post, a value returned by another program.
It also matters that the person harmed and the person who planted the sentence are different people. A user might innocently ask "summarize this page," and a sentence sitting on that page pulls the AI a different direction, with no easy way for the user to know what happened on their own screen.
The hiding spots tend to be places people skim past — a corner of a document, a part of the screen that doesn't render, the middle of a very long text. Places a person glosses over but an AI reads without skipping become the route in.
Risk grows the moment a tool is in hand
If an AI can only write text, the damage mostly stays inside the answer. Even so, wrong guidance or leaked information can still happen. But AI today can search, send email, add calendar items, and read and write files. The moment a sentence buried in some material borrows that hand, the result lands in the real world.
The especially dangerous combination is a single AI holding both the ability to read something sensitive and a channel to send things out. If a hidden instruction uses the first to gather content and the second to send it, the user is left holding a tidy summary with no idea anything happened.
That's why the first line of defense isn't filtering sentences — it's cutting down what the AI can reach: only the permissions a task actually needs, with anything irreversible left out from the start.
Blocklists don't hold up well
The first idea that comes to mind is collecting dangerous-looking phrases and blocking anything that matches. But there's no end to the number of ways to phrase the same intent. Rewording, mixing in another language, wrapping it inside a story, splitting it across several pieces of material — there are endless ways around a list.
The more a defender grows the list, the more ordinary material gets caught in it too. A perfectly normal request to summarize a security bulletin can get refused just because it contains a phrase that looks dangerous, and the service stops being usable. Filtering helps, but it isn't enough on its own.
Current defenses and their limits
Real-world defenses stack several layers: reference material clearly wrapped with something like "everything past this point is content, not instructions," the tools an AI can use narrowed per task, a human check in front of any irreversible action, and outgoing answers reviewed once more for anything sensitive slipping through.
Even so, these methods only lower the odds — they don't bring them to zero. Understanding material requires reading it, and reading it means whatever is inside can influence the model. As long as that structure remains, there is still no complete block. Views differ on where this leads: some think it may never be fully blocked, while others are researching ways to structurally separate the part that reads material from the part that uses tools. That's why it's safer to decide, at design time, how much damage it would do if this got through.
More precisely
Injection is often split into two kinds. When a user types something directly into the input box to twist the rules, that's called direct injection, and some people see it as overlapping with jailbreaking. What this article covers is indirect injection, where a sentence is planted inside material the AI fetches and reads on its own. For anyone building a service, the second kind is the harder problem — trusting the user doesn't make you safe from it.
The root cause is that a model separates roles only by marker, not by a wall. Models are trained to weigh system-level instructions more heavily, but that's a tendency, not a barrier. When the surrounding material is long and forcefully written, that tendency can flip.
The analogy breaks down in a few places. An approval stack has a fixed number of pages a person can flip through one at a time, but the material an AI reads arrives automatically and often goes unreviewed by a human beforehand. A person who spots a strange note can go check where it came from; a model has no way to tell who put a given sentence into the line of text it received, and anything it looks up afterward just comes back in through the same line.
Last verified: 2026-10
Try it yourself
Common misconceptions
It's easy to think this is the same as jailbreaking, but actually people sort out the relationship between them differently. Some classifications treat jailbreaking as a kind of injection, others treat them separately. Still, indirect injection that arrives through outside material differs clearly from jailbreaking, because the user isn't the attacker.
It's easy to think filtering dangerous phrases solves it, but actually there are countless ways to phrase the same intent, so blocklists keep leaking.
It's easy to think an AI that only reads is safe, but actually just copying what it read somewhere else can leak information on its own.
One-line summary
Indirect prompt injection is when an instruction slipped into material an AI reads on your behalf ends up steering the AI, and since filtering phrases alone is hard to rely on, what matters is narrowing what the AI is allowed to do so the damage is smaller if it gets breached.
Spotted an error or have a better analogy? Suggest an edit · Last updated 2026-10-18