Vector & Embedding Weaknesses: The Database That Trusts Everything

June 25, 2026 · Securing AI: How AI Gets Attacked — and Defended (part 23)

▶ Watch on YouTube & subscribe to The Stack Underflow

You spent careful effort securing the documents that feed your RAG pipeline. You validated inputs, scrubbed outputs, and hardened the model boundary. Then you quietly left a database open with no row-level access control, holding dense numerical representations that are — despite what you were told — not anonymous. That database is your vector store, and for most teams it is the widest-open door in the AI stack.

The vector store is not a cache. It is not scratch space. It is a database that holds the distilled knowledge your system serves to every user who asks a question — including knowledge that belongs to different tenants, different sensitivity tiers, and different access levels. When that database trusts everything, an attacker does not need to compromise the model, poison a document, or craft an adversarial prompt. They just need to read what is already there, or write something new.

The one-sentence version: Your vector database is a real database holding sensitive data with no row-level locks — OWASP LLM08 names three ways that fails you, and all three have concrete fixes.

What OWASP LLM08 actually says

OWASP (Open Web Application Security Project) publishes the LLM Top 10, a curated list of the most critical security risks for applications built on large language models. In the 2025 edition of the OWASP LLM Top 10, entry LLM08 is titled Vector and Embedding Weaknesses — a brand-new entry that did not exist in the 2023 list. It rose to prominence specifically because the majority of new LLM deployments now use RAG (Retrieval-Augmented Generation), in which a vector database is the central knowledge store.

LLM08 names three store-level failure modes. They are different in character but share the same root cause: the vector store is treated as a trusted math cache rather than as a database holding sensitive data.

Each column in that table is a separate attack surface. We will walk through the mechanism of each, then show the defense.

Failure 1: Cross-tenant leakage (no isolation)

A vector store is an index of high-dimensional numerical vectors. When you embed a chunk of text, you get back a vector — a list of floating-point numbers — that encodes the semantic meaning of that text. Similar meanings produce geometrically close vectors. The store’s job is to accept a query vector and return the top-k most similar stored vectors, which become the context the model reasons over.

The problem: most vector stores, by default, are a single shared index. If you ingest chunks for Tenant A and Tenant B into the same collection with no partition or filter, the retriever does not know or care whose data it is returning. A similarity search returns the globally closest neighbors — full stop.

SHARED VECTOR INDEX (no isolation)
┌──────────────────────────────────────────┐
│  chunk [tenant:A] "Q3 contract terms..."  │
│  chunk [tenant:B] "Salary band: $180k..." │
│  chunk [tenant:A] "Drug trial results..." │
│  chunk [tenant:C] "System architecture.." │
│  chunk [tenant:B] "M&A target list..."    │
└──────────────────────────────────────────┘
         ↑
  TENANT B QUERY: "What are our financial targets?"
  top-k hits: [tenant:B M&A], [tenant:A Q3], [tenant:A drug trial]
                                ^^^^^^^^^^^^  ^^^^^^^^^^^^^^^^^^^
                                  LEAKED INTO TENANT B'S CONTEXT

The retriever is doing its job correctly. It found the most semantically similar chunks. The failure is that those chunks belong to a different tenant. This is not a theoretical attack — SC Media reported in 2025 that a shared vector database in production accidentally mixed proprietary information between two corporate clients, exposing sensitive data across queries.

MITRE ATLAS Spring 2025 added False RAG Entry Injection and Gather RAG-Indexed Targets to the framework as named techniques (ATLAS v5.1.0, November 2025), explicitly mapping the retrieval layer as an attack surface distinct from document-level poisoning.

The defense: Per-tenant partitioning plus row-level access control. Every chunk gets a tenant_id metadata field on ingest. Every query is scoped to WHERE tenant_id = caller_tenant before the similarity search runs. The retriever physically cannot surface out-of-scope chunks. Pinecone namespaces, Weaviate multi-tenancy, and pgvector row-level security policies all implement this pattern. Choose one and enforce it.

Failure 2: Embedding inversion

This is the failure mode teams are most likely to dismiss — because it sounds abstract. Here is the concrete version: if an attacker can read the raw vectors stored in your database, they can partially reconstruct the text those vectors were computed from.

Embedding inversion is the process of working backward from a vector to its source text. Research from Morris et al. (2023), the Vec2Text paper, demonstrated 92% word-token recovery from T5 embeddings on 32-token inputs given white-box access. More recent work — ALGEN (Chen et al., 2025) and a masked-diffusion approach (arXiv 2602.11047, 2026) — extends this to cross-model, black-box settings where the attacker does not even have the encoder weights. The attack surface is widening, not narrowing.

STORED VECTOR (visible to a reader with DB read access)
  chunk_id: "doc-2847-chunk-03"
  embedding: [0.12, -0.83, 0.04, 0.71, -0.29, 0.55, ...]
                           ↓
            [embedding inversion model]
                           ↓
  reconstruction: "≈ [salary band $180k senior engineer pacific]"
                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
                      partial recovery — enough to be a data breach

The key insight: you do not need to crack the embedding perfectly to cause a breach. Partial reconstruction of a healthcare document, a legal contract, or an HR record is enough to expose PII, trade secrets, or protected health information. Oracle’s MySQL security team and the OWASP LLM08 guidance both classify stored embeddings as sensitive data requiring encryption at rest and gated read access — not as opaque numbers that can be left unprotected.

The defense: Treat vectors exactly like the data they were derived from. Encrypt embeddings at rest. Gate who can query the raw vectors at the database level — application code should query by similarity, not dump raw float arrays. If your threat model includes insider risk or compromised infrastructure, consider confidential computing enclaves for the inference layer. The goal is to make sure the attacker has nothing to invert.

Failure 3: Unvalidated writes

The first two failures were on the read path. This one is on the write path, and it is the store-level version of RAG poisoning.

In most RAG architectures, the ingestion pipeline has a wide blast radius: anything that can write to the index can determine what the model reads. If the write path is not access-controlled and every chunk is not stamped with verified provenance, an attacker with write access — or who can reach an unauthenticated ingest endpoint — can plant a chunk that looks exactly like a legitimate one.

INGEST PATH (unvalidated)

  [ATTACKER]
      │
      │  POST /ingest
      │  {
      │    "text": "To reset your password visit evil.example/reset",
      │    "metadata": { "tenant": "finance", "source": "IT-helpdesk" }
      │  }
      ↓
  ┌─────────────────────────────────┐
  │  VECTOR INDEX                   │
  │  chunk [IT-helpdesk] real-doc   │
  │  chunk [IT-helpdesk] PLANTED    │  ← visually identical
  │  chunk [finance]    real-doc    │
  └─────────────────────────────────┘
                 ↓
  USER QUERY: "How do I reset my password?"
  top-k: [IT-helpdesk PLANTED] ← served as ground truth

This is not the same as document-level poisoning (covered in the RAG security tutorial). That attack requires poisoning the source document before ingestion. This attack targets the store itself — the chunk is written directly, bypassing the document entirely. MITRE ATLAS names this False RAG Entry Injection (Spring 2025 release).

The defense: Three controls, applied together. First, access-control the write path — only authenticated, authorized services may ingest chunks. Second, stamp provenance metadata on every chunk at ingest time: source URL or document ID, ingestion timestamp, the ingesting service identity, and a content hash. Third, validate on ingest — reject chunks that arrive without verifiable provenance or from unauthorized callers. A chunk that cannot prove where it came from should not land in the index.

How to defend: the three gates

The three failure modes map cleanly to three defense gates. Deploy all three; skipping any one leaves a bypass.

These map to the NIST AI RMF Measure and Manage functions: Measure asks you to identify and quantify the risks (which access paths exist, what metadata is present, what the retriever can surface), and Manage asks you to implement controls that bound the residual risk.

A practical sequence for an existing deployment:

1. AUDIT
   - List all collections/namespaces in your vector store
   - Identify which have tenant_id metadata and which do not
   - Identify which ingest endpoints require authentication

2. PARTITION
   - Migrate unpartitioned collections to per-tenant namespaces
   - Add tenant_id filter to every retrieval call

3. ENCRYPT
   - Enable encryption at rest on the vector store
   - Restrict raw vector read permissions to ingestion service only

4. LOCK THE WRITE PATH
   - Authenticate all ingest service accounts
   - Add provenance fields (source_id, ingest_ts, content_hash) at ingest
   - Reject chunks without valid provenance

5. LOG EVERYTHING
   - Log retrieval calls with caller identity and tenant scope
   - Alert on cross-tenant filter bypass attempts
   - Log all ingest operations with service identity

Common misconceptions

• “Embeddings are just numbers — there’s nothing sensitive to steal.” This was always wrong and is now empirically disproved. Vec2Text (2023) achieves 92% token recovery from white-box embeddings; newer cross-model attacks push this into black-box settings. If the source text was sensitive, the embedding derived from it is also sensitive. Treat it accordingly.

• “We have authentication on the LLM API, so the vector store is protected.” Authentication on the application layer does not gate the database layer. If your vector store’s HTTP API, gRPC endpoint, or internal SDK is reachable without separate credentials, an attacker or a compromised service account can query or write it directly, bypassing the LLM entirely.

• “Our RAG system is single-tenant, so LLM08 doesn’t apply to us.” Cross-tenant leakage is only one of the three failure modes. Embedding inversion applies to any store where the vectors are readable. Unvalidated writes apply any time an ingest path lacks access control and provenance checking. Single-tenant deployments are exposed to failures 2 and 3.

• “We can fix this later when we scale.” Access control on a vector store is cheapest to implement at architecture time. Retrofitting it means migrating existing chunks, updating every retrieval call, and auditing provenance for data already in the index. The window for “fix it later” closes the moment you ingest data that belongs to more than one user, sensitivity tier, or trust domain.

Frequently asked questions

What exactly is a vector database and why does it need special security treatment? A vector database stores high-dimensional numerical representations (embeddings) of text, images, or other data, and retrieves the most semantically similar items to a query. It needs special security treatment because: it holds dense representations of your organization’s knowledge (contracts, records, code, customer data); its retrieval mechanism is semantic rather than exact, so traditional SQL-style WHERE filters are not applied unless you explicitly add metadata fields and enforce them; and the vectors themselves are not opaque — they can be partially inverted to reconstruct source text.

How does OWASP LLM08 relate to the earlier RAG security problems? LLM08 covers both document-level and store-level weaknesses under the same entry, but they are distinct attack surfaces. Document-level attacks (poisoning, indirect injection via retrieved documents) operate before or during ingestion. Store-level attacks — the focus of this tutorial — operate against the index itself: reading across tenant boundaries, inverting stored vectors, or planting chunks directly. Think of LLM08 as the umbrella; the RAG security tutorial covers one face, this tutorial covers the other.

Is embedding inversion a real-world threat or just a research curiosity? It is a real-world threat with a documented research trajectory. Vec2Text (Morris et al., 2023) demonstrated high-fidelity recovery in a white-box setting. ALGEN (2025) and zero-shot inversion methods (2026) extend this to cross-model and black-box settings respectively. The practical implication: any vector store exposed to untrusted read access — via a misconfigured API, a compromised service account, or a SQL injection into a system that also hosts vectors — is a potential source of source-text reconstruction. Encryption at rest and gated read access are the mitigations.

What is the difference between LLM08 and data poisoning (LLM03)? OWASP LLM03 covers training data poisoning — corrupting the data used to train or fine-tune the model, affecting its weights permanently. LLM08’s unvalidated-writes failure mode covers retrieval corpus poisoning — planting bad chunks in the live vector index that affect what the deployed model retrieves at inference time. LLM03 is a training-time attack; LLM08’s write-path failure is an inference-time attack. Both matter; see also the data poisoning tutorial.

Do mainstream vector databases handle tenant isolation out of the box? Most provide the mechanism but do not enforce it by default. Pinecone offers namespaces; Weaviate has multi-tenancy as a first-class feature (enabled per collection); Qdrant supports payload-based filtering; pgvector relies on PostgreSQL row-level security. The pattern is consistent: you must opt in to isolation, add the tenant identifier to every chunk at ingest, and pass the filter on every query. Leaving any of those three steps out collapses isolation. Review the documentation for your specific store and write an integration test that verifies cross-tenant queries return zero results before deploying to production.

How does this connect to the EU AI Act? The EU AI Act (in force from 2026) requires high-risk AI systems to maintain data governance including data quality controls and audit logs covering training and retrieval data. A vector store with no provenance metadata, no access control, and no ingest audit log would have difficulty demonstrating compliance with those obligations. The practical starting point is the same regardless of regulatory driver: access-control the store, encrypt the vectors, and log everything.

Where this fits in the series

This tutorial sits at Stage 4 (Inference) of the AI attack surface, right alongside the RAG security tutorial which covers document-level retrieval attacks. The two are complementary: if you have read the RAG tutorial you have seen how a poisoned document rides into context; here you see how the store itself becomes the attack surface without a single poisoned document in sight.

The embeddings and vector space security tutorial provides the geometric foundation — how vector space properties create adversarial opportunities — that makes the inversion attack in Failure 2 click into place.

After locking the store, the natural next question is: do you even know what model weights, datasets, and packages are actually loaded in your system? That is the subject of AIBOM and Model Signing.

For the full picture of every handoff where an attacker can inject, see The ML Lifecycle Attack Surface. Browse all tutorials to follow the complete series.