documented real-world prompt injection attacks against RAG-based enterprise tools

Documented attacks against RAG-based enterprise tools all trace back to one design choice: the system treats retrieved content with the same authority as its own instructions.

Why RAG Systems Treat Retrieved Content as Instructions

Traditional software keeps data and code in separate lanes. A database query and the text typed into a search box don't get to swap roles. SQL injection became famous precisely because it broke that separation, letting user input get executed as a command. Retrieval-augmented generation has the same kind of failure built into its foundation, not as a bug that slipped through testing, but as how the architecture works.

A RAG pipeline pulls in uploaded files, web pages, emails, database records, and third-party documentation, and drops all of it directly into the same context window the model reads as its instruction set. The model has no separate channel for "things a stranger wrote" versus "things the system told me to do." Cyberbit's analysis of LLM and RAG attacks makes the point directly: once RAG is in place, every document the retriever fetches on the user's behalf can steer the model, not just the user's prompt. Each new data source added to the pipeline expands the attack surface.

Agentic RAG systems raise the stakes further. Each step in an iterative retrieval loop is a fresh chance for the agent to run into injected content, and these agents are built to act on what they find: sending emails, calling APIs, editing records. A static RAG system that just answers questions is one kind of risk. An agent empowered to take action based on what it retrieves turns that same flaw into something with real consequences.

Enterprise platforms that run continuous monitoring on vendor AI deployments, Promptarmor among them, treat this boundary as a first-order risk, both during pre-deployment review and in ongoing use.

From Planted Content to Executed Instruction

The attack follows a pattern simple enough to describe in three steps, and the victim's own query is what sets it off.

First, plant. An attacker places malicious instructions somewhere the RAG system will eventually read: a public Slack channel, a crafted email, a support ticket, a KYC document, an entry in a knowledge base. None of this requires breaking in anywhere. It just requires writing to a place the system already trusts.

Second, retrieve. Some ordinary user, with no idea anything is wrong, asks a normal question. The retriever pulls the poisoned content into the context window right alongside the user's query and the system prompt.

Third, execute. The model, trained from the ground up to follow instructions found in its input, reads the injected text as a directive rather than as data to summarize or quote. It can't reliably tell system instructions apart from retrieved content, so it acts on what it finds. Cyberbit's analysis notes that this often stays invisible at the interface: the assistant looks like it's answering the question normally, even as it carries out someone else's instructions.

None of this needs access to model internals, a backend compromise, or malware of any kind. It only needs the ability to influence one data source the system reads from.

Attackers have also learned to scale this up. "RAG spraying" means injecting the same malicious prompt into many documents or emails at once, improving the odds that at least one copy lands in a target's retrieval context during some ordinary, legitimate query. The EchoLeak case below demonstrates this technique.

Some defenders assume retrieval filters or reranking will catch an adversarial document before it ever reaches the model. Adversarial edits can lower a document's odds of being retrieved in controlled lab tests, but confirmed enterprise CVEs tell a different story: wherever retrieval does surface attacker content in production, the impact has been severe, and the filtering assumption hasn't held up in practice.

The invisibility of this attack at the UI level, where the assistant looks like it's behaving normally while executing someone else's instructions, is why real-time visibility into RAG data sources matters so much. A single query can trigger retrieval of poisoned content with no warning sign the user would ever notice. Risk teams tracking vendor AI deployments need ongoing monitoring of which documents, emails, and knowledge-base entries have been added or changed.

OWASP and CrowdStrike's Threat Data on the Attack's Real-World Reach

Prompt injection against RAG and agentic systems is no longer just a research curiosity. It's confirmed, scaled, and running against production systems at real companies.

VentureBeat's reporting on the OWASP LLM Top 10 (2025) notes that prompt injection holds the LLM01 spot for the second edition running. That ranking reflects something simple: large language models still can't reliably tell instructions apart from data, across deployment after deployment.

CrowdStrike's Global Threat Report found threat actors injecting malicious prompts into legitimate generative AI tools at real organizations throughout 2025, using those injections to generate commands that stole credentials and cryptocurrency, in the report's own phrasing: "Prompts are the new malware."

The scale of damage from one compromised agent doesn't match a compromised human account. Obsidian Security's analysis points out that AI agents move far more data than people do, so a single compromised agent is a high-magnitude exposure event on its own. An agent with access to Salesforce, M365, and Workday simultaneously exposes the effective authority of every permission it holds across all connected systems.

As prompt injection climbs the OWASP list for a second year running and CrowdStrike documents active threat actors weaponizing RAG and agentic systems in production, the gap between theoretical risk and demonstrated attack surface has narrowed. That shift is what makes AI-specific third-party risk assessment, rather than generic compliance checklists, the baseline control for any enterprise deploying vendor AI tools at scale. The cases below show what that gap looks like up close.

Slack AI, August 2024: how a public channel became an exfiltration path for private data

Slack AI gives the clearest early proof that RAG's trust boundary failure isn't theoretical. An attacker with zero access to private channels could plant instructions, and Slack AI would leak private content to anyone who happened to ask the right question.

PromptArmor disclosed the vulnerability in August 2024. The attack starts with an attacker posting malicious instructions in a public Slack channel, which Slack AI then ingests into its RAG pipeline. When a victim later queries Slack AI, the injected instruction causes the model to render a markdown link, with private-channel content, including API keys pulled from developer direct messages, encoded right into the URL's query string.

What made this possible was Slack AI's default configuration: user queries could retrieve from both public and private channels, including public channels the querying user had never even joined. Slack itself described that behavior as intended. Reporting from The Register, along with PromptArmor's own disclosure, confirms Salesforce patched the private-channel variant of the attack, while the public-channel surface remained, still classified by Salesforce as intended behavior.

That "intended behavior" label deserves attention, because the ServiceNow case later uses the same defense against a far more serious finding.

Architecturally, the Slack case strips the attack down to its simplest form: no malware, no stolen credentials, no access to anything private. Just the ability to write to a public channel that the RAG system trusted exactly as much as everything else it read.

PromptArmor's disclosure also doubles as a model for how vendor risk assessment should work in practice. The incident turned on one configuration choice, retrieving from both public and private channels by default, that had to be identified and flagged before an injected instruction could ever weaponize it. That's the kind of AI-specific third-party risk management work that catches a misconfiguration before it scales into a full data exfiltration incident.

EchoLeak (CVE-2025-32711), June 2025: zero-click exfiltration from Microsoft 365 Copilot at CVSS 9.3

EchoLeak marks the first documented case of indirect prompt injection weaponized for confirmed data exfiltration from a production AI system, with no user interaction required at all. It shows the same trust-boundary flaw from the Slack case scaling up to cover the entire Microsoft 365 data estate.

Aim Security (Aim Labs) disclosed EchoLeak in June 2025. A separate arXiv paper from September 2025, by Pavan Reddy and Aditya Sanjay Gujral of George Washington University, analyzed it independently. The flaw was assigned CVE-2025-32711 and rated critical at CVSS 9.3. It affected Copilot integrations across Word, Excel, PowerPoint, Outlook, and Teams, the full M365 surface.

The attack chain starts with a single crafted email containing hidden prompt instructions. Copilot retrieves that email into its RAG context during some ordinary, legitimate query, and the injected instructions direct it to pull chat logs, OneDrive files, SharePoint content, or Teams messages, then transmit them to a server the attacker controls. No user action beyond simply receiving the email was needed for the exfiltration to happen.

What separates EchoLeak from a routine injection finding is the chain of four distinct bypasses stacked on top of each other: evading Microsoft's cross-prompt injection attack classifier, getting around link redaction, using auto-fetched images to open an outbound data channel, and escaping Content Security Policy through an allowlisted Teams image proxy. The attackers also used RAG spraying here: they injected the same prompt into multiple emails or documents so one would land in Copilot's context during a real query, without needing to target any specific person.

VentureBeat's reporting confirms that Microsoft patched the vulnerability server-side and found no evidence it was exploited in the wild. The researchers' own conclusion reaches further than one patch: EchoLeak exposes a structural flaw in how AI assistant architectures trust context, and similar risks will keep appearing in other LLM applications built the same way.

That four-bypass chain carries a lesson for anyone building defenses. Filtering and classification controls can be layered one on top of another, but an attacker who maps each control individually can chain a way around all of them. Patching one bypass, even a well-built one, doesn't touch the underlying trust model that made the chain possible in the first place.

ServiceNow Now Assist, 2025–2026: second-order injection and BodySnatcher (CVE-2025-12420) in a default-on enterprise agent

The ServiceNow cases add a new wrinkle: indirect prompt injection traveling through an enterprise's own internal workflows, not just arriving through inbound attacker content. They also confirm that vendors classifying dangerous AI behavior as "intended" is a pattern, not a one-off response.

In November 2025, researchers disclosed second-order injection: a low-privileged user embeds malicious instructions inside a support ticket, and when a more powerful, benign agent later processes that ticket, the injected text recruits it into exfiltrating data, escalating privileges, or sending emails that carry sensitive information, even with prompt injection protections already turned on for that agent. ServiceNow's response framed the behaviors researchers identified as intentional design choices, the same "intended behavior" defense Slack used over a year earlier.

Then, in January 2026, came BodySnatcher: CVE-2025-12420, CVSS 9.3. The flaw chained two separate failures: a hardcoded static secret shared across every ServiceNow instance, and an auto-linking mechanism that matched external users to internal accounts using nothing but an email address. The result let unauthenticated attackers impersonate any ServiceNow user with just their email, bypassing MFA and SSO entirely, then run privileged AI workflows and create backdoor administrator accounts.

Now Assist requires licensing and activation rather than arriving switched on for every account. Every customer running the affected Now Assist AI Agents and Virtual Agent API components was at risk until ServiceNow patched the majority of hosted instances on October 30, 2025.

Taken together, the two disclosures show that the injection surface is not limited to external content arriving by email or document upload; it includes any content flowing through an internal workflow that an agent with elevated privileges will eventually process. Second-order injection works by exploiting the trust a more powerful agent places in content a less powerful one produced.

KYC pipeline and automotive RAG chatbot: how the same flaw appears in purpose-built enterprise applications

The trust failure behind Slack, EchoLeak, and ServiceNow also appears, independently, in purpose-built enterprise RAG applications built for entirely different jobs. That repetition confirms the flaw belongs to the design pattern itself, not to any one vendor's particular implementation.

At [un]prompted 2026, Sean Park demonstrated a KYC pipeline attack: a passport image carried malicious instructions hidden in its text layer, and the AI field-extraction agent processed the OCR output without telling passport data apart from attacker instructions. The agent's whole job was reading fields off a document. It had no way to tell that some of what it read was not data.

Jason Haddix documented a separate case at OWASP Global AppSec USA 2025, involving an automotive company's RAG chatbot. System prompt extraction succeeded across a meaningful share of real enterprise AI assessments, and in this specific instance, the extraction revealed Jira and Confluence API keys hardcoded directly into the system prompt.

One reads passports. The other answers customer questions about cars. The flaw appeared in both tools because it was never about what the tool does. It's about how RAG decides what to trust once it reads something.