Safeguard
AI Security•

LLM08 vector and embedding weaknesses, explained with a RAG example

OWASP LLM08 covers leaks, poisoning and inversion in RAG systems. A hiring screen scenario from OWASP shows the risk and the controls that reduce it.

Safeguard Security Team
4 min read

OWASP LLM08, vector and embedding weaknesses, covers the ways retrieval augmented generation (RAG) can leak data, accept poisoned content, or return what a user should not see. The fix is the same discipline as any data system: control who can read, validate what goes in, and keep logs of what comes out.

What is a RAG system and where is the weak point?

RAG improves a model's answers by retrieving relevant text from a knowledge base at question time. Text is converted into vectors (embeddings), stored in a vector database, and matched to the question. OWASP says weaknesses in how vectors and embeddings are generated, stored or retrieved can be exploited to inject harmful content, manipulate outputs or access sensitive information.

The weak point is rarely the math. It is the pipeline around it: who can add documents, how they are checked, and who is allowed to retrieve them.

A walk through an OWASP scenario

OWASP describes this scenario in its LLM08 entry. We present it as an illustration from OWASP, not as a reported incident we have verified.

A company uses RAG to screen job applications. Applicants upload resumes, which are processed into the knowledge base. Someone submits a resume that contains text invisible to a human reader, such as white text on a white background, written to influence the model. The system extracts and stores that text along with the visible content. Later, when someone asks about the candidate, the model retrieves the hidden text and may follow it, so an unqualified candidate looks qualified.

Nothing was "hacked" in the traditional sense. The system accepted untrusted content into a trusted knowledge base and treated retrieved text as if it were trustworthy. OWASP's suggested mitigation is to use text extraction that ignores formatting and detects hidden content, and to validate all input documents before they enter the knowledge base.

The other risks in the entry

Unauthorized access and leakage. If access controls on the vector store are loose, the model can retrieve and disclose personal or proprietary data.

Cross context leaks. In multi tenant systems where groups share one vector database, one group's embeddings can be retrieved for another group's query. OWASP's mitigation is a permission aware vector database with strict logical partitioning.

Embedding inversion. OWASP notes attackers may be able to recover significant source information from embeddings, so treat stored vectors as sensitive as the text.

Data poisoning. Poisoned data can come from insiders, prompts, data seeding or unverified providers.

Behavior alteration. Retrieval can change the model's tone or emphasis in ways you did not intend, such as reducing empathy in support answers.

What the controls look like in practice

OWASP lists four groups of mitigation: permission and access control, data validation and source authentication, review and classification when combining data, and monitoring with detailed immutable logs of retrieval. In practice that means:

  • Attach access labels to every chunk and filter at query time using the asker's identity, not the model's.
  • Accept data only from sources you can name, and record the source on each document.
  • Classify data before combining sources, so restricted content does not mix with general content.
  • Log which chunks were retrieved for each answer so you can reconstruct a bad one.

What to do

  1. Inventory every knowledge base your AI features read from and who can write to each.
  2. Enforce per user or per group access at retrieval time, and test it with a user who should see nothing.
  3. Validate documents before ingestion, including extraction that surfaces hidden or formatted away text.
  4. Store source, owner and ingestion date on every document.
  5. Separate tenants logically, or physically where the data demands it.
  6. Log retrieval events immutably and review samples regularly.
  7. Treat embeddings as sensitive data in your retention and encryption policies.
  8. Record knowledge sources in your AI bill of materials.

Quick check

Are embeddings safe to store because they are just numbers?

No. OWASP notes embedding inversion can recover source information, so protect vectors like the data they came from.

Does a bigger model fix this?

No. The weakness sits in the data pipeline and access control, not in model size.

Sources

Last reviewed: 18 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.