Securing the data behind your AI projects: RAG, vector databases and DSPM

Up to date as of November 7, 2026. This article complements our analyses of AI agent security and of the AI-augmented SOC.

Most enterprise AI assistants do not rely on their model alone: they query a knowledge base built from your documents, tickets, emails or procedures. This technique, called RAG (retrieval-augmented generation), is effective. But it creates a new copy of your data, often without the protections that originally surrounded it.

An assistant is never safer than the data it can read.

RAG in a nutshell

Documents are split into chunks, then turned into vectors (numerical representations of their meaning) stored in a vector database. For each question, the system retrieves the closest chunks and passes them to the model, which uses them to answer.

The upside: there is no need to retrain a model for it to know your procedures. The downside: the vector database becomes a new data repository, to be secured as such.

The risks specific to AI data

Access rights lost along the way

This is the most common risk. Indexing is often done by a technical account with broad rights. If the original access rights of the documents are not carried over into the database, any user of the assistant can obtain, with a simple question, information they cannot access in the source applications.

OWASP has in fact devoted a category of its Top 10 for LLM applications (2025 edition) to vector and embedding weaknesses, recommending permission-aware vector databases and strict partitioning of datasets. Its RAG security guide specifies that access metadata must be attached to each chunk, that rights must be checked at retrieval time, and that the model must never be relied upon to enforce those rights.

Vectors that are not anonymous

One might think that a vector, a series of numbers, reveals nothing. That is wrong. In 2023, researchers showed that it was possible to reconstruct 92% of short texts (32 tokens, a sentence or two) exactly from their vectors alone, and to recover full names from clinical notes. Their conclusion: vectors must be protected with the same care as the texts they come from.

Copies that multiply

Extracts, chunks, caches, conversation histories, evaluation sets, training sets: an AI project multiplies copies of data, often outside the usual inventories and retention periods. When a person exercises their right to erasure under the GDPR, or a document is deleted at the source, the deletion must also propagate to these copies and to the index.

Mixing sensitivity levels

Bringing sources with different confidentiality levels together in the same database creates a risk of leakage: an answer can combine a public document and a confidential extract. Hence the value of labeling and classifying data as soon as it is ingested.

Poisoning of the knowledge base

A booby-trapped document added to the base can influence the assistant’s answers for a long time, or even contain malicious instructions (see our analysis Securing AI agents in the enterprise).

DSPM, a management tool

DSPM (Data Security Posture Management) solutions automate part of this work:

discover and classify data, including in the cloud, SaaS services and data lakes;
map who has access to it, and spot excessive rights;
detect exposures: sensitive data stored in the wrong place, public shares, forgotten copies;
prioritize fixes according to sensitivity and exposure.

Not all solutions cover vector databases and AI pipelines yet: coverage of these new repositories is a selection criterion to check.

The regulatory framework

The GDPR fully applies: purpose, data minimization, retention periods, individuals’ rights and, where relevant, an impact assessment. In 2024 and 2025, the CNIL published a series of practical guides on developing AI systems, along with a checklist.
The AI Act requires data governance for high-risk AI systems (Article 10): quality, relevance, origin and handling of bias in the datasets.
ANSSI, in its security recommendations for a generative AI system, recommends isolating the components and filtering and logging access to data.

Where to start

Map the data that each AI project reads, indexes or keeps, including conversation histories.
Classify the sources and exclude, or handle separately, what does not belong in a shared knowledge base: secrets, health data, HR data, strategic documents.
Carry over the original rights: access metadata on every chunk, filtering at retrieval time, partitioning by user group.
Protect the vector database like the source data: encryption, restricted access, logging of queries.
Manage the lifecycle: propagate deletions and updates, purge caches and histories, apply retention periods.
Manage the posture continuously with a DSPM tool, and monitor abnormal access from the SOC.
Choose hosting according to sensitivity: an AI that runs locally avoids entrusting your data and your indexes to a third party (see The AI-augmented SOC).

Sources

← All insights