There’s a pattern I keep seeing in security architecture reviews of enterprise AI systems. Teams spend a full afternoon debating prompt injection defenses, input validation strategies, and content moderation thresholds. Then someone asks about the document ingestion pipeline — the thing that feeds the retrieval system — and the room goes quiet. “That’s all internal data,” someone says. The conversation moves on.

That assumption is wrong, and research published over the past eighteen months has proven it, repeatedly, with numbers that are hard to dismiss.

RAG was supposed to fix the hallucination problem. Ground the model in real, verified documents, and it produces real, verified answers. That framing is accurate as far as it goes. But the security implication — that grounding an LLM in “trusted” documents makes the system more trustworthy — doesn’t follow. It introduces a new class of attack surface that most organizations aren’t testing at all.

What a RAG Pipeline Actually Looks Like

Before talking about attack surfaces, it helps to be precise about what we’re analyzing. A production RAG pipeline isn’t one thing — it’s a sequence of distinct components, each with its own trust boundary and its own failure mode under adversarial pressure.

The trust inversion at the bottom of that diagram is the root cause of most RAG vulnerabilities. User inputs get sanitized, rate-limited, flagged by classifiers. Retrieved context — the documents the system selects and drops directly into the prompt — gets treated as trusted. This isn’t a bug in any single implementation. It’s an architectural assumption baked into how RAG was designed.

Attack Surface 1: Knowledge Base Poisoning

This is where the most consequential research is happening right now, and the numbers are genuinely alarming.

PoisonedRAG, presented at USENIX Security 2025 by researchers at Pennsylvania State University and the Illinois Institute of Technology, demonstrated something that should change how you think about knowledge base security. Five carefully crafted documents injected into a knowledge base containing millions of texts can corrupt AI responses for targeted queries with a 90% attack success rate. Not in a toy environment — across real benchmark datasets, evaluated against multiple LLMs.

The attack works because retrieval systems are fundamentally similarity-matching engines. If an attacker can craft a document that scores highly on semantic similarity to a target query, it gets surfaced in the top-k results. From there, the LLM processes it as authoritative context. The attack doesn’t need access to the model, the vector database credentials, or any part of the inference infrastructure. It only needs a write path to the knowledge source.

That write path is often much wider than teams realize. Public web crawlers, Confluence integrations, Slack channel scrapers, automated document ingestion from email — every one of these is a potential injection surface. One practical attack pattern that doesn’t require any sophisticated tooling: briefly edit a Wikipedia article, public documentation page, or GitHub README with poisoned content. If the RAG pipeline ingests that source on a scheduled crawl, the poisoned version enters the vector database. Even after the source edit is reverted, the poisoned embedding persists until the next full re-indexing, which in most organizations happens weekly or monthly.

Attack Surface 2: Indirect Prompt Injection Through Retrieval

Prompt injection via direct user input is well-understood at this point. Teams build classifiers for it, apply guardrails, monitor for suspicious patterns. What’s genuinely harder to defend is the indirect variant — where malicious instructions arrive not from the user but from documents the RAG system retrieves and presents as trusted context.

The OWASP GenAI Top 10 lists this as LLM01:2025 — the highest-priority vulnerability class — explicitly noting that RAG and fine-tuning do not eliminate the risk. The reason it’s so persistent: the model has no reliable way to distinguish between “instructions from the system operator” and “text retrieved from a document that happens to contain instructions.”

The attack chain is straightforward to execute. An attacker places malicious instructions in any content that the RAG pipeline might ingest: public web pages, forum posts, PDF attachments in a help desk ticket, GitHub README files, email bodies. The instructions are written in natural language to blend into surrounding content. When a user query triggers retrieval of that content, the LLM processes the attacker’s instructions as part of its authorized context and executes them.

In August 2025, attackers demonstrated this against development environments by implanting hidden instructions in public GitHub README files. When developers used AI coding assistants to summarize those repositories, the assistants unwittingly executed the embedded commands. The distinction between “summarize this document” and “execute these instructions embedded in this document” turns out to be quite blurry from the model’s perspective.

HijackRAG: When the Retriever Itself Becomes the Weapon

HijackRAG (arXiv 2410.22832) goes a step further. Instead of relying on a single injection point, it structures the attack as an optimization problem: craft a document that simultaneously (1) scores highly on retrieval similarity for the target query, and (2) contains instructions that reliably steer the LLM toward an attacker-chosen response. The researchers tested black-box and white-box attack variants across LLaMA2, LLaMA3, and ChatGLM3, on Natural Questions, HotpotQA, and MS-MARCO datasets.

Peak ASR: 97% on HotpotQA with LLaMA3. Across other combinations, consistently above 80–90%. More concerning: the attack transfers across different retriever models. You can’t mitigate it by swapping out your embedding model. The researchers tested paraphrasing defenses and top-k expansion, finding neither meaningfully reduced success rates — with top-k increased to 50, attack effectiveness remained stable.

Attack Surface 3: Embedding Model and Vector Database

The 2025 revision of the OWASP Top 10 for LLM Applications introduced LLM08:2025 — Vector and Embedding Weaknesses as a new entry. This is worth pausing on. The OWASP list isn’t revised frequently. Adding a new category specifically for the retrieval infrastructure is a signal that the security community recognizes this as a distinct problem class, not a variation of existing issues.

The attack vectors here operate at a level that most application security teams don’t currently reason about. Because retrieval is based on continuous vector embeddings, an attacker can optimize input sequences — analogous to adversarial examples in computer vision — to manipulate which documents get surfaced for which queries. You don’t need to inject documents into the knowledge base directly. You can craft query inputs that, due to properties of the embedding space, consistently retrieve documents that wouldn’t otherwise rank highly.

This connects to a broader problem: the most common enterprise RAG vulnerability in practice isn’t a sophisticated algorithmic attack. It’s inadequate access control on the vector database itself. Vector databases frequently run with overly permissive write access, no authN on query endpoints, or both. Organizations that would never expose a SQL database without authentication regularly deploy vector databases with effectively open write permissions on internal networks, assuming network perimeter controls are sufficient.

The CVE Registry: Confirmed RAG Vulnerabilities, 2025–2026

This isn’t theoretical risk. The CVE database now has an accumulating record of concrete, exploitable RAG pipeline vulnerabilities. The table below covers confirmed disclosures with public documentation.

The LangChain figure is worth dwelling on. LangChain Core has hundreds of millions of package installs globally. A CVSS 9.3 serialization flaw in an orchestration framework that underpins a significant fraction of production RAG deployments represents supply chain risk at scale. Organizations that patched their application logic but didn’t update framework dependencies remained exposed for months after the disclosure.

Attack Surface 4: The Data Loader Pipeline

Document parsing is where a lot of teams’ mental model of the attack surface breaks down. PDFs, Word documents, HTML pages, Slack exports — all of these require parsing libraries that are processing untrusted content before it reaches the embedding stage. Research on RAG data loaders found a 74% poisoning success rate against implementations that fail to sanitize inputs from documents and PDFs, enabling hidden injections that survive into the vector database.

The attack surface here is broader than most teams account for. Hidden text in PDFs. Metadata fields in Office documents. Comments in HTML. Speaker notes in PowerPoint files — which is exactly what EchoLeak exploited against M365 Copilot. The AI processes everything the parser extracts, including content that a human reader would never see. Standard content security tools scan for malware signatures. They don’t flag natural language instructions embedded in document metadata.

Attack Surface Taxonomy: Severity and Defensive Coverage

Research confidence labels: ESTABLISHED = confirmed in peer-reviewed research or production exploit; PROBABLE = demonstrated in controlled conditions, production evidence limited; SPECULATIVE = theorized with formal modeling, limited empirical data.

What Could Be Wrong With the Current Threat Model

Attack Surface 5: The Multi-Tenant SaaS Problem

Enterprise SaaS products that use RAG — AI-powered support platforms, knowledge management tools, coding assistants — face an attack surface that single-tenant deployments don’t: cross-tenant data leakage via the shared vector space. If retrieval logic doesn’t rigorously enforce tenant isolation at query time, a carefully crafted query from Tenant A might surface documents indexed from Tenant B’s knowledge base.

This isn’t a theoretical concern. The failure mode is documented in security assessments of enterprise RAG architectures, and it’s architecturally subtle. Tenant isolation enforced at the application layer doesn’t automatically propagate to the vector database query layer. Organizations building on top of vector database platforms need to verify that their metadata filtering is enforced at query execution time, not just at ingestion.

The cost estimate for a cross-tenant retrieval breach in a SaaS environment goes beyond the technical impact. Depending on what’s in the exposed knowledge base — customer PII, contractual documents, proprietary IP — a single retrieval boundary failure can constitute a data breach under GDPR, triggering notification obligations and regulatory scrutiny that dwarf the cost of the defensive architecture that would have prevented it.

Defense Architecture: What Actually Works

The honest answer is that no single control is sufficient. The research record on this is consistent: paraphrasing, top-k expansion, and existing prompt injection classifiers have all been tested against PoisonedRAG and HijackRAG and found inadequate. This doesn’t mean defense is impossible — it means defense requires architectural changes, not just guardrails bolted on at the output layer.

At the Ingestion Layer

• Cryptographic provenance tracking on every ingested document. Every chunk in the vector database should carry a verifiable hash and source attestation. Unsigned or unverifiable sources should fail ingestion, not silently enter the knowledge base.
• Strip and separately log all metadata, comments, hidden text, and speaker notes from documents before embedding. These fields should not enter the retrieval context without explicit review.
• Restrict write access to the ingestion pipeline. Only authorized processes — not ad-hoc scripts or development shortcuts — should be able to modify the knowledge base. Audit logs on all writes, treated with the same seriousness as database write logs.

At the Retrieval Layer

• Retrieve context and track provenance — surface sources alongside results in the final output, or at minimum in internal logs. If you can’t tell the system which documents it retrieved for a given query, you can’t audit it.
• Anomaly detection on retrieval patterns. A document that suddenly appears in top-k results for queries where it previously didn’t rank is a signal worth investigating. Most organizations log zero retrieval telemetry today.
• Enforce tenant isolation at the vector database query layer, not only at the application layer. Test it explicitly with cross-tenant query attempts in your security regression suite.

At the Generation Layer

• Prompt partitioning — keeping system instructions, user inputs, and retrieved context in structurally distinct positions in the prompt, with explicit labeling of trust levels. This is an emerging pattern; no standard implementation exists yet, but the EchoLeak post-mortem paper at arXiv 2509.10540 outlines the approach.
• Monitor output for anomalies: Markdown image references to external domains, unexpected URL constructions, content that includes data from outside the user’s stated query scope.
• Least-privilege access for the AI agent. Copilot’s ability to retrieve from the entirety of a user’s email history, SharePoint, Teams, and OneDrive simultaneously is what made EchoLeak’s exfiltration scope so broad. Limit what the retrieval system can access to what the task actually requires.

At the Dependency Layer

• Run dependency scanners against your orchestration framework — LangChain, LlamaIndex, or whatever you’re using. CVE-2025-68664 (LangChain, CVSS 9.3) affected hundreds of millions of installed packages. These frameworks release security patches, but they don’t automatically propagate to production deployments.
• Subscribe to security advisories for every library in your RAG stack. This is basic supply chain hygiene that’s still not standard practice in AI engineering teams.

Red Team Checklist: Testing Your Own Pipeline

If you operate a RAG-powered application in production, these are the tests you should be running — and probably aren’t. Tools like Promptfoo and Garak support RAG-specific test scenarios.

The Optimistic View — And Why It’s Warranted

There’s a genuine reason for optimism here, though it’s different from the kind security vendors tend to sell. RAG security is a young field. OWASP LLM08:2025 is less than a year old. The first formal threat model for RAG systems was published in September 2025 by researchers at the University of South Florida. The first zero-click production exploit — EchoLeak — was discovered and patched in the same year it was found, with coordinated disclosure and no evidence of exploitation in the wild.

The research community is ahead of the attacker community on this, for now. PoisonedRAG and HijackRAG are published because the researchers wanted defenders to understand the risk — the CVE process, the OWASP categorization, the vendor patch coordination — all of this is working. The window between research disclosure and production exploitation isn’t closed, but it’s being monitored.

What would make me more optimistic: standardized retrieval security testing frameworks that security teams can actually run without deep ML expertise. The gap between what research teams can test and what production security teams can operationalize is still wide. The tools exist in prototype form; adoption is the challenge.

A Note on Scope

My analysis here draws on B2B enterprise deployments — primarily large organizations in US and EU markets, where I’ve seen RAG systems in production contexts. Consumer-facing RAG deployments, smaller organizations, and markets outside this scope may face different risk profiles. The attack research is generally model-agnostic, but the organizational context — access control complexity, data sensitivity, and incident response capability — varies significantly. I haven’t tested these techniques at scale in environments outside B2B enterprise. No sponsorship disclosure: none of the tools or frameworks mentioned here are ones I have a commercial relationship with.