Your embeddings are not anonymous: the vector-store exposure problem compliance teams are missing, examined in technical-depth

Most compliance teams treat vector stores as "already anonymized" because the data inside looks like arrays of floating-point numbers. This is wrong. The technical-depth of recent inversion research shows that embeddings can be reversed to recover names, emails, clinical notes, and addresses with startling fidelity. Worse, the infrastructure layer has its own problems: deletion often does not mean deletion, encryption is frequently absent, and the regulatory clock is ticking. If your organization runs a vector database (and 64% of AI-adopting organizations now do), this piece is for you.

Key Takeaways

• Embedding inversion attacks can recover 92% of short text inputs exactly, and over 89% of full names from clinical notes, per award-winning 2023 research. Newer zero-shot attacks from 2025 and 2026 push this further without needing any leaked training pairs.
• Vector database deletion is frequently a soft operation at the metadata level: "ghost vectors" from soft-deleted records can still be reconstructed with 99% identity accuracy, undermining GDPR right-to-erasure workflows.
• Between 87% and 98% of AI workloads across major cloud providers lack customer-managed encryption, and exposed vector database instances have been found containing PII, credentials, and medical records in the clear.
• Adding noise to embeddings degrades utility faster than it degrades attack performance. No mature, off-the-shelf defense exists today.
• If the source data falls under GDPR, HIPAA, or PCI-DSS, the embedding vectors do too. Regulators will not accept "but it's just floats" as a defense.

Can embeddings really be reversed to recover the original text?

Yes. The foundational result here is the 2023 Cornell Tech paper "Text Embeddings Reveal (Almost) As Much As Text," which won the Outstanding Paper Award at EMNLP 2023. The researchers developed a multi-step attack called Vec2Text that iteratively corrects and re-embeds candidate texts until they converge on the original. On 32-token inputs, Vec2Text recovered 92% of texts exactly. When pointed at clinical notes, it retrieved 94% of first names, 95% of last names, and 89% of full names. The researchers' conclusion was flat: text embeddings and raw data expose comparable amounts of sensitive information and should be treated with equal precautions.

That was 2023. The attack surface has only expanded since then.

What about newer attacks that don't need leaked data?

They work too, and they need less. Follow-on research in 2024 found that adversarial-decoding approaches can recover named entities and sensitive details at rates above 80% even when only a tiny set of embedding-text pairs is available, or none at all in zero-shot settings. By 2025 and 2026, methods like BeamClean and Zero2Text represent a meaningful escalation: they adapt on-the-fly and remain effective even under noise conditions that would have thwarted earlier approaches. The trend line is clear. Each generation of attack requires fewer assumptions and less auxiliary data.

Are some embedding architectures more resistant than others?

There is some nuance here, and we should be honest about it. A 2026 study found that encoders using token pooling (producing multiple embeddings per input rather than collapsing to a single vector) appear to be structurally more resistant to inversion than the single-vector encoders most commonly deployed in production RAG pipelines. This complicates the blanket claim that all embeddings reveal as much as text. But most production vector stores today use single-vector encoders, so the practical exposure for the median deployment remains high.

Why doesn't adding noise to embeddings fix this?

Because the privacy/utility tradeoff is brutal. Adding Gaussian or Laplacian noise to embedding vectors can reduce inversion fidelity, but only at the cost of significant utility degradation for the downstream tasks that justified building the vector store in the first place. A February 2026 paper on concept-aware privacy mechanisms notes that existing differential privacy defenses assume uniform sensitivity across embedding dimensions, leading to excessive noise and degraded utility. In practice, you have to set the privacy budget so strictly that the embeddings become useless for retrieval.

And even if you accept the utility loss, modern adaptive attacks route around it. Zero2Text and BeamClean were specifically designed to remain effective under strong noise conditions. Noise is a speed bump, not a wall.

No mature, off-the-shelf fix exists today. That's the honest state of the field. Researchers are working on it. Production teams should not assume the problem is solved.

What does "delete" actually mean in a vector database?

Less than you think. A 2026 paper on "ghost vectors" examined how popular HNSW-based vector databases implement deletion and found something compliance teams need to hear: deletion is typically a soft operation at the metadata level, preserving the graph structure for performance reasons. The underlying vector data may persist indefinitely. In the researchers' tests, soft-deleted facial image embeddings could still be recovered with 99% top-1 identity accuracy.

Think about what this means for a GDPR Article 17 erasure request. A data subject asks you to delete their data. Your application layer marks the record as deleted. Your DPO signs off. But the vector, which we just established can be reversed to recover names and clinical details, is still physically present in the index and still reconstructible. Your right-to-erasure workflow is, in a meaningful technical sense, lying to your Data Protection Officer.

This is not a theoretical concern. It is a concrete audit finding waiting to happen.

How exposed are production vector databases right now?

Badly. Orca Security's 2026 State of AI Security Report, based on telemetry from over 1,200 production organizations, found that 64% of AI-adopting organizations now run vector databases. Between 87% and 98% of AI workloads across the three major cloud providers lack customer-managed encryption.

In earlier hands-on research, Orca's security team scanned for exposed vector database instances and found multiple exposed instances across several platforms. The contents were not just embeddings. They included PII, credentials, medical records, biometric data, and internal system secrets. Stored alongside the vectors or retrievable from them, the distinction barely matters.

The picture is: most vector databases in production are not encrypted with customer-managed keys, many are directly exposed, and the data inside can be reversed. This is not a future risk. It is a current condition.

Do compliance frameworks actually cover embeddings?

Yes, and the logic is straightforward. If the source data is subject to GDPR, HIPAA, or PCI-DSS, a mathematical transformation of that data does not change the regulatory classification. Storing PII, PHI, or financial data as embeddings does not reduce the compliance obligations for those vectors. The embedding is derived from regulated data. It can be reversed to approximate that data. It is regulated data.

This matters especially now because of regulatory timing. The EU AI Act's high-risk obligations begin August 2, 2026. Colorado's amended AI law takes effect January 1, 2027. Compliance teams that have been categorizing vector stores as "derived, non-personal data" will need to reclassify, and the reclassification has downstream consequences for access controls, retention policies, encryption requirements, and erasure procedures.

Why is the insider access angle more important than the breach angle?

Most coverage of embedding inversion frames it as an external attacker problem: someone breaches your vector store, downloads the embeddings, and reverses them. That threat is real. But the more common and less-examined exposure is simpler. An engineer with legitimate read access to the vector store has effective read access to approximations of the underlying text. This is rarely modeled as a risk because the data looks like arrays of numbers, not records.

Consider the access patterns in a typical RAG deployment. DevOps engineers can query the vector store for debugging. Data engineers run bulk operations for reindexing. ML engineers evaluate retrieval quality by inspecting nearest-neighbor results. All of these roles have read access to embeddings that, with a publicly available inversion model, can be turned back into something resembling the original text. None of these roles would typically be granted read access to the source data (medical records, financial documents, HR files) through normal access control policies.

The vector store is a side channel around your existing access controls. Not because of a vulnerability. Because of architecture.

What should you actually do about this?

We will not pretend there is a clean, single-step fix. There is not. But there are concrete architectural decisions that reduce exposure now and position you well for the regulatory changes coming in 2026 and 2027.

How do you apply data minimization before embedding?

Strip PII before it enters the embedding pipeline. This sounds obvious, but the typical RAG architecture ingests documents whole, chunks them, and embeds the chunks. If those chunks contain names, email addresses, Social Security numbers, or clinical identifiers, all of that is now encoded in your vectors. Running a PII detection and redaction step between chunking and embedding (several tools now target this exact step) is the single highest-leverage change most teams can make. It does not eliminate the inversion risk, but it limits what an inversion can recover.

How should you handle encryption for vector stores?

Use customer-managed encryption keys. The Orca data showing 87-98% of AI workloads lacking this is genuinely alarming. Vendor-managed keys mean the vendor (or anyone who compromises the vendor) can decrypt. Customer-managed keys mean you control the key lifecycle. This is table stakes for any data store containing regulated information, and your vector store contains regulated information.

For context on how we think about this at Selina: memory is encrypted at rest, but we are clear that memory is NOT end-to-end encrypted, because a slice of each request reaches a frontier provider at inference. Files and transfers via SelinaSEND are end-to-end encrypted. We draw this distinction deliberately. Calling something end-to-end encrypted when it is not would be the kind of thing that sounds good in marketing and falls apart in an audit. We would rather state the honest limit.

How do you make deletion actually delete?

This is harder than it should be. Given that HNSW-based vector databases implement deletion as soft deletion by design, you need to verify that your specific database and version actually purge vectors from the underlying storage, not just from the index metadata. Some databases support compaction or vacuum operations that physically remove soft-deleted data. Others do not. You need to test this empirically: delete a record, run compaction, then attempt to recover the vector from a storage-level dump. If you can still find it, your erasure workflow does not satisfy Article 17.

If your vector database cannot provide provable physical erasure, you may need to treat it as a cache with a bounded retention window and rebuild the index periodically from source (with the deleted records actually excluded). This is operationally expensive. It is also, for some regulated workloads, the only defensible approach.

What access controls belong on a vector store?

The same ones you would put on the source data. If the source documents are classified as confidential, the vector store derived from them should inherit that classification. Role-based access should be scoped to the minimum necessary. Query logs should be retained and auditable. Bulk export should require elevated authorization. The vector store is not a lower-sensitivity copy of your data. It is a differently-encoded copy, and as we have established, the encoding is reversible.

What is the "encrypt-before-embed" bug class?

We have seen this pattern in production, and it is subtle enough to deserve its own section. The idea seems sound on first pass: encrypt the text, then embed the encrypted text, so that even if someone inverts the embedding they only recover ciphertext. The problem is that embedding models operate on semantic content. Encrypted text has no semantic content. The resulting embeddings are nonsensical for retrieval purposes. Your search quality drops to near-random.

Teams discover this quickly and revert to embedding plaintext, but sometimes only partially. We have seen configurations where some chunks are embedded from plaintext and others from encrypted text, producing a vector store that is both insecure (the plaintext-derived vectors) and non-functional (the ciphertext-derived vectors). It is a bug class that hides in plain sight because the system does not crash. It just silently returns poor results for some queries and leaks data on others.

The correct order of operations is: redact sensitive fields, then embed the redacted text, then encrypt the resulting vectors at rest with customer-managed keys. Encryption protects storage. Redaction protects the semantic content. They solve different problems and neither substitutes for the other.

How should compliance teams reclassify their vector stores?

Start with a data inventory that includes vector stores. Most data mapping exercises for GDPR Article 30 or HIPAA do not enumerate vector databases as data stores containing personal data. They should. For each vector store, document: what source data was embedded, whether PII redaction was applied before embedding, what embedding model and architecture was used (single-vector vs. token-pooled), what deletion mechanism is in place, whether customer-managed encryption is enabled, and who has read access.

Then apply the same classification to the vector store that you apply to the source data. If the source data is "restricted" under your internal taxonomy, the vector store is "restricted." If the source data requires encryption in transit and at rest under PCI-DSS, the vector store does too.

This is not a theoretical exercise. The legal position is that vectors derived from personal data are personal data. The technical research confirms that the transformation is reversible. The only remaining question is whether your organization updates its controls before or after a regulator asks.

Where does this go from here?

The attack research will continue to improve. Each generation of inversion attack needs fewer assumptions and less auxiliary data. Defense research is active but immature. The concept-aware privacy mechanisms paper from February 2026 represents the current frontier of defense, and the authors themselves acknowledge severe limitations. Token-pooled architectures offer some structural resistance, but they are not yet the default in production embedding pipelines.

Regulators will catch up. They always do, with a lag. The EU AI Act high-risk provisions beginning in August 2026 and Colorado's AI law in January 2027 will create enforcement mechanisms that do not currently exist. Compliance teams that build their vector store governance now will be ahead. Those that treat embeddings as inherently anonymous will, eventually, have a conversation with a regulator that they would prefer not to have.

The operational metadata we retain at Selina uses a short retention window, not zero retention, because honest engineering means acknowledging that some operational data is necessary for reliability. Similarly, our account is protected, not encrypted end-to-end, because those are different guarantees and conflating them helps no one. We think this kind of precision about what is and is not protected is exactly what compliance teams should demand from every vendor in their AI stack, including their vector database provider.

The vectors are not anonymous. They never were. Act accordingly.

If you want to see how we handle memory, encryption, and data minimization in practice: start a free 7-day trial, no card required.

Michael C.

Founder & Principal Engineer, Selina Labs

Michael builds Selina, a privacy-first AI that remembers you across conversations. He ships security-sensitive AI in production — real attacks, real fixes, measured in minutes and dollars — and writes about privacy, security, and LLMs from that seat. Top Rated Plus and expert-verified on Upwork.

• www.upwork.com
• x.com
• medium.com
• selinalabs.io