Knowledge & actions · Explore this field ↗ · Security · 3 min read
Prompt injection at retrieval and tool boundaries
Treat retrieved text, attachments, web pages, and tool output as untrusted content before they can steer an action.
See the source / a related case
The dangerous boundary is meaning, not syntax
A retrieval pipeline commonly turns a user question and a set of documents into one model context. That makes a document capable of carrying both facts and hostile imperative text. The model may not reliably honor the distinction even when the application labels a block as untrusted. OWASP describes indirect prompt injection through external pages, documents and retrieval systems, and tool manipulation as an agent-specific risk. Design as though any page, attachment, email body, support ticket, OCR result, or tool response can attempt to redirect the model. This includes content generated by trusted colleagues: accidental instructions can be operationally harmful even without an attacker.
Give data a narrow job
Retrieval should supply evidence for an answer, not authority to change system policy. Keep document content in a clearly delimited data field; capture source identity, lifecycle state, access scope and retrieval reason beside it. Do not dynamically promote text into system instructions, tool descriptions, routing rules, credentials, URLs to fetch, or approval criteria. A useful control is to ask a constrained component to extract typed facts—policy identifier, effective date, permitted option—from content, then validate those fields against an expected schema. The acting component receives the validated result and the original user goal, not a free-form command copied from an untrusted page.
Validate intent at the action boundary
Every write-capable tool call needs a policy check outside the model. Compare proposed account, object, fields, destination and consequence against authenticated user context and the stated task. Reject extra recipients, external URLs, export fields, scope expansion and irreversible actions unless an explicit workflow permits them. A human confirmation is most useful when it presents the exact structured change, not a vague question such as ‘continue?’ The confirmation cannot rescue a design that has already sent confidential data to an untrusted tool; authorization and minimization must happen before invocation.
Quarantine high-risk content paths
Some work requires reading material that should never reach a privileged actor directly, such as public web pages, uploaded files, repository issues or vendor-generated text. Put that processing in a lower-privilege stage with no secrets and no action tools. Pass forward only bounded, attributable outputs: a classification, selected factual fields, a safety flag, or a request for human review. Log the source URI and transformation version so an analyst can reproduce the path. This is defense in depth, not proof that a classifier will catch every injection. Deterministic authorization, allowlists, output validation and rate limits still protect the action surface.
Evaluate the full path
Build tests where a benign user request retrieves malicious instructions that request a secret, a different user’s data, an outbound request, a tool call, or a policy override. Include instructions hidden in tables, markdown links, document metadata, OCR, and tool error messages. The expected result is not merely a safe sentence. Confirm that no disallowed retrieval, network call, permission change or write occurred. NIST’s Generative AI Profile frames risks across the lifecycle; use that wider lens to assign owners for ingestion, tool policy, incident response and regression tests.
Bound the claim
No prompt wording, detector, or separate model makes prompt injection solved. The practical objective is reducing what hostile content can reach and limiting what the system can do if it reaches the model. Reassess the boundary when adding a connector, widening document ingestion, changing model behavior, or exposing a new tool. Security review is required for an application-specific threat model.
Primary reading
Sources and limits
These links support the architecture, policy, or product behavior discussed above. Vendor documentation describes vendor features; it is not independent proof of performance. Current details should be rechecked before a production decision.