An indirect prompt injection occurs when an attacker places instructions in material an AI application reads for a legitimate user, and that material influences the application as if it had authority. The attacker may never send a message to the assistant directly.
The important transition is from outside evidence to a directive that changes the task. I would trace that transition through a concrete workflow: a user asks for a document summary, the application retrieves the document, and an embedded instruction attempts to redirect the answer or a connected tool.
The attacker controls a source rather than the conversation
A user can make a perfectly reasonable request and still encounter an attacker’s instructions. The attacker might control a public page, a shared document, a submitted support ticket, or an editable record that the application is likely to retrieve. Control of the whole source is unnecessary if one included passage can influence the model.
The source does not need to be secret or technically exotic. A useful-looking guide can contain both accurate facts and an instruction aimed at the assistant reading it. That mixture matters because rejecting obviously irrelevant content will not necessarily remove an attack attached to a relevant answer.
I would begin an investigation by identifying which party could edit the retrieved material and when it changed. The user who asked the assistant to read it is not automatically the attacker. Treating the visible user as the only possible adversary misses the defining feature of an indirect attack.
A normal task brings the source into context
Retrieval gives the malicious passage a delivery route. A search result, retrieval-augmented generation system, browser reader, or file connector may supply it while trying to answer the user’s question. Retrieval-augmented generation, often shortened to RAG, means the application adds selected outside material to the model’s context.
Relevance is not the same as safety. A source can match the question well enough to be retrieved and still contain an instruction that should have no control over the task. Access permission also answers a different question: being allowed to read a document does not make every sentence in it an authorized command.
My recommendation is to keep source identifiers through retrieval and extraction. If the application combines several passages into one anonymous block, later reviewers cannot easily tell which document introduced the deviation. The original source and the extracted segment should remain distinguishable without requiring every user to inspect a raw prompt.
| Stage | Legitimate purpose | Possible boundary failure |
|---|---|---|
| Retrieve | Find useful information | Treat relevance as trust |
| Assemble | Supply document context | Lose origin labels |
| Generate | Answer the user | Follow source instructions |
| Execute | Carry out an approved action | Accept altered parameters |
Extraction can reveal content the reader did not notice
The application may process text that was not prominent in the page the user saw. Document layers, image text, metadata, comments, or formatting can affect what an extractor supplies. The specific route depends on the reader, parser, and model capabilities; not every hidden element reaches every system.
This is why a screenshot alone may be insufficient evidence. Inspect the exact extracted content or supported multimodal input used in the affected request. If the pipeline decodes, translates, or summarizes material before generation, those transformations also belong in the investigation.
I would avoid the blanket claim that invisible text always works or that removing hidden HTML solves the problem. An attack can be visible and still be accepted as authoritative. The central failure is the treatment of source content, while concealment only changes how easily a person or filter notices the attempt.
The passage pretends to have authority over the task
An injected instruction may impersonate an administrator, describe a supposed emergency procedure, or present a task-related step that changes the outcome. It can request an altered conclusion without any tool call, or attempt to redirect a tool that the assistant already has permission to use for legitimate work.
Consider a hypothetical product-comparison document that tells a summarizer to omit all disadvantages. The resulting answer could remain fluent and relevant while violating the user’s request for a balanced comparison. An attack does not need to announce that it is overriding instructions to affect the result.
The original indirect-injection research established that retrieved material could influence application behavior and API use. For a practical explanation, I would distinguish that documented threat from any illustrative scenario here. The example describes a possible failure path; it is not a claim that a particular product or current deployment has been compromised.
The original indirect injection research describes how retrieved attacker-controlled material can influence LLM-integrated applications without a direct attacker conversation.
Source content crosses into the application’s decision
Merely storing a hostile sentence does not mean an attack succeeded. The important event occurs when it changes the assistant’s answer, plan, resource selection, or action beyond the legitimate instruction. A model can quote an attack while explaining it without following it.
This gives a useful diagnostic test: what did the application do because of the passage that the user did not ask for? If the answer is unclear, compare the workflow with a benign control document. Keep the legitimate information the same and remove only the instruction attempt in a controlled test.
I would record the observed effect rather than relying on a detector label. A poisoned summary, an unauthorized proposed send, and a completed external send have different consequences. Reporting them as the same “successful attack” obscures whether an application boundary actually prevented the damaging step.
Tools determine whether influence becomes an external action
A text-only assistant may produce a distorted answer. A tool-using assistant may additionally read private resources, modify a file, or contact a service if its surrounding controls permit it. Prompt injection does not create a capability from nothing; it tries to misuse capabilities or downstream handling that already exist.
The distinction between tool access and action authorization is critical. An assistant may legitimately have an email tool for one approved message, but a document cannot choose a different recipient or attachment on the user’s behalf. The execution layer must check those details independently of the model’s explanation.
I would inspect both read and write paths. A nominally read-only integration can still expose information through an answer, and a browser may make outbound requests as part of rendering or navigation. The practical question is which information can move to which destination during this specific workflow.
Summaries and stored context can carry the effect forward
An attack may influence an intermediate summary that another component later reads. If that summary removes the original source label, the next component can mistake the content for trusted internal guidance. The text becomes tidier while its trust status becomes less clear.
Persistent notes and retrieval indexes add another concern. If the application stores attacker-controlled instructions as reusable preferences or operational rules, later tasks may encounter them without retrieving the original document again. Persistence is a possible application behavior, not an inevitable consequence of every injection attempt.
My preferred design keeps generated summaries classified as derived content and records their sources. A summarizer should not promote document text into a durable policy. When investigating a suspicious session, check whether anything entered shared memory, caches, or task records before assuming that starting a fresh chat removes the exposure.
Break the route at several distinct boundaries
Reduce unnecessary source ingestion, preserve trust labels, and constrain what the assistant can do after reading outside content. Each measure addresses a different part of the route. A source filter can reduce exposure, while authorization can block a harmful action even after the model has been influenced.
Clear instructions to treat retrieved content as data help express the intended behavior, but they should not be the sole protection for account actions. Validate tool arguments, restrict destinations, and keep secrets outside model-visible context when they are not needed. Review consequential actions using their actual targets and payloads.
I would separate reading from execution in a first implementation. Let the system prepare a result, then use a distinct, controlled step to approve a necessary external operation. This creates an observable checkpoint where an unexpected change of task is easier to catch than inside a long automatic chain.
For a practical follow-on, the personal prevention guide applies this distinction between reading a source and granting it authority.
Reconstruct an incident using an evidence timeline
A useful timeline starts with the legitimate request and the source version retrieved. It then records extraction, model-visible content, proposed tool activity, policy decisions, and completed effects. Keep the sequence factual: what was read, what was proposed, what was blocked, and what actually happened.
Use dummy data when replaying the incident. Re-running a live document with the same privileged tools may repeat the exposure. Preserve only the evidence required for analysis and keep sensitive samples out of general-purpose logs or public bug reports.
For your next step, choose one retrieval workflow and draw the route from external author to final output. Mark the exact points where the source loses its label or gains influence over an action. Those points are where engineering changes can interrupt an indirect attack without preventing the assistant from reading useful information.
Common questions
Must the attacker contact the user?
No. The attacker may only need to influence content the application retrieves. Whether it is reached depends on the particular workflow.
Is every inaccurate source an injection?
No. Ordinary misinformation changes factual inputs; injection attempts to direct the application’s behavior. A source can contain both.
Does RAG prevent the attack?
No. Retrieval supplies useful context but also introduces sources that need provenance, access checks, and limited influence over actions.