The retrieval boundary

A retrieval pipeline fetches a document, reduces it to text, and puts the text in front of a model. The failure is not in any of those steps. It is that the text usually arrives concatenated into the same field as the operator’s instructions, and at that point a sentence written by a stranger has the same standing as a sentence written by you.

Why filtering the text is the wrong lever

The intuitive fix is to detect and strip malicious instructions before they reach the model. Three properties make that a losing position.

The input set is unbounded and adversary-authored. The attacker rewrites until something passes, and they can iterate against your filter offline for as long as they like.

It is natural language, so the filter is a classifier with a false negative rate — and unlike a signature match, there is no representation you can normalise to that makes the problem exact.

And the carriers are open-ended. Hidden text, comments, script literals, accessibility attributes, invisible Unicode: each one is a different place to put the same sentence, and a new one appears whenever a new format enters the pipeline. You are guessing which representation reaches your model; they are enumerating.

A filter is worth having as depth. It is not worth relying on.

Keep retrieved text in the data position

The first structural fix is placement. Retrieved content should arrive in a clearly delimited region the system prompt describes as untrusted reference material, not concatenated into the instruction block. This does not make a model immune — models do follow instructions found in data regions — but it converts the problem from “indistinguishable” to “distinguishable and sometimes ignored,” and it makes the boundary something you can reason about and test.

Test it directly. Put a benign instruction in a document, retrieve it, and see whether the model does what the document said or what you said. If you have never run that test, you do not know which position your retrieved content occupies.

Constrain what the component can do

The second fix is the one that holds when the first fails. Assume the injection lands, assume the model complies, and ask what it can actually cause.

The action set is small, enumerable, and yours. A component that summarises retrieved documents needs to read documents and produce text. It does not need to make outbound HTTP requests, read local files, or call tools that move money. If it holds none of those permissions, a successful injection produces a wrong summary rather than an exfiltration — a quality problem instead of a security incident.

This is the asymmetry worth exploiting. You cannot win an argument against unbounded attacker-authored text. You can decline to grant an outbound request permission to the thing reading that text.

The two questions

Almost every real incident in this class comes down to one of these being unanswered:

• Is retrieved content separated from instructions in the prompt, and have you tested that it is?
• Was the component that acted on it permitted to make that action at all?

The second is usually the cheaper fix and the one that survives being wrong about the first.

npx hackmyagent secure checks both.

![OpenA2A research marker](https://agentpwn.com/api/canary/ingest/render/apwni_2145a026650759ee)