Safeguard
AI Security•

OWASP LLM08 vector and embedding weaknesses: a checklist for leads

LLM08 covers how vectors and embeddings are generated, stored and retrieved in RAG systems. Review access, sources, tenancy, logging and behavior.

Safeguard Security Team
5 min read

OWASP LLM08:2025 is about the retrieval layer of an AI application: how vectors and embeddings are generated, stored and fetched. If any of those steps lets the wrong person, or the wrong document, into the model's context, the model can leak data or repeat poisoned content. Review five areas: access, sources, tenancy, logging and behavior.

The OWASP entry defines the risk as weaknesses that can be exploited, intentionally or not, to inject harmful content, manipulate model outputs or reach sensitive information. It applies to any system using retrieval augmented generation, where a model is combined with an external knowledge source.

Why is this different from prompt injection?

Prompt injection is about what the model is told. LLM08 is about what the model is given. A retrieval system pulls text from a store and puts it in front of the model as trusted context. If that store contains something an attacker or an accident put there, or something the current user should never see, the model has no way to know.

The checklist

Access

  • Does the vector store enforce permissions at query time, per user or per group, and not only at the application layer?
  • Is each document's access level stored with its embedding, so a search cannot return content the asker could not open directly?
  • Can an administrator list who can read which collection, and has anyone reviewed that list this quarter?

OWASP recommends fine-grained, permission-aware vector and embedding stores, with strict logical partitioning of datasets between user classes.

Sources

  • Is there a written list of approved sources for the knowledge base?
  • Does ingestion validate documents before they are embedded, and does it reject content from unverified providers?
  • Do you extract text with a tool that ignores visual formatting, so hidden or invisible text surfaces during review instead of reaching the model unseen?
  • Who can add a document, and is that logged?

OWASP's own poisoning example is a résumé containing hidden text that tells the model what to recommend. The listed mitigation is text extraction that detects hidden content, plus validation of every document before it enters the knowledge base.

Tenancy

  • If several customers or teams share one vector database, is there a hard partition, such as separate indexes or enforced filters that cannot be omitted by a caller?
  • Have you tested that a query from tenant A cannot return a chunk from tenant B, including through near-duplicate content?
  • Are federated sources reviewed when they disagree? OWASP names conflicting data from multiple sources as its own failure mode.

Logging

  • Do you keep detailed logs of retrieval activity: who asked, which chunks came back, and from which source?
  • Are those logs immutable enough to be useful after an incident?
  • Does someone look at them, or is there an alert on unusual retrieval patterns?

OWASP calls for detailed immutable logs of retrieval to detect and respond to suspicious behavior.

Behavior

  • Have you compared the model's answers with and without retrieval on a fixed set of questions?
  • Do you track whether retrieval changes tone, completeness or refusal behavior in ways your product owner would object to?

OWASP notes that retrieval can alter foundational model behavior. Its example is an answer that becomes more factual and loses empathy. Whether that matters depends on your product, but someone should be deciding.

What about embedding inversion?

OWASP lists embedding inversion as a risk: an attacker who can reach embeddings may recover significant source information from them. The practical takeaway for a lead is that embeddings are not anonymized data. Treat them with the same access controls and retention rules as the source text, including deletion when the source is deleted.

What to do

  1. Draw the data flow from source document to chunk to embedding to retrieval to prompt. Mark where permissions are checked.
  2. Close any gap where the check happens only in the application and not in the store.
  3. Write the approved-source list and the ingestion validation steps. Assign an owner.
  4. Run a cross-tenant test and a hidden-text test as part of your release checks.
  5. Turn on retrieval logging and decide who reviews it and how often.
  6. Apply deletion to embeddings when you delete source records, and test that it works.

Quick check

Are embeddings safe to store without access controls because they are just numbers?

No. OWASP lists embedding inversion as a way to recover source information, so protect embeddings like the text they came from.

Is a permission check in the chat application enough?

It is a start, but OWASP recommends permission-aware stores and partitioning of the datasets themselves, so a bug in one layer does not expose everything.

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.