DSPM Meets RAG: Data Classification for the Knowledge Base Era

Three years ago, Data Security Posture Management was the answer to a specific cloud problem: nobody knew where their sensitive data lived. S3 buckets multiplied, OneLake landed, BigQuery tables forked from analytics into production, Snowflake shares crossed accounts. Wiz, Cyera, Varonis, Securiti, and Microsoft Purview built a category around classifying data at rest, mapping lineage, and enforcing posture rules at the storage tier.

That problem is mostly solved on the storage side. The data did not stay there.

It moved into Retrieval-Augmented Generation corpora. Every enterprise that has stood up a Copilot, a customer-support assistant, a contract analyst, or an internal knowledge agent has built a derivative copy of its most sensitive documents, chunked them into small pieces, embedded those pieces into a vector index, and exposed the index to a model that retrieves and reasons over the contents on behalf of whichever principal is asking. The chunks are not in S3 any more. They are in Pinecone, Weaviate, Qdrant, OpenSearch, pgvector, Bedrock Knowledge Bases, Azure AI Search, Vertex AI Vector Search.

DSPM tooling does not, by default, look there. The result is that the highest-velocity sensitive-data surface in the modern enterprise is the surface that the data security posture programme is least equipped to assess. The pattern we recommend is to treat DSPM and RAG security as one practice, not two. This piece sets out why, what the practical classification gates look like, and the architecture pattern that follows.

Key takeaways

DSPM has done the cloud-storage discovery job well, but the highest-velocity sensitive-data surface has migrated into RAG corpora that storage-tier classification was never designed to assess.
Chunking shatters object-level access control: source ACLs do not propagate to chunks by default, embeddings inherit source sensitivity, and retrieval composes fragments into answers more sensitive than any single chunk a user is entitled to see.
Four documented exfiltration vectors target RAG specifically — prompt-injection extraction (OWASP LLM01:2025), embedding-similarity discovery, model memorisation, and agent action-via-retrieval — and none are stopped by storage-tier controls.
Five sequential classification gates — classify at source, preserve ACL at chunk, embedding-tier policy, retrieval-time pre-filtering, response-time policy — cover the dominant failure modes. The pre-filter at the vector store is the gate most teams skip.
GDPR Article 5(1)(c), EU AI Act Article 10, NDPA, and NIS2 Article 23 all converge on the same question: prove which data entered the AI system, on what basis, with what controls, and what was exposed when something failed.

What DSPM does well today

Before naming the gap, it is worth being precise about what DSPM has earned. The category took the discovery problem seriously. A modern DSPM platform — Cyera, Wiz DSPM, Varonis on the unstructured side, Securiti for multi-cloud regulated workloads, Microsoft Purview for the Microsoft 365 estate — does four things competently.

First, it discovers data stores across IaaS, PaaS, and SaaS surfaces without an agent footprint, typically via OAuth and cloud-native APIs. Second, it classifies content using a mixture of regular expressions, named-entity recognition, and trained classifiers, with accuracy rates that have improved sharply as transformer-based classifiers replaced regex-and-dictionary approaches. Third, it builds lineage — where a customer record came from, where it flowed, who has access to it. Fourth, it enforces posture rules: this S3 bucket should not be public, this Snowflake share should not cross to that account, this BigQuery dataset should not contain unencrypted PII.

Several vendors have extended into what is loosely called AI-SPM or DSPM for AI. Most of these extensions, in their current form, focus on two narrow questions: which sanctioned and unsanctioned AI applications are users sending sensitive data to, and which sensitive data sources are sanctioned AI applications reading from. Those are real questions. They are not the full set.

The full set requires asking what happens to the data once it crosses the boundary into a RAG pipeline. That is where current DSPM coverage thins out and where attackers are concentrating.

What changes when the data lands in a RAG corpus

Object-level access control assumes a coarse-grained unit: a file, a row, a table, a SharePoint item. RAG ingestion deliberately shatters that unit. A 200-page policy document becomes 800 chunks. A confidential contract becomes 60 chunks. A board pack becomes hundreds of fragments, each indexed independently, each retrievable independently, each comparable by cosine similarity to whatever query the model happens to receive.

Four properties shift in ways the storage-tier DSPM model does not anticipate.

The chunk loses its parent's identity. By default, a chunk carries a vector and a small bag of metadata. It does not carry the source file's ACL unless someone deliberately attaches it. If the ingest pipeline forgets to propagate the source ACL — and many do — the chunk is effectively public to every principal who can query the index.

The embedding is itself derivative data. For years, teams treated embeddings as if they were hashes: lossy projections, not reversible. The 2025 literature put that to rest. Modern inversion attacks recover plaintext from embeddings under realistic conditions, including in black-box and cross-domain settings. Treating an embedding store as a low-sensitivity artefact of a high-sensitivity corpus is a category error. The embeddings inherit the sensitivity of the source.

Retrieval surfaces fragments the user could not have read whole. A user with no access to a contract may still have access to one paragraph of it through some other surface — a quoted excerpt in an internal wiki, a summary in a board pack. Retrieval composes across sources. A model answering a question pulls the chunk it judges most relevant, regardless of which source it came from. The resulting answer can be more sensitive than any single chunk the user is entitled to.

Classification has to follow the chunk. Storage-tier classification — this file is "confidential", this dataset is "restricted" — does not survive chunking without explicit propagation. The classifier has to run again on the chunk, or the source label has to be carried as metadata, or both. Otherwise the index contains content whose sensitivity is invisible to the retrieval layer.

These four shifts produce a class of risk that storage-tier DSPM was never designed to catch.

The four exfiltration vectors

The risk is not hypothetical. Four exfiltration patterns are now well-documented in the literature and in real incidents.

Prompt-injection extraction. The dominant real-world attack pattern, and OWASP's LLM01:2025, is prompt injection. Against a RAG system, the model becomes a willing exfiltration channel. An attacker plants instructions inside a document the model will retrieve, or smuggles them through an indirect channel — an email the assistant summarises, a calendar invite, a support ticket — and the model dutifully follows them. Published work has demonstrated scalable verbatim extraction of corpus contents through this vector, including extraction from systems whose principals had no direct read access to the documents in question.

Embedding-similarity discovery. An adversary with query access to a vector index can use similarity scores as an oracle. Cosine distance leaks information about which content is present. Nearest-neighbour probing has been shown to recover sensitive attributes — diagnoses, nationalities, occupations — at over 90 per cent accuracy without ever seeing the source text. If the embedding model is known, full inversion of the most similar chunks is feasible.

Model memorisation. When a base model is fine-tuned on the corpus, or when long-context techniques pack the corpus into the prompt repeatedly, the model retains sensitive content. Backdoor implantation during fine-tuning has been demonstrated as a reliable extraction channel — researchers achieved 94 per cent verbatim extraction with five per cent poisoned training data. Even without fine-tuning, in-context memorisation across a session lets later turns surface what earlier turns retrieved.

Agent action-via-retrieval. The fastest-growing pattern: the model is not just answering, it is acting. It retrieves a document, decides on a tool call, and executes. Where the agent's tool surface includes anything that can communicate externally — sending an email, posting to a webhook, calling a downstream API — the retrieval layer becomes a privilege-escalation surface. The agent retrieves data its human principal cannot read, then takes an action that exfiltrates or acts on that data. This is the variant where existing identity controls fail hardest, because the action is performed under the agent's service identity, not the user's.

Storage-tier classification does not stop any of these. They all happen after the data has crossed into the RAG pipeline.

Five classification gates for RAG corpora

The practical question for a CISO or data protection officer is what controls actually move the needle. Five gates, applied in sequence, cover the dominant failure modes.

Gate one: classify the source before ingest. Before any document enters the chunking pipeline, run the DSPM classifier against the whole object. Tag the source's sensitivity class, regulatory category (personal data, special-category data under GDPR Article 9, financial, health, trade secret, export-controlled), and ACL snapshot. Any source whose classification exceeds the index's allowed maximum sensitivity is rejected at this gate.

Gate two: preserve the source ACL at chunk level. Every chunk written to the vector store carries the source's ACL as metadata: the entitlements that gate read access to the originating object. For SharePoint sources, this is the SharePoint permission set. For Google Drive, the file's sharing state. For Confluence, the space and page restrictions. For a database row, the row-level security predicate. The chunk's metadata is authoritative for retrieval-time filtering; without it, the index leaks across principals.

Gate three: embedding-tier policy. Not every classification tier should be embedded at all. A working policy ladder: public and internal data is embedded freely. Confidential data is embedded only in tenant-isolated, encrypted-at-rest stores with documented inversion resistance. Restricted and regulated-special-category data is not embedded — it is retrievable only through query-time lookup against the source system with full ACL enforcement, never through nearest-neighbour over a precomputed vector. This is the gate most teams skip. It is also the gate that makes embedding-inversion attacks survivable.

Gate four: retrieval-time policy enforcement. When a query arrives, the vector store filters by principal before nearest-neighbour, not after. The candidate set is restricted to chunks whose ACL metadata includes the querying principal. Most vector databases now support metadata filters at the index level. Post-filtering — retrieve broadly, then drop results the user cannot see — is not equivalent. Post-filtering still leaks through similarity-score oracles even when the content itself is hidden.

Gate five: response-time policy enforcement. Even with pre-filtered retrieval, the response itself needs guardrails. A PII filter on the model's output catches cases where retrieval surfaced low-classification chunks that compose into a high-classification answer. A denied-topic policy stops the model from producing content the corpus is not authorised to support. Contextual grounding checks confirm that every cited fact in the response traces to a retrieved chunk the principal was entitled to see, and that nothing was hallucinated in.

The five gates are independent in design but cumulative in effect. A team that ships only gates one and two has reduced the most common leakage by an order of magnitude. A team that ships all five has a defensible posture against the four exfiltration vectors above.

The architecture pattern

The gates describe controls; the architecture describes where they live. The pattern we recommend has eight stages and one assumption: the vector store is not the system of record for access control. The source systems are. The vector store enforces a cached copy of source-system entitlements, refreshed on a schedule and invalidated on permission change.

Source systems feed a classification gateway that runs DSPM classification on the whole object and decides — based on sensitivity tier and embedding policy — whether the object proceeds to ingest. Approved objects pass to a chunker that emits chunks with three metadata fields attached at write time: source sensitivity classification, source ACL snapshot, and source provenance pointer. Chunks below the embedding-tier ceiling are embedded and written to the vector store; chunks above it are indexed only by source pointer for query-time lookup.

A retrieval gateway sits between the model and the vector store. It accepts a query, resolves the principal, expands the principal's effective entitlements (including group memberships, scoped roles, and conditional access constraints), and issues a filtered similarity search. The candidate chunks come back with their ACL metadata; the gateway revalidates the principal's access against the current source ACL before the chunks reach the model context. This catches the case where a permission was revoked between ingest and query but the metadata has not yet been invalidated.

The model produces a response under a response-time policy that runs PII detection, denied-topic enforcement, and contextual grounding verification. Every step writes to an audit trail keyed by request ID: which chunks were retrieved, which ACL decisions were made, which response policy fired. The audit trail is the artefact a regulator will ask for; it is also the artefact the incident response team will need when something does leak.

This pattern composes with the controls we have described elsewhere — the principal-aware retrieval discipline in our piece on strict RBAC for enterprise knowledge bases, and the deployment posture in our piece on air-gapped LLM deployments on AWS Bedrock. DSPM-for-RAG is the data-classification spine that those access-control and deployment patterns hang on.

Regulatory framing

The classification gates and architecture above are not just good engineering. They are increasingly what regulators expect.

GDPR Article 5(1)(c) — data minimisation — has been read by EU supervisory authorities as binding on AI systems. A RAG corpus that contains personal data the assistant has no legitimate need to retrieve fails Article 5(1)(c) on its face. The classification gate at ingest is the control that demonstrates minimisation; without it, the controller cannot prove the corpus was scoped to purpose.

EU AI Act Article 10 — data governance — applies to providers of high-risk AI systems and takes effect from 2 August 2026. Providers must document the data sets used to develop and validate the system, including their statistical properties, design choices, and bias assessment. For high-risk RAG-backed systems, this maps directly onto the classification gate's outputs: which sources were included, on what basis, with what governance over personal data.

NDPA, in Nigeria, treats RAG-backed assistants that handle personal data as data processors in their own right where they operate on the controller's behalf. The same five gates apply; the audit trail is the proof.

NIS2 Article 23 imposes a 24-hour early warning, 72-hour notification, and one-month final report for significant incidents at in-scope entities. A RAG-driven data exfiltration that affects service continuity or personal data triggers the clock. The architecture's audit trail is what makes the 24-hour window survivable.

The pattern across all four regimes is the same. The regulator does not ask whether you bought DSPM tooling. The regulator asks whether you can prove which data entered the AI system, on what basis, with what controls, and what was exposed when something failed. The five gates and the audit trail are the artefacts that answer.

What this teaches us about enterprise scaling

The instinct, when a new technology surface like RAG opens up, is to wait for the existing tools to catch up. DSPM vendors will extend further into RAG corpora; they are already moving. They will all converge on something resembling the gates above within the next 12 to 18 months. Waiting for them is not a defensible posture.

Two reasons. First, the exfiltration vectors are mature now. Prompt injection and embedding inversion are not future risks; they are documented attack patterns being exploited at scale. The cost of a leak this year is not the cost of a leak next year. Second, the gates are not vendor features. They are architectural choices. A team that ships gate four — retrieval-time policy enforcement at the vector store rather than at the application layer — has changed where the trust boundary sits. No DSPM purchase, however expensive, retrofits that. The architecture has to be there first.

The deeper lesson is one we keep relearning at the edges of every new compute paradigm. The data security posture is not a product. It is a property of the system. Cloud DSPM worked because the cloud data planes exposed the right APIs and the vendors built on them; the RAG equivalent works the same way, but the APIs are different, the trust boundary moved, and the classification has to follow the chunk. The teams that get this right will not be the teams with the largest DSPM contracts. They will be the teams whose ingest pipelines, vector stores, and retrieval gateways were built with the five gates in from the start.

FAQs

Why isn't existing DSPM enough to cover RAG corpora?

DSPM was built for cloud data stores and excels at discovery, classification, lineage, and posture rules at the storage tier. RAG ingestion shatters the unit of access control: a 200-page policy becomes 800 chunks, each retrievable independently, often without the source's ACL attached. Most DSPM platforms classify the source object but stop there. The chunk, the embedding, and the retrieval-time decision are outside their default coverage.

Are embeddings really sensitive, or are they just lossy projections?

The 2025 inversion-attack literature settled this. Modern attacks recover plaintext from embeddings under realistic conditions, including in black-box and cross-domain settings. Embeddings inherit the sensitivity of the source they were computed from, and an embedding store of restricted data is a restricted store.

Which of the five gates is most often missed?

Gate four — retrieval-time policy enforcement at the vector store, before nearest-neighbour, not after. Most teams post-filter at the application layer, which still leaks through similarity-score oracles. Gate three — embedding-tier policy, where restricted content is not embedded at all — is the second most commonly skipped.

What changes when an agent is doing the retrieval rather than a user reading the answer?

The agent's tool surface becomes a privilege-escalation channel. If the agent can retrieve a document and then call a tool that sends email, posts to a webhook, or hits a downstream API, the retrieval layer is no longer just an information surface — it is an action surface. Existing identity controls fail here because the action is performed under the agent's service identity, not the user's. This is the case where principal-aware retrieval and the IAM delegation chain matter together.

Should we wait for DSPM vendors to extend into RAG?

No. The exfiltration vectors are mature now, and the gates are architectural choices, not vendor features. Gate four moves the trust boundary to the vector store — no DSPM purchase retrofits that. The architecture has to be there first; vendor tooling can then enforce it.

Companion content

How to engage

If you are standing up RAG infrastructure at enterprise scale and want a posture review against the five gates and the architecture pattern above — including a documented mapping to GDPR Article 5(1)(c), AI Act Article 10, NDPA, and NIS2 Article 23 — talk to us at creativeminds.dev/contact.