OWASP LLM08 Vector and Embedding Weaknesses Guide

LLM08 Vector and Embedding Weaknesses is the OWASP entry that turns a retrieval augmented generation (RAG) store from a search convenience into an access control, integrity and privacy boundary that most teams have not yet assessed as one. This guide reads LLM08:2025 as a requirement set: what its risks and mitigations demand, how to test them, what evidence to expect, and how it maps to NIST SP 800-53, NIST CSF 2.0, ISO/IEC 27001:2022, CIS Controls and MITRE ATLAS. It is for AppSec leads, AI platform owners and auditors. The engineering detail of hardening a RAG pipeline lives in the RAG Security Guide and the retrieval patterns in the Permission-Aware RAG Guide; this page links to them rather than repeating them.

Key takeaways

LLM08 is a 2025 addition aimed squarely at RAG. OWASP scopes it to weaknesses in how vectors and embeddings are generated, stored or retrieved, and lists five risks and four mitigation areas you can assess one by one.
Retrieval is an authorisation decision. The first and most testable requirement is permission-aware retrieval with strict logical and access partitioning, enforced on the server for every query.
Vectors inherit the sensitivity of their source. Published inversion research recovers a large share of input text from sentence embeddings, so an embedding store holding HR or customer data is HR or customer data.
The knowledge base is an input channel. Anyone who can write to an indexed source can influence answers, which makes source authentication, document validation and write-access review part of LLM08 compliance.
Evidence matters more than intent. An assessor should see a store inventory, partitioning tests run as users with different entitlements, ingestion validation results and immutable retrieval logs, not just a design diagram.

What it is and who it applies to

LLM08:2025 Vector and Embedding Weaknesses is the eighth entry in the OWASP Top 10 for LLM Applications 2025, published by the OWASP GenAI Security Project. The official text describes weaknesses in how vectors and embeddings "are generated, stored, or retrieved" that can be exploited, intentionally or not, to inject harmful content, manipulate model outputs or access sensitive information. It was new in the 2025 edition. For the full list and how LLM08 relates to the other nine risks, see the OWASP Top 10 for LLM Applications Guide.

LLM08 applies to any system where an LLM receives context that was selected by similarity search over embeddings. In practice that includes:

Enterprise assistants and copilots: tools that index SharePoint, Google Drive, Confluence, ticketing or mail and answer staff questions. See the Enterprise AI Copilot Security Guide.
Multi-tenant SaaS with AI features: products that store many customers' embeddings in one vector database or index.
Agents with memory or retrieval tools: agents that write to and read from a vector store between sessions. See the AI Agent Memory Security Guide.
Screening pipelines: systems that index external documents (CVs, claims, leads) for an LLM to assess.

LLM02 covers private data reaching a response, LLM04 training data poisoning and LLM01 the instructions a poisoned chunk may carry; LLM08 is the vector layer between them. See the OWASP LLM Top 10 LLM02 Sensitive Information Disclosure Guide and the Prompt Injection Guide.

Structure and key requirements

The entry has five risks, four mitigation strategies and three attack scenarios. Each risk should trace to a mitigation and a test.

The five risks and what each demands

OWASP risk	What goes wrong	Requirement it implies	How to test it
1. Unauthorized access and data leakage	Misaligned access controls let retrieval return embeddings and chunks holding personal, proprietary or licensed content to people who should not see it	Retrieval filtered by the requester's entitlements; licensed and regulated content tagged and excluded where use is not permitted	Run the same query as two users with different source permissions and compare the chunk IDs returned
2. Cross-context leaks and federation knowledge conflict	Users or applications sharing one vector database see each other's context; sources that contradict each other, or stale model knowledge, produce wrong answers	Logical and access partitioning per tenant, user class or application; source precedence rules when data is combined	Tenant A queries for a canary string planted only in tenant B; conflicting-source test set with an expected answer
3. Embedding inversion	An attacker with access to vectors reconstructs significant amounts of the source text	Vectors classified and protected at the level of their source; no export of embeddings outside the trust boundary	Review who and what can read raw vectors (API keys, backups, analytics exports, snapshots)
4. Data poisoning	Malicious or simply wrong content from insiders, prompts, data seeding or unverified providers changes outputs	Trusted, authenticated sources only; validation of documents before indexing; integrity audit of the knowledge base	Submit a labelled test document with hidden text through each ingestion path and confirm it is flagged or quarantined
5. Behaviour alteration	Augmentation shifts the model's behaviour, for example answers become factually correct but lose empathy	Evaluation of response quality before and after retrieval changes	Regression suite with qualitative criteria run on every index or prompt change

OWASP's own sources for risk 3 are research papers rather than incidents. Song and Raghunathan (2020) recovered roughly 50 to 70 percent of input words from popular sentence embeddings. Li, Xu and Song (2023) went further with a generative attack, GEIA, that reconstructs coherent whole sentences. Treat vectors as derived source data, not anonymised data.

The four mitigation areas as control objectives

Permission and access control: OWASP asks for fine-grained access controls, permission-aware vector and embedding stores, and strict logical and access partitioning between user classes and groups. The objective is that no query can retrieve a chunk its requester could not open at the source.
Data validation and source authentication: robust validation pipelines for knowledge sources, regular audits of knowledge base integrity for hidden codes and poisoning, and acceptance of data only from trusted and verified sources. The CV scenario adds a specific requirement: text extraction that ignores formatting and detects hidden content.
Data review for combination and classification: review combined datasets, and tag and classify data in the knowledge base to control access levels and prevent data mismatch. Classification labels are what make partitioning enforceable. See the Data Classification Guide.
Monitoring and logging: detailed, immutable logs of retrieval activity so that suspicious behaviour can be detected and investigated.

Choosing a partitioning model

Partitioning is where most design decisions sit. Vendor documentation shows the options are not equivalent:

Model	Example mechanism	Isolation strength	Choose it when	Watch for
Separate store or index per tenant or sensitivity tier	Dedicated database, cluster or index	Strongest; separate credentials possible	Regulated data, few large tenants, contractual isolation commitments	Cost and operational overhead as tenants grow
Namespace or collection per tenant	Pinecone namespaces, which Pinecone describes as physical isolation of tenant data; per-tenant offboarding by deleting the namespace	Strong at the data layer if the application selects the namespace server side	Multi-tenant SaaS with many tenants	Namespace chosen from a client-supplied value
Shared store with metadata or ACL filters	Azure AI Search security filter using `search.in` over a `Collection(Edm.String)` field set filterable and not retrievable; PostgreSQL row level security on a pgvector table	Depends entirely on correct, server-side filter construction	Per-user document permissions inside one organisation	Microsoft notes the principal is "just a string" and the service does not authenticate the caller; the filter must be on every query
Live query with delegated identity	Assistant queries the source at request time with the user's token	Always current, inherits source authorisation	Sources with good native search and fast permission changes	Latency, and sources whose search APIs are weak

Small organisations running one internal assistant can usually meet risk 1 with source-side permission clean-up plus a single shared index using ACL filters or native document-level access, provided it is tested. Large or multi-tenant organisations should not rely on a shared index for tenant separation: use namespaces or separate stores for tenants, and filters only for user-level permissions within a tenant. Pinecone itself flags filtering on large lists of individual user IDs as an anti-pattern and limits $in and $nin to 10,000 values each, which is a hint that per-user lists belong in groups. The pattern-by-pattern engineering trade-offs are in the Permission-Aware RAG Guide.

Identity and NHI requirements

Every LLM08 control depends on two identities being right: the non-human identity that writes into the store, and the identity on whose behalf the store is read.

Indexing connectors are privileged NHIs: the service account or app registration that crawls sources usually holds read access far wider than any user. Give each connector its own identity, read-only, scoped to the sources it indexes, and keep its credentials in a vault or replace them with workload identity. See the AI Infrastructure Workload Identity Guide.
Separate write and read rights on the store: the ingestion identity writes; the query service reads; neither should hold administrative rights. A single admin API key shared by both breaks poisoning and inversion controls at once.
Database owners bypass row filters: PostgreSQL documents that superusers and roles with BYPASSRLS always bypass row level security, and table owners do too unless ALTER TABLE ... FORCE ROW LEVEL SECURITY is set. If the application connects to a pgvector table as its owner, the RLS policy you are relying on may not apply.
The requester identity must come from the session, not the prompt: group and user IDs used in filters must be resolved server side from an authenticated token. Accepting them from the client or from model output reduces the filter to a suggestion.
Agents use the intersection of permissions: an agent retrieving for a user should see only what both the user and the agent's own scope permit, and must not carry one user's retrieved chunks into another user's session. See the AI Agent Authorisation Guide and the OAuth Token Exchange and Delegation Guide.
Writers to indexed sources are part of the attack surface: a public web form, inbound mailbox or shared drive feeding the index lets outsiders write into it. In the SalesBleed Salesforce Agentforce 2026 case, records submitted through a public Web-to-Lead form were later read by an agent as ordinary business data.

Implementation steps

Run steps 3 and 4 in monitor mode first, and keep each change reversible.

Inventory stores and sources. List every vector database, search index and embedding cache, the sources feeding each, the ingestion identity, the query identity, tenancy model, backups and snapshots, and where embeddings are exported (analytics, evaluation sets).
Classify and tag. Apply a sensitivity label and an owner to each source and propagate both onto every chunk as metadata, alongside source ID, ACL, ingestion time and content hash. Hold back the most sensitive sources until step 3 is verified.
Enforce partitioning and permission-aware retrieval. Pick the partitioning model from the table above. Build filters server side from the authenticated session, deny by default when entitlements cannot be resolved, and make permission and delete changes at the source reach the index within a defined time.
Validate ingestion. Normalise documents before chunking, strip or flag hidden text (white-on-white, zero-size fonts, invisible Unicode), require authenticated sources, and route external or low-trust content to a quarantine index until it passes review. Pilot with alerts only, then enforce.
Protect the vectors. Require authentication and TLS on the store, encrypt at rest including snapshots, restrict raw vector reads to the query service, and include vectors in deletion and retention processes.
Log and evaluate. Write immutable retrieval logs (requester, agent, query hash, chunk IDs, source IDs, filter applied) to a store the application cannot alter. Add a regression suite covering access, poisoning canaries and response quality, and run it on every index, embedding model or prompt change.
Plan rollback. Version the index so a poisoned or mis-permissioned build can be replaced by the last known good version, and keep a switch that disables retrieval from a given source without redeploying the application. Test the rollback once before go-live.

The pipeline-level controls behind steps 4 to 6, such as trust-weighted ranking and grounding checks, are covered in the RAG Security Guide.

Evidence and assessment

What an assessor should request:

Mitigation area	Evidence to request	Good looks like	Red flag
Permission and access control	Store inventory, tenancy model, filter code path, results of multi-user retrieval tests	Filters built from the session token server side; tests run as at least three entitlement levels and a second tenant	Tenant or group ID taken from the request body; no negative tests
Data validation and source authentication	Ingestion pipeline description, list of sources and their writers, hidden-text test results, quarantine records	Every source has an owner and known writers; test documents are flagged	Public forms or shared mailboxes indexed without isolation
Combination and classification	Classification scheme, chunk metadata sample, source precedence rules	Every chunk carries label, source and ACL; conflicts resolved by documented precedence	Chunks with no source or label; merged datasets never reviewed
Monitoring and logging	Sample retrieval log, log integrity controls, SOC use cases	Logs include requester and chunk IDs, are append-only, and feed detections	Only prompts and responses are logged, not what was retrieved
Embedding protection	Store access list, backup and export locations, deletion procedure	Vectors handled at source classification, erased with the source	Vectors treated as anonymous and copied to analytics freely

Detection signals and metrics

Signals to alert on: retrieval of chunks whose ACL does not include the requester (should be zero if filtering works, so any hit is critical); a single source dominating results for unrelated queries, which the live EchoLeak 2025 research achieved by spreading one payload across many topics; bulk similarity queries or raw vector reads from an identity other than the query service; spikes in new documents from external sources.
Cross-tenant canary hit rate: target zero across scheduled runs.
Chunk provenance completeness: percentage of chunks with source ID, label and ACL; target 100 percent.
Permission propagation latency: time from a source permission or delete change to the index reflecting it, against a stated objective such as one hour.
Ingestion validation coverage: share of sources whose documents pass hidden-content and authenticity checks before indexing.
Retrieval log coverage: share of LLM requests with a retrieval log entry.

Mapping to other frameworks

LLM08 area	MITRE ATLAS	NIST SP 800-53 Rev. 5	NIST CSF 2.0	ISO/IEC 27001:2022 Annex A	CIS Controls v8.1
Unauthorised access, cross-context leaks	AML.T0064 Gather RAG-Indexed Targets; AML.T0057 LLM Data Leakage	AC-3 Access Enforcement; AC-4 Information Flow Enforcement; AC-6 Least Privilege	PR.AA-05	5.15 Access control; 8.3 Information access restriction	Control 3 Data Protection; Control 6 Access Control Management
Embedding inversion	None specific; nearest is AML.T0024.001 Invert AI Model, which targets models rather than stored vectors	SC-28 Protection of Information at Rest; AC-6	PR.DS-01	8.24 Use of cryptography; 5.12 Classification of information	Control 3
Data poisoning	AML.T0070 RAG Poisoning; AML.T0071 False RAG Entry Injection; AML.T0066 Retrieval Content Crafting; AML.T0051.001 Indirect prompt injection	SI-7 Software, Firmware, and Information Integrity; SI-10 Information Input Validation	PR.DS-01; PR.DS-10	8.26 Application security requirements	Control 16 Application Software Security
Combination and classification	None specific	RA-3 Risk Assessment; AC-4	PR.DS-01	5.12 Classification of information; 5.13 Labelling of information	Control 3
Monitoring and logging	None specific	AU-2 Event Logging; AU-9 Protection of Audit Information	DE.CM-09	8.15 Logging; 8.16 Monitoring activities	Control 8 Audit Log Management

NIST AI 600-1, the Generative AI Profile, places these concerns under its Data Privacy, Information Integrity and Information Security risks, and suggested action MS-2.5-005 asks organisations to verify that fine-tuning or RAG data is grounded. OWASP ASVS 5.0 requirement V8.2.2 (data-specific access restricted to consumers with explicit permissions) is a useful verification line for the retrieval API. See the NIST AI 600-1 Generative AI Profile Guide.

Common pitfalls

Filtering in the client or the prompt: asking the model to "only use documents the user can see", or letting the front end pass group IDs, fails the first LLM08 mitigation outright.
One shared admin key for ingest and query: a quick-start configuration reaches production, and anyone with the key can read every vector and write poisoned chunks.
Deletes that never reach the index: a document removed or re-permissioned at source stays retrievable from chunks, caches and snapshots. ConfusedPilot researchers reported that the effect of a malicious document could persist after it was deleted.
Treating inbound records as internal: CVs, emails, tickets and web form leads are written by outsiders.
Owner connections bypassing RLS: an application role that owns its pgvector tables silently skips row level security unless FORCE is set.
Logging prompts but not retrieval: without chunk and source IDs in logs, a leak or poisoning event cannot be scoped, and the fourth mitigation is not met.

Practitioner checklist

Inventory every vector store, index and embedding export with its sources, identities and tenancy model.
Classify sources and carry label, owner, source ID and ACL onto every chunk.
Enforce retrieval filters server side from the authenticated session and fail closed.
Separate tenants with namespaces or separate stores, not shared metadata filters alone.
Give ingestion and query their own scoped identities and remove shared admin keys.
Detect hidden content and authenticate sources before indexing; quarantine external material.
Protect and erase vectors at the classification of their source, including snapshots.
Keep immutable retrieval logs with chunk IDs and feed them to detection.
Run multi-user, cross-tenant and poisoning canary tests on every index or model change.
Version indexes and rehearse rollback to the last known good build.

OWASP LLM Top 10 LLM08 Vector and Embedding Weaknesses Guide: Securing RAG Stores