Does Your AI Assistant See More Than Your Users?

The AI assistant you deploy on internal data is a ticking time bomb if you connect it through a single service account. The risk everyone fears is external attack: a hacker siphoning the database. The real risk, materializing daily in companies that skipped the permissions design phase, is lateral leak between teams: an authorized employee extracting through the assistant what the application screen denies them.

This article treats the AI layer as one more user, subject to the same permissions as your human staff, and distinguishes two architectures with opposite consequences: the unified index queried by a service account versus the query executed under the user's identity. It adds query and export logging as a standalone requirement, because what matters is not only who can see what, but also who will be able to reconstruct six months later what was seen.

The leak you fear comes from inside, not outside

Classic scenario in RFPs: a CISO asks how you prevent an external intrusion from extracting all internal documentation via the AI assistant. The answer is trivial: encryption in transit, OAuth authentication, network segmentation, access log auditing. Important, but not the real problem.

The real problem is the legitimate employee who asks an innocuous question and gets an answer they should never have seen. Three concrete cases, all flagged during client audits in the last six months:

1. A junior buyer queries the assistant about average supplier payment terms. The assistant quotes a financial dashboard the buyer cannot access in the management system, with cash figures only the finance team should see.

2. A marketing manager requests a summary of current campaign performance. The assistant includes CRM sales data in its answer, notably margins per customer, though marketing never had margin access.

3. A project officer queries the assistant about case progress. The assistant quotes an internal email between general management and legal, classified confidential, because the index contains every email from the Exchange server.

In all three cases, the assistant worked exactly as designed: it searched the index, found the information, and returned it. The problem is not a technical bug, it is an architecture where AI has access to everything and filters afterward, which amounts to no filtering at all.

Two architectures, two risk levels: service account versus user identity

There are two ways to design AI assistant permissions on internal data.

Architecture 1: unified index with service account. All data is indexed in a single search engine (Elasticsearch, Azure Cognitive Search, vector database). The AI assistant queries this index with a service account granted universal read rights. User permissions are supposedly applied after the search, when the assistant filters results before displaying them.

This is the default approach in 80 percent of deployments we audited, because it is the simplest to implement and best documented by RAG platform vendors. The problem is this architecture turns AI into a bypass of all business permissions.

Why? Because filtering afterward means asking the AI to redo the access control system's job, while it has zero visibility into business rules governing those rights. An example: in your ERP, a buyer can see purchase order lines for their geographic scope, but not margins negotiated at group level. This rule is not a simple filter "margin field equals masked", it is application logic combining role, geographic scope, hierarchy level, and contract type. How should the AI reproduce it after retrieving a document mixing everything?

Short answer: it cannot. So it returns everything, or it filters on approximate criteria that let leaks through. Both scenarios have been measured in production.

Architecture 2: query executed under user identity. The AI has no service account. When a user asks a question, the assistant forwards the query to source systems (ERP, CRM, file server, document repository) impersonating that user, via an OAuth token or Kerberos impersonation. Source systems apply their own permission rules and return only what the user is allowed to see.

This is the approach we have recommended since January 2026 to every client managing sensitive data or compartmentalized business scopes. It costs more to implement because it requires connecting AI to each source system via its authenticated API rather than indexing everything into a single silo. But it delegates rights management to systems that already know it, instead of recoding it in an AI layer with zero legitimacy to do so.

Why filtering the answer afterward protects nothing

A RAG platform vendor will tell you: "our system applies security filters on results before displaying them to the user, so even if the AI queries a global index, the user will see only what they are allowed to see."

Here is why this argument does not hold.

First issue: filtering relies on metadata nobody maintains. To filter, you need to know who can see what. So each indexed document must carry metadata like "visible by: Finance team, management role, N+2 level". In companies we audited, this metadata simply does not exist, or is inconsistent across systems. Result: either the index is open to all, or closed to all, which makes AI useless.

Second issue: business rules are not tags. Business permissions never reduce to a tag list. They combine role, organizational scope, data context, and application logic. Real example: a purchasing manager can see signed purchase orders from their scope, but not quotes under negotiation carried by a colleague in the same department. This is not a tag "visible by purchasing", it is a rule "visible if signed AND user scope OR if case owner". Reproducing this logic in a generic search filter means recoding the entire ERP in the AI layer.

Third issue: AI sees data before filtering. Even if filtering worked perfectly, the AI read forbidden data to be able to filter it. Current language models keep session memory: if the assistant saw a confidential document in a previous query, it can reuse fragments in a later answer, even if the filtered document should no longer be visible. This is not a bug, this is normal behavior for a long-context model.

Bottom line: post-query filtering is an illusion of security. It can work on simple cases (a public document versus a private one), but fails as soon as permission rules reflect a real organization with business scopes.

Role and scope: two distinct dimensions vendors conflate

A recurring confusion in specifications: asking the vendor "how do you manage user roles in AI" and getting as answer "we apply team filters on search results".

Role and scope are two distinct dimensions.

Role defines what a user can do: view, edit, approve, export. In an ERP, a management controller has "read-only" role on accounting data, while an accountant has "edit" role. Role says nothing about which data the user can see, only what they can do with it.

Scope defines which data a user can see: their team, their region, their customers, their cases. In a CRM, a sales rep can see opportunities in their portfolio, while a sales director can see all opportunities in their region. Scope says nothing about what the user can do with this data, only which they can touch.

A complete permissions system combines both: role AND scope. A junior buyer has "read" role on "suppliers in their category" scope, while a purchasing director has "edit" role on "all group suppliers" scope. If your AI vendor does not distinguish the two, they cannot reproduce business rules from your applications.

What happens to a document's rights when it enters an index

Question asked by a CIO during a March 2026 workshop: "when we index a SharePoint document into AI, do SharePoint rights follow the document into the index?"

Short answer: no, unless you explicitly code it.

By default, an indexer (whether Elasticsearch, Pinecone, or Azure AI Search) knows nothing about source system permissions. It extracts document content, computes vector embeddings, records it in the index, and forgets everything else. SharePoint rights stay in SharePoint.

For rights to follow the document, the indexer must retrieve each document's access control lists (ACL) and store them as metadata in the index, then the search layer must filter results based on the connected user. This is technically feasible, but a customization 90 percent of vendors do not deliver by default.

Practical consequence: if you index a SharePoint with restricted libraries and query this index with a service account, all documents become visible to all users going through AI, regardless of SharePoint rights. The leak is structural.

Fallback solution: do not index, and force AI to query SharePoint via its Graph API with the connected user's token. SharePoint applies its own rights and returns only what the user can see. This is architecture 2 described above.

Log queries and exports: what you must be able to reconstruct six months later

A data leak is never detected the same day. It is discovered three months, six months, sometimes a year later, during an audit, security incident, or customer complaint. At that point, the question becomes: who saw what, and when?

To answer it, your system must log four elements:

1. Who asked the question. Identity of the connected user, not "AI service account". If all logs read "service-account-rag-prod", you will never trace a leak.

2. What question was asked. Exact text of the user query, not just "search performed". A query "which customers have over 500K€ revenue?" does not have the same sensitivity level as "what is the weather in Casablanca?".

3. Which documents were consulted to answer. Identifiers of documents retrieved by the RAG, with their source system (ERP, CRM, SharePoint, document repository). If AI quoted a confidential financial dashboard, you must be able to find which Excel file was used.

4. What answer was displayed to the user. Text generated by the AI, because this is what the user actually saw. A document may contain a hundred lines, but if AI quoted only one, it is not the same exposure.

These four elements must be recorded in an immutable log system, with timestamp and signature, to reconstruct a reliable timeline during an audit. GDPR and Moroccan law 09-08 both mandate traceability of personal data access, so legally this is not optional.

In practice, we found 60 percent of enterprise AI deployments log nothing beyond "query executed". No trace of user, no trace of consulted documents, no trace of displayed answer. If a leak materializes, the company can neither prove nor quantify it, putting it in breach with CNDP or a court.

Six questions to ask the vendor, and answers that should alert you

Here are six questions to ask any RAG platform or AI assistant vendor on internal data. Answers indicate whether the vendor designed security from the start, or whether permissions are a cosmetic layer added afterward.

Question 1: does AI query a global index with a service account, or does it query source systems under user identity?

Expected answer: under user identity, via OAuth tokens or impersonation. If the answer is "global index", ask how permissions are applied and who maintains rights metadata.

Question 2: if a document changes rights in the source system (a SharePoint file becomes confidential), how long before the index reflects this change?

Expected answer: real-time, or under fifteen minutes. If the answer is "weekly re-indexing", you have a seven-day window where a confidential document stays visible to all.

Question 3: can AI quote a document the user is not allowed to open in the source application?

Expected answer: no, never, because AI receives only authorized documents. If the answer is "we filter results before display", ask how this filter reproduces business rules from the source system.

Question 4: do logs record the identity of the user who asked the question, or only the service account that queried the index?

Expected answer: user identity, in an immutable log. If the answer is "we log system queries", you will never trace a leak.

Question 5: if a user exports an AI answer (copy-paste, PDF, screenshot), is this export logged?

Expected answer: yes, with user identity, timestamp, and exported content. If the answer is "we do not manage exports", you have a gaping hole in traceability.

Question 6: if I ask you in six months who accessed a specific document via AI, can you provide the list?

Expected answer: yes, with query, answer, and timestamp. If the answer is "we do not retain this data", you are in GDPR breach as soon as personal data transits through AI.

The first three questions test permissions architecture. The last three test traceability. If a vendor fails more than two questions, either they did not design their product for sensitive data, or they are selling cosmetic security.

FAQ

Can we apply the same permissions to AI as to a human user?

Yes, this is exactly what the impersonation architecture does: AI queries source systems impersonating the connected user, so it inherits their permissions. The source system sees no difference between a human query and an AI query, it applies the same rules.

If AI can only see what the user can see, does this limit its usefulness?

No, because the user asks questions about data they already have the right to see. AI does not serve to bypass permissions, it serves to synthesize and cross-reference scattered data. A buyer querying AI about their suppliers will get a useful answer even if AI sees only their scope, because their scope is what interests them.

Can filtering results after search work if rights metadata is properly maintained?

On simple cases, yes. On real organizations with complex business rules, no. Rights metadata is never up to date because nobody has time to maintain it manually, and because business rules change faster than tags. Impersonation delegates this maintenance to the source system, which already knows it.

How to log queries without violating GDPR?

GDPR mandates logging access to personal data, so recording who consulted what is an obligation, not a violation. What matters is securing logs (encryption, restricted access, limited retention period) and using them only for audit and security, never for generalized surveillance.

Can a user extract data via AI even if they do not have the right to export it in the source application?

Yes, if AI allows copy-paste or PDF generation without control. This is why exports must be logged and, in some cases, blocked. A user who has the right to view a document does not necessarily have the right to export it, and AI must respect this distinction.

Need to audit your AI permissions or design a secure architecture for your internal data? We support companies in implementing RAG systems compliant with business and regulatory requirements. Discover our enterprise RAG offering and our digital consulting support.