Vector Stores and Embeddings as Security Assets
A vector database full of document embeddings is a new asset class that most security teams have not yet inventoried or secured. Because embeddings can be partially inverted and chunking defines context boundaries, these stores require the same access controls as the original plaintext.
By Piotr Zenon Żabrowski · Published · Updated
Embeddings are not one-way hashes
Security teams often mistake stored document vectors for anonymized or irreversibly hashed data. They are not. Unlike static token dictionaries or transient hidden states—which exist only briefly in memory during inference and carry negligible storage risk—document embeddings are persistently stored mathematical representations of complete text segments. They form a permanent searchable index.
Research on embedding inversion proves that this process is not a one-way trip. Substantial portions of the original source text can be reconstructed directly from its vector representation. An attacker who gains read access to a vector database can extract personally identifiable information, intellectual property, or confidential records without ever touching the primary application database. Consequently, vector stores cannot be treated as sanitized data lakes. They demand the exact same encryption at rest, network isolation, and access classification as the raw, unencrypted plaintext they represent.
Chunking as a structural access boundary
Before source documents enter the vector database, they are split into chunks. In a retrieval-augmented generation pipeline, this chunking strategy dictates the authorization boundaries of the data. When the system retrieves a vector to answer a user’s query, the model is fed the entire underlying chunk. If the chunking is too broad or arbitrarily divided, it hands the retriever far more surrounding data than necessary, creating a significant risk of unintentional data leakage.
Consider a financial document where a public earnings summary sits adjacent to a confidential, unreleased forward-looking statement. If the text is sliced arbitrarily, both clauses might end up in the same chunk. A harmless query about the earnings summary would then pull the restricted statement into the model’s context window, exposing it to the user. Tightly scoped chunking is therefore a core data protection control.
The chosen division method directly determines the scope of potential exposure. Cutting text strictly by token count is computationally cheap but structurally blind, maximizing the chance of crossing confidentiality boundaries. Logical splitting by headers, paragraphs, or document hierarchy requires custom parsing logic but ensures the AI system retrieves only the specific clause relevant to a prompt, keeping unrelated sensitive data safely out of the context.
| Strategy | Security and boundary impact | Common use cases |
|---|---|---|
| Fixed token length | Arbitrary splits can cut across definitions or expose adjacent unrelated data | Prototypes, rapid indexing |
| Paragraph or section | Respects natural boundaries, containing exposure to a single logical unit | Contracts, procedural documents |
| Hierarchical | Maintains parent-child document structure, allowing precise context scoping | Due diligence, case files, policies |
Frequently asked questions
Do vector databases act as a form of data anonymization?
No. Document embeddings can often be inverted to reconstruct the original text. They provide no cryptographic protection or anonymization and require identical access controls to the raw documents.
Why does chunk size matter for security?
Because a retrieval system fetches entire chunks. If a chunk contains both a relevant public fact and an adjacent restricted clause, the model receives both. Tightly scoped chunking acts as a boundary against unintentional context exposure.
Related
AI security
How to secure GenAI, LLM and agentic AI systems: current OWASP threat classes, layered controls, agent authority, retrieval isolation and monitoring.
Retrieval poisoning
A poisoned RAG document can turn retrieval into prompt injection. See how ingestion, ranking, permissions and testing contain the attack.
AI security assessment
Security assessment of GenAI and LLM systems: prompt injection, tool and agent abuse, data leakage, model supply chain and monitoring gaps.
STRIDE for AI systems
Applying STRIDE to LLM and agentic applications: what each category means when untrusted text can act as instructions, where STRIDE stops covering multi-agent failure modes, and the controls per element.
Prompt injection defence
Why prompt injection cannot be filtered away, why it has no full fix yet, and how to design AI systems — architecturally, not just with better prompts — so a successful injection has no useful consequence.
LLM security controls
A control checklist for enterprise GenAI: data handling, retrieval isolation, agent authority, cascading-failure containment, monitoring, cost limits and vendor terms.