Securing Enterprise RAG: PII Masking, Token-Level Access Control, and Boundary-Aware Retrieval

Securing enterprise RAG means treating the retrieval pipeline as the attack surface. Mask personal data before it can reach a model, propagate access control into the vector store so retrieval respects source-system permissions, and enforce tenant and classification boundaries at query time. The model is rarely the weak point. The pipeline around it is.

#The RAG Threat Model

What this means for you: none of the four dominant attacks require breaching the model. They exploit the plumbing, which means they are architecture defects your own team can fix.

Retrieval-augmented generation introduces attack vectors that a standalone model does not have, because it deliberately widens the set of things that can influence a response. Four threat classes dominate in enterprise deployments.

The first of those deserves particular attention, because it inverts an assumption most security models rest on. RAG places external text inside the model's context by design, so the boundary between data and instruction is drawn by prompt structure rather than by the transport.

Retrieval turns your corpus into an input channel, and every writer to that corpus into a potential prompt author.

The third is the one we find most often in production. Cross-tenant leakage is an architecture bug rather than a model bug, and it fails silently: everything works, the answers look right, and nothing surfaces until an auditor or a customer notices. The fourth is the one most often argued away, usually on the assumption that a vector database is somehow a derived artefact rather than a copy.

#PII Masking Before the Model Ever Sees It

What this means for you: two design decisions — where you mask and how you mask — determine whether masking protects you or merely destroys the utility you were paying for.

Masking at the edge keeps sensitive customer data inside the secure boundary even during model processing, through identification and transformation of sensitive entities before data enters the context window. This single control is what makes RAG viable in the most tightly regulated sectors.

#Where to mask: pre-index or query-time

Pre-index masking sanitises documents before embedding, so the index never contains raw identifiers. That is the stronger posture — a compromised index leaks tokens rather than identities, and it mitigates embedding inversion at the same time. Its cost is lost specificity: queries about a particular person cannot match on the masked identifier.

Query-time masking keeps the index richer and scrubs retrieved chunks, and user queries, just before they enter the context window. It preserves utility but leaves raw personal data resident in the index, which must then be defended as a sensitive store in its own right. Regulated deployments typically combine them: pre-index masking for high-risk identifier classes, query-time scrubbing as the defence-in-depth layer for whatever detection missed.

#How to mask: deterministic tokenisation or redaction

Redaction replaces an entity with an opaque placeholder — simple and maximally safe, but destructive. The model can no longer tell that two mentions refer to the same person, which breaks reasoning across documents.

Deterministic tokenisation replaces each entity with a stable pseudonym, so the same customer always becomes the same token, preserving referential integrity without exposing real identifiers. A governed mapping service re-identifies tokens in the response for authorised users only.

Note also that pseudonymised data remains personal data under the UK GDPR. Tokenisation reduces exposure and supports data minimisation; it does not take the processing outside the regime, and any control narrative that claims otherwise will not survive review.

#Access Control That Survives the Pipeline

What this means for you: the moment documents are chunked and embedded into a shared index, your source-system permissions are gone unless you deliberately carried them along.

Source systems enforce permissions. A naive RAG pipeline flattens them. The principle that fixes it: entitlements must propagate into the vector store as metadata and be enforced at query time, integrated with enterprise identity and access management.

In practice, every chunk is written with a security envelope — owning tenant, source system, document-level ACL or role list, classification label, and any row-level restrictions inherited from structured sources. Chunk-level control matters because documents are not uniformly sensitive: a report whose body is general but whose appendix is restricted must not become uniformly retrievable just because it was split.

For data originating in databases with row-level security, the same predicate logic must be re-expressed as chunk metadata, or the RAG layer silently becomes a bypass of controls the data team spent years building.

#Boundary-Aware Retrieval

What this means for you: the retriever, not the model, is where boundaries are enforced — and every scope should be attached by the platform from authenticated context, never inferred from the prompt.

On top of these deterministic filters, boundary agents add a semantic layer of defence: independent model-driven checks that audit retrieval results for sensitivity before they are surfaced, catching what metadata cannot express — a document that is technically "internal" but plainly should not reach this audience.

The deterministic filters are the enforcement. The boundary agent is the smoke detector. Neither substitutes for the other.

Where retrieval feeds autonomous agents rather than a chat interface, this boundary becomes load-bearing for the whole architecture, in the sense described in the four layers of autonomous enterprise architecture and scoped for delivery in our agentic AI engagements.

#Auditability of Generations

What this means for you: regulated AI has to answer, months later, what the system said and why. That is a logging design decision made now, not a forensics exercise made then.

A complete generation record captures the caller's identity and resolved entitlements, the query as issued, the filters applied, the chunk IDs retrieved with their source and classification at retrieval time, the masking transformations applied, the model and prompt version, and the response delivered.

If sensitive data enters the context window, assume it can exit through the response.

Because the log reproduces sensitive context, it inherits the classification of the data it records. Audit stores need the same access control and retention governance as the corpus, and masking should apply to logged content just as it does to live context.

Done well, auditability is also the operational feedback loop: leakage reviews, red-team findings, and access-anomaly detection all run off the same trace. Expressing those controls as versioned, testable artefacts rather than policy documents — the governance as code discipline — is what keeps them true after the launch team moves on.

#The Control Map

What this means for you: nine controls, each tied to a specific threat. The final column is the one to read before deciding which to defer.

#What Changes in Regulated Industries

What this means for you: in financial services, healthcare, and critical infrastructure, these controls stop being best practice and become the evidence base for a supervisory conversation.

The baseline is the same everywhere in the UK. There is no UK AI Act, so obligations run through existing regimes rather than a single statute.

The UK GDPR requires data minimisation and purpose limitation on what you retrieve, security of processing on where you store it, and data protection by design in how you build it. Each of those is satisfied by the pipeline controls above rather than by a policy statement.

Where a RAG system contributes to a significant automated decision, UK GDPR Articles 22A to 22D, introduced by the Data (Use and Access) Act 2025, set out the safeguards that must be in place. The operating model that satisfies them is a subject in its own right.

#What each sector adds on top of the baseline

Financial services. Supervisors expect demonstrable control over customer data flows, traceability of model-influenced outputs, and evidence that confidentiality obligations survive the AI layer. The FCA's Consumer Duty and the senior manager accountability regime put a named individual behind that evidence, and the PRA's SS1/23 model risk management framework, for firms within its scope, expects inventory, tiering, and independent validation.

Healthcare. Clinical text is special category data under Article 9 of the UK GDPR and carries a common-law duty of confidentiality alongside it. Minimum-necessary retrieval scoping and masking-before-context are the operative controls, with re-identification restricted to authorised care contexts and logged as an event in its own right.

Utilities and critical infrastructure. Operational documents are sensitive less for privacy than for safety and resilience, and operators of essential services carry obligations under the Network and Information Systems Regulations 2018. Classification ceilings and purpose-based scoping carry the weight here, and the semantic modelling that makes those classifications machine-enforceable is usually the prerequisite work.

Regulators reward architectures where controls are structural — enforced in the pipeline and provable from logs — over architectures where safety depends on the model behaving well.

Anyone trading into the EU should also read Article 2 of the EU AI Act, which brings providers and deployers established outside the Union into scope where the output of the system is used inside it. Tokenisation with a governed vault and complete generation logs are the default posture across all three sectors rather than an enhancement to it.

These are the patterns we implement in our data security and compliance engagements, and the retrieval boundary itself is one of the load-bearing walls in our enterprise agentic AI readiness framework.

#Frequently Asked Questions

#What is the biggest security risk in enterprise RAG?

Cross-tenant or cross-user leakage through a shared vector index. Similarity search ignores permissions, so without chunk-level access-control metadata and mandatory query-time filters, content from the wrong tenant or clearance level can be retrieved and surfaced. It is the most common defect in production systems because it fails silently: everything appears to work until an auditor or a customer notices.

#Should PII be masked before indexing or at query time?

Both, in layered fashion. Pre-index masking gives the strongest posture, because the index never holds raw identifiers, which also mitigates embedding inversion. Query-time scrubbing catches entities the first pass missed and cleans user queries before they reach the context window. Use deterministic tokenisation rather than blunt redaction wherever the model needs to reason about relationships between masked entities.

#Are embeddings themselves a data leak risk?

Yes, on two counts. Inversion techniques can partially reconstruct source text from stored vectors, and most vector databases store the original chunk text alongside the vectors in any case. Treat the vector store as a governed copy of its source data, with the same classification, the same identity and access management integration, and the same encryption and retention rules.

#How do you prevent prompt injection through retrieved documents?

Structurally, because detection alone is unreliable. Isolate retrieved chunks in the prompt as quoted data rather than instructions, restrict what the generation step is permitted to do regardless of what the context says, filter outputs for policy violations before delivery, and log every generation so injection attempts are discoverable afterwards. Reducing who can write into indexed sources closes the loop.

#Does UK law regulate RAG systems specifically?

Not as a named technology. There is no UK AI Act; the UK GDPR governs the personal data flowing through the pipeline, requiring minimisation, purpose limitation, security of processing, and design-stage protection. Where the system contributes to a significant automated decision, Articles 22A to 22D of the UK GDPR add safeguards. Sector rules and, for EU-facing output, the EU AI Act apply on top.

---

Unolabs is a Data and AI first engineering consultancy, headquartered in the United Kingdom with engineering operations in Pune and active engagements across the UK, Australia, and Hong Kong. We help enterprises build the architectural foundation for autonomous AI execution — governed data platforms, semantic intelligence, and agentic systems that enterprises can stand behind.

If you are preparing a RAG deployment for regulated data and need the control evidence to exist before launch, book a discovery call.