Distinguish requests from injected instructions
A malicious user prompt directly requests something unsafe or unauthorised. Prompt injection introduces instructions through task material, such as a retrieved page, document, email or tool response. The sources are different even where both attempt to redirect the model.
A document being summarised might tell the model to ignore its task and send information elsewhere. The document is data, not an authorised instruction source. A useful response based on that document does not justify accepting its directions about tool use, permissions or disclosure.
Treat external material as untrusted input
Identify where content enters outside the trusted instruction path, including search, repositories and tool results. A source can help answer a question without being trusted to direct behaviour. Consider what happens when one retrieved document conflicts with the application's operating rules.
Separate instructions and external content in application design and show provenance where practical. These help but model behaviour is imperfect. Delimiters and 'ignore malicious instructions' wording cannot guarantee prevention. Keep sensitive information and unnecessary tools out of the workflow rather than relying on the model not to use them.
Enforce permissions outside the model
Restrict data and tools to what the workflow needs. Validate proposed actions against user permissions and application rules independently of generated output. Do not place secrets in prompts assuming instructions will hide them. A model response requesting a privileged operation is not proof of authorisation.
Use scoped credentials, controlled destinations and approval for consequential actions. Avoid arbitrary commands or unrestricted network targets where unnecessary. Server-side authorisation and isolation between users remain necessary. Technical design should prevent a forbidden action even if the model produces a convincing argument for it.
Test realistic failure paths
Use hostile instructions in the documents and responses the application actually processes. Check attempted disclosure and unauthorised actions, not only inappropriate wording. Test with authorisation and non-sensitive information. A test that never exercises a connector cannot establish the connector is safely constrained.
Route unexpected behaviour to the technical owner. Stop sensitive work and report suspected injection rather than experiment with live credentials. Review logs proportionately and revisit tests after model, retrieval, permission or tool changes. Compass is available now and is not a security enforcement layer; the guidance here stands on its own.