Permission-Aware AI: Access Control for Enterprise AI
Learn how permission-aware AI enforces access control at retrieval time, inherits source-system permissions, and prevents sensitive data exposure in enterprise AI.
8 min readby Prithvi
Permissions are enforced at retrieval time, per user, like the source systems — not at index time with a single service account.*
That one architecture decision is the reason why a deployment is either possible to scale beyond one team or impossible.
Systems that index everything under one privileged identity can work well in a pilot. But the second you add a second department, they can become a data-exposure problem: the AI is able to surface anything it indexed to anyone who asks the right question.
This guide covers the failure mode, what correct permission enforcement looks like, the security risks that have been documented in the literature, and the questions that distinguish actual permission handling from a website claim.
The Failure Mode: When AI Indexes Everything
Most retrieval systems are built in a straightforward way.
The product connects to your systems with a service account with wide read access, indexes everything it can reach, and answers questions from that index.
It is quick to build and works well in a pilot, because everyone using it may have similar access.
But it breaks in three predictable ways as it rolls out.
1. Exposure Across Departments
The index includes HR case notes, compensation information, financials that have not been released, and legal correspondence.
Someone in another function asks a question that semantically matches one of those documents, and the system returns content from it — or worse, summarises it without a link, so nothing in your audit log looks like a document access.
2. Stale Access
Someone switches teams or leaves a project.
Their permissions get updated in the source systems. The index doesn't.
It can therefore continue to serve them content they can no longer legitimately access.
3. Inference Without Direct Access
If the system summarises information from a document, a user without access to that document can still learn its contents.
Traditional access control is binary: you had the file open or you did not.
Generated summaries make that boundary porous in a way that most audit tooling was never built to catch.
The usual answer to all three problems is to limit what gets indexed.
That fixes the exposure problem by making the system less useful.
Hence all the deployments that end up with an AI that can only see the wiki.
How to Enforce AI Permissions Correctly
There are four properties a genuinely permission-aware AI system needs.
If it lacks any one of them, it is not truly permission-aware, regardless of what the marketing says.
1. Enforce Permissions at Retrieval Time, Not Index Time
The permission check should happen when the question is asked, against that user's current permissions.
It should not happen only when the document is ingested.
This is the load-bearing architectural decision.
Index-time filtering means the system's view of who can see what is effectively frozen at whatever point the indexing process ran.
Retrieval-time enforcement means the system checks the user's current access when it actually retrieves information.
2. Inherit Permissions From Source Systems
AI should not have its own separate access model.
It should read the existing permissions on each connected system and respect them.
A separate permission model in the AI tool creates two systems that can drift apart — and that drift will always favour over-exposure.
3. Return Results Per User
The same question from two people should produce different answers where their access is different.
If your system returns the same results to everybody, permissions are not being enforced at retrieval.
This is one of the easiest things to test, yet almost nobody tests it during an evaluation.
4. Log Retrieval Access
If the AI reads a document to answer someone's question, that access should appear in the audit trail as that user accessing the document.
Otherwise, you have created a channel through which information can move without a corresponding record — which is a finding waiting to happen in your next audit.
What Security Research Says About AI Access Control
There are two areas of published work worth knowing before you evaluate an enterprise AI system.
OWASP and Sensitive Information Disclosure
The OWASP Top 10 for LLM Applications is a direct response to security risks in this space.
Sensitive Information Disclosure relates to systems leaking information through generated output, not just through direct document access.
Excessive Agency describes systems with more ability or permission than the task requires. The particular risk here is an AI agent operating with the privileges of a service account rather than those of the user making the request.
RAG Access Control Research
Research published on arXiv has examined confused-deputy risks in RAG-based systems, where a user tricks a system with more privileges into fetching and disclosing information for them.
Related work argues that enterprise AI needs participant-aware access control: the identity of the person asking the question has to propagate all the way through retrieval rather than being checked once at the door.
NIST AI Risk Management Framework
The NIST AI Risk Management Framework provides the governance scaffolding through its Govern, Map, Measure, and Manage functions.
Access control and data provenance appear throughout the framework.
If your security team is asking for a framework to evaluate an AI deployment against, this is one of the key frameworks to understand.
A vendor that can speak clearly to all three areas can shorten a security review considerably. It shows that the vendor has encountered the actual risk model, rather than simply completing a generic security checklist.
RBAC Is Necessary but Not Sufficient
Permissions are often assigned by role using role-based access control (RBAC).
It is the right foundation, and it is where most vendors end up.
But RBAC alone does not solve three important problems.
Resource-Level Exceptions
Real organisations have plenty of exceptions:
- A specific deal room
- A confidential project
- A document shared with two people outside the owning team
These are not covered by simple role-based rules.
A system that only implements RBAC can therefore over-expose or over-restrict information.
Time-Limited Access
A contractor may have access for the length of an engagement.
An investigator may have access for the length of a case.
RBAC can handle the grant, but rarely handles the expiry by itself.
Expired-but-still-indexed access is therefore a common gap.
Purpose Restriction
GDPR and similar regimes do not permit data accessed for one purpose to automatically be used for another.
An AI system capable of retrieving anything a user could theoretically open might still be processing that information for a purpose that was never established.
The Practical Takeaway
When evaluating an AI system, ask whether it enforces RBAC and inherits resource-level permissions from source systems.
The second part is what deals with the exceptions.
And the exceptions are where the exposure is.
How Deployment Model Affects AI Permissions
Deployment model and permission enforcement are often treated as separate procurement questions.
They are actually interconnected.
Permission enforcement relies on the AI system reading your identity and access data — group memberships, sharing rules, resource-level grants, and other parts of the permission graph.
In a vendor-cloud setup, that access metadata leaves your environment along with the content.
For most organisations, that may be acceptable as part of a data processing agreement.
For some, it is not.
This is a category that is often missed because the focus is put on the documents rather than the permission graph describing who can access them.
Where Does the Permission Graph Live?
| Deployment | Where content resides | Where the permission graph resides |
|---|---|---|
| Vendor Cloud | Vendor infrastructure | Vendor infrastructure |
| BYOC | Your cloud account | Your cloud account |
| Local | Your network | Your network |
If your security review distinguishes between content and metadata about access, specifically ask where the latter lives.
Enterprise AI Permission Checklist
Bring these questions to a vendor call.
The answers quickly separate real implementations from everything else.
Permission Enforcement
- Are permissions enforced at index time or retrieval time?
- Does the system have its own permission model, or does it inherit from source systems?
- How quickly do permission changes in the source system propagate?
- Can you show two users asking the same question and getting different answers?
Auditability
- Is retrieval logged in our audit logs as user access?
- What happens when someone leaves or moves to a different team?
- Can a user learn the contents of a document they cannot open, in the form of a summary?
AI Agents
- When an agent takes action, is it using the user's permissions or a service account's permissions?
This is the Excessive Agency question, and it is one of the questions most often answered vaguely.
Data and Deployment
- Where does the real permission graph reside?
- Does the permission graph remain in our environment?
- How are resource-level permissions inherited from connected systems?
Common Objections to Permission-Aware AI
"Our data aren't that sensitive."
Nearly every organisation has compensation data, performance notes, legal correspondence, and unreleased financials somewhere in the systems being indexed.
The question is not whether there is sensitive data.
The question is whether the AI can get to it.
"We'll limit the index instead."
This works.
But it costs you the deployment.
The quickest way to get an enterprise AI system abandoned is to build one that can only look at public documentation and only answer questions that have already been publicly answered.
"We'll do permissions later."
Adding per-user enforcement to an index created with a service account usually involves rebuilding the retrieval layer.
It is a fundamental architectural decision, not a feature you simply add later.
How Libra Handles Permission-Aware AI
Libra implements permission-aware retrieval on every query, inheriting access from your source systems rather than running a parallel permission model.
It can run locally, in your own AWS, Azure, or GCP account, or on Libra Cloud so both the content and the permission graph can stay where your policy requires.
We never train on your data.
