On this page
Protect consequences, not just wording
An LLM API shield should consider what happens when a model misunderstands untrusted content. A document may contain useful information and instruction-like text. Labels and prompt structure can help communicate the distinction, but the application still needs enforceable limits on what can be accessed or executed.
The prompt injection defense guide develops this boundary for a document research assistant. It treats filters as one supporting layer, not a complete guarantee. The central review question is whether an incorrect model interpretation can cause an unauthorized disclosure or action.
Review every channel into context
Include user messages, retrieved documents, file metadata, tool errors, previous responses, conversation summaries, and persistent memory. Context can become more trusted accidentally as it moves between components. A summary of an untrusted source should not become a privileged instruction merely because a model produced it.
Attach provenance to source fragments and review prompt-assembly code. Keep controlled application instructions in a separate configuration path. Evaluate indirect sources as well as visible chat messages. When a failure appears, identify which transition allowed content to gain authority rather than only adding the observed wording to a blocklist.
Authorize retrieval before exposing data
Use current user and tenant context to constrain retrieval before source text reaches the model. Asking the model to ignore unauthorized documents is not equivalent to keeping them out of context. Include source identifiers, titles, caches, and stored answers in the access review.
Consider what happens when access is revoked after indexing or generation. Recheck relevant permissions when serving results and citations. The RAG and agent security playbook traces the data path separately from the action path so that correct retrieval does not conceal an overprivileged execution tool.
Validate tool proposals and exact approvals
Treat generated tool calls as proposals. The executor should check actor, action, resource, argument shape, budget, and approval state using trusted context. A valid JSON object does not make the proposed operation authorized.
For actions requiring approval, present the normalized operation that will actually execute. Bind approval to the exact target and arguments, and reevaluate relevant state when execution occurs. Keep read-only and write-capable tools separate, and add a new capability only when the product needs it. Narrow tools are easier to reason about than unrestricted command or destination interfaces.
Evaluate the entire interaction
Test multiple turns, later retrieval, reused memory, tool timeouts, altered action arguments, and cancellation. Measure unauthorized outcomes and legitimate-task completion separately from the model’s wording. Keep test configuration and expected behavior with the fixtures.
Plan a capability-level containment path: disable a risky connector, restrict one tool, or remove a memory feature without automatically broadening some other access path. Use the AI shield API architecture to connect these controls to task budgets, output contracts, observability, and the decisions needed during dependency failures.
