Document-grounded agents can search thousands of pages and then take action in calendars, CRMs, support queues or financial systems. The same workflow gives an attacker an attractive route: place instructions inside material that the agent will read as evidence. Production defenses must therefore be designed across retrieval, identity, tool execution and incident handling. This guide turns established security guidance into a practical implementation checklist, without treating a stronger prompt as a substitute for access control.

A retrieved document is data, not an operator

AI agents often read pages, emails, tickets and indexed documents before deciding whether to answer a question or call another tool. That makes retrieval useful, but it creates a second instruction channel that the developer did not control. A hostile page can present itself as an administrator message, insist that the model ignore earlier directions or provide forged tool-call arguments. The attacker does not need to compromise the model provider. Placing instructions where the agent expects ordinary evidence may be enough to confuse the boundary between information and authority.

OWASP’s LLM security guidance treats prompt injection as a leading application risk and explains that retrieval augmentation alone does not remove the problem. The critical failure is not merely that an answer sounds wrong. It is that lower-trust material changes the system’s objective, permissions or next action. A support bot that repeats malicious text has a quality failure; an agent that uses the text to disclose account data or trigger a payment has crossed a security boundary. Engineering controls should therefore focus on the actions available after retrieval.

Map every place where untrusted text enters the workflow

Begin with a data-flow diagram rather than a larger system prompt. Identify the original user request, retrieved search snippets, full documents, third-party API replies, OCR or transcription output, tool descriptions and cached memories. Give each source a trust label and record which component is allowed to interpret it. A document can be authoritative evidence about its own subject without becoming authoritative instructions for the assistant. The same distinction applies to a spreadsheet cell containing a command-like string or a web page designed to look like a developer note.

Instrument retrieval events with the document identifier, content version, fetch time and the tool called after the content was read. Avoid logging full confidential passages by default; hashed references and carefully redacted excerpts may be sufficient for incident investigation. Include cases where the document changes after indexing and where a trusted search result links to a lower-trust page. If engineers cannot reconstruct what evidence preceded an external action, they cannot confidently separate a model error from injected instructions.

Enforce permissions outside the language model

The central control is to give the model less authority than the surrounding service can exercise. A retrieval agent that needs to summarize invoices should not automatically receive payment permissions. Use narrow tool scopes, per-tenant access checks, short-lived credentials and explicit approval for high-impact operations. Model-generated arguments should be validated against the authenticated user’s permissions and typed schemas in the application backend. Never treat text that happened to appear inside a retrieved document as user consent.

Tool boundaries should also resist confused-deputy mistakes. A document might contain another customer’s account number, but the backend still needs to verify that the current user can access that account. For outbound requests, restrict allowed destinations and sanitize URL parameters to prevent an agent from turning arbitrary text into an exfiltration channel. OAuth security guidance such as IETF RFC 9700 helps frame credential protection, but integrating OAuth does not by itself make the model’s decisions trustworthy.

Treat retrieved instructions as suspicious evidence to evaluate

Prompt-level defenses still have a role, provided they are not the only layer. Instructions to the model can clearly describe retrieved content as untrusted and explain that it must not override system policy or authorize a tool call. Retrieval pipelines can annotate document provenance, isolate quoted text and reject known malicious control sequences. These reduce accidental compliance and make the distinction easier for the model, but attackers can hide their instructions in long documents, translated text or seemingly benign formatting.

During evaluation, build a corpus with realistic business material and adversarial variants. Include policy documents that falsely demand credential disclosure, support messages that invent escalation rules, and emails that request an external transfer. Record whether the model identified the information needed for the user, ignored the injected objective and passed safe arguments to the tool. Test multiple languages and document formats, not only a handful of English strings copied from public prompt-injection demos. Measure the dangerous action, not the model’s declared confidence.

Separate incident detection from incident response

Runtime signals might include an unexpected tool selection, a request for a new domain, a sudden change from answering to taking action or a document asking to disable safeguards. Use these signals to pause high-risk execution, not to accuse every unusual question of being malicious. Operations teams need a containment playbook: disable the affected integration, revoke temporary tokens when appropriate, isolate poisoned index entries, preserve limited audit evidence and notify the appropriate owner. The exact response depends on whether any real unauthorized action occurred.

After an incident, treat the compromised document and the application permission model as separate remediation targets. Removing the text may stop one example, but an agent with unrestricted credentials remains vulnerable to future malicious sources. Conversely, limiting tools may prevent loss even when the model repeats hostile instructions. A good postmortem records entry point, chain of trust violations, affected data or actions, detection lag and the specific regression test added before the workflow is released again.

A release gate for production retrieval agents

Before launch, ask six questions: Can every retrieved item be tied to a source and version? Does the backend recheck user authorization for every sensitive operation? Are destructive actions separately approved? Can a retrieved page redirect requests to arbitrary domains? Can the team reproduce a suspicious tool action without exposing entire private conversations? And has the adversarial test suite been rerun against the exact deployed configuration? A failed answer should block the relevant capability rather than be explained away as an edge case.

NIST’s Generative AI Risk Management Profile is useful as an organizational checklist for documenting risks, evaluations and controls across the system lifecycle. Pair that governance discipline with concrete OWASP threat scenarios and IETF OAuth guidance for credential use. These sources do not promise that a single instruction or classifier can eliminate prompt injection. The realistic goal is layered containment: assume some untrusted text will reach the model, make unsafe effects hard to execute, and keep enough evidence to improve the next release.

References: OWASP LLM Application Security Top 10; IETF RFC 9700, OAuth 2.0 Security Best Current Practice; NIST Generative AI Risk Management Profile.