Your AI assistant inherited your access problem

Somewhere in your shared drive there’s a folder like this one. Policy documents, an old acquisition plan nobody remembers and a spreadsheet someone copied out of a restricted finance workspace three years ago. Nobody stumbles on the sensitive files by browsing. They’re buried.

Then you connect an AI assistant, and search and summarisation make buried things easy to find.

Here’s the uncomfortable part: the assistant may not have broken a single access rule. The rule was wrong all along. AI just made the existing access efficient enough to matter.

Follow the whole path from source to answer

Start with the sources in your first release. For each one, find the owner, the intended audience and how access is granted and removed. Include the copies and exports, because the permission on a copy is often not the permission on the original.

Then look at everything derived from them: search indexes, extracted text, embeddings, conversation history, cached answers. Information can linger in any of these after the source changes. Your access design needs to explain how a user’s identity and current permissions apply all the way along that path.

OWASP’s guidance on vector and embedding weaknesses describes leakage from weak access controls and mixed contexts. Permission-aware retrieval and separation between datasets are real controls. Telling the model to keep secrets is not.

Test the questions it must not answer

Build your evaluation around people as well as questions. A finance reviewer and an operations colleague can ask the same thing and rightly get different evidence. Try direct questions, indirect summaries and requests that compare several documents. A restricted fact can leak through an aggregate or a summary even when the document itself never appears.

Then change some permissions and watch. Remove someone from a group. Restrict a document. Delete an obsolete copy. Check new answers, earlier conversations and caches against your retention policy. Write down how long changes should take to apply, and who owns it when they don’t.

Use representative data in controlled conditions. Don’t plant real secrets in a test just to see whether the model gives them away. Your security team should choose evidence that fits the environment and the threats you actually face.

Keep “allowed” separate from “accurate”

A correct answer can still be an unauthorised disclosure. A refusal can be exactly the right response. Report these separately from accuracy, or your evaluation will reward the system for answering questions it should have declined.

Prompt injection adds another twist: retrieved text can contain instructions trying to steer the assistant. Treat external content as evidence to inspect, never as authority to change permissions or rules. Your security testing should include deliberately hostile content, not just accidental over-sharing.

The National Cyber Security Centre’s cloud security principles cover user management, separation, administration and audit. None of that stops mattering because the interface became a chat box. The model is one more component to secure; the controls around it still do the heavy lifting.

Start with a library you can vouch for

Choose a useful set of sources with clear owners and access rules you can maintain. Fix the obvious over-sharing and document the exceptions. Expand once your team can show a permission change taking effect, investigate a questionable answer and respond to an incident.

Citations make evidence inspectable. Access controls decide whether that evidence belonged in the answer at all. You need to demonstrate both, with a source owner in the room, because technical access and intended business access are often not the same thing.