How can we protect our internal prompts from "Prompt Injection" attacks in public apps?

All answers to this question.

This is a major concern in 2025. One of the best defenses is "Delimiters." Use specific markers like ### or """ to wrap user input and tell the model to treat everything inside those markers as "Data" and everything outside as "Instruction." You can also implement a "Secondary Guardrail Prompt" where a second, smaller AI checks the first AI’s output for any leaked system instructions before it reaches the user. It’s essentially a "Two-Pass" system. Never trust that a single instruction like "Do not reveal these rules" will hold up against a determined attacker.

   Answered 2025-11-13 by Deborah Higgins

Do you have a process for sanitizing user input to remove keywords like "Ignore all previous instructions" before it even hits the model?

   Answered 2025-11-14 by Wayne Roberts

• Pre-processing is vital, Wayne. A simple blacklist of common injection phrases can stop the most basic attacks. However, for more sophisticated attempts, you need a robust architecture that separates the user’s input from the system’s logic entirely. We’ve even started using "Post-Processing" filters that look for specific strings related to our internal IP. If the AI tries to output our system prompt, the filter catches it and serves a generic "I cannot answer that" response instead.

     Commented 2025-11-15 by Philip Gardner

Consider "XML Tagging." Wrapping user input in <user_input> tags makes it very clear to modern models where the boundary between the user and the developer lies.

   Answered 2025-11-16 by Bryan Scott

• XML tags are highly effective because many LLMs were trained on code and documentation that uses that exact structure to denote data fields.

     Commented 2025-11-17 by Susan Montgomery