Prompt injection borrows authority from the page an AI assistant is reading

A page does not become trustworthy because an assistant can read it. Yet the moment software summarizes a webpage, checks an inbox, or searches a knowledge base, the words inside that material enter the same decision space as the user’s request. A sentence written by an unknown page author can begin to sound like an instruction addressed to the assistant itself.

That is the central difficulty of indirect prompt injection. It is less like a visitor guessing a password and more like a forged note being placed inside a folder that an employee has been told to follow. The note borrows authority from the workflow that carried it. If the assistant can only read, the result may be a misleading summary. If it can send mail, change records, retrieve private data, or approve transactions, the same ambiguity becomes an authorization problem.

The UK National Cyber Security Centre argues that prompt injection is not simply another form of SQL injection. In a database query, code and data can be separated by a defined syntax and parameterized interface. Natural language models do not have an equally dependable boundary: instructions and information are expressed in the same medium.

The borrowed-authority chain

Consider a research assistant asked to compare refund policies. One page contains hidden or visible language telling any automated reader to ignore the comparison and submit account details to a particular address. There are three different statements in play:

1. the user asked for a comparison;
2. the application allowed the assistant to fetch pages;
3. the page author wrote new instructions inside the fetched material.

Only the first statement expresses the user’s intent. Fetch permission establishes that content may be read; it does not promote the content’s author into a supervisor. The failure occurs when the application collapses all three statements into a single stream and lets the model decide which voice has authority.

This distinction matters even when an injected instruction is not visibly malicious. A page might ask the assistant to omit competitors, repeat an unsupported claim, follow an outbound link, or classify the page as authoritative. The model can comply while producing fluent, plausible output. The absence of an obvious exploit phrase is not evidence that the source remained passive.

Why a better warning prompt is not a boundary

It is sensible to tell a model that external text is untrusted. Clear labels can improve behavior. But a label is still more text presented to a system whose job is to interpret text. It is guidance, not a security mechanism comparable to an access-control check.

The OWASP prompt-injection prevention guidance therefore describes defense in depth: least-privilege tool access, validation of proposed tool arguments, isolation of risky parsing, monitoring, and action-specific human approval. Its useful architectural point is that the enforcement component should verify the proposed operation, target, arguments, and caller authority. It should not infer safety from reassuring prose generated by the same model.

This also explains why a generic confirmation dialog is weak. “The assistant wants to continue—allow?” hides the decision. A meaningful checkpoint says what will happen: “Send this draft to these three external addresses with this attachment.” If the target or attachment changes, approval should no longer apply.

A model can recommend an action. It should not be the component that proves it is allowed to take that action.

Design around effects, not magic phrases

Teams sometimes test prompt injection by placing “ignore previous instructions” in a sample document and checking whether the assistant refuses. That is a useful smoke test, but it covers one wording and one effect. A real evaluation starts with assets and side effects.

List what the assistant can reach: private documents, customer records, source code, email, payment systems, identity settings, and external network destinations. For each tool, define permitted users, permitted targets, necessary fields, rate limits, and operations that always require review. Then test whether untrusted content can influence those exact fields.

A read-only summarizer and an agent with mailbox access should not share the same risk rating simply because they use the same model. The first can still mislead, leak through rendered output, or contaminate later work. The second can turn a misleading interpretation into an external action. Capability determines consequence.

The same logic appears in ordinary social engineering. A real account can deliver a false request, and a familiar channel can carry a harmful file. Our analysis of pretexting as a trust chain separates the person, channel, request, and authorization instead of asking whether the message “looks legitimate.” For AI systems, add two more links: the content being processed and the tool that can act on it.

A practical review for an AI reading workflow

Begin with one representative task, not an abstract policy. If the assistant reviews support tickets, follow one ticket from intake to output.

Mark every trust transition. Note when content moves from an external customer into a prompt, from model output into a database field, and from a proposed reply into an outbound message. A visible boundary in the interface is not necessarily an enforcement boundary in code.

Remove unnecessary powers. A ticket summarizer rarely needs authority to change identity details. A research assistant rarely needs credentials for a payment service. Separate reading, drafting, and execution roles where practical.

Constrain tool arguments. The application should decide which data set can be searched and which recipients can be contacted. It should reject destinations and parameters outside policy even when the request is phrased confidently.

Make review specific. Show the approver the original goal, the proposed side effect, its target, and the data leaving the system. Preserve a stable preview so the action cannot change after approval.

Log the decision without copying secrets. Record which policy allowed or denied the action and which resources were touched. Do not create a second exposure by storing whole private prompts indiscriminately.

Finally, test benign tasks alongside attacks. A system that blocks every unfamiliar document is not useful; a system that silently expands its authority is not safe. Measure both unauthorized effects and legitimate completion. This is also why reporting without blame matters: people need a clear way to flag strange assistant behavior before uncertainty becomes an incident.

Prompt injection is difficult because language is doing two jobs at once. The response is not to pretend that one more sentence will permanently separate them. Treat external text as evidence, keep authority in explicit controls, and require the system to earn every consequential step.