SELINA.ai
Sign in
can embeddings be reverse engineered

Can Embeddings Be Reverse Engineered? Yes, and Your Vector Store Is Not Anonymized

Most engineering teams treat their vector databases as inert. Numbers in, numbers out. The implicit assumption: once text becomes a 1536-dimensional float array, it is effectively anonymized. This assumption is wrong. The question of whether can embeddings be reverse engineered has moved from "theoretically, under contrived conditions" to "yes, with black-box API access and surprisingly few resources." Your vector store likely carries the same PII exposure as the source database it was derived from, possibly worse, because nobody put it in the data processing inventory.

Key Takeaways

Why Do Engineers Assume Embeddings Are Safe?

Because they look safe. You feed a sentence into an embedding model and get back a dense vector of floating-point numbers. No words. No syntax. No obvious structure a human could read. The intuition that "it's just math now" is strong, and for years it went mostly unchallenged outside of niche ML security research.

This intuition rests on a flawed mental model: that the transformation from text to vector is a one-way function, like a cryptographic hash. It is not. Embedding models are trained to preserve semantic similarity. That is their entire purpose. The geometric relationships between vectors encode meaning, and meaning can be decoded.

The practical question was never whether information leaked through embeddings. It was how much, and how hard an attacker had to work to extract it.

How Has Embedding Inversion Research Progressed?

The trajectory is clear, and it points in one direction: attacker requirements are shrinking while reconstruction quality is improving.

In 2023, Morris et al. published Vec2Text, demonstrating that embeddings from commercial APIs could be inverted with high accuracy. The title of the paper said it plainly: "Text Embeddings Reveal (Almost) As Much As Text." This was the foundational result. It required substantial compute and access to leaked embedding-text pairs, which let some teams rationalize the risk as "high attacker cost, low probability."

That rationalization started aging fast. In early 2025, ALGEN was published at ACL 2025, introducing few-shot inversion attacks. A single leaked data point was sufficient for a partially successful inversion. With as few as 1,000 samples, performance plateaued across a range of black-box encoders. No leaked training data required. The bar had dropped by orders of magnitude.

Then in 2026, Kim et al. introduced Zero2Text, a training-free, cross-domain embedding inversion technique that requires no prior leaked embedding-text pairs at all. Just black-box query access to the victim embedding model. Zero leaked pairs. Zero training. Query access only.

Read that trajectory again: massive leaked datasets (2023), then a thousand samples (2025), then zero samples (2026). If your threat model was written in 2024, it assumed a world that no longer exists.

What Has Been Found in Exposed Vector Databases?

This is not hypothetical. Security firm Orca scanned the internet and found multiple publicly exposed, unauthenticated vector database instances. These were deployed across major cloud providers and self-hosted environments. No authentication required. Just point a client at the endpoint and query.

What was inside: real names, phone numbers, email addresses, national ID numbers, home addresses, credentials, medical records, biometric data.

In one documented case, secrets discovered inside an exposed vector database were used to pivot laterally and compromise customer accounts on an entirely separate platform. This is not a conference demo. This is a real incident chain that started with an unprotected vector store.

The pattern here is familiar to anyone who lived through the era of exposed MongoDB and Elasticsearch instances circa 2017. New database technology ships. Teams adopt it rapidly. Security configuration is an afterthought. Sensitive data accumulates. Somebody scans the internet and finds thousands of open instances. We are replaying that cycle with vector databases right now, except the data inside is arguably richer, because it encodes semantic meaning, not just raw records.

Are Embeddings Pseudonymized or Anonymized Under GDPR?

Pseudonymized. Almost certainly. And pseudonymized data is still personal data under GDPR.

This distinction matters enormously. Under GDPR, pseudonymization means the data has been transformed so that it cannot be attributed to a specific individual without additional information. An embedding is exactly that: a transformed representation that, with additional information (the embedding model, or query access to it), can be traced back to the original content. Pseudonymized data remains in-scope for all GDPR obligations. Breach notification. Data subject access requests. Right to erasure.

True anonymization, which would exempt the data from GDPR, requires meeting a strict three-part identifiability test as defined by the EDPB. Data must fail all three tests to qualify as anonymous. Given that inversion attacks can now reconstruct source text with zero leaked pairs, it is difficult to argue that embeddings pass these tests. The "additional information" needed to re-identify is just API access to the same model that generated them.

Most engineering teams have never mapped their vector stores into their data processing inventories. The vector database sits in a terraform module somewhere, populated by a pipeline that chunks documents and calls an embedding endpoint. Nobody filed a DPIA for it. Nobody added it to the Article 30 records of processing activities. If you are storing embeddings of EU user data, you likely have a compliance gap that exists not because someone was negligent, but because the assumption that "vectors aren't personal data" was never examined.

Why Is Right-to-Erasure Architecturally Harder for Embeddings?

Deleting a row from a relational database is straightforward. You know which row corresponds to which user. You delete it. You can verify it is gone.

Deleting an embedding is a different problem. Consider what happens when a user says "delete my data." You can delete the source document. You can delete the chunks. But the embedding vectors derived from those chunks live in a vector index, often in a purpose-built store like Pinecone, Weaviate, Qdrant, or Chroma. Can you trace each vector back to the source record it was generated from? Did you store that mapping? If you did, is it reliable after re-indexing? What about vectors that were generated from composite contexts (a chunk that blended two users' data)? What about cached query results that contain nearest-neighbor vectors from the deleted user's records?

Most teams did not design for this. The vector store was built for retrieval performance, not for auditability or selective deletion. The result: "delete my data" becomes an architectural excavation rather than a query. And if you cannot demonstrate deletion, you cannot comply with Article 17.

This is the sharper version of the risk that most security coverage misses. The threat is not only "your vector DB can be breached." It is "your vector DB may make you structurally incapable of complying with deletion requests." That is a design-time problem, not a bolt-on fix.

What Did OWASP Codify in 2025?

OWASP added "Vector and Embedding Weaknesses" as LLM08 in the 2025 update to its Top 10 for LLM Applications. The entry specifically cites that attackers can invert embeddings to recover substantial source information, compromising confidentiality. It also flags multi-tenant context leakage, unauthorized access to vector stores, and inadequate access controls as core risk vectors.

This matters for two reasons. First, it gives you a citable, industry-standard risk category for internal conversations. "OWASP says so" moves budget in a way that "I read a paper on arXiv" does not. Second, it signals that the security community considers this risk mature enough to institutionalize. This is no longer an emerging research curiosity. It is a catalogued vulnerability class with a taxonomy and recommended mitigations.

One analysis of the update called it one of the most important new risk categories in the list, specifically because it forces a wider audience to confront how critical these components are in production LLM architectures.

How Does Multi-Tenancy Make This Worse?

If multiple users or applications share the same vector store (and in most SaaS architectures, they do), every query is a potential information leak. A nearest-neighbor search does not respect tenant boundaries unless you explicitly enforce them. Without namespace isolation, filtering, or access controls at the vector level, User A's query can return embeddings derived from User B's data.

This is context leakage, and it is a structural property of how similarity search works. The database returns the most similar vectors, period. It does not ask who they belong to unless you told it to. In multi-tenant environments, this creates a risk surface that scales with the number of tenants and the density of the shared vector space.

The fix is not complicated in principle (namespace isolation, metadata filtering, row-level access controls), but it requires the team to have treated the vector store as a first-class data system with access control requirements. Many teams did not. The vector store was "just the retrieval layer."

What Does the Scale of Sensitive Data in LLM Inputs Look Like?

Consider the upstream problem. One Q4 2025 industry analysis found that 34.8% of enterprise inputs to LLM tools contain sensitive data: customer records, payment card information, health details. That figure was up from 11% in 2023. This matters because that same sensitive input is often what gets chunked, embedded, and persisted downstream in a vector store for retrieval-augmented generation or long-term memory.

The pipeline is: user enters sensitive data into an LLM-powered tool, the tool chunks it for future retrieval, the chunks get embedded, the embeddings get stored. At no point in this pipeline did anyone classify the vector store as containing PII. But it does. Because the embeddings encode the PII that was in the input.

What Does This Cost When It Goes Wrong?

IBM's 2025 Cost of a Data Breach Report found that breaches involving shadow AI cost an average of $4.63 million per incident, $670,000 higher than breaches without AI involvement. Vector stores that were never registered as data assets, never included in security audits, never added to the data processing inventory fit the definition of shadow AI infrastructure precisely.

A separate incident in early 2026 illustrated the broader pattern: a chatbot wrapper application exposed roughly 300 million messages belonging to over 25 million people due to a backend database misconfiguration. No authentication required. The vector store scenario is structurally identical. An AI memory layer sitting behind an API, holding user data, with security treated as an afterthought.

What Should You Actually Do About This?

Start with the assumption that your vector store is a regulated data asset. Then work backward.

Inventory it. Add your vector databases to your Article 30 records. Include them in DPIAs. Map the data flows: what gets embedded, where it comes from, whose data it contains, and who can query it.

Build deletion traceability at design time. Every embedding needs a reliable mapping back to its source record. When a deletion request comes in, you need to be able to identify and purge every vector derived from that user's data. This is trivial to design for on day one and extremely painful to retrofit.

Enforce tenant isolation. If you are running multi-tenant, namespace your vectors. Apply metadata filters at query time. Test that queries from one tenant cannot surface results from another. This is table-stakes access control; it just happens to be commonly missing in vector stores.

Encrypt at rest, but understand what that covers. Encrypting your vector store at rest protects against offline exfiltration (stolen disks, backup leaks). It does not protect against inversion attacks by anyone with query access. Both layers matter.

Revisit your threat model. If your last risk assessment assumed inversion attacks require massive leaked datasets or white-box model access, it is out of date. Few-shot attacks and zero-shot attacks have moved the feasibility boundary. Update accordingly.

Authenticate your vector store endpoints. This should go without saying, but Orca's findings suggest it does not. Treat vector databases like you treat any other database: authenticated, network-isolated, access-logged.

A Bug Class That Hides in Plain Sight

We build Selina, a privacy-focused AI assistant with persistent, adaptive memory. Memory that remembers you across conversations is the feature. Which means the question of how to handle embeddings responsibly is not abstract for us. It is the core design constraint.

One pattern we encountered early: encrypt-before-embed. The instinct is understandable. You encrypt the source text, then embed the encrypted version. Problem solved, right? No. Embedding an encrypted string produces a vector that encodes the statistical properties of the ciphertext, not the semantic meaning of the plaintext. The embedding is useless for retrieval. You have destroyed the utility of the vector store without gaining meaningful security, because the "protection" is that nobody can search your data, including you.

The actual design problem is harder. You need the embeddings to be semantically useful (that is the point), which means they will encode meaning, which means they are invertible to some degree. The question becomes: who can query them, how is access scoped, how is deletion traced, and how is the store protected at rest. These are access control and data lifecycle problems, not encryption problems. Treating them as encryption problems leads to encrypt-before-embed, which leads to a vector store that does not work.

Selina's memory is encrypted at rest but is not end-to-end encrypted, because a slice of each request reaches a frontier provider at inference. That is the honest trade-off. Files and transfers via SelinaSEND are zero-knowledge encrypted. Memory is not. Knowing where the boundary is matters more than pretending it does not exist.

The Uncomfortable Bottom Line

Vectors are not anonymized. They are pseudonymized at best, and the pseudonymization is weakening with every new inversion technique published. Your vector store carries the same PII exposure as your source database, the same regulatory obligations, and, given how few teams have audited them, probably worse operational security.

The fix is not exotic. It is the same discipline you already apply to your relational databases: inventory, access control, encryption at rest, deletion traceability, threat modeling, and inclusion in your compliance framework. The only thing novel here is that you need to start doing it for a data store that most teams forgot to classify as a data store at all.

As one database engineering analysis put it: when embeddings are not anonymized, they remain information-dense. They do. Treat them accordingly.

If you want to see how we handle persistent AI memory with these constraints baked in: start a free 7-day trial, no card required.

Frequently Asked Questions

Can embeddings really be reverse engineered back into readable text?

Yes. Embedding models preserve semantic similarity, so their geometric relationships encode meaning that can be decoded. Research has progressed from needing massive leaked datasets in 2023 to requiring zero leaked pairs by 2026, using only black-box query access.

Why do engineers assume vector embeddings are safe or anonymized?

Because embeddings look like meaningless arrays of floating-point numbers with no visible words or syntax, engineers assume the text-to-vector transformation is a one-way function like a cryptographic hash. This is a flawed mental model, since embedding models are specifically trained to preserve semantic similarity, which can be reversed.

Have exposed vector databases actually leaked sensitive data in practice?

Yes. Security firm Orca found multiple publicly exposed, unauthenticated vector database instances across major cloud providers containing real names, phone numbers, medical records, and credentials. In one documented case, secrets found in an exposed vector database were used to pivot laterally and compromise accounts on a separate platform.

Are embeddings considered personal data under GDPR?

Almost certainly yes, embeddings qualify as pseudonymized data rather than truly anonymized data under GDPR, since they can be traced back to original content with additional information such as access to the embedding model. Pseudonymized data remains fully in-scope for GDPR obligations like breach notification, DSARs, and right-to-erasure.

Why is it hard to comply with data deletion requests when using vector databases?

Unlike deleting a row from a relational database, vector stores are typically built for retrieval performance, not auditability, so teams often cannot trace individual embeddings back to source records after deletion requests. This makes complying with right-to-erasure obligations like GDPR Article 17 an architectural challenge rather than a simple query.

Sources & References

Michael C.

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.

Learn more about Selina.ai