embeddings are not encryption

A security architect at a healthcare technology company was reviewing a proposed AI deployment in early 2026. The deployment involved embedding clinical notes into a vector database for a RAG-based clinical search tool. The architect asked the implementing team a specific question: what happens if the vector database is compromised?

The implementing team’s answer was that the vectors are opaque. A vector is a list of numbers. Numbers are not PHI. Numbers can’t be read by a human. If an attacker got the vectors, they would have lists of floating-point numbers, not clinical notes. The embedding itself serves as a kind of obfuscation.

The architect forwarded the team a recent research paper on embedding inversion. The paper demonstrated that modern embedding models, the same ones commonly used in enterprise RAG systems, produce vectors from which the original text can be approximately recovered using a trained inversion model. The recovered text isn’t identical to the original, but it’s often close enough to recover the substantive content, including names, diagnoses, and other identifying details.

The implementing team’s assumption, that embeddings were a form of secure transformation, was wrong. The vectors were not encryption. They were a lossy but partially reversible representation of the original text, stored in a database that itself wasn’t treated as containing PHI.

This essay is about that misunderstanding. It shows up frequently in how teams think about vector databases and embeddings, and it matters for how those systems should be classified, protected, and audited.

an embedding is a transformation, and transformations leak

An embedding is a mathematical transformation of text into a vector in high-dimensional space. The transformation is designed to preserve semantic meaning, similar texts map to similar vectors, which is what makes retrieval work. The transformation is not designed for security or privacy.

A vector from a modern embedding model contains enough information about the original text to be useful for retrieval. Retrieval works by finding vectors similar to the query vector, which only works if the vectors encode enough content to distinguish between texts. The more retrieval-useful the vectors are, the more content they encode.

The same content that makes vectors useful for retrieval makes them partially reversible. Given enough vectors from a known model and access to similar text data for training, an inversion model can learn to approximate the reverse transformation. The result is text that recovers much of the original semantic content.

The inversion models published in research are not perfect. They recover approximate text, not verbatim. But approximate text is often enough. Approximate text that includes the person’s name, the approximate topic, and the approximate details of a conversation is enough to qualify as a privacy breach under most regulatory frameworks.

The common intuition, “vectors are numbers, numbers are not data”, is wrong in the way that “hashed passwords are not passwords” is wrong in the weak-hash case. The math is a one-way function in principle; in practice, with the right tooling, it’s partially reversible.

what people assume about embeddings, and what holds

the assumption

it's just numbers

• Vectors can't be read, so they're safe
• The database can sit in a lower data class
• Deleting the source deletes the content

what holds

it's the content, transformed

• Published research has reconstructed approximate text from embeddings
• Classify the vectors like the source they came from
• Deletion has to reach the index too

the inversion research

The academic literature on embedding inversion has been building for several years. Key results to be aware of:

Vec2Text (Morris et al., 2023) demonstrated that text can be recovered from sentence embeddings with high fidelity. The technique used a learned iterative inversion: generate an initial candidate, compare its embedding to the target, refine, and repeat. Recovery rates on tested datasets were meaningful, a significant fraction of the original text was reconstructed verbatim or near-verbatim.

Subsequent work extended this to embeddings from major commercial embedding APIs. The inversion is more computationally expensive for stronger models, but not prohibitively so. An attacker with budget for compute and a target embedding database can run inversion at scale.

Related work on membership inference showed that even without full inversion, an attacker can often determine whether a specific text was in the training data or in the embedded corpus, based on how the embedding responds to queries.

These results have been published, replicated, and extended. They are not theoretical. They describe practical attacks that can be executed against production embedding systems.

The implication is that a vector database should be classified and protected based on the content that was embedded, not based on the assumption that embeddings are secure transformations. If the embedded content is PHI, the vector database contains PHI. If the embedded content is PII, the vector database contains PII. If the embedded content is attorney-client privileged, the vector database contains privileged content.

the classification gap

Most companies classify data stores based on the structured assumption that stored data equals its classification. A database holding employee records is classified as containing employee data. A database holding customer transactions is classified as containing customer transactions.

Vector databases are often created without explicit classification, or with a classification that reflects only the vector format rather than the underlying content. The classification gap is the specific problem that vectors look like floating-point numbers and are treated as low-sensitivity infrastructure.

The correction is to classify vector databases based on what was indexed. A vector database whose source corpus included medical records is a medical record database. A vector database whose source corpus included financial data is a financial data database. The classification flows from the source, not from the storage format.

This has downstream implications for access control, encryption, audit logging, and retention. A high-sensitivity vector database needs the controls appropriate to high-sensitivity data, not the controls appropriate to a generic analytics database.

The specific audit question: have you classified your vector databases based on the underlying content? If not, the classification is probably defaulted to something low, and the controls match. The controls should be raised to match the content.

the separation of concerns that isn’t

RAG deployments often involve multiple components, each with its own sensitivity profile. The source documents. The embedding model. The vector database. The retrieval logic. The LLM that generates responses.

In some architectures, the components are separated across different infrastructure tiers. The source documents might be in a secure document management system. The vector database might be in a general-purpose cloud infrastructure. The LLM might be a third-party API. Each tier might have different controls.

The assumption is that the separation provides defense in depth. If the LLM API is breached, the source documents are safe. If the vector database is breached, the LLM is unaffected.

The inversion problem undermines this assumption. If the vector database is breached, the content of the source documents is recoverable, not just referenced. The vector database is not a safer copy of the source, it’s a near-copy with different obfuscation.

The separation of concerns is still a valid architectural pattern, but it has to account for the actual information content of each tier. The vector database is not a low-sensitivity tier. It’s a high-sensitivity tier with a specific risk profile (partial reversibility of stored content) that differs from the source tier (direct storage) but doesn’t provide independence from it.

the retrieval system as an inversion oracle

A subtler risk: the retrieval system itself, when exposed to an attacker, can serve as an inversion oracle without requiring direct access to the vector database.

The attacker has access to a search interface that runs against the vector database. The attacker submits queries. The retrieval system returns chunks of source text in response to each query. Over many queries, the attacker can build up a picture of what’s in the corpus.

Specifically, the attacker can craft queries designed to surface the most sensitive content. Queries like “executive compensation,” “layoff plans,” “legal settlement,” or “security incident” retrieve the most relevant chunks. If the corpus contains any of those topics, the most relevant chunks are returned, giving the attacker the contents without needing any direct database access.

This is not inversion in the mathematical sense. It’s retrieval, which is the designed purpose of the system. But from an attacker’s perspective, the retrieval interface is a way to extract corpus contents through crafted queries.

The defense against this is permission-aware retrieval (discussed in the previous essay) and query monitoring. The retrieval system should only return content that the querying user has permission to see. The system should also log queries and flag anomalous patterns, queries designed to surface sensitive content across multiple domains, queries from users who don’t normally ask such questions, query bursts that look like systematic extraction.

Most deployments don’t have this monitoring. The retrieval interface is treated as a productivity tool, not as a potential extraction path. The assumption is that users query for what they need and don’t try to extract the corpus. The assumption is wrong for any user with malicious intent, and the interface facilitates the extraction.

the data subject rights problem

A specific compliance issue: data subject rights, as defined under GDPR and similar frameworks, require companies to be able to locate all data about a specific individual on request, correct it, and delete it.

For structured data in traditional systems, this is difficult but tractable. Query the database, find the records, update or delete them. The semantics of “all data about this person” maps reasonably onto SQL queries.

For vector databases, the mapping is less clean. A vector is a representation of a chunk of text. The text might mention a specific individual, but the vector doesn’t have a structured field that says “this is about person X.” Finding all vectors related to a person requires either searching the original chunks for mentions, or doing similarity search against a representation of the person.

Neither approach is complete. Text mentions are easy to miss if the person is referred to in different ways across chunks. Similarity search is approximate. The result is that “delete all data about this person from the vector database” is a harder operation than the equivalent in a traditional database.

The compliance obligation, however, is the same. The regulatory framework doesn’t care that vector databases are harder to search. It cares that the company can execute the data subject request.

Companies that have tried to handle this have usually fallen back on a nuclear option: delete the entire vector database and re-index from source, after the source has been updated to reflect the data subject request. This is operationally expensive but provably comprehensive. The alternatives, trying to surgically remove specific content from a vector database, are less reliable.

For compliance programs, the vector database is a specific complication that needs explicit handling. Most programs haven’t updated their data subject response playbooks to account for RAG systems. The gap is a compliance risk that will surface the first time a company receives a data subject request that includes content in the vector database.

the controls to apply

The specific controls for a high-sensitivity vector database.

Encryption at rest. The database is encrypted with keys managed by the company, not by the cloud provider’s default encryption. Access to the keys is audited.

Encryption in transit. All access to the database is over encrypted channels. Network paths to the database are restricted to specific infrastructure.

Access control at the query layer. Permission-aware retrieval is implemented, filtering results by the querying user’s identity and permissions.

Query logging and anomaly detection. Every query is logged. Patterns suggesting systematic extraction are flagged.

Inversion risk acknowledgment. The deployment documentation explicitly acknowledges that the vector database contains content recoverable from the embeddings, and classifies the database accordingly.

Synchronization with source. Deletions, updates, and permission changes at the source propagate to the vector database on a defined cadence.

Retention policy. The vectors are retained for as long as the source documents are retained, and no longer. When source documents are deleted, vectors are deleted.

Backup policy. Backups of the vector database are treated with the same sensitivity as backups of the source data.

None of these is novel. They are the standard controls for sensitive data stores, applied to a store that is frequently miscategorized as non-sensitive.

controls for a vector database

1. 1classify by the sourceThe most sensitive document embedded sets the class.
2. 2match the controlsEncryption, access logging, keys you manage.
3. 3permission-aware retrievalUsers only retrieve what they could open in the source.
4. 4align retention and deletionWhen a source is deleted or a person asks to be forgotten, the vectors go too.

the exercise

If your company has any vector database in production use, run this specific audit.

Identify each vector database. In a typical mid-market deployment, there might be several, an internal knowledge search, a customer-facing chatbot, a developer productivity tool, a specific application feature.

For each vector database, document: what source corpus was embedded? What sensitivity class does that source belong to? What controls are in place on the database?

Compare the source sensitivity to the vector database controls. If the controls are weaker than the source warrants, the database is under-protected.

For any database containing material that would be classified as sensitive in its source form, upgrade the controls. Encryption, access logging, permission-aware retrieval, retention alignment with source.

Write into your data subject response playbook a specific procedure for vector databases. How will you handle a deletion request that touches content in the vector database? Test the procedure before you need it.

Review the research on embedding inversion with your security team. Make sure everyone understands that the vectors are not a security barrier. The assumption that “it’s just numbers” is the specific assumption that this essay exists to refute.

The vector database is a copy of your sensitive data, in a representation that’s partially reversible. Treating it as low-sensitivity infrastructure creates a specific exposure that an attacker aware of current research can exploit.

Classify the database by the content that was embedded. Apply the controls appropriate to that classification. Treat embedding as a useful technique for retrieval, not as a protective transformation.

The math that makes retrieval work is the same math that makes inversion possible. You can’t have one without the other.