Input filtering and injection defence

What it does

It reduces the chance that text from an untrusted source is obeyed. It combines detection, which looks for content that reads as an instruction to the model, with separation, which tells the model which parts of its context are data. Security engineering owns it; it runs on every input and every item of retrieved content.

How to implement it

• Classify inputs and retrieved content for injection patterns before they reach the model.
• Delimit untrusted content clearly and instruct the model to treat it as data.
• Strip hidden text, markup and unusual encodings from documents.
• Restrict or suspend tool use while the model is handling untrusted content.
• Log detections and feed them to monitoring.
• Update detection as new techniques appear.

Evidence it operates

Design: an architecture record showing every route by which content reaches the model and the screening on each. Operation: detection logs; results of tests using current injection techniques, with the pass rate; evidence that retrieved and tool content pass through the same screening as user input.

Where it fits

Runs at the system's boundary on every request. It is a primary control for prompt injection and agent goal hijack, and works with output validation and approval gates, which limit the damage when it fails.

Limits

No filter is reliable against a determined attacker; new phrasings pass. It lowers the rate of success and must never be the only control between untrusted content and a consequential action. Its detection rate should be measured and reported, so that reliance on it rests on evidence.