Guides › Secure RAG › Restricted documents

Can Employees See Restricted Documents Through an AI Assistant?

Hunter Moore, Founder and CTO · Updated August 4, 2026

Often, yes. Not by circumventing anything. An internal assistant built on retrieval will surface content an employee cannot open directly whenever the index was built with broader access than the person asking, which is the default configuration in most deployments.

At a glance
  • Usually yes. An index built by a broad-scope service account holds the union of what every employee can see.
  • No exploit involved. The retriever returns the best semantic match unless it re-checks the asking identity's entitlements at query time.
  • Hard to notice. There is no error and no alert, and the source system recorded the indexing account rather than the employee.

How does that happen without an exploit?

The connector that builds the index authenticates as a service account with broad read scope, because that is the only practical way to index everything on a schedule. The index then contains the union of what all employees can see.

When someone queries the assistant, the retriever searches that union. Unless it re-checks the requesting person's entitlements at that moment, it returns the best semantic match regardless of who asked. The employee did nothing unusual. They asked a question and got an answer.

WHAT THE ASSISTANT CHANGED WAS NOT THE PERMISSION, IT WAS THE REACH Before After finding it required knowing about it finding it requires a sentence Know the document exists Know which system holds it Know roughly what it is called Have the folder open to you Search by filename or keyword Ask a question in plain language Semantic search removed every step on the left. The obscurity that was quietly acting as access control stopped working, all at once, for the whole corpus. The over-sharing was usually there for years. What arrived with the assistant is discoverability. That distinction decides where the fix belongs: tightening the retriever treats a symptom if the document was world-readable at source.
An internal assistant rarely creates the exposure. It removes the friction that was standing in for a control, which is why the problem appears suddenly in systems that did not change.

What does it look like in practice?

Someone asks about bonus structure and the answer reflects the actual compensation band table. Someone asks why a project slipped and the answer draws on a post-incident review restricted to the security team. Someone asks about headcount plans and the answer includes a reorganization that has not been announced.

In each case the assistant is behaving correctly by its own logic. There is no error, no alert, and usually no log entry that marks the moment as significant. The employee may not even realize they saw something restricted, because the answer arrives as prose rather than as a document with a classification banner.

The assistant did not create the exposure. It made it reachable in one sentence.

Is this the AI's fault?

Mostly not. The underlying content was frequently over-shared long before the assistant existed. It sat in a SharePoint site with inherited permissions nobody reviewed, or a shared drive folder that was opened up once for a project and never closed.

What changed is discoverability. Finding a mislabeled file used to require knowing it existed and where to look. Semantic search removed that friction entirely, so the obscurity that was quietly acting as access control stopped working. The assistant did not create the exposure. It made it reachable in one sentence.

What to do

That distinction matters when assigning the fix. If a document was world-readable in the source system, tightening the retriever treats a symptom.

How do you find out whether yours does this?

  1. Pick the documentsA handful of genuinely restricted documents that are already in the index.
  2. Pick the identitiesTest identities at different access levels.
  3. Write the questionsQuestions whose answers live in those documents.
  4. Run the matrixRun each question as each identity.
  5. CompareCheck what came back against what each identity was entitled to.

The full method, including the prerequisite of retrieval logging, is set out in the RAG leakage self-test. Most teams get a usable answer in an afternoon, and the number is usually higher than expected.

What stops it?

Entitlements enforced per query against the person asking, applied as a filter before similarity search rather than after. Post-filtering, where the system retrieves first and discards afterward, still leaks through result counts and latency and degrades answer quality besides. The mechanics are in RAG permissions.

Alongside that, handling content at ingestion so the sensitive material in indexed documents is transformed before it becomes an embedding. That way an entitlement mistake costs less, because the chunk that leaked carries less.

WHERE THE EVIDENCE IS, AND IS NOT Source system log Shows the indexing service account reading the file, on a schedule, months ago. The employee does not appear at all. Useless for this question Retrieval log Shows which chunks were returned, to which identity, for which query. This is the only record that answers it. The only sufficient record Model provider log Shows the prompt and the completion. No entitlement context, and frequently no retention you control. Insufficient on its own If retrieval provenance is not logged, the disclosure is not merely undetected. It is unreconstructable after the fact. You will not be able to answer which documents went to whom, which is the first question counsel asks. Turn retrieval logging on before you look for leaks. It is the cheapest item on the list and every other finding depends on it. Retention should match the source data's clock, not the application's default.
The reason this goes undetected for long periods is structural. The system that holds the document never saw the employee, and the system that did see them is usually not recording.

What should you do if you find it already happened?

Treat it as a disclosure rather than a bug. Establish which documents were returned, to whom, and over what period, which requires retrieval logs. Involve counsel early if the content includes personal data, because notification duties can attach even though no system was breached in the conventional sense.

  1. Retrieval filteringCloses the ongoing exposure.
  2. Source-system permissionsClose the underlying one.
  3. Ingestion controlsReduce what the next mistake costs.

Frequently asked questions

Does this apply to Microsoft 365 Copilot and similar tools?

The same dynamic applies to any assistant retrieving over a corporate corpus, though products differ in how faithfully they honour source permissions. The question to ask any vendor is whether entitlements are evaluated per user at query time or captured at index time, and how quickly revocations propagate.

Would we see this in an access log?

Not in the source system's log, because the source system was accessed by the indexing service account, not by the employee. You would only see it in retrieval logs, if you keep them. That gap is why this goes undetected for long periods.

Is restricting the assistant to public documents a reasonable answer?

It is safe and usually leaves the assistant unable to answer the questions people actually have, which means adoption collapses or exceptions accumulate. Enforcing entitlements properly is more work and preserves the value.

How quickly do revoked permissions take effect?

As quickly as your index refreshes, which for many deployments is nightly. That leaves a window where someone who left the team, or the company, still matches chunks they can no longer open. Offboarding is the case worth testing first.

Sources

Hardshell, RAG leakage self-test. · Hardshell, RAG permissions. · Hardshell, Secure RAG.