Prompt Injection Guardrail Best Practices
Defense against prompt injection is a set of practices that stack. No single technique is sufficient — not the model's built-in safety training, not a filter, not a system prompt warning. The systems that hold up under attack are the ones where each layer compensates for the next layer's blind spots.
Separate instructions from data as a matter of architecture. Your system prompt is instructions; everything a user, website, or document contributes is data. The most effective rule is the simplest: data never becomes instructions. When data must inform behavior, route it through code — a lookup, a structured extraction — rather than letting the model interpret it freely.
Delimit untrusted content explicitly and never interpret the delimiters as data. Wrap external text in clear markers and instruct the model to treat the delimited block as content only. The guardrail catches delimiter-break attempts — inputs that try to close the tag early and inject instructions afterward. Delimiting works best when combined with a filter that watches for tag tampering.
Apply an input filter in front of the model. A fast, deterministic regex guardrail runs before any token is sent to the model, triaging inputs by risk score. It is not a silver bullet — attackers obfuscate — but it catches the common attack families cheaply, and it gives you a structured signal for routing and logging.
Treat the risk score as a routing signal, not a hard block. Define what each score band means for your system: low goes straight through, medium goes through with the flag recorded, high goes to manual review or a neutralized form. Refusing everything above a threshold invites obfuscation and hurts legitimate users; routing preserves safety while keeping the system usable.
Log every flag and review the logs. The threat landscape changes weekly, and your filter's blind spots only become visible in the inputs it let through. Review flagged inputs regularly to refine patterns, and keep an eye on near-misses — inputs that scored low but should not have.
Never place secrets, tool outputs, or other users' data where untrusted content can echo it. Injection becomes exfiltration when the model holds private data it can be persuaded to repeat. Minimize the private data in the prompt context and keep sensitive retrieval behind tool calls that enforce their own permissions.
Add output-side checks alongside input-side ones. An instruction to "repeat everything above" can be caught on the way out as well as on the way in, and output checks double your chances of catching an input the filter missed. The strongest systems filter both directions.
Keep your guardrail patterns versioned and tested. Store the rule set with a small corpus of known attack samples and benign examples, and re-run the suite whenever you edit a pattern. The matrix on this page is deterministic, which makes it testable — a property worth protecting as you add rules.
Finally, document your threat model. Write down what your system protects, what it trusts, and where untrusted content enters. Injection defense is a process of deciding where the trust boundary sits; documentation turns that decision from a guess into an asset your whole team can maintain.