Privilege AIMKC2 results

The AI became
the widest door
in the building.

An assistant indexed across every repository can answer questions no individual user was ever allowed to ask. Access control is what prevents that by construction.

READ THE DEFINITION ↓IDENTITY · INHERITANCE · ISOLATION

01 / DEFINITION

The short answer first.

What is AI access control?

AI access control is the enforcement of existing data permissions inside an AI system, so that a model answering a question can only use material the requesting person is entitled to see. It is applied at retrieval time, against the requester's identity, rather than to the finished answer.

The failure this prevents is specific and common. An assistant is built by indexing everything available, because indexing everything is the easy path and produces the most impressive demonstration. Once deployed, it answers questions using documents the asker could not have opened — and because the answer is synthesised prose rather than a file, no access log records a violation.

02 / WHY THE AI LAYER WIDENS ACCESS

Four mechanisms, all of them accidental.
01 — UNION INDEXING

Everything in
one place.

Content from many systems, each with its own permission model, is combined into a single index with no permissions at all. The union becomes readable by anyone who can query it.

Index scopePermission loss
02 — SYNTHESIS

The answer
has no ACL.

A generated paragraph drawn from a restricted document carries no trace of the restriction, so conventional access logging sees nothing unusual.

Derived outputAttribution
03 — SERVICE IDENTITY

It reads as
itself.

A pipeline authenticating with its own credentials makes every user as privileged as the pipeline. The most common single cause.

IdentityPropagation

A fourth mechanism is cache sharing. A response cache keyed only on the question returns one user's answer to another, which defeats correct retrieval filtering entirely. Caches in AI systems must be keyed by identity as well as by query, or scoped per user.

03 / THE PATTERN THAT WORKS

Where identity has to appear.

Filter at query time,
with the asker's identity.

The reliable arrangement is straightforward and has to be built in rather than added later. Every indexed unit carries the access metadata of its source. Every query is executed with the requesting user's identity attached, so the candidate set is restricted before relevance scoring. Caches are keyed by identity. Nothing enters the context window that the user could not have opened directly.

Two alternatives are worth naming because they are frequently proposed and both fail. Post-filtering — generating an answer and then checking permissions — is too late, because the restricted content has already shaped the response. Prompt-level instruction — telling the model not to use certain documents — is not a control, for the reasons set out in AI agent access control.

Permission freshness is the operational detail that catches teams out. Access changes constantly: someone leaves a matter, a confidentiality wall goes up, a document is reclassified. An index whose permission metadata is refreshed nightly is enforcing yesterday's permissions, which for a conflicts-of-interest boundary is not acceptable. Either query the authoritative source at retrieval time or keep the synchronisation lag inside what the strictest boundary tolerates.

04 / WHAT TO TEST

Access control that has been verified, not assumed.
↳ 01

Ask as the wrong person.

A standing test suite that queries for content each test identity should not reach, run continuously rather than once at launch.

↳ 02

Check the derivatives.

Embeddings, caches, logs and evaluation sets each have their own access model. The boundary is only as strong as the weakest copy.

↳ 03

Verify after every re-index.

Permission metadata is the first thing lost when an indexing pipeline is rewritten, and nothing visibly breaks when it is.

Privilege AI treats this as part of the architecture rather than a configuration step: permissions and retrieval boundaries define which information a model can access and which actions it can propose. The retrieval-specific implementation is covered in RAG access control, and the derivative-copy problem in AI data security.

05 / QUESTIONS

Asked when connecting AI to real repositories.

Can an AI assistant respect existing document permissions?

+

Yes, if the index carries per-document access metadata and queries run with the requesting user's identity. What cannot be made to work is a permissionless index with filtering applied to the generated answer.

What about answers that combine restricted and unrestricted sources?

+

If any contributing passage is out of scope for the requester, it should never have entered the context. Filtering the candidate set before retrieval makes the combination question disappear rather than requiring a judgement about the answer.

How do you handle confidentiality walls?

+

As a hard filter at query time, sourced from the authoritative system and refreshed fast enough that a new wall takes effect immediately. A nightly synchronisation is not adequate for a boundary that exists to prevent a specific person seeing a specific matter.

Do embeddings need access control?

+

Yes. An embedding is a derivative of the source text and informative about it, so it belongs under the same policy as the document. Storing vectors in an unrestricted index is a common and consequential gap.

How is this different from agent access control?

+

This page is about which data an AI system may read on behalf of a person. Agent access control is about which operations an agent may perform. Most deployments need both, and they are enforced in different places.

Keep permissions
meaningful.

Privilege AI designs retrieval boundaries so that an AI layer inherits existing access control instead of bypassing it.