Skip to content

File shares as each person

Gate opens Windows file shares as the person asking, with their own NTFS permissions. If Maria cannot open a folder in Explorer, Maria's AI cannot either. Gate never uses a shared account and never stores anyone's password. On-prem editions only (Windows Server, Linux, Mac).

How it works

For each request, Gate asks a domain controller for a ticket that says "this is Maria" and then a ticket for the file server (Kerberos constrained delegation with protocol transition). The file server applies Maria's permissions as if she opened the share herself. Guardrails can only narrow that further, never widen it.

Which shares

Gate offers each person the drives they already have mapped, learned from Active Directory:

  • Group Policy drive maps (Group Policy Preferences → Drive Maps), including item-level targeting by security group or OU, link order, enforced links and blocked inheritance.
  • Home folders (the user's Profile tab → Home folder, for example H:).
  • Simple logon scripts with net use X: \\server\share lines.

Only paths under a person's mapped roots are reachable. A share nobody has mapped is not offered.

What the AI can do

Read only, in this version:

Tool Does
files__list_shares The person's mapped shares
files__list_folder One folder (up to 500 entries)
files__read_file Text, CSV, JSON, logs and Word .docx, up to 2 MB
files__search File names, up to four folders deep

PDF and Excel contents are not read yet; the AI can still find them by name.

Setting it up

Setup did it. It allowed the server's computer account to delegate to cifs on:

  • every file server in your Group Policy drive maps, home folders and logon scripts, and
  • every domain controller (for reading SYSVOL).

Added a file server later? Run Start → Acutis Gate → Set up Acutis Gate again. It adds the new server and keeps everything else.

On gate-svc → Delegation tab: Trust this user for delegation to specified services only → Use any authentication protocol → add cifs on each file server and each domain controller. (Linux step 1.)

Added a file server later? Add it to the same Delegation tab.

Hiding what people cannot open

Without Windows Access-Based Enumeration (ABE), someone who can open S:\Company still sees every subfolder name, like HR\Layoffs 2027, and is only refused on open. Gate closes that gap on its own: listings and searches show only what the person can open, and a path they cannot open answers "not found", exactly like a path that does not exist. The hidden names are never stored; the audit row records only a count.

To make Explorer behave the same way, turn on ABE on the file server: Server Manager → File and Storage Services → Shares → the share → Properties → Settings → Enable access-based enumeration, or Set-SmbShare -Name Company -FolderEnumerationMode AccessBased -Force.

Who is never opened

Accounts marked Account is sensitive and cannot be delegated, or in the Protected Users group, cannot be acted for. The DC refuses, and their AI gets no file access. That is on purpose: mark your admin accounts this way.

Narrow it with guardrails

Resources look like files://<server>/<share>/<path>. For example, to keep everyone's AI out of every Legal folder, whatever Windows allows:

{"id": "never-legal", "who": ["*"], "effect": "deny", "do": ["*"], "on": ["files://**/Legal/**"], "locked": true}

More in Guardrails, a worked example.

Check it

  • Health check → Run all checks: the File shares rows (broker, delegation, SYSVOL, ABE).
  • Health check → Test as a person: for each of their shares, what the guardrails say and what Windows says.
Problem Fix
Nobody gets any shares Gate cannot read SYSVOL: delegation to cifs on the DCs is missing, or DNS. See SYSVOL policy access.
One server's shares fail That server is missing from delegation. See Delegation.
One person gets nothing Sensitive account or Protected Users; or no drive maps apply to them (check gpresult /r on their PC).
"Windows denied this" Working as designed: their NTFS permissions do not allow it.