A document can contain instructions without having authority
Prompt injection becomes dangerous when a model can turn untrusted text into a tool call or when a hidden instruction changes the task before the user notices.
Keep the trust boundaries visible
Separate user intent, approved system policy, retrieved evidence, tool schemas, and tool results. Label untrusted content in the application context and avoid concatenating raw instructions into a single undifferentiated prompt.
OWASP treats prompt injection as a broad risk because the attack can be direct or indirect. A document can be the carrier even when the user did not ask for anything unsafe.
Put authorization in deterministic code
The model may propose a search or action. Code must check the caller, target, scope, data sensitivity, and required approval. Validate identifiers and allowed fields before execution. Use allowlisted tools with narrow inputs instead of a general shell or database access.
A tool result is also untrusted input. Do not assume that a CRM field or web response is safe merely because it came from an integrated system.
Make high-impact actions reviewable
For sending messages, changing records, granting access, exporting data, or triggering money movement, show the target, proposed change, evidence, and side effects. Ask for explicit approval at the point of action.
The assistant should be able to stop and explain what it could not verify. A visible refusal is safer than a fluent guess.
Test attacks and ordinary work together
Build a test set with hidden instructions in a policy PDF, a customer email, a web page, a task comment, and a tool response. Pair each attack with a legitimate version of the same request. Measure unauthorized tool calls, data disclosure, false refusals, and recovery quality.
NIST's risk-management framing supports continuous monitoring and improvement. Prompt-injection defense is a system property, not a model-vendor badge.
Threat-model the complete path
List every place instructions can enter: user messages, documents, email bodies, web pages, ticket comments, metadata, tool results, and model-generated text. Mark which inputs are evidence, which are policy, and which can authorize an action. Treat any retrieved instruction as untrusted unless a separate application rule grants that authority.
Test direct attacks and indirect attacks with ordinary requests beside them. A useful test set includes a malicious PDF, a customer email, a copied web page, and a tool result that asks for data export.
Constrain tools and validate outputs
Give each tool the smallest input and capability it needs. Check the caller, target, fields, scope, and approval in deterministic code. Validate the proposed output against a schema before execution, and show high-impact changes for approval. Do not let a model write arbitrary SQL, shell commands, or messages.
Log blocked calls, source IDs, and the reason for refusal without retaining more sensitive content than the security policy allows. Review false refusals as well as successful blocks so the defense does not make ordinary work unusable.
The LeanOrchestr Business Brain connects approved company sources, preserves access boundaries, and turns useful context into a maintained operating layer. Start with one question, one accountable owner, and an evaluation set you can rerun.
Sources and verification
Primary product, architecture, risk, and security sources checked on 10 September 2026. Product behavior can change, so verify current plan and admin documentation before implementation.