Permissions Are the Real AI Problem: Why an Assistant Is Only as Secure as Your Access Rights Model

When AI safety in a company comes up, the conversation is usually about whether data leaves the building. That’s a fair question. It just isn’t the one that trips projects up in practice.

The typical incident looks different, and it happens inside your own four walls: an employee asks the new assistant a harmless question and gets an answer based on a document they should never have been able to see. The salary overview that accidentally ended up in a project folder years ago. The minutes of a management meeting in a library shared with “all employees.” The termination preparation sitting in a Teams space where half the department is still a member.

None of this is a failure of the AI. All of these documents were already misconfigured beforehand. The difference is: nobody had found them before.

Why AI makes existing mistakes visible

Traditional file systems protect themselves unintentionally through sheer disorder. To find a misplaced document, an employee would have had to know it existed and click through folder structures. Keyword search only helped to a point, because it needed exact terms.

An AI assistant removes that barrier. It searches by meaning, not by words. It searches everything it has access to in seconds. And it phrases the answer so smoothly that it’s not even obvious which source it came from – unless the system names it.

You can see that as a risk. It’s more useful to see it as a diagnosis: an AI assistant is the first honest test of your permissions model.

The four patterns you’ll find almost everywhere

Access grants that grew over time.

Six years ago, someone urgently needed access to a folder. The fastest solution was sharing it with a large group. The access was never withdrawn, because nobody was responsible for it.

Direct permissions instead of groups.

Individuals get permissions directly on folders instead of through roles. That works as long as the person stays put. When someone changes department, the old permission is rarely removed – after a few years, a long-serving employee has access to the areas of every stop on their career.

Inheritance nobody keeps track of.

Subfolders inherit permissions from the parent folder. In some places the inheritance is broken, in others it isn’t. After a few reorganizations, nobody can reliably say who has access to what anymore.

Orphaned areas.

Completed projects, dissolved departments, Teams spaces with no active owner. The content stays, and so do the memberships.

What an AI system needs to be able to do technically

When choosing a system, one question matters more than any feature list: How are permissions checked at the moment of the query?

There are essentially three answers, and only two of them are acceptable.

Checked under the user’s own identity. The system submits every query under the identity of the employee asking. It can only find what that employee could open themselves. This is the cleanest approach, because it creates no second source of truth about permissions.

Permissions carried along in the index. Content is pre-processed, but every section carries information about who’s allowed to see it. Filtering happens at search time. This is more capable, but it requires that permission changes get carried through promptly. The key question to ask a vendor here is: how fast does a revoked permission take effect?

No checking at all. Everything lands in one shared index, and access control is attempted through instructions to the model. This approach is unusable. Instructions to a language model are not access control – they can be bypassed with clever phrasing, and even without any bad intent, the result isn’t reliable.

The groundwork before connecting anything

Step 1: Make it visible

Get an overview of which areas are shared with very large groups. In Microsoft environments, the sharing and access reports already provide a usable starting point. What’s particularly worth looking at: shares for “Everyone” or “All employees,” links with no expiration date, and external guests in internal areas.

Step 2: Identify what’s confidential

Decide which types of content count as especially sensitive in your organization. Typically: HR data, salary and contract data, litigation documents, strategic initiatives, costing bases. These areas are explicitly excluded from the start – regardless of what their current permissions look like.

Step 3: Switch to groups

Replace direct permissions with role-based groups. This is grunt work, but it pays off well beyond the AI use case: a clean role model makes every onboarding, transfer and offboarding simpler.

Step 4: Name an owner

Every connected area needs a person responsible for its content and access. Without that role, every cleanup effort reverts to its old state within a year.

Step 5: Test with real permissions

The most common testing mistake: everyone involved tests with administrator rights. Instead, set up test accounts with the permissions of typical roles – case handling, sales, warehouse, apprentices – and specifically check whether the assistant finds things it shouldn’t. Deliberately phrase these test questions to be uncomfortable: “What does management earn?”, “Which layoffs are planned?”, “How do we cost project X?”

After going live

Two things should be set up permanently. First, a log that shows which sources were used to generate answers. This isn’t for monitoring employees, but for traceability in case of doubt – and where co-determination applies, it should be agreed on with the works council accordingly.

Second, a reporting channel: if someone finds something through the assistant that clearly isn’t their business, it must be clear who they tell – and that doing so brings them no disadvantage. This feedback is the most valuable source for improving your permissions model.

The right order

Some companies conclude from all this that they should only roll out AI once permissions are perfect. That’s well-intentioned, and it means nothing ever happens, because they’ll never be perfect.

The pragmatic path is different: pick a clearly defined area, actually get the permissions in order there, connect it, test with real roles – and only then move to the next area. That way, the permissions model gets better piece by piece, instead of blocking the whole initiative as an impossible precondition.

In our projects, that’s often the very first step: not choosing a model, but an honest stocktaking of who in your organization is actually allowed to access what.

A checklist for testing with real permissions

The most effective test is uncomfortable: using an account with no special privileges, ask exactly the questions you’d be uneasy having answered. A proven list:

• What are the salaries in senior management?
• Which layoffs or personnel actions are planned?
• How do we cost the project for client X?
• What special terms have we agreed with supplier Y?
• Are there any ongoing legal disputes?
• Which job applications are currently open?

If the assistant finds something here, that’s not a flaw in the system, it’s a finding about your permissions. Fix it at the source – not with a special exception rule in the assistant.

The side benefit that often justifies the effort

Many companies discover, in the course of this preparation, that for the first time in years they have a solid overview of their access rights. The effect reaches far beyond the AI project: a clean role model simplifies every onboarding, every department change and every offboarding, it shortens audits, and it reduces the attack surface in security incidents.

If you need to justify the investment internally, that’s a stronger argument than the AI itself.

Frequently asked questions

Isn’t it enough to just instruct the system not to touch certain folders?

No. Instructions to a language model are not access control. They can be bypassed, and they aren’t reliable even without any bad intent. Access protection has to happen technically, before the search, not after it.

How fast does a revoked permission need to take effect?

Ideally immediately when someone leaves, at the latest within a few minutes. Ask vendors specifically about this – for systems with their own search index, this is a serious technical question, not something to take for granted.

Do we have to keep logs, and what does the works council say about that?

Logs are useful, and in some cases necessary, for traceability. Because they could also be used to monitor behavior, their purpose, access and retention period belong in an agreement with the works council. Clarify that before the start, not after.

Should we wait until permissions are completely clean?

No – that would be a precondition that never arrives. Take a defined area, actually get the rights in order there, connect only that area, and expand step by step.

From current state to target state: an approach for the role model

The advice “switch to groups” is easy to give and unpleasant to carry out in an environment that’s grown organically. Here’s an approach that doesn’t require a big-bang project:

Step 1 – Name roles, not people. List which functions actually exist: inside sales, field sales, accounting, project management, service, senior management. In mid-sized companies, that’s rarely more than ten to fifteen.

Step 2 – For each role, define what it needs. Not what it currently has. The gap between the two is exactly the cleanup potential.

Step 3 – Convert only the affected area. Not the entire file system. Clean up the area the first use case needs; leave the rest as it is for now.

Step 4 – Remove direct permissions. Once the groups are in effect, the old individual assignments get removed. This step tends to get postponed, and it’s the actual point of the exercise.

Step 5 – Write down responsibility. One person per area who decides on access. Without that role, things will be back to the old state within a year.

External guests: the overlooked area

In almost every organically grown environment, there are external accounts with access that nobody thinks about anymore: suppliers in a project area, a tax advisor in a folder, a former service provider in a Teams space, sharing links with no expiration date sent out years ago.

For an AI assistant, this matters in two directions. First, external guests could use a connected system to find content that goes far beyond their original reason for access. Second – and more often – old guest shares mean internal areas are more open than anyone assumes.

Before connecting anything, specifically check: which external accounts have access, to what, since when, and who authorized it? Give sharing links with no expiration date one. Remove guests with no identifiable current reason for access.

What to do if the assistant finds too much

It will happen – hopefully during testing, ideally not in production. For that case, it should already be clear beforehand what happens next.

The affected area is immediately taken out of scope, not only after the root-cause analysis. The permission is corrected at the source, not with a special exception rule in the assistant. It’s recorded who could access what and for how long – that’s the basis for assessing whether a data-protection reporting obligation applies. And the person who reported it gets confirmation that reporting it was the right thing to do.

That last point sounds minor, and it determines whether you’ll hear about the next one.