How is this different from ordinary prompt injection?

The delivery. Ordinary prompt injection arrives in the user's message; indirect injection arrives in something your system fetched. That changes who the attacker can be, since they need write access to your corpus rather than access to your product, and it changes who is harmed, since the person asking the question is not the person who planted the text.

Does the attacker need access to our systems?

Not necessarily. They need something they can write to end up in front of the model. A public page you crawl, a ticket anyone can file, or a document a customer can upload can each be enough on their own, and none of them requires access to anything of yours.

Can we detect a poisoned document before it is retrieved?

Partly. Scanning content at ingest catches instruction-shaped text and is worth doing, and it is the same losing game as input filtering, because the attacker chooses the phrasing. It works better as a signal than as a boundary.

Does this apply if the model only answers questions?

Yes, with a smaller blast radius. A read-only system can still be made to answer wrongly, to reveal what else is in its context, or to steer a person toward a decision. What it cannot do is take the action itself, which is why the deployment shape changes the assessment rather than just the score.

What is the single most useful control?

Least privilege on whatever the system can reach. It does not reduce how often an attempt succeeds, and it decides what a success is worth, which is the number that matters when one eventually does.

What is indirect prompt injection?

Indirect prompt injection is when the instructions reach the model through content your system pulls in, rather than through anything the user typed. The attacker need never talk to your system. They write a document, a page, a ticket or a record that your system will later read, and wait. It is the variant that matters most for retrieval, because retrieved text is attacker-writable in ways a prompt is not.

Why retrieval changes the threat model

A direct attack requires access to your interface and produces a result the attacker sees. An indirect one requires only that something they can write eventually gets retrieved, and the result lands in front of whoever asked the question. That is a different set of attackers and a different set of victims.

It also removes the assumption that quietly underpins a lot of chat security, which is that the person typing and the person harmed are the same person. Once content arrives from elsewhere, the user is not the threat. They are the target.

Where the content comes from

Anywhere your corpus does. Support tickets written by customers. Pages crawled from the open web. Documents uploaded by anyone with an account. Records synced from a system somebody else administers. Email. Calendar invitations. Filenames.

The useful exercise is to list every path by which text enters the corpus and mark which ones a stranger can write to. The paths that matter are the ones nobody filed under input: a filename, a calendar invitation, the body of a synced record.

What containment looks like

Treat retrieved content as data throughout, never as instructions, and enforce that in the code that assembles the prompt, not in a sentence asking the model to behave. Keep provenance on every chunk so that when an answer is wrong you can find the document that made it wrong and remove it.

Then bound the effect. If retrieval feeds a system that can act, the interesting question is whether a poisoned document can reach an action, and what stands between the two. If the answer is nothing, the score on everything else is not the point.

Common questions

How is this different from ordinary prompt injection?: The delivery. Ordinary prompt injection arrives in the user's message; indirect injection arrives in something your system fetched. That changes who the attacker can be, since they need write access to your corpus rather than access to your product, and it changes who is harmed, since the person asking the question is not the person who planted the text.
Does the attacker need access to our systems?: Not necessarily. They need something they can write to end up in front of the model. A public page you crawl, a ticket anyone can file, or a document a customer can upload can each be enough on their own, and none of them requires access to anything of yours.
Can we detect a poisoned document before it is retrieved?: Partly. Scanning content at ingest catches instruction-shaped text and is worth doing, and it is the same losing game as input filtering, because the attacker chooses the phrasing. It works better as a signal than as a boundary.
Does this apply if the model only answers questions?: Yes, with a smaller blast radius. A read-only system can still be made to answer wrongly, to reveal what else is in its context, or to steer a person toward a decision. What it cannot do is take the action itself, which is why the deployment shape changes the assessment rather than just the score.
What is the single most useful control?: Least privilege on whatever the system can reach. It does not reduce how often an attempt succeeds, and it decides what a success is worth, which is the number that matters when one eventually does.

Find out where you stand

The assessment on this site asks up to 21 questions about what your system can reach, and returns a score, a verdict and, where a control is short, the one thing to fix first. It takes about ten minutes, and questions your deployment shape has no surface for are dropped rather than scored against you.

It is a self-assessment of design and evidence, not a penetration test, not an audit of a running system, and not a certification.

Run the assessment