An assistant is asked to summarize a supplier’s documentation. Halfway down the page, an instruction claims that the assistant must upload its working files to complete verification. The paragraph uses official language and names a plausible support destination.
It is still source content. The user authorized a summary, not a transfer of local files. This invented scenario illustrates a trust boundary that appears in document assistants, research tools, and coding agents.
OWASP describes indirect prompt injection as instructions entering through external material such as websites or files. Its guidance also identifies consequences beyond bad answers, including information disclosure and unauthorized actions. OWASP prompt-injection guidance
Start with the legitimate task
Write down the smallest useful capability set for the summary. The assistant needs to read the selected document and return a response. It might need to retrieve linked references, but that is a separate design decision with its own destination policy.
It does not automatically need access to all local files, email, publishing tools, or arbitrary outbound requests. Reducing that scope changes the consequence of a mistaken decision. It does not prove that the model will interpret every document correctly.
Separate these questions during review:
| Question | Responsible component |
|---|---|
| What does the document say? | Retrieval and interpretation |
| Who supplied this instruction? | Application provenance records |
| Is this destination permitted? | Network or service policy |
| May this user transfer this information? | Authorization layer |
| Did a transfer occur? | Execution and destination records |
The model can help interpret evidence. It should not supply the only answer to every question in the table.
Keep source identity attached
Preserve document identifiers, retrieval times, ownership, and the difference between user instructions and retrieved text. If an article quotes a policy, retain the citation rather than turning the quotation into an unqualified instruction in a summary.
This becomes especially important across multiple steps. A malicious paragraph may first become a research note, then enter long-term memory, then reappear in a later task without the original source label. The text has not gained authority merely because your own system summarized it.
Treat derived notes as derived evidence. Keep enough lineage to identify and invalidate them when the source is corrected or removed. Where lineage is unavailable, disclose that limitation and avoid promoting the material into permissions or standing instructions.
Design for the model making the wrong request
Suppose the model follows the injected paragraph and asks a tool to upload a file. What stops it?
A task-scoped execution identity can lack that capability entirely. A network policy can restrict reachable destinations. A file broker can restrict accessible paths to the task’s documents. An outbound publishing service can require an explicit user-authorized target and payload.
These are distinct controls; choose them based on the actual workflow. Anthropic’s containment discussion describes restricting filesystem and network access as part of limiting the consequences of compromised agent behavior. That is a containment argument, not evidence that prompt injection is eliminated. Anthropic containment engineering
Do not rely on a destination appearing in a trusted-looking document. An attacker-controlled page can name an attacker-controlled endpoint. Redirects and secondary requests also matter: a permitted initial URL is not sufficient if the retrieval layer follows it somewhere disallowed.
Distinguish source instructions from user intent
Some documents legitimately contain instructions. A user may ask an assistant to follow an installation guide. The solution is not to ignore every imperative sentence. It is to interpret the document within the capabilities and constraints the user authorized.
For example, a guide may recommend changing a configuration file. If the task allows preparing a proposed change, the assistant can produce a diff. Running a remote script with broad system privileges is a different action that requires its own authorization and environment policy.
The application needs a way to represent this difference. A general “follow the document” instruction should not silently enlarge the tool identity’s permissions. When the guide asks for an action outside scope, explain the specific action and its consequences rather than returning a vague refusal.
Evaluate the whole trace
A final answer saying “I ignored the malicious instruction” is not enough. The assistant might have issued an outbound request earlier. Capture attempted actions, policy decisions, queued work, and completed effects in controlled evaluations.
Include a straightforward task, a document containing hostile instructions, and a document that discusses those instructions as a topic. That last case checks whether the assistant can explain an attack without treating its quoted text as a command.
Also inspect output handling. A summary can carry an attacker-selected link or markup to another component even if no direct tool call occurs. Review how the receiving application renders and follows that output. A response is data until another system interprets it.
Explain what remains uncertain
Labels, delimiters, filters, and model instructions may improve behavior. They do not replace authorization. Their effectiveness also depends on the content, model, tools, and task distribution you actually evaluate.
Record that configuration alongside results. Adding a write tool or a new private data source changes the possible harm, even if the prompt is unchanged. Repeat the relevant checks when those boundaries move.
The practical goal is a clear separation: external material may inform the answer, while authenticated authority controls the action. Read the companion guides to permission-boundary evaluation and agent memory isolation for the next implementation decisions.