Sensitive Data and Vector Weaknesses: What OWASP's LLM02 and LLM08 Actually Cover
Part 2 of 6 in a series going through the OWASP LLM Top 10 one category at a time — this time: what leaks, and where it lives
Part 1 of this series covered LLM01: Prompt Injection. This post covers two categories together, because they describe the same underlying problem from two different angles: what a RAG system exposes, and where that exposure actually lives — in the vector store itself.
LLM02: Sensitive Information Disclosure
Per the official OWASP entry, sensitive information disclosure covers a broader category than “the model leaked a password.” OWASP’s own scope includes personal identifiable information, financial details, health records, confidential business data, security credentials, legal documents, and — for closed or foundation models — proprietary training methods and source code.
The document frames this as a two-directional problem. Sensitive data can leak out through a model’s output, or it can be absorbed in through training or fine-tuning on data that shouldn’t have been included in the first place. Different failure modes, different fixes.
Three named patterns, one with real precedent. OWASP lists PII leakage (personal data disclosed during ordinary use, no attack required), proprietary algorithm exposure, and sensitive business data disclosure. For the second one, OWASP anchors to a concrete precedent: the “Proof Pudding” attack (CVE-2019-20634), where disclosed training data let attackers reconstruct and invert a model, then use that reconstruction to bypass the email spam filter the model was meant to enforce. It’s an older, non-LLM-specific case, but it’s the hard technical precedent the category is built on.
OWASP also points to the ChatGPT/Samsung incident as real-world context: employees pasted proprietary source code into ChatGPT, which then became part of what the model could potentially surface elsewhere. Nobody injected anything. Someone just typed confidential code into a chat box. That’s the clearest illustration that this category isn’t purely an attack category — it’s often just a usage category.
Mitigations read like general data-protection hygiene: sanitize inputs before they reach training data, enforce least-privilege access to sensitive data, use privacy-preserving techniques like federated learning and differential privacy, educate users not to paste sensitive information into a chat box, and keep the system prompt concealed from override or extraction. None of this is exotic if you’ve done data protection work before LLMs existed. The novelty is that a conversational interface makes it easy to forget these protections still apply.
LLM08: Vector and Embedding Weaknesses
This is the newest and most RAG-specific category in the entire OWASP list, added in the 2025 edition specifically because RAG had become the dominant deployment pattern. Where LLM02 is about sensitive data in general, LLM08 is about the mechanism — the vector store itself — that makes a RAG-specific version of that leakage possible.
Per the official entry, the core risk is that inadequate or misaligned access controls on embeddings can let a model retrieve and disclose personal data, proprietary information, or sensitive content it technically has stored but was never supposed to surface to a given user.
Three specific failure patterns are named:
Multi-tenant context leakage. When multiple users or applications share the same vector database, there’s a real risk that one tenant’s query surfaces another tenant’s data. This is the same access-boundary problem as any shared-infrastructure system, just applied to embeddings instead of rows in a SQL table.
Embedding inversion. Attackers can exploit vulnerabilities to invert embeddings and recover meaningful amounts of the original source information — turning a vector that was supposed to be an opaque numerical representation back into readable content. This directly undermines the assumption that embeddings are a “safe,” anonymized form of the original data.
Data poisoning. Poisoned data can enter a vector store intentionally (a malicious actor) or unintentionally (a bad upstream data source), manipulating what the system retrieves and, downstream, what it tells users. This overlaps with the corpus-poisoning territory from Part 1’s coverage of LLM01, but the framing here is about data integrity in storage, not injection through retrieval.
How this differs from prompt injection, concretely: prompt injection targets model instructions directly. LLM08 attacks manipulate the data layer the model retrieves and implicitly trusts — often without touching a prompt at all. That distinction matters operationally: your defenses against one don’t automatically cover the other.
A practical mitigation worth naming specifically: for multi-tenant leakage, one straightforward fix is separating data into per-tenant collections or indexes at the vector-store level — the same idea, at the infrastructure layer, as row-level security in a traditional database. If you’re building a RAG system that serves more than one customer or user group from a shared corpus, this is the first thing to check, not an afterthought.
What This Means If You’re Building RAG
The pattern connecting LLM02 and LLM08 to each other, and back to Part 1’s coverage of LLM01, is the same each time: what you ingest is what you’re exposed to, and the exposure surface isn’t just the model’s output — it’s every layer of the pipeline that stores, indexes, or retrieves that data. A RAG system that ingests contracts, internal wikis, support tickets, or medical records is doing exactly what these two categories warn about, by design. The question isn’t whether that data is exposed somewhere in the system. It’s whether you’ve deliberately controlled who can retrieve it, and whether the storage layer itself — not just the chat interface — enforces that control.