Audit permissions before you switch on AI search, not after. Run an access review over every folder the index will cover, looking for inherited rights, open-to-all shares and stale groups. AI search does not create oversharing, it makes existing oversharing findable. Mickai scopes private knowledge bases by department: answers draw only on passages the person is permitted to see.
Why does AI search expose permission problems nobody noticed?
Because keyword search punished you for not knowing what to look for, and retrieval does not. Documents that were technically reachable but practically invisible become one plain question away from anybody with a login.
Consider how a shared drive gets used. Somebody needs a file, somebody else grants access to the parent folder because it is quicker, and the grant outlives its reason. Nobody notices, because finding that folder required knowing its name. Obscurity was doing the work of access control.
An internal assistant removes obscurity. It reads meaning across the whole index, so "what did we agree about the Henderson dispute" pulls the right passage whether the file is named sensibly or not. The permissions did not change. The consequences of getting them wrong did.
This is a common reason an internal AI rollout stalls after go-live. Someone asks an ordinary question, gets an answer drawn from a document they were never meant to read, and the project pauses while somebody works out how that happened. The work below is how you avoid that, and the order matters.
What should we inventory before the audit starts?
Start with a list of every repository the index will cover, not a list of documents. You cannot review millions of files and you do not need to. You need to know which containers are in scope and who is accountable for each.
For every repository, record six things: the location, the named business owner, what it is for, whether it holds personal data or special category data, whether it holds legally privileged or contractually restricted material, and when its access was last reviewed. Two of those columns are usually blank at the start. The blanks are your findings. A repository with no named owner cannot be signed off, and a repository nobody has reviewed in four years is where your problems live.
Include the awkward sources while you are here: mailbox archives, ticket attachments, meeting recordings and transcripts, scanned post. These are usually among the least governed content in an estate, and they are exactly what people want an assistant to read.
How do we find documents that are open to everyone?
Query for the principals that mean everyone, then sort by document count. In most estates that means Everyone, Authenticated Users, Domain Users, an All Staff group, anonymous or organisation-wide sharing links, and any guest or contractor account that has drifted into a broad group.
Do not work the output in the order the tool produced it. Rank it. Reach multiplied by sensitivity gives you a queue worth working: a folder of 40,000 low-value templates open to everyone is untidy, eight settlement agreements open to everyone is something you fix this week. Sharing links deserve separate attention: they bypass group membership entirely and expire on nobody's calendar.
How do we deal with inherited permissions and nested groups?
Resolve to effective permissions for real users, not to the permissions on the container. Inheritance and nested groups are the two mechanisms by which access nobody granted becomes access somebody holds, and neither is visible if you only read the access control list at the top of a folder.
Flatten the groups. A group inside a group inside a distribution list will happily deliver read access to a department that was never discussed, and the people in it have no idea. Then find every point where inheritance was broken, because a break is either a deliberate tightening you should keep or a forgotten widening you should remove, and the folder cannot tell you which. Only the owner can.
The other half is lifecycle. Access follows joiners, movers and leavers, and it is the movers who accumulate. Someone who has held three roles in five years can end up holding the union of all three sets of rights. The NCSC's guidance on identity and access management, part of its 10 Steps to Cyber Security, deals with exactly this: least privilege, and reviewing privileges rather than granting them once. User access control is also one of the five technical control themes in Cyber Essentials. If you cannot meet that baseline on a repository, that repository is not ready to be indexed.
Which documents should be left out of the index entirely?
Some material should not be in scope at any permission level, because the cost of a retrieval error is higher than the value of finding it quickly. My default exclusions are legally privileged correspondence, live employee casework, board and committee papers before publication, security documentation such as incident reports and network diagrams, anything under a contractual confidentiality restriction, and personal drives.
Exclusion is the fastest control you have and the easiest to reverse, which is why it comes before remediation rather than after it. You can take a repository out of scope in an afternoon. Rebuilding its permission model takes a quarter. Do the first, schedule the second, and record the exclusion as a decision with a named owner rather than a silent technical filter somebody removes later without knowing why.
Who signs off the scope, and what do we record?
The business owner of each repository signs off, and IT evidences the decision. IT can tell you who has access. Only the owner can tell you who should, because that judgement depends on the purpose of the documents and the obligations attached to them.
Record one row per repository: the location, the decision (index, exclude, or index after remediation), the permission scope it will be indexed under, the effective-access evidence that supported the decision, the named approver, and the date. That record is what you hand to an auditor, a regulator or a client, and it is what stops the same argument being reopened in nine months.
If the documents contain personal data, screen for a Data Protection Impact Assessment at this point rather than at the end. The ICO's guidance on AI and data protection covers how to assess security and data minimisation in AI systems, and a DPIA is the natural place to write down the minimisation decisions you have just made. Our note on DPIAs before deploying AI goes further into when one is required.
How do we test the result before staff get access?
Test adversarially, with real accounts, before anyone gets a login. Write twenty to thirty questions designed to surface the material you would least like to see, phrased the way a curious employee would ask rather than the way an attacker would.
Then run the same set as several different people: a new starter, a mid-level analyst, a line manager, a contractor, and somebody who changed department last year. That last account is the one that finds things. Log every answer and every passage it drew on. A question that returns nothing is a pass. A question that returns a settlement agreement to the contractor account stops the rollout until you know why.
Keep the test set. Re-run it after every permission change and every new repository, because scope creeps quietly and the questions cost nothing the second time.
How does a sovereign system keep permissions enforced at question time?
By scoping the knowledge base and constraining what an answer may be built from. In the Mickai Sovereign Intelligence Operating System, private knowledge bases are scoped by department, and an answer draws only on passages the person asking is permitted to see.
Two properties matter to a buyer. The system runs on hardware you own, offline capable, with no data egress, so the access review you have just done covers an estate that stays inside your own boundary. And every consequential action is sealed in the Open Audit Record under ML-DSA-65, the post-quantum signature scheme NIST published as FIPS 204 in 2024. That makes the record tamper-evident rather than tamper-proof: nothing physically prevents someone altering an exported record, but altering it makes verification fail, and your auditor checks it offline with a public key using tools that are not ours. Consequential actions also wait for a named person to approve them.
One caveat, since it bears on this problem. A local OCR runtime has read scanned PDFs in controlled tests, and the extraction and ingestion integration into SIOS is still being completed. If your estate leans heavily on scanned material, factor that in when you plan the rollout.
None of this is an argument against the companies building the compute and cloud layer. Cloud remains the right answer for a great deal of non-regulated work. The assumption worth arguing with is that a regulated organisation must rent its intelligence, ship its documents offsite and accept a vendor's word for what happened to them. If you are scoping this work, the internal knowledge AI and sovereign AI pages set out our approach, and the note on privileged and classified documents covers the hardest end of the estate. The closed beta is open, with one regulated company onboarding as a design partner.
Frequently asked questions
Will AI search let staff see documents they should not?
Only if your permissions already allow it. A properly scoped assistant retrieves within the permissions of the person asking, so it grants no new rights. What it removes is obscurity as a control. Material that was reachable but hard to find becomes answerable in a single question, which is why the access review comes before go-live.
How long should a permissions audit take before an AI rollout?
Long enough to be defensible, and the effort is driven by three things rather than the calendar: how many repositories are in scope, how many of them break inheritance or rely on nested groups, and how stale the group membership is. An estate with named owners and recent reviews moves quickly. One with neither is mostly archaeology.
Do we need a DPIA before indexing staff documents?
Usually, yes. Indexing documents that contain staff personal data is new processing, and the ICO's guidance on AI and data protection points you towards a DPIA where processing is likely to result in high risk to people. Even where it is arguable, a DPIA is the cheapest place to record your scope, exclusions and minimisation decisions.
Should we fix the permissions or just exclude the folders?
Both, in that order. Exclude first, because taking a repository out of scope is fast, reversible and needs no coordination. Then fix the permissions, because exclusion shrinks the value of the system and is not a permanent answer. Treat every exclusion as a recorded decision with an owner and a review date, not a quiet technical filter.
Who should own the permissions audit, IT or the business?
Both, with the split made explicit. IT produces the effective-permissions data, resolves nested groups and runs the tooling, because only IT can. The business owner of each repository decides who should have access and signs the scope off, because that judgement depends on what the documents are for. If IT signs off alone, nobody has checked the decision that matters.
Written by Micky Irons, founder and chief executive of Mickai LTD, which builds a sovereign AI operating system for regulated organisations. More at mickai.co.uk.
Top comments (0)