Treat embeddings as sensitive as the text they came from. OWASP lists embedding inversion as a risk in LLM08:2025, where attackers reverse embeddings to recover much of the original source information. A vector store that holds personal or proprietary data needs the same access controls, retention and encryption decisions as the source.
The common mistake
Teams often say "we only store vectors, not the documents", as if numbers were anonymous. Vector stores usually keep the chunk text and metadata next to the vector, which makes this moot. Even where they do not, OWASP names inversion as a confidentiality threat in its list of common risks.
How much can be recovered depends on the embedding model and the attacker's access, so no single figure applies to every system. Plan for the worst case.
What follows from that
Classify the index by the most sensitive thing in it. If one source is regulated, the whole shared index inherits that sensitivity unless you separate it. That is one reason to partition data by access level, as OWASP recommends.
Apply the same access controls. Who can query the store, who can export vectors, who can read backups. Treat an export of vectors like an export of the source documents.
Apply the same retention rules. If a document must be deleted on request, its chunks and vectors must go too. Check that deletion reaches the store, replicas and backups.
Think about third parties. If you send text to an external embedding service, that service sees the text. Review that provider as you would any processor of the same data. Do not assume the vendor's terms from a general summary; read them.
Encrypt at rest and in transit. This is basic, but vector databases are often stood up quickly with defaults.
Questions for a design review
- What is the most sensitive source feeding this index?
- Can any user, service or admin export vectors in bulk?
- Is the embedding model hosted by someone else?
- Does deleting a source delete its vectors?
- Do backups follow the same retention rules?
- Is retrieval logged, as OWASP advises?
If you answer "I don't know" to two or more, you are not ready to put regulated data in the index.
A related risk: cross-context leaks
OWASP also describes leaks between users in multi-tenant stores and knowledge conflicts between sources. Inversion is about what an attacker can do with the vectors. Cross-context leaks are about what your own retrieval returns to the wrong person. You need to address both. The permission-aware retrieval guide covers the second.
Quick check
If I only store vectors and not text, am I safe?
Not by that fact alone. OWASP lists inversion as a way to recover source information from embeddings, so treat vectors as sensitive.
Do I need a separate store for each sensitivity level?
Often it is the simplest way to keep access rules clean. Logical partitioning with strict filters is the alternative, with more risk of a missed filter.
Sources
Last reviewed: 19 October 2026.
