Reference

AI access governance.

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.

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".

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.

  1. 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.

  2. 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.

  3. 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.

  4. 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.

The approaches

Four ways companies actually handle this.

ApproachWhat it gets rightWhere 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.

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.

One approach to this, with its limits published.