Treat user input, retrieved documents, emails, and tool results according to their trust level. Prompts help define behavior; application controls enforce access and actions.
1. Understand direct and indirect instructions
A direct injection is an attempt in the user’s input to redirect the assistant beyond its intended task. An indirect injection arrives through material the assistant reads, such as a document, web page, email, or tool result. The text may ask the assistant to reveal information, ignore rules, or use a tool for a different purpose.
For example, a retrieved support article could contain a sentence asking the assistant to export a customer list. It is still document content, not authorization from the signed-in user. The risk depends on the tools and data the application exposes, which is why this is an architecture question as well as a prompting problem.
2. Keep identity and authorization in trusted code
Resolve the user’s identity through the application’s normal authentication process. Determine which records, documents, and operations that identity may access before returning information or executing a proposed action. Do not let model-generated fields choose the authenticated tenant or override account permissions.
Apply access filtering in retrieval and authorization in each tool implementation. A perfect semantic match from another customer’s collection remains unauthorized. If the user cannot perform an action through the application, asking an assistant should not create a new permission to perform it.
3. Expose a small and understandable tool surface
Prefer a specific lookup or business operation over a broad “run any request” capability. Validate arguments, enforce allowed destinations, and return only the fields required for the task. Keep model credentials and other secrets in application configuration, outside prompts and ordinary tool responses.
Separate drafting from sending and reading from writing. When a consequential action needs review, show the actual proposed operation and content. Tie that review to the operation being executed, rather than treating an earlier approval as permission for a materially different request.
On small screens, scroll the table sideways to see every column.
| Input source | Attempted behavior | Application boundary |
|---|---|---|
| Retrieved document | Request unrelated private data | Permission-aware retrieval and scoped tools |
| Customer message | Change another account’s record | Trusted identity and record authorization |
| Tool result | Send information to a new destination | Validated actions and destination rules |
4. Limit the consequences of untrusted content
Keep source material distinguishable from task instructions, and make the intended use explicit. Limit input size, tool turns, output size, and runtime as appropriate for the feature. These measures make behavior easier to control and observe; they do not prove that a model will never follow a misleading instruction.
Review logs and traces for sensitive content. Storing every prompt, document, and response can create another place where private information is exposed. Decide what is needed to investigate problems, who can see it, and how long it is retained.
5. Exercise the boundaries with realistic cases
Build test documents and messages that contain conflicting requests, attempts to access another tenant, and instructions to use an unapproved destination. Confirm that the application denies unauthorized retrieval and actions even when the model proposes them.
Inspect both the model output and the actual side effects. A refusal message is not sufficient if a tool has already executed. Repeat tests after changes to models, prompts, retrieval, tool contracts, and access rules. The goal is layered protection with visible failures and recovery, not a claim that one special prompt makes the application immune.
6. Frequently asked questions
Can we fix injection with a system prompt?
Instructions help establish intended behavior, but they are not an authorization boundary. Restrict data and operations in trusted application code and test what actually executes.
Does read-only access remove the risk?
It reduces some action risks, but unauthorized reading or disclosure can still matter. Read-only retrieval must still respect document, record, and tenant permissions.
Should we block every unusual user request?
Define the supported task and application permissions. Handle unexpected requests through clarification or handover, and test the specific data and actions the product can access.
7. Related articles and next steps
Bring representative inputs, expected outputs, and the systems involved. Discuss your requirements with OdooMatrix.