Your finance manager types a question into the new internal chatbot and it hands back a paragraph from a colleague's salary slip. Nobody clicked anything they shouldn't have. The system just retrieved it. That is the default behaviour when a RAG deployment is built without rag access control, and in the UAE it can be a reportable data breach under the Personal Data Protection Law, not just an embarrassment.
Key Takeaways
- RAG retrieves the most relevant content, not the most permitted — Without a permissions layer, vector search returns whatever is semantically closest, so staff can surface a colleague's salary slip or a client's Emirates ID they have no right to see.
- Exposing personal data via a misconfigured RAG chatbot is a legal breach — Federal Decree-Law No. 45 of 2021 (PDPL), in force since 2 January 2022, applies regardless of intent. DIFC and ADGM companies carry an additional layered regime on top of the federal law.
- Filtering results after retrieval doesn't fix the exposure — Restricted document IDs are already surfaced inside your infrastructure before the filter runs. The fix is in-database authorisation, which keeps restricted chunks out of the candidate set entirely.
- Tag every document with permission metadata before indexing — Each chunk needs a tag for department or role, PDPL sensitivity level, and document type, checked at query time. Retrofitting these tags after launch costs far more than designing the schema up front.
- RBAC covers most UAE SME access needs; ReBAC is the exception — RBAC assigns permission by role, like Sales seeing pricing and Engineering seeing specs, and fits clean departmental splits. ReBAC is only needed when access is relationship-dependent, such as a manager seeing everything their direct reports can see.
Why RAG Pipelines Are Built to Ignore Permissions
RAG is optimised for one thing: finding the most semantically relevant chunk of text for a given question. Permission is not part of that objective. As one authorisation vendor puts it, RAG pipelines are great for finding relevant information but terrible at respecting permissions.
Vector databases introduce a structural gap between authorisation logic and semantic search. The engine returns the closest match. Whether the person on the other side may read it is a question the store was never designed to answer.
OWASP, the authority on application security standards, lists Sensitive Information Disclosure and Vector and Embedding Weaknesses among its Top 10 Risks for Large Language Model Applications. Both map directly onto badly built rag access control.
In a UAE knowledge base the exposure is concrete. Corporate document sets here contain Emirates IDs, trade licences, VAT invoices, salary records and signed client agreements, often with Arabic and English mixed on one page. Push all of that into a vector store with no permissions layer and every document becomes retrievable by anyone who can type a question. The mechanics of how documents get indexed and queried are covered in how RAG works with a real company knowledge base.
For information security more broadly the reference standard is ISO/IEC 27001, which most UAE procurement checklists still lead with.
RAG Access Control as a UAE Compliance Obligation
Photo: Markus Winkler on Pexels
Here is what makes rag access control a legal question in the UAE, not just an engineering one. Federal Decree-Law No. 45 of 2021, the PDPL, came into force on 2 January 2022. The UAE Data Office was established under Federal Decree-Law No. 44 of 2021 as the federal regulator. Surfacing protected personal data to an unauthorised employee through an AI system can constitute a breach regardless of intent.
Companies in DIFC and ADGM sit under an additional layered regime on top of the federal PDPL, with their own data protection authorities and reporting expectations. If you operate inside one of those free zones, your access control architecture has to account for both layers at once.
The consequence is direct. If a chatbot retrieves a colleague's salary slip for a broad HR question, or pulls a client's Emirates ID into a summary for a different account manager, that is a reportable incident. Permissions in RAG are a compliance obligation for any UAE business handling personal or commercially sensitive data, not an optional refinement.
Three Ways to Enforce RAG Access Control, and Why Two of Them Break
Three broad architectures exist for adding permissions to a RAG pipeline. Two look reasonable on a whiteboard and fall apart in production. One works.
Filter after search. Ask the vector store for the top 10 results, throw out the eight the user should not see, keep the two that survive, then ask for results 11 to 20 and repeat. Each iteration means another vector similarity search, two network hops and a loop cycle. It is slow, wasteful, and restricted document IDs have already been surfaced inside your infrastructure before the filter ran.
Filter before search. Fetch the list of authorised document IDs from the application database and pass it as a filter into the vector search. This holds up for small permission sets. It breaks the moment a user legitimately has access to 50,000 documents, because the filter itself becomes the bottleneck and semantic search degrades to picking something relevant inside a huge allow-list.
In-database authorisation. Embed the permission check inside the retrieval operation itself. No restricted chunk ever enters the candidate set. Authorisation specialists describe this as treating authorisation as an internal concern rather than an external one, and it is the only approach that closes the gap.
Retrieval quality also suffers when filters are bolted on outside the vector search: ranking is calculated against the wrong candidate set and answers drift toward vague, a failure mode we unpack in chunking, embeddings and retrieval quality.
Comparing the three approaches side by side makes clear why only one closes the gap.
| Approach | How it works | Outcome |
|---|---|---|
| Filter after search | Fetch top results, discard the ones the user shouldn't see, repeat | Slow, and restricted document IDs are already exposed internally |
| Filter before search | Pass a list of authorised document IDs into the vector search | Breaks once a user has access to 50,000 documents |
| In-database authorisation | Permission check is embedded inside the retrieval operation itself | No restricted chunk ever enters the candidate set |
RBAC vs ReBAC: Picking a RAG Access Control Model
Two models dominate access control conversations. The right one depends on how you actually grant document access today.
Role-based access control (RBAC) assigns permissions to roles. Engineering sees technical specs. Sales sees pricing. Finance sees the ledger. It is simple to implement, maps onto an org chart, and covers the majority of access patterns for UAE SMEs. When departmental splits are clean and documents belong to a department rather than to specific individuals, RBAC is almost certainly enough.
Relationship-based access control (ReBAC) tracks who can access which specific document, not just which role they hold. It draws on the same principles as Google's Zanzibar, whose whitepaper was published in 2019, with an open-source implementation called SpiceDB available for teams that want to model relationships that way. ReBAC becomes necessary when the same document must be visible to some members of a team but not others, or when permissions are inherited through relationships such as a manager seeing everything their direct reports can see.
Most UAE SMEs never need ReBAC. If you do, you will already know, because your existing access rules read like relationships rather than roles. Unsure which model fits your document set? That is a good question to raise on a scoping call with the Lenoo AI team before any code is written.
Permission Metadata: The Foundation of RAG Access Control
Photo: Markus Winkler on Pexels
Permission information has to live in the document itself, attached as metadata at indexing time. This is the piece most teams get wrong when they try to retrofit access control onto an existing RAG system.
Every chunk needs an identifier for who is allowed to retrieve it. The pattern is a document-level tag that the permission system checks at query time. For UAE compliance, useful tags include the department or role permitted to see it, the sensitivity level under PDPL (personal data, financial data, commercially confidential), and the document type (Emirates ID, VAT invoice, salary record, trade licence, client agreement).
Bilingual content adds a wrinkle. UAE documents routinely mix Arabic and English on the same page, so the metadata schema has to stay language-agnostic and consistent regardless of the underlying text. The permission check cannot depend on being able to read the document; it depends on knowing what the document is and who owns it.
Retrofitting permission tags after a RAG system is live is significantly more expensive than designing the schema before launch. This decision belongs at the start of the project.
What an Access-Controlled RAG Pipeline Looks Like from Query to Answer
If you are evaluating a proposal from a vendor, this is the shape the pipeline should take. It is worth being able to spot when a step is missing.
Step 1: identity check. Before the query reaches the vector store, the system establishes who the user is and what they may retrieve. This is the gate, not an afterthought bolted on later.
Step 2: constrained retrieval. The vector search runs only against document chunks the user is authorised to see. No restricted chunk enters the candidate set at any stage.
Step 3: post-retrieval guard. A secondary check confirms nothing slipped through, which matters when permission rules are complex or overlapping.
Step 4: grounded generation. The LLM receives only the permitted chunks and generates its answer from those. If it cannot support an answer from permitted content, the system says so rather than inventing one.
This is the broad pipeline described in our guide to RAG for business, wrapped in an authorisation layer at every retrieval step. When the knowledge base draws on structured records or organisational graphs rather than pure documents, the retrieval pattern shifts and permissions have to be modelled differently, which we cover in Graph RAG and structured data.
Where to Start If Your RAG Deployment Has No Access Control Yet
Start with an audit of documents, not a debate about technology. Which files in your knowledge base contain personal data under PDPL? Which contain salary information, client agreements or financial records? Those documents define the minimum scope of your permission requirements.
Next, map your existing access rules before touching anything technical. Who is supposed to see what? How do those rules change when someone joins a new team, changes role or leaves? If you cannot write this down on paper, no permission library will save you.
For most UAE SMEs working in the AED 10,000 to 50,000 or AED 50,000 to 200,000 budget bands, a well-scoped RBAC implementation covers the majority of practical risk. ReBAC becomes necessary only when access patterns are genuinely relationship-dependent. Do not over-engineer the model to solve a problem your business does not have.
If you are unsure where your current RAG setup is exposed, or you have not started yet and want an honest read on what to prioritise, book a free 30-minute consultation with Lenoo AI. We will identify the gaps, tell you which ones matter for your business, and give you a straight recommendation, including if access control is not the most urgent next step right now.
Related reading
FAQ
Can a RAG chatbot accidentally show one employee documents that belong to a different department?
Yes. This is the default behaviour of a RAG system built without an explicit permissions layer, because the vector search returns whatever is most semantically relevant with no awareness of which documents the employee is authorised to see.
Does the UAE's PDPL apply to internal AI systems that process employee or customer data?
Yes. Federal Decree-Law No. 45 of 2021 applies to the processing of personal data whether the system is customer-facing or internal, and an AI tool that surfaces personal data to an unauthorised person is a processing event under the law.
What is the practical difference between filtering before retrieval and filtering after retrieval?
Filtering after retrieval means the vector store returned restricted results that the application then throws away, which is slow and exposes the IDs internally. Filtering before retrieval passes an allow-list into the search, which works for small sets but breaks when a user has access to tens of thousands of documents.
Should access control be designed into a RAG system from the start, or added after launch?
Design it from the start. Retrofitting permission metadata onto documents already indexed and vectorised is significantly more expensive than tagging them the first time, and it means running the system with a compliance gap in the meantime.
What is the difference between RBAC and ReBAC for a small or mid-size business?
RBAC assigns permissions by role: Sales sees pricing, Engineering sees specs. ReBAC assigns permissions by relationship to specific resources, so two people in the same role might legitimately see different documents. Most UAE SMEs are fine with RBAC.
How do DIFC or ADGM requirements change the access control architecture for a RAG deployment?
Companies in DIFC and ADGM sit under those free zones' own data protection regimes in addition to the federal PDPL. The core architecture is the same, but the tagging schema needs to reflect extra classifications and the audit trail must satisfy the free zone regulator as well as the federal one.
Does RAG access control work differently when the knowledge base contains Arabic documents?
The permission logic works the same. The metadata schema has to be language-agnostic so tags such as sensitivity level and department apply consistently whether the underlying text is Arabic, English or a mix, because the permission check cannot depend on being able to read the document.
