DocsSign inInstall Kastel
All articles
Access scope

Can you connect an AI to your internal tools without exposing sensitive folders?

An assistant connected “to the drive” reads the whole drive, HR folder included. A scope attached to responsibility changes what each AI receives.

By Alexis PratJuly 31, 20264 min read
The short answer

Yes, provided the right to read is attached to the responsibility of the person the AI works for, rather than ticked tool by tool. A per-tool box opens the whole tool, sensitive folders included. A responsibility-based rule hands each AI only the slice that person is allowed to read, and nothing else.

The HR folder sits three clicks from the marketing folder

On your company drive, the HR folder sits three clicks from the marketing folder. It holds salaries, disciplinary files, sometimes a dismissal in progress. The day someone connects an assistant “to the drive”, the question stops being theoretical: a read permission granted per tool is a read permission on the whole tool. The box is called “allow access to the drive”, never “allow access to the marketing folder”.

This is not carelessness on the part of whoever did the connecting. It is the granularity these settings offer: you allow an entire tool, or you do not. Anything in between means copying, by hand and into every tool, an access policy that nobody has written down anywhere.

What happens when an AI asks to read

With Kastel, an AI never connects “to the drive”. It works for a specific person, and it connects to your Kastel, the structured memory of your organisation, which knows who decides what and who is allowed to see what. When the AI asks to read, the filter applies the scope of that person’s responsibility, and the AI receives only its slice. The rest is not hidden from view, it sits outside the slice that is sent.

The walkthrough takes four steps. The AI makes its read request. Kastel identifies who it is working for. The filter keeps what that person’s responsibility covers: their processes, their accounts, their working documents. The AI receives that slice, with the sensitive folders out of range from the start rather than removed after the fact. You decide what each AI is allowed to see, and that decision is a written rule, not a checkbox.

Drive, email, CRMResponsibility-based scopeWhat the AI readsOutside its slice
The filter applies the responsibility’s scope: the AI receives its slice; the rest stays outside what is sent.

When the person changes roles, the scope follows

A head of marketing moves to lead the sales team. With per-tool boxes, someone has to remember everything she could read, open the settings of the drive, the messaging tool and the CRM, then redo every box the right way round without missing one. Experience says that someone has other emergencies that day.

With a scope attached to responsibility, the role change is enough. Her scope follows her new responsibility: the AI working for her now reads the sales accounts and no longer reads the media plans. There is nothing to reconfigure tool by tool, because nothing was ever configured tool by tool.

Two boxes to keep in sync, or one rule

Take a genuinely sensitive document: a salary grid. It lives on the drive, and it also lives as an attachment on a CRM record, because a salesperson attached it to an account one day mid-negotiation. With inherited per-tool boxes, that document leads two lives: one box on the drive, one box in the CRM, and both have to be kept in sync forever. The first time they drift apart, the AI reads the copy nobody was watching.

With a rule attached to responsibility, the same document leads a single life: the rule says who is allowed to read it, and the filter applies it whichever door the AI comes through. That is the difference between adjusting sharing settings and governing your context: a written rule has an author, an approval and a history, where a checkbox has none of those. Knowing who can see what when an AI plugs in becomes a question you answer by opening the rule, no longer by opening five settings pages.

And if you have not connected anything yet, this question comes first on the list of checks to run before connecting an AI to email, storage and the CRM.

Check it without asking our permission

The Kastel core installs free of charge on your own servers, with no size limit and no time limit, and you plug in your own AI keys. Create two people with different responsibilities, ask the same question through each of them, and compare what the AI receives: the slice changes with the responsibility. You can then export your entire context whenever you want, including to leave. What this page claims can be observed on your own machine, and not in a demonstration we prepared for you.

See the scope in action

On the product page, the responsibility-based scope is shown in action: one read, one filter, one slice.

See how Kastel applies the scope