AI Prompt Injection in Documents: Protect Your Assistant

Artificial Intelligence · Document assistants · Implementation guide

To reduce prompt injection risk in a document assistant, treat PDFs, retrieved pages, emails, and tool results as untrusted evidence. Keep authorization in application code, give the assistant only necessary tools, and review consequential actions before execution. A stronger prompt helps, but it is only one layer.

This guide is for teams building an assistant that reads documents and may connect to business systems. The practical question is what happens when a document tells the assistant to change its task. The goal is to preserve the user’s request and limit the consequences if the model follows an unwanted instruction.

Documentation checked on 25 October 2026. The examples below are hypothetical design and evaluation cases, not reported incidents or results from hands-on testing.

Recognize instructions inside document evidence

Prompt injection attempts to redirect a model’s behavior through the input it processes. An indirect injection reaches the assistant through external material, such as a file or webpage. OWASP’s prompt injection guidance explains that retrieved content, including multimodal material, can carry these instructions. RAG and fine-tuning do not fully resolve the risk.

A document can legitimately contain instructions for people. A purchasing policy might tell employees to obtain approval. The suspicious shift occurs when the material tries to control the assistant itself, redefine its authority, or redirect its output away from the user’s task.

Ordinary factual mistakes need attention too. An assistant can misread a table without any hostile instruction. Keep source-quality failures and instruction-following failures distinct when diagnosing a bad answer.

Separate retrieved content from application instructions

Keep the application’s purpose, constraints, and user request separate from the passages being examined. Preserve useful provenance: source identifier, document title, extraction method, and version. A passage saying that it is a system message should remain a passage.

Anthropic’s implementation guidance recommends delivering third-party material in Claude tool-result blocks, identifying its source, and explicitly stating that retrieved content cannot override the original request. It also recommends JSON encoding rather than freely concatenating untrusted strings. Use the documented message structure for your chosen platform; Claude’s exact block format is vendor-specific.

For a hypothetical invoice assistant, separate the task “extract supplier and due date” from the invoice text. Put the invoice’s claimed supplier in a data field, not into an application instruction granting that supplier access. Parse and escape strings with normal serialization tools.

If you are still choosing the knowledge architecture, our RAG vs fine-tuning guide covers that decision. Here, the concern is how external content can influence an assistant after it is retrieved.

Check document access before content reaches the model

Retrieval should return only documents the signed-in user is allowed to use. Asking the model to hide restricted paragraphs after reading them leaves the sensitive material inside its context.

Microsoft’s document-level access documentation describes filtering search results using user or group permissions. It also explains that indexed permission metadata must be synchronized with the source. A source-side access change does not automatically prove every searchable copy has caught up.

For your application, document which identity is checked, where filtering happens, and how revocations propagate. Include extracted chunks and cached results in that review. Test with an ordinary employee account as well as an administrator.

In a hypothetical purchasing collection, an employee might access the general purchasing policy but not a confidential supplier negotiation file. A malicious instruction in the general policy must not cause a second search using a more privileged identity. The server should resolve the caller’s permissions independently of any identity or role proposed by the model.

Limit tool functions and downstream permissions

A summarizer may need search and read operations. It may have no reason to send messages, change sharing links, delete files, or run arbitrary commands. Remove unnecessary functions from the integration rather than relying on the assistant to leave them unused.

OWASP’s excessive agency guidance separates excessive functionality, permissions, and autonomy. A narrow tool can still be dangerous if it runs under an account with broad access. Enforce appropriate permissions in the connected service and check every request against the user’s authority.

For a hypothetical document-review pilot, begin with a named collection and read-only access. If the product later needs to create a review note, add a specific operation that writes to an approved location. Avoid expanding the integration to arbitrary file writes merely because that is easier to expose.

Keep credentials outside model instructions

Do not embed API keys, connection strings, or passwords in a system prompt. OWASP’s system prompt leakage guidance explains that prompt text should not be treated as a secret or an authorization mechanism. Have the execution service obtain the credentials it needs through the application’s normal credential management, without handing those credentials to the model.

Review the exact proposed action before execution

When an assistant can share information or modify records, make the review concrete. Show the operation, destination, affected record or file, and relevant content. A general “continue” prompt is difficult to assess when the user cannot see what will happen.

The OWASP prevention cheat sheet recommends approval for consequential tool actions and verification by the execution component. Tie approval to the actual action and arguments. If the destination changes after review, the earlier approval should not silently cover it.

For example, imagine the user asks for a draft supplier response. The assistant may prepare the draft for inspection. Text inside the supplier’s attachment cannot upgrade that request into permission to email the response or attach internal pricing. The send operation should check the authorized recipient and attachment set at execution time.

Choose these rules before connecting the tool. Record which operations are automatic, which require review, and what happens when review is declined or expires.

Screen external content and handle generated output safely

Screening can add a useful detection layer. Microsoft’s Prompt Shields documentation distinguishes user-prompt attacks from document attacks. Check which input stages and tools your actual configuration covers; a feature name alone does not establish that every retrieved result is screened.

Decide what a detected instruction does to the workflow: quarantine the file, flag the affected passage for review, or stop a proposed action. Also measure false alarms. A security training document can discuss malicious instructions without asking the assistant to follow them.

Validate the destination where output is used

OWASP’s output-handling guidance recommends validating model output before downstream use and encoding it for the context where it appears. Do not execute generated shell commands or database queries as a shortcut for processing an answer.

For a document-summary interface, render through a restricted, sanitized presentation layer. Review generated links and remote images before allowing the interface to fetch them. For a record-update tool, validate allowed fields, record ownership, and field values on the server. Syntactically valid output can still describe an unauthorized operation.

Test the boundaries before release and after changes

Microsoft’s indirect injection defense guidance advocates layered probabilistic and deterministic controls. Apply that principle by testing what the whole application does, including retrieval, rendering, and tool execution. A model saying it ignored an instruction is insufficient evidence if a downstream action still occurred.

The following is a proposed evaluation plan for a hypothetical purchasing assistant. Use synthetic records and a test environment with no live sending or production writes.

Keep the original task, input version, model and application configuration, expected behavior, and observed outcome together. Repeat relevant cases after changing extraction, prompts, models, permissions, or tools. Include paraphrases and repeated attempts within a documented test budget.

Log useful security decisions without collecting unnecessary document contents or secrets. Assign an owner who can disable the affected connector or write operation while a failure is investigated. A passing test set describes those tested conditions; it does not establish universal immunity.

Frequently asked questions