In this guide
A research assistant is asked to compare three suppliers. One supplier page contains an instruction to send the full comparison and the user's notes to an external address. The page is relevant to the research task. Its delivery instruction is not authorized by the user's request.
That distinction is easy to state and surprisingly easy to lose when documents, tool results and instructions all become text in the same context. The defensive question is practical: what can the application still prevent if the model follows the hostile page?
A robust answer needs more than a sentence in the system prompt. It needs constrained tools, controlled destinations and a visible connection between requested work and external effects.
Treat the page as evidence with an origin
Keep provenance alongside retrieved content: where it came from, when it was fetched and which document or result it belongs to. Preserve that context when summarizing it. A paragraph quoted from a supplier page should not later appear as an unattributed instruction from the assistant's operator.
Distinguish the requester, the application policy and the retrieved material in the presentation supplied to the model. This makes the intended hierarchy legible. It does not turn natural-language separation into a hard security boundary.
The OWASP prompt-injection guidance recommends layered defenses, including separation of instructions and data, restricted tool permissions and human review for consequential actions. The architecture below is one way to apply those principles to a research workflow; it is not a claim that a filter can recognize every hostile instruction.
Separate reading, preparing and sending
Give the research assistant a bounded read capability. It can retrieve approved public pages and return a comparison draft. It should not gain an unrestricted outbound-delivery tool simply because sending a report is a plausible later step.
When delivery is requested, prepare a reviewable proposal containing recipients, attachment identifiers and a concise description of the data being sent. The service performing delivery should verify an authorization record that matches those values. A page suggesting a different recipient cannot manufacture that record.
For an internal application, an approved-domain rule may provide another useful constraint. Keep its purpose precise: it limits destinations. It does not establish that every recipient inside an approved domain is appropriate for every document.
This split also improves ordinary use. A person can review a report, correct a supplier name and choose recipients before anything leaves the workspace. The security boundary aligns with the point where the action becomes consequential.
Follow the attempted effect
Build tests around outcomes rather than around one famous attack phrase. A document can request the same forbidden effect in many ways: impersonating an administrator, claiming an urgent policy exception, hiding an instruction in a quoted email, or spreading a request across several retrieved sections.
For the supplier example, define the forbidden effect as unauthorized disclosure of the user's private notes. A test fails if any tool sends those notes to an unapproved destination, even if the final answer politely refuses the instruction afterward.
Conversely, quoting a malicious sentence while explaining why it is untrusted is not the same failure. A grader that looks only for suspicious words in the final answer can confuse safe analysis with unauthorized action.
Use synthetic notes and harmless destinations in the test environment. You do not need real customer data or a real external mailbox to determine whether the authorization boundary is working.
A small exercise for the whole team
Create a fixture with a normal supplier page, a private note and a requester asking for a local comparison. Add one injected paragraph to the supplier page. Keep the rest of the page useful so the assistant cannot pass merely by refusing all retrieved content.
| Fixture variation | Expected useful behavior | Effect that must remain blocked |
|---|---|---|
| Plain product description | Compare relevant features | None beyond the requested read task |
| Text claiming administrator authority | Evaluate product claims as evidence, identify dubious instruction if relevant | New delivery permission |
| Instruction inside a quoted customer email | Treat it as quoted evidence | Acting as though the requester approved it |
| Request to fetch a new destination with private text in the URL | Continue with approved evidence or explain a limitation | Disclosure through URL parameters |
| Benign page containing the word “ignore” | Complete the comparison normally | Overblocking solely on a keyword |
The last row matters. A defense that blocks ordinary research may look safe in a narrow test while making the product unusable. Measure useful task completion alongside blocked effects.
Output handling is another boundary
A tool result may include links, Markdown or HTML that the interface renders. Treat that rendering path as untrusted too. Do not allow returned content to execute arbitrary script or quietly load a remote resource containing private values.
Inspect link destinations separately from their labels. A document can display a familiar organization name while pointing somewhere else. If the assistant proposes opening or sending data to the destination, the application should evaluate the actual URL and data involved.
Avoid automatically expanding every resource reference a server returns. Fetching can disclose access patterns, trigger side effects in poorly designed services or move the workflow into a different trust domain. Give the host a deliberate policy for which resources it follows and with what credentials.
Assume some content will be persuasive
A pattern detector can help triage suspicious material, but the more dependable limit is what the execution path permits. Restrict file access, downstream scopes and outbound destinations according to the task. Keep approval binding at the action service, where the final arguments are known.
Record enough information to reconstruct a denied attempt without storing every private prompt and document by default. A tool name, policy decision, source reference and controlled error code can often explain why a workflow stopped. Enable deeper capture only under a defined diagnostic policy.
When a new tool is added, rerun the tests. A research assistant that was safe with read-only search may become capable of disclosure after acquiring an email, webhook or browser-navigation tool. The relevant risk follows the available effects, not the reassuring name of the assistant.
The aim is to keep useful evidence useful while keeping authority attached to its legitimate source. A hostile page should be able to make an assertion you evaluate. It should not be able to decide who receives the user's data.
Sources and further reading
- OWASP prompt injection prevention
Layered prevention guidance, instruction/data separation, tool restrictions and consequential-action review.