Reference

AI access governance. The unglamorous half of the work.

AI access governance is deciding which people may reach which business systems through an AI assistant, enforcing that per person, and being able to prove afterwards what was actually reached. It is an access-control problem that happens to involve AI, rather than an AI problem.

Talk to us The security model

The phrase is new because the situation is: assistants arrived inside companies faster than the controls around them, usually without anybody deciding they should. Most organisations are somewhere between "we told people not to" and "we have no idea", and in practice have already landed on one of five approaches without calling it a decision.

The shape of it

Four questions. And you need all four.

Any approach – bought, built, or banned – has to answer these. It is worth writing down your current answers before evaluating anything, because "we do not know" is a common and useful answer.

01

Who is asking?

Not which application, and not which service account. Which person, verified by the same directory that already governs their email. If the answer is a shared credential, every other question below becomes unanswerable.
02

What may they reach?

Per person, per system, per environment. The important word is may rather than can: the useful design refuses by default and adds narrowly, because the alternative requires somebody to remember to take things away.
03

What did they reach?

A record of every call, including the refused ones. Refusals are the more interesting half: somebody repeatedly hitting a boundary is either misconfigured or probing, and both are worth knowing.
04

How fast can you take it away?

If revocation means editing a config file and restarting something, it is not revocation. The test is whether a person who left on Friday can reach anything on Monday, and how you would prove it either way.

Adjacent, and not the same

Four things it gets confused with.

Each of these overlaps and none of them covers it, which is why the phrase exists at all. If you already own one of them, the useful question is which part of the four above it answers.

Discipline	What it governs	What it leaves open
Identity governanceIGA, joiners and leavers	Who exists, who they are, which accounts and groups they hold, and how that is reviewed.	Question one, completely and well. Your identity provider should stay the only list of people. It has nothing to say about which tool touches which cube for which person, because that granularity never existed as an account.
Data governancecatalogues, lineage, classification	What the data means, where it came from, how sensitive it is, and who owns it.	Whether a particular person may reach it through a particular assistant, right now, and what happened when they tried. A catalogue describes; it does not stand in the request path.
Data loss preventionDLP, egress controls	Content leaving by channels you can watch: mail, uploads, managed endpoints.	A person legitimately asking a legitimate question and receiving more than they should have. Nothing has leaked in the DLP sense, and that is exactly the failure mode here.
AI governancemodel risk, policy, ethics	Which models are approved, what they may be used for, bias, oversight and disclosure.	The plumbing underneath it. An approved model on an ungoverned connection is still an ungoverned read, and the approval document will not be what somebody asks for during an incident.

The short version. Identity governance answers who somebody is. AI access governance answers what they may reach through an assistant, and proves what they did reach. Those are two systems answering two questions, and keeping them separate is what makes revoking somebody a single edit rather than a project.

The approaches

Four ways companies actually handle this.

Approach	What it gets right	Where it fails
Ban it	Simple, and honest about the risk.	It does not work. People paste into a chat window from a personal device and now the copy is outside the company entirely, with no record it happened.
A shared read-only login	Fast, and keeps the data in your systems.	One credential for everybody. Every answer is attributable to the credential rather than to a person, and taking it back means changing it for everyone at once.
Index everything into a copy	Good answers, quickly, across many sources.	Your content now exists twice, and the second copy is re-permissioned by somebody's model of your access rules. When that model drifts, the failure is silent and the exposure is theirs to explain.
Per-person governed access	Answers all four questions, and nothing is copied.	It is more work to set up, and it is only as good as the entitlements somebody maintains. It also cannot make an unconnected system reachable.

The distinction that matters most

Reading is not the same as copying.

Almost every argument in this category reduces to this one. A system that copies your content into its own store has to reproduce your permissions inside that store, and keep them in step forever.

Why drift is the real risk

The copy is made once and your permissions change constantly. Somebody moves team, a folder is restricted, a project closes. Every one of those is a change the copy has to learn about, and when it does not, the copy answers a question the original would have refused.

Why the failure is silent

Nothing errors. The assistant returns a confident answer built from content the person should not have seen, and there is no signal anywhere that it happened. This is the exposure that does not appear in an evaluation, because in an evaluation the copy is one day old.

Ownership

Who owns this inside a company. And who only blocks it.

The commonest reason an evaluation stalls is that it started with the wrong person. This is not a security purchase that security makes; it is an enablement purchase that security has to be satisfied by, and those are different conversations in different orders.

Role	Their question	What they decide
The AI programme ownerusually the buyer	Our assistants are rolled out and useful everywhere except where the numbers live. How do we open those?	Whether this happens at all, and out of whose budget. The rollout is already stalling on exactly this, which is why the money is here rather than in a security line.
Securityinfluencer, not buyer	What can it reach, whose permissions apply, and what can I see afterwards?	Whether it proceeds. They rarely fund it and they can always stop it, so their questions get answered first even though they are not signing.
The identity administratorthe long pole	Does this need admin consent in our directory, and what exactly is it asking for?	The timeline. At enterprise size this is a process rather than a click, and it is the step that decides whether a pilot starts in week two or week nine.
The data ownerper system	Who among my people gets to read my system this way?	The grants themselves. In practice this is the person who should be writing them, and the commonest mistake is centralising that with whoever administers the tool.

Boundaries

What it is not, stated so the term stays useful.

A category that expands to mean everything stops meaning anything, and this one is new enough to be at risk of it. Three things it explicitly does not cover.

It is not accuracy

Governing reach does not make an answer correct. An assistant with perfectly narrowed access can still misread what it was given, and no permission model fixes that. Anybody selling governance as an accuracy control is selling two things as one.

It is not model safety

What a model will and will not say is decided by whoever supplies it, under your contract with them. Access governance sits underneath that and is indifferent to which model is on the other end, which is the property that makes it survive a change of vendor.

It is not a substitute for the system's own controls

Where the system being read enforces per-user permissions itself, that enforcement is stronger than anything a middle layer adds, and the right design defers to it. The honest version of this is a published table of where that is true and where it is not.

Getting started

What to do before you buy anything.

Worth doing this month

Find out what is already happening. Assistants are usually in use before anybody approves them.
Write down your four answers from the section above, honestly.
Pick the one system where a wrong answer would actually hurt, and start there.

Not worth doing yet

A policy nobody can enforce. It creates a paper trail, not a control.
Connecting everything at once. The value is in one system used properly.
Buying on a demo. Ask instead for a fortnight of audit rows from your own environment.