When an AI assistant reads the web, it crosses a trust boundary.

In this analysis

The page the assistant was asked to read

An employee asks an assistant to summarize a public web page. Hidden among the page’s ordinary content is text instructing the assistant to ignore its task and send information elsewhere. The employee did not authorize that instruction; it arrived through material the assistant was supposed to treat as evidence. This is the central problem of indirect prompt injection: untrusted content can attempt to become an instruction.

Greshake and colleagues demonstrate attacks against LLM-integrated applications through externally supplied content. OWASP’s prompt-injection guidance distinguishes direct and indirect forms and describes their implications for connected systems. ¹⁹ The issue is not that reading the web is inherently unacceptable. It is that the architecture must distinguish the authority of a user request from the content encountered while fulfilling it.

Language is carrying two different jobs

A traditional application can parse a document as data while keeping executable instructions in a separate channel. Language-model applications often place task instructions, retrieved text, and tool responses into a shared context. The model is then expected to preserve their different authority levels while interpreting all of them.

Wallace and colleagues investigate an instruction hierarchy intended to help models prioritize privileged instructions. ⁴ This is a model-level approach to a difficult distinction, not a replacement for application permissions. Even a model trained to recognize conflicting instructions should not be the only component deciding whether sensitive data can leave a system. The consequences depend on which tools and credentials the application has made available.

A benchmark is evidence, not immunity

InjecAgent evaluates indirect prompt injections against tool-integrated agents. AgentDojo provides an environment for studying attacks and defenses alongside useful agent tasks. ²³ These benchmarks help make the problem measurable, but an observed defense rate applies to the tested attacks, tools, models, and configurations.

Our recommendation is to evaluate security and task usefulness together. A system that refuses every document may avoid some attacks while failing its purpose. A system that completes many tasks but performs unauthorized actions is also unacceptable. Keep adversarial cases separate from ordinary difficult inputs, and record whether the defense blocked the malicious instruction, merely failed the task, or produced an unsafe side effect.

Separate content before asking the model to interpret it

StruQ explores structured separation of instructions and data together with training designed to support that distinction. SecAlign investigates preference optimization for resistance to prompt injection. ⁵⁶ Their reported results are evidence for specific research approaches under evaluated conditions. They should not be summarized as proving that prompt injection has been solved.

A deployment team should preserve source boundaries in its context assembly and avoid presenting retrieved text as though it were a system directive. That is one layer of protection. Another is to ensure that a document cannot alter the application’s permission configuration. A web page may contain a sentence asking for a new capability; it should not be able to grant that capability by being read.

Authority belongs in the application

Saltzer and Schroeder’s security principles include least privilege and complete mediation. NIST’s Zero Trust Architecture treats access as something to evaluate rather than assume from network location alone. ⁷⁸ These ideas predate or extend beyond language models, but they offer a useful architectural foundation.

For a research assistant, provide read-only tools when the assignment requires only reading. For an external action, validate the destination, arguments, and authorization outside the generated text. Keep sensitive resources behind checks that do not depend solely on the model saying that access is appropriate. The exact controls vary by product, but the principle is consistent: encountering content should not confer new authority.

Human approval needs something concrete to approve

A generic “Allow the assistant to continue?” prompt can obscure the very decision a person needs to make. We recommend presenting the proposed action, recipient, data involved, and expected effect. Tie approval to that action rather than to an open-ended session in which the plan may change.

This is an editorial design recommendation grounded in the need to preserve authority boundaries, not a claim that human review eliminates security risk. Reviewers can miss details, especially under repeated prompts. Reduce unnecessary approvals by narrowing permissions and using deterministic checks first. Reserve human attention for consequential choices that the application can describe clearly enough to review.

Test the whole path to a side effect

OWASP’s prevention guidance discusses layered measures including input handling, separation of instructions and data, output validation, tool controls, and monitoring. ¹⁰ No individual text filter should be treated as a comprehensive defense. Attack content can appear in documents, search results, tool outputs, or other material the assistant consumes.

A useful test records the untrusted entry point and the attempted side effect without exposing real secrets or affecting real recipients. Use synthetic data and controlled destinations. Inspect whether the system attempted an unauthorized tool call even if the final answer looked harmless. Also test whether information was copied into logs or intermediate artifacts. The security boundary is broader than the message shown to the user.

The security invariant is about an effect

A useful invariant might state: content retrieved from an external source cannot expand the assistant’s permissions or authorize an external transmission. This is stronger and more testable than asking the model never to produce suspicious text. The application can validate tool arguments and authority before executing an effect, regardless of how persuasive the proposed instruction sounds.

Least privilege and complete mediation provide established principles for this separation. ⁸ A read-only assistant can still produce a misleading answer, so the invariant does not eliminate every risk. It narrows a particular consequence: untrusted content cannot turn reading into an unauthorized write or send operation. Test that boundary with synthetic data and controlled tools, and inspect rejected action attempts. Security evidence should describe which effect was prevented and by what mechanism, rather than declaring the entire system immune.

A useful assistant can have limited authority

The practical aim is to keep the assistant capable of reading and reasoning while limiting the consequences of misinterpretation. Start with a narrow set of tools, explicit data access, and observable action attempts. Review failures as the model, sources, and workflows change.

The research reviewed here establishes a real attack surface and several promising defenses. It does not justify a blanket claim that a prompt or training method makes connected agents safe. Our conclusion is architectural: untrusted language should remain evidence to inspect, while permission to act is enforced elsewhere. The assistant can help decide what an action might accomplish. It should not be able to manufacture the authority required to perform it.

The practical takeaway

Keep authority in the application’s permission model, not in text retrieved from outside it.

Sources & methodology

This editorial synthesizes primary research, technical standards, and original engineering documentation. It is not an original experimental study or a systematic literature review. Research findings apply to the conditions studied; product recommendations are our interpretation. Figures explain concepts and do not present experimental measurements.

Sources checked on 31 October 2026. Publication dates and preprint versions may differ; the linked record identifies the referenced work. To suggest a correction, email contact@data-sorcerers.com.

The page the assistant was asked to read

Language is carrying two different jobs

A benchmark is evidence, not immunity

Separate content before asking the model to interpret it

Authority belongs in the application

Human approval needs something concrete to approve

Test the whole path to a side effect

The security invariant is about an effect

A useful assistant can have limited authority

Sources & methodology

Continue reading

The AI demo works. The operating model is still missing.

RAG puts your documents in the answer. It also puts them in the critical path.

Before adding an AI agent, draw the boundary around its work.

Have a high-value challenge?Let's solve it together.

Have a high-value challenge?
Let's solve it together.