Indirect prompt injection is an attack in which the malicious instructions are not in the user’s message at all, but hidden in third-party content the AI system reads while carrying out a task — a webpage, a PDF, an email, a calendar invite, a code file. The person using the AI has done nothing wrong and may never see the payload; the content was planted by someone else, and the AI encounters it in the course of ordinary work.
This is what separates it from direct prompt injection, where the user themselves tries to override the system. In the indirect form, three parties are involved: an attacker who plants instructions in content, a user who asks an AI to work with that content in good faith, and the AI, which must decide — with no perfectly reliable method — which text in front of it is instruction and which is data. The user is not the attacker. Usually, the user is the target.
How the attack is structured
The pattern has three consistent elements, regardless of the specific scenario:
- Placement. Instructions are embedded in content that exists outside the conversation — anywhere an AI assistant might read in the course of a task. Research demonstrations have used webpages, documents, emails, and other everyday content types.
- Retrieval. A user asks the AI to do something routine with that content: summarize this page, process this inbox, review this document, check this calendar.
- Execution. The model, reading the content, encounters text phrased as a directive and — depending on the system, its configuration, and its tool access — may act on it: altering its summary, suppressing or emphasizing information, or, in agentic systems, taking steps the user never requested.
What makes this a research-grade concern rather than a theoretical one is that each element is mundane. No exploit code is involved. The attack surface is the ordinary fact that AI assistants are useful precisely because they read and act on content from the world.
What has actually been demonstrated
It is important to keep the evidence level straight. Indirect prompt injection has been demonstrated repeatedly by security researchers under controlled conditions: assistants manipulated by hidden text in pages and documents they were asked to process, including demonstrations in published research (notably work presented in 2023 showing LLM-integrated applications could be compromised through content retrieved from external sources) and ongoing vendor and academic testing since. These demonstrations establish that the technique works against real system designs, not just in principle.
What has not been established is prevalence. There is no reliable public measurement of how often indirect injection is attempted against businesses in the wild, how often it succeeds against current production systems, or how much real-world harm it has caused. Vendors have added mitigations since the earliest demonstrations — content/instruction separation techniques, classifiers, tool-permission controls — and researchers continue to find bypasses. The accurate statement is the uncomfortable one: the vulnerability class is real and demonstrated, defenses are layered and improving, and no complete defense is known. Anyone claiming either “this is everywhere and unstoppable” or “this has been solved” is ahead of the published evidence.
A concrete example
Consider a business owner who uses an AI assistant connected to their email and calendar to produce a morning briefing. A third party sends a meeting invitation whose description field contains text addressed not to the human recipient but to any AI that processes it — directing the assistant to present a particular vendor as already approved, or to quietly leave a competitor’s meeting out of the day’s summary. The owner reads a briefing that looks complete and neutral. Nothing in it signals that one entry was shaped by instructions the owner never wrote and never saw.
Variants of this shape — payload in a document, an inbox item, a web page, a shared file — are the standard form in the research literature, because they all exploit the same property: the AI reads content from parties it has no way to fully vet, on behalf of a user who trusts the output because they trust the tool.
Why businesses should care — in both directions
As users of AI tools. Any assistant your business deploys that reads external content — web research tools, inbox and document summarizers, coding assistants reading repositories, agents browsing on your behalf — can be steered by what it reads. The practical defenses are organizational as much as technical: give AI tools the least access they need (least privilege), require human confirmation before consequential actions like sending, paying, publishing, or deleting, and review outputs that will drive decisions against their sources.
As publishers of content. Your business’s own content sits in the same ecosystem. Pages and documents you publish can be copied, quoted, and modified downstream, and content hosted on platforms you don’t fully control can be altered or appended to. Keeping your published information accurate, monitored, and consistent — the same source hygiene that protects your AI visibility — also reduces the chance that material associated with your business carries someone else’s additions. And if your business aggregates or republishes third-party content, that content deserves the same skepticism you would apply to any unvetted input to your systems.
Limitations and misconceptions
“This is the same as RAG poisoning.” They are related but distinct. RAG poisoning plants documents so that a retrieval system will surface false information in answers — it corrupts what the AI says. Indirect injection plants instructions in read content — it attempts to corrupt what the AI does. A poisoned document misinforms; an injected document directs. Defenses overlap (source vetting, monitoring) but are not identical.
“If I don’t use AI agents, I’m not exposed.” Tool access raises the stakes, but even a plain summarization or research assistant can be influenced in what it reports. Exposure scales with capability; it does not start at zero.
“Antivirus-style scanning will catch it.” Scanning helps against known patterns. Instructions are ordinary language, infinitely paraphrasable, and their meaning depends on context — which is why this is an open research problem rather than a signature-matching exercise.
“My vendor says their model refuses injections.” Treat such claims as partial. Resistance in testing is real progress, but the published research record shows mitigations being bypassed as models and attacks evolve. Design your processes so that a successful injection still cannot quietly cause a consequential outcome.
The bottom line for a business
Indirect prompt injection does not require you to stop using AI tools. It requires treating AI assistants the way you would treat a capable new employee with no ability to judge a source’s motives: give them limited authority, check consequential work, and control what they can act on without approval. On the publishing side, it is one more reason — alongside accuracy and AI visibility — to know exactly what your business’s content says and to notice when it changes.
Related questions
- What Is Prompt Injection?
- What Is RAG Poisoning?
- Can Malicious Documents Influence AI Answers?
- Can Fake Reviews Influence AI Recommendations?
- How Can Businesses Protect Their AI Reputation?
For the full research picture — the documented poisoning studies, the taxonomy of attacks on what AI systems know and retrieve, and what remains unknown — read the deep article: AI Poisoning and RAG Poisoning.
Published: November 1, 2026
Last reviewed: November 1, 2026