RAG can quietly undo years of access-control work
When you connect a large language model to your company's documents, the retrieval step usually ignores the one thing your security team spent years getting right: who is allowed to see what. A user asks the assistant a question, the retriever pulls the most relevant passages from the vector store, and those passages land in the prompt regardless of whether that user could ever have opened the source file. The model then answers, helpfully, with content the person was never cleared to read. This is the central security problem with retrieval-augmented generation, and most teams discover it only after the assistant has surfaced a salary sheet or a board memo to the wrong audience.
RAG itself is a sound pattern. It grounds the model in your real data, cuts hallucination, and keeps answers current without retraining. The retrieval plumbing around it is where the risk sits, and it is the same lesson we keep relearning with every new integration layer: the model is rarely the weak point. The way you feed it data is.
How retrieval flattens your permission model
A standard RAG pipeline chunks documents, converts each chunk into an embedding, and stores those vectors in a database such as pgvector, Elasticsearch, OpenSearch, or a managed service. At query time it embeds the user's question, finds the nearest chunks by similarity, and pastes them into the prompt. Nothing in that default flow knows or cares about the access-control list on the original file.
The source systems had permissions. SharePoint, Confluence, the file server, the ticketing system, each enforced who could read each document. The moment you extract that content into a shared vector index, you have created a copy that carries none of those controls unless you deliberately rebuild them. Similarity search is permission-blind by design. It returns what is relevant, not what is authorised.
We have reviewed pipelines where a single index held HR records, finance data, and general wiki pages side by side, queried with one service account, and exposed to everyone with access to the chat interface. That is not an AI problem. It is a classic broken-access-control problem wearing new clothes, and it maps directly to sensitive-information disclosure in the OWASP Top 10 for LLM Applications.
Permission-aware retrieval, in practice
The fix is to make the retriever answer as the user, not as the application. Three techniques do most of the work, and they combine well.
Carry the ACL into the index
When you ingest a document, capture its access-control metadata alongside the vector: the groups, roles, or user IDs allowed to read it, plus a classification label. Re-sync that metadata when permissions change in the source, because a stale ACL is worse than none. Several vector stores and search platforms support this directly, sometimes marketed as security trimming or document-level permissions.
Filter by the caller's identity at query time
Pass the authenticated user's identity and group memberships into the retrieval call, and constrain the similarity search with a metadata filter so it only ever considers chunks that user is entitled to see. The filter should be applied inside the query, not as a post-hoc trim of results, so that a document the user cannot access never influences the answer and never appears in a citation.
Re-check authorisation after retrieval
Even with filtered search, run a final authorisation check against the source system's live permissions before the content reaches the model, for anything sensitive. Permissions drift between sync cycles, and this second gate catches the gap. Defence in depth applies here exactly as it does to any data path.
Isolation across tenants and trust boundaries
If you serve multiple customers, business units, or classification levels from one platform, the index is a shared resource that crosses trust boundaries, and it must be isolated accordingly. Give each tenant its own namespace, collection, or index rather than relying on a metadata filter alone to keep them apart. A filter is a single line of code away from being forgotten in a refactor; a physically separate collection fails safe. Whatever design you choose, write an automated test that asks tenant A's assistant for tenant B's data and confirms it gets nothing. Run that test in CI, not once at launch. This is the same isolation discipline we apply to multi-tenant SaaS and shared cloud environments, and it belongs in any RAG build that spans more than one audience.
Every retrieved chunk is untrusted input
Retrieval does not only leak data outward. It also carries data inward, and that data can be hostile. If an attacker can get a document into your corpus, a support ticket, an uploaded PDF, a wiki page edited by a low-privilege user, they can plant instructions inside it. When the retriever surfaces that chunk, the model may follow the buried instruction rather than the user's actual question. This is indirect prompt injection, and RAG is its most common delivery vehicle.
Treat retrieved content as untrusted data, never as instructions. Keep a clear separation in the prompt between the user's query and the retrieved material, so the model is told to use the passages as reference and not to obey commands found inside them. Track provenance on every chunk so you can trace a bad answer back to the document that caused it. Where the corpus accepts user-generated or externally sourced content, scan and review it before it is indexed, and constrain what the model is allowed to do with retrieved text, especially if the assistant can also call tools or take actions.
What you embed leaves a copy
Embedding is a data-processing step, and it deserves the same scrutiny as any other. Sending documents to a third-party embedding API means your content, or a mathematical representation of it that can leak information, has left your boundary. For regulated data in banking, telecom, healthcare, or public-sector work, that can breach data-residency rules or contractual controls on its own, before the model ever generates a word. In the UAE this intersects directly with PDPL and sector regulations that govern where personal and sensitive data may be processed.
Classify and, where appropriate, redact content before it is indexed, so that secrets and personal data are not embedded at all unless they must be. For sensitive corpora, run the embedding model and the vector store inside your own environment or an isolated tenancy, hardened to CIS Benchmarks, so the data and its vectors stay where you can attest to their location. Encrypt the index at rest, control who can query it, and remember that the ability to run arbitrary similarity searches over an index is itself a powerful read primitive that needs its own access control.
Naive RAG versus permission-aware RAG
DimensionNaive RAGPermission-aware RAG
Who the retriever acts as
The application / one service account
The authenticated end user
Access control at query time
None; similarity only
Metadata filter by user roles and groups
Source ACLs
Lost on ingestion
Captured, synced, and enforced
Multi-tenant separation
Shared index
Per-tenant namespace or index, tested in CI
Retrieved content
Trusted, pasted into prompt
Treated as untrusted data with provenance
Sensitive data
Embedded as-is
Classified, redacted, kept in-boundary
Auditability
Prompt logs only
Query, user, chunks, and citations logged to SIEM
Log what the assistant retrieved, and who asked
For investigation and compliance, the answer text is the least useful artefact. What matters is which user asked what, which chunks were retrieved, which documents they came from, and which of those were shown as citations. Log that at the retrieval boundary and forward it to your SIEM alongside the rest of your security telemetry. With that data in place, you can detect the patterns that signal abuse: a user whose queries suddenly reach into document sets they never touched before, a spike in retrieval volume, or repeated near-miss queries that look like someone probing for what the index will reveal. Without it, a data-exposure incident becomes unprovable in either direction, and that is the position no one wants to be in when an auditor or a regulator asks what happened.
A pre-production checklist for RAG security
- Retrieval runs as the authenticated user, carrying their roles and group memberships into every query.
- Source access-control metadata is captured at ingestion and re-synced when permissions change.
- Similarity search is constrained by a metadata filter so unauthorised chunks never enter the prompt or citations.
- Sensitive requests get a second authorisation check against live source permissions after retrieval.
- Tenants and classification levels are separated by namespace or index, with a cross-tenant leakage test running in CI.
- Retrieved content is treated as untrusted data, kept separate from instructions, and tracked with provenance.
- User-generated or external documents are scanned and reviewed before indexing.
- Content is classified and redacted before embedding, so secrets and personal data are not indexed unnecessarily.
- Embeddings and the vector store for sensitive data run in-boundary, encrypted at rest, and hardened to a recognised benchmark.
- Every query, user, retrieved chunk, and citation is logged to the SIEM, with detections for anomalous retrieval.
Miss the first three and the assistant is an open reading channel over data it should never expose. Miss the rest and you lose isolation, integrity, or the ability to prove what happened. All ten are achievable with tools that already exist; the work is in the wiring, not in inventing anything new.
Mapping RAG controls to the standards you already run
None of this requires a new governance framework. NIST CSF 2.0 covers the identify, protect, detect, and govern functions these controls sit under. ISO 27001 gives you the access-control and cryptography structure. PCI-DSS and SOC 2 set the evidentiary bar for payment and service environments, and in the UAE the PDPL and sector rules shape where data may be processed. Adopting RAG is an opportunity to extend those controls to a new data path, not a reason to work around them. When the retrieval layer respects the same permissions as the systems it draws from, the assistant becomes something you can defend in an audit rather than a gap you hope no one finds.
How Aydahwa Enterprise can help
Aydahwa Enterprise builds and secures data platforms for organisations in banking, telecom, and critical national infrastructure, where a single leaked document can be a regulated event rather than an embarrassment. Our work is led by a hands-on architect with more than 25 years across UNIX, Linux, Windows, and cloud, holding the Microsoft Cybersecurity Architect Expert certification, so the advice is grounded in systems we have actually designed and defended.
We help you design permission-aware retrieval, tenant isolation, and SIEM-backed auditing around your RAG and AI assistants, and we map those controls to ISO 27001, PCI-DSS, SOC 2, NIST CSF, CIS Benchmarks, and UAE data-protection requirements so your rollout stands up to scrutiny. If sensitive data means the embedding model and vector store need to run on-premises or in an isolated tenancy, we cover that end to end. Explore our cybersecurity services and cloud security and migration work, or start with the free cybersecurity self-assessment and readiness checklist to gauge where you stand. When you want to talk specifics, get in touch and we will help you deploy RAG that keeps your data on the right side of every permission you already enforce.
