Permissions that hold: access control for AI, enforced in the database

Connecting an AI assistant to company documents raises one question above all others in a security review: will anyone see something they should not? This paper explains how K-Lake answers it. Access is enforced in the database rather than in application code, the permissions already on each file are honoured as they stand, and every assistant works as a named user whose activity is recorded.

Why filtering in code is fragile

Many search and AI products decide what a user may see in their application layer. Each query builds a filter, and the filter removes results the user is not entitled to. The weakness is that every code path has to remember to apply it. A new feature, an export function or an API endpoint written in a hurry can forget, and when it does, the failure is silent. Nothing breaks; data simply leaks.

Security reviewers know this pattern, which is why they ask where access control lives before they ask how it works.

Enforcement inside the database

K-Lake enforces access with row-level security in its database. Each request runs in a database session bound to the caller's identity and tenant, and the database itself refuses to return rows the caller is not entitled to. Every interface and every future code path inherits the control automatically.

The default is to deny. A file with no computed permissions stays hidden until its permissions are known, and tenants are isolated from one another at the same layer. K-Lake would rather hide a file a user could have opened than show one they could not.

The permissions you already have

Rebuilding an access model in a new system is slow, and it drifts. K-Lake uses the permissions the files already carry. During a crawl it captures NTFS and NFSv4 access control lists and POSIX ownership, then matches the identities in those permissions to the identities in the organisation's directory.

That matching is deliberately cautious. An exact identity key, such as a security identifier mapped to a directory object, grants access. A looser match, such as two accounts with similar names, is recorded and shown to an administrator but grants nothing until someone verifies it.

Identity through your own provider

K-Lake stores no passwords. People sign in through the organisation's identity provider over OpenID Connect and OAuth 2.1, including Microsoft Entra ID, Okta, Google and Keycloak. Personal access tokens are available for scripts and for disconnected sites, and each token acts as one named user.

Assistants as named users

An AI assistant is treated as a user, never as a privileged service account. K-Lake's MCP server includes its own OAuth 2.1 authorisation server, federated to the organisation's identity provider. When someone connects Copilot, Claude, ChatGPT, Gemini or an internal agent, the assistant signs in as that person and inherits exactly their permissions.

The MCP endpoint is switched off until an administrator enables it. Once it is on, the console shows which assistants are connected, for whom, and which sources they are reaching. An administrator can end a session or hide a sensitive source from AI while staff can still search it. Assistants receive extracted text, never the original files.

Classification before exposure

K-Lake labels every file it indexes as public, internal, confidential or restricted, and records the evidence behind each label. Rules decide what search and AI may return at each level, and those rules are enforced in the data layer alongside permissions. A data protection officer can show which restricted material an assistant is able to reach, and demonstrate that the answer is none.

Secrets and the audit trail

Source credentials and identity provider secrets are encrypted with authenticated encryption before they reach the database, under a master key held outside the API process. The key can be rotated without restarting services, and secrets cannot be read back through any API.

Every privileged action is recorded with the person, the tenant and the resource involved. That includes sign-ins, source changes, searches, file opens and every AI query, including queries K-Lake refused. Logs and metrics go to the organisation's own SIEM and monitoring tools.

Explaining a decision

When a user expects to see a file and cannot, an administrator can run a check that shows which permission, identity mapping or source setting is responsible. The same reasoning that keeps the file hidden is visible to the people who have to defend the control to an auditor.

What a reviewer should test

1. Ask for a user with no access to a sensitive folder, and confirm that neither search nor a connected assistant returns anything from it.
2. Remove someone's access at the source, recrawl, and confirm the change is reflected.
3. Disable the MCP endpoint and confirm assistants lose access immediately.
4. Review the audit record for a refused AI query.
5. Confirm where the master key is held and how it is rotated.

Each test can be run during a proof of concept on your own data, with your own security team watching.