Where does this apply to AI tools specifically?

Wherever the tool holds access rather than the person using it. A search deployment or a connected assistant often inherits its reach from whoever installed it, so the question is not what the person asking may see but what the tool may reach on their behalf, and those can differ substantially.

Is this the same as reviewing who has access?

They are two halves of the same problem from opposite ends. This is about what gets granted in the first place; a review is about catching what accumulated anyway. Doing only the second means permanently cleaning up after a process that keeps producing the same result.

How narrow is narrow enough?

Narrow enough that somebody would have to ask for more, which is the practical test rather than a rule. If nobody ever comes back requesting additional access, the grants are almost certainly wider than the work requires and nothing in the system will report that.

Glossary

Least privilege

Giving each person and each system only the access their work actually requires, so a mistake or a stolen login reaches less than it otherwise would.

In plain terms

Handing over the key to one room rather than the master key, because whoever holds it can only ever open the one door. Nobody disputes that this is sensible. What makes it hard is that the master key is quicker to issue, and the cost of having issued it only appears later, to somebody else.

Why it matters

Because it decides how far a single bad moment travels. A person clicking the wrong link, a login sold on, a script doing something unintended: none of those is prevented by this principle, and all of them are contained by it. What the account could reach is what the incident becomes, and that scope was fixed months earlier by whoever granted it, usually in a hurry.

How it works

The pressure runs one way and that is the whole difficulty. Granting access resolves somebody's immediate problem and takes a minute; withholding it creates friction now against a benefit nobody will ever observe, because a breach that did not happen leaves no trace. A principle that costs something today and pays invisibly is not one that survives on good intentions.

Roles drift because people move and permissions do not. Somebody joins a second team, gains what that team needs, and keeps what the first team gave them. Repeat that across a few years and the estate holds people who can reach a great deal without any individual decision having been unreasonable.

Machines are where it is loosest, and where it matters most. An automation given broad access at setup, because narrowing it was fiddly and nobody wanted the integration to fail, will hold that access indefinitely and without complaint. It also never mentions that it is over-permissioned, which a person eventually might.

Narrowing works better at the point of granting than as a later clean-up. Reducing access somebody already has means arguing about whether they need it, with the person who wants to keep it; granting narrowly in the first place means agreeing what the work requires, which is a much easier conversation and happens once.

Applying it to AI tools is different in one specific way. A search or assistant deployment often derives its reach from whoever installed it rather than from whoever is asking, so a tool set up by an administrator can answer questions using material the person in front of it could never open directly. The principle has not changed; the thing holding the privilege has.

What the principle does and does not do

Separating the columns is worth doing because the principle is often argued about as though it were on the left, which makes it sound like a statement about how much people are trusted. It is not. It assumes everybody involved is competent and acting in good faith, and it still applies, because none of the three things on the left is the person. A login that has been sold on is not its owner; a script does not intend anything. What the principle governs is the blast radius, and the uncomfortable property of a blast radius is that it is set months in advance by somebody who was solving a different problem at the time. That is also why the clean-up framing fails: by the time anybody is looking at the right-hand column, every grant on it has an owner who will explain why they need it, and each of those explanations is individually reasonable. The cheap moment is the first one, when the question is what the work requires rather than what somebody would lose.

Seen in the wild

Giving a search deployment access to one department's material rather than everything, so an answer cannot quote what the reader could not open.
Glean
Narrowing an automation's connection to the two systems it touches, rather than the account it was set up with.
Make
Restricting an assistant's connected applications to those a team genuinely uses, rather than every one available.
ChatGPT

Common misconceptions

People assume

It is about not trusting people.

In fact

It is about limiting the reach of things that are not the person: a stolen login, a mistaken click, a script behaving unexpectedly. The principle assumes everybody is acting in good faith and still holds, which is why it survives arguments about trust.

People assume

It can be fixed later with a clean-up.

In fact

Removing access somebody already has means arguing about whether they need it, and the person who wants to keep it is in the room. Granting narrowly costs one conversation at the start; recovering it later costs one per person, repeatedly.

Questions

Where does this apply to AI tools specifically?: Wherever the tool holds access rather than the person using it. A search deployment or a connected assistant often inherits its reach from whoever installed it, so the question is not what the person asking may see but what the tool may reach on their behalf, and those can differ substantially.
Is this the same as reviewing who has access?: They are two halves of the same problem from opposite ends. This is about what gets granted in the first place; a review is about catching what accumulated anyway. Doing only the second means permanently cleaning up after a process that keeps producing the same result.
How narrow is narrow enough?: Narrow enough that somebody would have to ask for more, which is the practical test rather than a rule. If nobody ever comes back requesting additional access, the grants are almost certainly wider than the work requires and nothing in the system will report that.