Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

Why do 80% of prompt injection attacks don't start at the prompt?

The 80 percent figure is an unverified premise; no published source establishes that share. What the record establishes is the mechanism: a documented class of prompt injection arrives through the pages, documents, emails, tool outputs and images a system reads, not through the prompt field. A defense that screens only what users type never meets that class.

Images, folders, tables and files converge at a scanner before reaching a model input.

The 80 percent figure is an unverified premise; no published source establishes that share. What the record establishes is the mechanism: a documented class of prompt injection arrives through the pages, documents, emails, tool outputs and images a system reads, not through the prompt field. A defense that screens only what users type never meets that class. The user types an ordinary request, the application fetches content to answer it, and an instruction planted in that content is what the model follows. Primary sources set out where injections originate, why the retrieval path is structurally exposed, and which controls address that path. What a planted instruction can collect depends on what the model holds while it works, which is the question Least Exposure answers: for each piece of work, the AI receives exactly the data the task requires and nothing more, enforced before any model reads the screen. The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.

Key findings

  • OWASP ranks prompt injection as LLM01 in the 2025 Top 10 for LLM Applications and separates direct injection, entered by a user, from indirect injection, embedded in external content the model later processes (OWASP, 2025).
  • NIST's adversarial machine learning taxonomy treats indirect prompt injection as its own category, with sub types organized by whether the goal is loss of availability, integrity, privacy, or abuse (NIST, 2023).
  • Peer reviewed research demonstrated indirect injection against real LLM integrated applications, including data theft and self propagating payloads, with the attacker never interacting with the victim system directly (Greshake et al., 2023).
  • Web based indirect injection has since been observed in live telemetry on real websites, with payloads concealed in markup and aimed at agents that summarize, review, or act on pages (Palo Alto Networks Unit 42, 2026).
  • No source reviewed publishes a defensible percentage split between direct and indirect attacks across the field; benchmarks such as AgentDojo report attack success rates for their own task sets, not shares of attack origins (Debenedetti et al., 2024), which is why the premise figure in the headline cannot be confirmed.

What does it mean for an attack to start somewhere other than the prompt?

In a direct attack, the adversary is the user of the moment. They type or paste an instruction intended to override the system instructions, extract a system prompt, or make the model ignore a constraint. That attack is visible in the conversation, tied to an account or a session, and logged where a reviewer would expect to find it.

In an indirect attack, the adversary and the victim are different people, and often different organizations. The attacker publishes or plants content. Later, a victim application retrieves that content to complete an unrelated, legitimate task, and the planted instruction arrives inside the retrieved material. Greshake and co authors described this as a blurring of the line between data and instructions, where processing untrusted retrieved content becomes comparable in effect to running untrusted code (Greshake et al., 2023).

Three properties follow from that structure. The attack is asynchronous: it can be planted long before it triggers. It is scalable: one planted page can be retrieved by many agents. And it is misattributed by default: the logs show a normal user request and a normal retrieval, so the malicious step looks like the application's own behavior.

Starting point also determines who can defend. A user facing control, such as screening what a person types, cannot see an indirect payload at all. The relevant controls sit at ingestion, at tool design, at privilege, and at action approval.

Why is retrieved content such an effective delivery channel?

The core reason is architectural. A language model receives instructions and data as one token stream. It has no separate, trustworthy channel that labels which tokens came from the developer and which came from a web page fetched a moment earlier. OpenAI's published work on an instruction hierarchy addresses exactly this, training models to prioritize system and developer instructions over user input and over tool output, with tool output at the lowest level of trust (OpenAI, 2024). That such training is needed, and that it remains a research problem rather than a solved property, tells a reader how weak the default separation is.

Retrieval also expands the attack surface with every feature. Each connector, each document store, each browsing capability, and each tool that returns text adds a source an attacker may be able to influence. An attacker does not need access to the application. They need access to something the application reads, which may be a public page, a shared document, a support ticket, a listing, or a message in a shared inbox.

Trust habits make it worse. Applications are often built as if retrieved content were neutral evidence, because for search and summarization it usually is. The same pipeline is then given tools, credentials, and the ability to act. NIST's taxonomy is useful here because it separates the injection from its intended effect, which can be a change to integrity, a disclosure of private material, a loss of availability, or abuse of a connected capability (NIST, 2023). The delivery channel is the same in each case. What changes is what the agent is allowed to reach after it is steered.

Finally, the attacker gets to choose the wording with no time pressure and no interaction limit. They can test a payload against public models, revise it, split it across sources, and repeat it in several forms on the same page, as observed in live cases where one page carried many delivery attempts (Palo Alto Networks Unit 42, 2026).

Which non prompt sources carry injections in practice?

Web pages are the most studied source, including visible text, hidden markup, comments, attributes, and script delivered content. Documents are a second source: PDFs, office files, and their metadata can carry instructions that survive conversion to text. Email and messaging are a third, because agents that triage inboxes read messages written by strangers as a core function. A message that asks the assistant to forward, delete, or summarize in a particular way is both content and an attempted instruction.

Retrieval augmented generation adds a fourth source: the corpus itself. If an attacker can add or edit a document in a knowledge base, a wiki, a ticket history, or a shared drive, the injected instruction can be retrieved repeatedly for many different user questions, and it inherits the authority of an internal source. Tool outputs are a fifth source. Calendar invitations, transaction records, customer relationship notes, search results, and application programming interface responses all return text that another party may control in part.

Multimodal input is a sixth source. Text rendered inside an image, a screenshot, a chart, or a scanned form can carry an instruction that a text only review of the input would not show. As agents take screenshots as a primary input, this channel becomes more important rather than less.

The common feature is not the format. It is that the content was authored by someone other than the developer and the current user, and it was treated as material to act on rather than only material to describe.

Why cannot a percentage for this be stated responsibly?

A percentage needs a numerator, a denominator, and a population, and none of the three is well defined for prompt injection as a whole. There is no shared reporting regime in which all direct and indirect attempts are counted. Vendors see only their own traffic. Researchers see benchmarks and telemetry from specific products. Many indirect attempts are never detected, because a steered answer can look like an ordinary answer, and many direct attempts are indistinguishable from ordinary misuse testing.

Definitions also move the result. Counting attempts gives a different answer from counting successful attacks, which gives a different answer from counting confirmed incidents with harm. A benchmark can report an attack success rate for its own task set, as AgentDojo does for its environments, but that is a property of the benchmark and the target configuration, not a field wide share of attack origins (Debenedetti et al., 2024).

Publication bias compounds the problem. Indirect injection is the more novel and more publishable phenomenon, so it is over represented in papers, talks, and vendor reports relative to routine direct attempts that nobody writes up. A reader who estimates the split from the literature will systematically overstate the indirect share.

The responsible statement is therefore qualitative, and it is strong enough to act on: indirect injection is a primary, documented, and actively used route, it bypasses controls aimed only at the user prompt, and any agent that reads external content while holding tools or sensitive data must be designed on the assumption that some of that content is hostile.

What defenses address the retrieval path specifically?

The first defense is at ingestion: treat every retrieved source as untrusted by default, record its provenance, and transform it before it reaches the model. Stripping non rendered markup, comments, and metadata, normalizing unusual characters, and marking the boundary between system instructions and retrieved material all reduce the chance that planted text is read as a command. Microsoft Research's spotlighting techniques, which delimit, mark, or encode untrusted input, were reported to reduce attack success substantially on the test sets in that study (Microsoft Research, 2024).

The second defense is structural separation in planning. Designs in which a planning component works from the user instruction without ingesting untrusted content, while a separate component handles retrieved material with no authority to set goals, limit the ability of retrieved text to redirect the task. Instruction hierarchy training supports the same goal inside the model, but it should be treated as one layer, since published evaluations continue to find bypasses (OpenAI, 2024).

The third defense is privilege. OWASP guidance for both prompt injection and excessive agency points to least privilege, separation of functions, and human approval for sensitive actions (OWASP, 2025). If retrieved content steers an agent that can only read a limited set of records and cannot send, pay, delete, or change anything without approval, the injection has little to collect and nowhere consequential to go.

The fourth defense is output and action checking: validate tool arguments against the user's original task, check destinations against allow lists, and examine results for values that came only from retrieved content. The fifth is monitoring that preserves provenance, so an investigator can see which source was in context when an action was proposed.

Where does RedactSure sit?

RedactSure addresses the retrieval path at the point where the defenses above converge: what the model holds when a planted instruction reaches it. Supervised AI co-workers work an organization's applications inside a governed environment, with no per-application integration and no change to user permissions, and read screens only after policy selected values have been replaced by tokens at the render layer. Material carrying an injection reaches a model that holds tokens and task context, not real values; a successful injection collects SSN_001 and ACCT_001 (Prompt Injection When the Agent Sees Only Tokens).

The Planner sets which values are tokenized and what the agent may do on each screen; a named person confirms that policy before the run. A consequential action prompted by retrieved material still stops for that person under Supervised Delegation. Real values resolve only at approved destinations at the moment of an approved action. Every screen as tokens, every action and every approval lands in the AI Control Record and exports to the customer's SIEM. Keys stay with the customer, the model is swappable, and deployments are in pilot. Everyone else controls where data can go. RedactSure controls what the AI can see.

Methodology and limitations

The headline carries an 80 percent figure. That figure is an unverified premise taken from the question itself. No published measurement was supplied for it, and the sources reviewed do not publish a field wide percentage split between direct and indirect prompt injection. The figure is stated as unverified in the opening and here, and nowhere else on this page as a fact. The answer rests on what those sources establish: the definition and taxonomy of indirect injection, documented cases in research and in live telemetry, and published defenses. The sources are OWASP LLM01:2025 and LLM06:2025 (standards guidance), NIST AI 100-2e2023 (official guidance), Greshake et al. (preprint, also AISec 2023), Wallace et al. (OpenAI preprint), Hines et al. (Microsoft Research preprint), Debenedetti et al. (preprint) and the Palo Alto Networks Unit 42 telemetry report (industry analysis), read as of October 13, 2026.

The page is a literature synthesis. No attacks were counted, no telemetry was analyzed, and no product was tested for its resistance to injection. The defenses described are reported from the papers and guidance that proposed them; the reductions in attack success those authors measured on their own test sets do not transfer automatically to other models or configurations. Vendor features, model behavior and benchmark results change; the page carries its date. The inbox, knowledge base and screenshot examples describe classes of input, not any organization; no customer or prospect is described.

Whether a control meets an organization's requirements, and whether an incident involving retrieved content is reportable, belongs to its counsel, assessor, and security and compliance officers, not to the page.

What the record shows

The percentage in the headline cannot be defended, and it is not used as a finding. No source reviewed publishes a defensible split between direct and indirect prompt injection, so that share is unknown rather than large or small. What the evidence establishes is the channel: injections routinely arrive inside material a system retrieves or reads, web pages, documents, emails, tool outputs, records, and images, while the user's own request stays innocent. Defending only the prompt field therefore guards an entrance this class of attack does not use. The test for any agent that reads external content is one question: when a planted instruction steers it, what does the model hold and what can the agent do without a named person? If the answer is the full record and a tool that can send, pay or change something, the retrieval path is open.

Frequently asked questions

Is indirect injection more common than direct injection?

Nobody can responsibly say, on the published record. OWASP and the NIST taxonomy both treat indirect injection as a distinct and serious category, and peer reviewed work demonstrated it against real applications, but neither those sources nor any other located counts attacks across the field by entry point. Claims of an exact share, in either direction, go beyond the evidence. The category's existence and severity are documented; its proportion is not.

Where do injections that bypass the prompt actually hide?

In the material a system fetches while doing ordinary work for a user. The sources name web pages, documents, emails, tool outputs, database records, and images as carriers, and live telemetry has found payloads concealed in website markup aimed at agents that summarize or act on pages. The user types a normal request and never sees the instruction, which is why searching the prompt, or filtering what users type, never encounters this class of attack.

Can a strong system prompt stop retrieved injections?

Not on its own. A system prompt is another instruction inside the same context the payload enters, and the research shows models struggle to keep instruction and data apart when both arrive as text. Guidance therefore pairs any prompt level defense with structural controls: provenance marking for retrieved content, least privilege for tools, separation between reading and acting, and human approval for steps that move money, data, or records. The prompt can help; it cannot carry the boundary.

Does retrieval augmented generation make indirect injection worse?

It adds a source with internal authority. If an attacker can add or edit a document in a knowledge base, wiki, ticket history or shared drive, the planted instruction is retrieved again and again for many unrelated user questions, and it arrives looking like the organization's own material. Provenance recording, write controls on the corpus, and treating retrieved passages as untrusted input are the controls that address it.

Can an image or a screenshot carry a prompt injection?

Yes. Text rendered inside an image, a chart, a scanned form or a screenshot can carry an instruction that a text only review of the input would never show. Agents that take screenshots as a primary input read that text the same way they read a page. The same ingestion rule applies: the content was authored by someone other than the developer and the user, so it is material to describe, not material to act on.

What is the first control to add for an agent that reads external content?

Privilege and approval. If the agent can only read a limited set of records, and cannot send, pay, delete or change anything without a named person's approval, a successful injection has little to collect and nowhere consequential to go. Ingestion filtering and spotlighting reduce the number of injections that land; limiting what the agent holds and what it may do bounds the damage from the ones that do.

Book an AI Agent Security Review →

Bring your hardest questions.

Bring one sensitive workflow and the decisions your team needs to keep in its hands.

Book a demo

About the author

Christopher Sowa
Chris SowaCo-Founder, President and Chief Commercial Officer, RedactSure

Chris Sowa is a founder of RedactSure and a former CEO of an AI company; he started it years before ChatGPT existed. He previously led AI at Accenture, served as Global VP of Strategy & Innovation at Schneider Electric, was CCO of Sovos, and spent more than a decade at Oracle, with earlier roles at SAP and IBM.

Book a demo

Book a demo

Having trouble? Open the booking page or email us.