Connecting an AI assistant to your company's documents is one of the fastest ways to show value with AI. You ask how a machine is calibrated, what a supplier contract says or when a piece of equipment was last serviced, and it answers in seconds, citing the document. The problem shows up the day someone asks something they shouldn't know, and the assistant knows it.

When I build one of these assistants, the first question I ask isn't which model to use. It's who can read each document, and at what point that gets checked.

◢How does an AI assistant over documents (RAG) work?

The technique is called RAG, retrieval-augmented generation. The assistant doesn't learn your documents. It splits them into chunks, stores each chunk in a special search index (a vector database) and, every time someone asks, it looks up the chunks most similar to the question and hands them to the model along with it. The model writes the answer from what it has just read.

That middle step is the key to everything that follows: whatever enters the model's context is something the model can repeat.

◢Why can an assistant over documents leak data?

Because the search index doesn't know who is asking unless you tell it. If the public manual, internal reports and payroll all go into the same index, and retrieval doesn't filter by user, the intern and the CFO get the same chunks. The model will answer both with whatever it finds.

No attack is needed. A normal question from someone without permission is enough.

◢Redact the answer or filter the search: try it yourself

There are two ways to apply a permission. The tempting one is to let the assistant read everything and redact afterwards what the user isn't allowed to see. The right one is for the search to never hand the model the chunks that user can't read.

In the exhibit below the question is always the same. Change the level of the person asking and where the permission is applied, and watch the list of chunks: those are the ones that reach the model.

Interactive exhibitWhat each level sees

An AI assistant answers from the company's documents (RAG). The question is the same; what changes is who asks and where the permission is applied. Fictional data.

Who is asking

PublicInternalConfidential

Permission applied by

Redacting the answerFiltering the search

Question

Who signed off the last check of the line 2 brake tester, and what tolerance is it calibrated to?

Assistant's answer

The last check of the line 2 brake tester was on October 14. It was signed off by technician B. It's calibrated to a tolerance of ±2%, according to manual MT-23, chapter 4.

In case it helps: it's the same night-shift colleague who opened the September incident.

Leak by paraphrase. The name is redacted, but the fragment was in the context and the model describes it in other words.

Fragments the model reads

• Public · in the contextManual MT-23, ch. 4. Brake tester calibration procedure.
• Internal · in the contextInspection log. Content restricted to level internal.
• Confidential · in the contextSign-off sheet. Content restricted to level confidential.

With the permission applied at the end, the name is blacked out, but the model has already read the chunk. If it lets a hint slip through a paraphrase ("the night-shift colleague"), the redaction misses it, because it doesn't match the text that had to be hidden. With the permission applied at retrieval, that chunk never arrives and there is nothing left to slip out.

◢Is it enough to tell the assistant not to reveal confidential data?

No. An instruction like "don't reveal confidential information" is a request to the model, not a control. It can fail through a slip by the model itself and, above all, it can be bypassed by text crafted for that purpose, which is exactly what indirect prompt injection does. Any data that sits in the context should be treated as seen.

Security has to live outside the model, in the code that decides which chunks it receives. It's the same idea as with AI agents with too many permissions: the model should only have at hand what it needs for that person and that task.

◢What if I use Copilot or a commercial assistant?

That moves the problem somewhere else: if half your staff can open the payroll folder because someone shared it with "everyone in the organisation" years ago, the assistant will respect that wrong permission. The risk used to be that someone would stumble on that folder. Now they only have to ask. So before switching on any assistant over documents, a permissions clean-up comes first.

◢What to do before connecting an assistant to your documents

If you're going to build or buy one, these are the questions I would ask:

• ▹Does each chunk store who can read it? The permission has to travel with the piece of document, not stay behind on the original folder.
• ▹Does retrieval filter by the user's real identity before anything is passed to the model? If the answer is "we filter at the end", that's the bad option from the exhibit.
• ▹Are there separate indexes for what is truly sensitive? HR, management and customer data shouldn't share a search index with the onboarding handbook.
• ▹Are permissions updated when someone changes role or leaves? An index copied once and never synced keeps access that no longer exists.
• ▹Is there a log of what each user asked and which chunks they received? Without it there's no way to investigate a leak.

On the staff side, everyone should understand what the assistant sees and why they shouldn't upload internal documents to external AI tools on their own. I wrote a guide on what not to paste into ChatGPT.

◢A simple test before going live

Create a test user with the lowest access level and ask the assistant about things that user shouldn't know: a salary, an incident with a customer, the name of whoever signed something. Ask directly and also sideways ("who usually handles...?"). If any answer gives something away, the permission is in the wrong place.

If you want your team to understand these risks before they start using AI with company data, that's exactly what I cover in the AI training for teams.