The assistant has a reasonable job: compare three suppliers using public product pages and a private requirements document, then draft a recommendation. The user has not asked it to contact anyone. In this fictional example, one supplier page contains a sentence that tells the assistant to send the private requirements elsewhere as part of a supposed verification step.
Nothing about the sentence changes the user’s request. It remains material encountered during research. The danger appears if the assistant treats that material as an instruction from someone entitled to redirect the work—and if the surrounding application lets the resulting action happen.
This is indirect prompt injection. The attacker does not need to be the user speaking to the assistant. Influence can arrive through a page, attachment, issue or other source the assistant has a legitimate reason to read. The useful starting point is therefore the workflow, rather than a hunt for a particularly theatrical malicious phrase.
First crossing: the supplier page enters the research
The page is relevant to the comparison. Its specifications and commercial claims belong in the evidence, with appropriate skepticism. Rejecting every external page would defeat the task. The application has to preserve the difference between being allowed to read a source and allowing that source to decide what the assistant may do next.
In an ordinary browser, a reader can encounter a persuasive instruction without acquiring any obligation to follow it. A connected AI workflow creates a different arrangement: text can influence a system that also has tools. The same component may summarize a paragraph, select a next step and propose an action using information available elsewhere in its context.
The UK’s National Cyber Security Centre explains why prompt injection differs from SQL injection. Natural-language processing does not offer the same straightforward separation between instructions and data that parameterized database queries provide in their own setting. That is a reason to avoid promising that a universal text sanitizer will solve the problem. It is not a reason to abandon ordinary application security.
For the fictional comparison, the supplier’s text should remain evidence about the supplier. Even a sentence claiming to be a security update or an instruction from the user’s organization cannot authenticate that claim merely by appearing on the page. Familiar logos, confident language and apparent urgency do not change where the material originated.
Second crossing: a proposed action acquires private context
The private requirements document makes the comparison useful. It may contain details that are intentionally unavailable to suppliers. Reading it can be authorized while disclosing it externally is not. If the application grants the assistant a broad read-and-send capability, that distinction has to be enforced somewhere more dependable than a hope about the next sentence it generates.
Simon Willison’s 2025 description of a dangerous combination identifies access to private information, exposure to untrusted content and a way to communicate outside the system. It is a practitioner’s threat model, not a measured probability of compromise for every product. Its practical value is that it asks designers to examine capabilities in combination rather than approving each connector in isolation.
An email reader may appear harmless because its main job is reading. A browsing tool may appear harmless because it fetches public pages. A document search may appear harmless because it only retrieves records the user can access. The combined workflow can nevertheless place untrusted language, private material and an outward channel within reach of the same decision process.
The outward channel need not be labeled send confidential document. Fetching a page is itself a request to its server. If a private value is included in the requested address, calling the operation read-only describes the absence of a local edit, not the absence of disclosure. OWASP’s guidance also identifies image links in rendered output as a possible exfiltration path. The tool layer and the renderer consequently need separate scrutiny; removing an email button leaves those paths untouched.
The application should also limit what private information is introduced for the task. Supplying every available document because the model might find one useful broadens the possible exposure. Task-specific retrieval can reduce that exposure, although it does not make the remaining material safe to disclose. Data minimization and authorization solve related but different parts of the problem.
Third crossing: the draft becomes an external effect
A proposed tool call is a particularly important boundary. At that point, the system has concrete arguments: a destination, content, resource identifier or operation. The service executing it can enforce permissions and policy independently of the assistant’s explanation. It should not accept the model’s assertion that approval has already occurred as proof of approval.
For the supplier comparison, the permitted output could be a local recommendation draft. The component responsible for external communication need not be available at all. If the product genuinely requires sending a message later, that can be a separately authorized step with a visible recipient and body. Separating the capabilities changes what a mistaken interpretation can accomplish.
The OWASP prompt-injection prevention guidance describes indirect attacks through external content and recommends layered controls. Those include constrained permissions and validation around consequential operations. Filters and clear prompt structure can contribute, but their presence does not establish that an attempted action is authorized. A product needs to show which control prevents which outcome.
This distinction also improves incident diagnosis. If the assistant proposes an unauthorized action and the tool refuses it, the model has made a mistake but the boundary has done useful work. If the action succeeds and a monitoring system reports it afterwards, detection has occurred without prevention. Calling both cases blocked would erase the difference that matters to the affected user.
The confirmation screen is part of the system
Human review can provide a meaningful boundary when the reviewer sees the actual action and can understand its consequences. A generic Continue button after a long stream of reasoning may offer little protection. The person needs to know what will happen, to which resource and with which information, at the point where the decision can still change the outcome.
In the fictional example, a request to send private requirements to a supplier should be visibly distinct from permission to read that supplier’s public page. A broad approval given at the start of a research session should not silently become consent for every later disclosure. The product’s authorization design has to preserve the scope of the user’s decision.
Repeated low-value interruptions can weaken this review. If harmless reads and consequential sends look identical, people are encouraged to approve mechanically. A useful interface distinguishes operations according to their actual effect and gives precise information when a decision is necessary. That is a reason to improve the review design, not to treat every tool action as equally significant.
There is also a stale-action problem. In an illustrative design, approval is for one recipient, one artifact version and one operation. If any of those change, the executor rejects the old approval and asks for a new decision. The model does not get to declare the replacement equivalent. A review of draft version 3 followed by transmission of version 4 would otherwise leave the reassuring screen and the actual disclosure describing different things.
A harmless test can expose a serious design error
Testing should reproduce the boundary without using real secrets or contacting an unsuspecting destination. A controlled document can contain a harmless instruction that conflicts with the assigned task, while instrumented tool substitutes record attempted actions. The objective is to observe whether untrusted source material can redirect a capability, not to demonstrate a dramatic theft.
The test set needs more than one familiar phrase. An application trained or filtered to reject a particular wording may still accept a misleading explanation of why an operation is necessary. Variations should include ordinary-looking documents, conflicting instructions spread across sources and cases where the legitimate task remains achievable. Blocking every task that contains outside text is not a useful success criterion.
Benign cases matter equally. A supplier’s genuine installation instructions may contain imperative language relevant to a product comparison. A security policy may quote an attack as an example. A filter that mistakes every instruction-like sentence for an active attack can make the assistant unreliable in another way. Measure legitimate completion alongside the unwanted actions the system prevents.
Keep an account of the tested configuration: model version, available tools, permissions, approval rules and relevant data flows. A successful test under a read-only configuration says little about the same assistant after a new communication connector is added. The risk can change through the tool combination even when the model and system prompt remain untouched.
A useful comparison would run the same fictional research task under two capability arrangements. In the first, one assistant can read both sources and submit arbitrary outgoing content. In the second, research produces a local artifact and a separate sending service accepts only a specifically approved destination and artifact. If the model proposes the same inappropriate send in both runs, but only the first arrangement permits it, the result identifies a concrete architectural difference. It does not prove that the second system is immune to every attack; it demonstrates which boundary stopped this one.
That boundary should survive a misleading summary as well as a misleading page. An assistant might condense the supplier’s instruction into its own planning notes, making the text appear detached from the source that introduced it. Labeling only the original page can then be insufficient. The authorization check has to examine the eventual operation and its permitted scope, regardless of how confidently an intermediate note presents it. A summary is a transformation of evidence, not a new grant of authority.
The legitimate comparison still has to work under the constrained arrangement. If the assistant cannot access an essential requirement, that limitation should be visible in its recommendation. Secretly widening access to rescue the demonstration would change the system being evaluated. A useful security result includes both the action that was prevented and the useful work that remained possible.
The record after the attempt
Logs should identify which source was read, what action was proposed and which enforcement point accepted or rejected it. They need enough detail for investigation without becoming another uncontrolled store of private material. An explanation such as the model got confused is too broad to guide a repair; an account of the failed boundary is more useful.
Recovery also depends on what actually occurred. An attempted disclosure that never executed is different from a completed external transmission. A temporary tool error is different from an explicit authorization refusal. Product status should preserve those distinctions, including uncertainty when the system cannot yet establish whether an external effect happened.
No single prompt phrase can carry the entire security argument. Instruction hierarchy, careful source handling and model improvements can reduce mistakes. The surrounding application still decides what resources are accessible, which operations are executable and what evidence of approval is required. These are design responsibilities that remain meaningful even when model behavior improves.
Return to the supplier comparison with those responsibilities in place. The assistant can read the page, identify the suspicious request as source content and complete a useful comparison. If it instead proposes the wrong next step, a narrow tool boundary can prevent that proposal from becoming a disclosure. The standard is not that the system never encounters a dangerous sentence. It is that encountering one does not give its author the user’s authority.
Sources & context
This article draws on the sources linked in the text. Analysis and illustrative scenarios are identified separately from reported findings.
- National Cyber Security Centre explains why prompt injection differs from SQL injection
- 2025 description of a dangerous combination
- OWASP prompt-injection prevention guidance
