Why instructions inside content are different
An assistant may read a document, ticket or web page while helping a user. That content can contain text that looks like an instruction to run a command, reveal information or change the task. The application must distinguish information to analyze from authority to act. A sentence inside a retrieved document cannot grant a new system permission.
Prompt injection is therefore an application-boundary problem as well as a model-behavior problem. OWASP recommends layered defenses and keeping authorization and least-privilege controls outside the model. No prompt sentence or content filter should be represented as a universal guarantee against every attack.
Setup: inventory capabilities and trust sources
List each tool, its read or write effect, permitted resources and required authorization. Identify which instructions come from the authenticated user or trusted application policy and which arrive inside untrusted content. Keep credentials in the tool service, not in prompts or model-visible documents.
Give tools narrow structured parameters and validate them at execution time. A model's proposed resource identifier must still be checked against the user's actual permissions. Separate low-impact reads from actions that send data, change infrastructure or create external commitments. Define review requirements according to the business risk.
Illustrative incident: a support document requests an export
An illustrative assistant retrieves a support document containing an instruction to export unrelated customer records. The document is relevant to a troubleshooting task but has no authority to expand access. This is a defensive teaching example, not a report about a real attack or customer breach.
Use synthetic documents and harmless test tools to reproduce the boundary. Verify that the application rejects the proposed export even if the model repeats the document's instruction confidently. Avoid testing with live credentials or production data when a controlled fixture can establish the same security property.
Troubleshooting: inspect the authorization path
| Observation | Evidence | Investigation |
|---|---|---|
| Retrieved text changes the tool destination | Provenance and proposed parameters | Is content being treated as an authority source? |
| A denied action succeeds through another tool | Shared permission checks and capabilities | Are alternate paths enforcing the same policy? |
| Sensitive text appears in a prompt or log | Data-flow inventory | Was unnecessary information exposed to the model? |
| One blocked example is called secure | Evaluation variety and repeated attempts | Is the claim larger than the evidence? |
Do not rely on the model to police its own permissions through a textual reminder. The tool gateway must independently reject unauthorized resources and effects.
Corrective action through capability boundaries
Constrain tools to the user's authorized task and resources. Require explicit approval for actions whose business process calls for it, and bind approval to the concrete destination and effect. Treat retrieved instructions as content to summarize or flag, never as permission to bypass those checks.
Use output validation, provenance labeling, network restrictions and monitoring as additional layers. Keep rollback or compensating actions available where possible. For deployments and email, provide a preview that makes the proposed effect reviewable before execution. Do not automatically send campaigns merely because a generated plan recommends them.
Verification, security objective and SOP
Test hostile instructions in documents, tool results and user-supplied fields using an approved adversarial fixture set. Verify rejection at the execution boundary, not just a polite refusal in the assistant's text. Record the tested scope and residual uncertainty.
An internal security objective can measure correct authorization decisions across defined tool scenarios. It is separate from model helpfulness and any customer SLA. The SOP should identify capability ownership, approval records, incident containment, secret rotation and review of attempted boundary crossings. Avoid advertising prompt-injection immunity from a small demonstration.
See AI and intelligent automation and cloud security.
Technical reference
OWASP LLM prompt injection prevention, reviewed 19 October 2026. Follow documentation matching the installed product version.