What does least privilege mean for an AI agent?

It means each step of a system gets exactly the access that step needs to do its job, and nothing else. The step that reads a document gets read access to the document store and no ability to send mail. The step that drafts a reply gets no write access to the accounting system. In practice this means several narrow credentials rather than one broad one, which takes longer to set up and is the difference between an incident that is contained and one that is not.

Why is a broad AI credential dangerous?

Because an AI system takes instructions from content it reads, and content can come from outside your business. A model processing a supplier's email, a customer's document, or a web page can encounter text crafted to look like an instruction. If the system holding that credential can send payments, delete records or email your client list, then the reach of a successful manipulation is the reach of the credential. Narrowing what each step can do limits the damage without needing to prevent every attempt.

Should an AI system have write access?

Only where writing is the point, and then only to what it writes. A great many useful systems need to read and to propose, with a person or a separate narrowly scoped step performing the write. Read-only by default is worth holding as a rule, because read access that turns out to be insufficient is a small inconvenience, and write access that turns out to be excessive is an incident.

How do I know what an AI system did?

By requiring, at build time, that every action it takes is recorded with which step took it, when, against which record, and under which credential. Retrofitting this is possible and considerably more expensive than specifying it up front. The test is whether you can answer, six months on, which system touched a particular customer record last March and why. A business that cannot answer that has no audit trail, whatever its documentation says.

AI Agent Permissions: Least Privilege for Business Buyers

Here is a thing that happens in the first week of building, and it is entirely reasonable in the moment.

The system needs to read documents from the shared drive, look up customers in the accounting package, and send a confirmation email. Setting up three narrow credentials with the right scopes takes most of a day, involves two vendor support tickets, and one of the vendors only offers full access or none. Setting up one credential that reaches everything takes twenty minutes and works immediately.

Everyone takes the twenty minutes. And now a piece of software that reads text from outside the business holds more access than any employee has ever held.

The principle has a name, least privilege, it usually gets explained to engineers, and the piece on orchestration here states it in a paragraph. This is the buyer’s version: how to decide what a system gets, what to do when a vendor will not allow it, and how to tell afterwards what the thing actually touched.

Why this matters more for AI than for other software

Ordinary software does what it was programmed to do. An AI system does what it was programmed to do, plus whatever it concludes it should do from the content it reads.

That distinction is the whole reason permissions matter differently here. A system processing supplier emails, customer documents or web pages is reading text that came from outside your business, and text from outside can be written to look like an instruction. This site has covered how content and tools become two doors into a system at length. The relevant consequence for this piece is narrower: you cannot rely on preventing every attempt, so what decides the damage is what the system could do if an attempt worked.

A system that can only read the document folder has a bad day. A system holding one credential that reaches the accounting package, the customer database and the mail server has an incident that involves lawyers.

This is a catalogued risk rather than a theoretical one. OWASP, which maintains the reference list of security risks for this kind of software, ranks prompt injection first in its 2026 top ten for large language model applications, and lists excessive agency, which is the name for granting a system more reach than its job requires, at number three, up from sixth the year before as real agent deployments produced real incidents.

The same logic covers the more mundane and more likely case, which is a mistake instead of an attack. A step that malfunctions and processes the same batch four hundred times causes an annoyance if it can only read, and a mess if it can write.

The inventory, which is the actual work

Before anything about scoping, there is a listing exercise, and it is the part that gets skipped because it looks clerical.

For each step in the workflow, four columns. What system does this step touch. Does it need to read, write, or both. Which specific records or fields, rather than which system in general. And what would happen if this step went wrong a hundred times in a row.

That last column is the one that changes decisions, because it converts an abstract permission into a concrete consequence. “Can write to the customer record” is a checkbox. “Could overwrite four hundred customer records with the wrong address, and the previous values are gone” is a design input.

Doing this for a six-step workflow takes about an hour, and in my experience it turns up two things almost every time. Steps that were going to be granted access they never actually use, because the access came bundled. And one step, usually a write, where the honest answer to the fourth column is bad enough that it should have a person on it, which is the same conclusion checkpoint placement reaches from the other direction.

Four rules that carry most of the benefit

Read-only is the default until a step proves it needs to write. Most steps in most workflows only need to read and propose. The write is a smaller, later, narrower step. Read access that turns out to be insufficient costs an afternoon; write access that turns out to be excessive costs considerably more.

A credential per step, not per system. The reason to separate them is that it makes the blast radius equal to the step instead of the system, and it makes the log meaningful, because you can tell which step did something. That is the rule; what follows is what to do when a vendor makes it difficult. This is the rule vendors most often make difficult, and where they do, that difficulty is a fact for the design to work around instead of a reason to abandon the principle.

Scope to records, not to systems, where the vendor allows it. Access to the invoices from the last ninety days rather than the whole accounting database. Access to one folder instead of the drive. Vendors vary enormously in whether they support this, and it is worth asking, because when it is available it is the single largest reduction in exposure on the list.

Short-lived credentials over permanent ones. A key that expires and is renewed automatically is dramatically better than one issued in 2024 and pasted into a configuration file. The failure mode this prevents is the common one: a credential that outlives the project, the person who created it, and any memory of what it was for.

The vendor problem, honestly

The rules above assume the systems you use support them, and a good number do not.

Some offer full access or nothing. Some scope by user instead of by application, so the only way to grant an AI system access is to give it a person’s account, which is bad for the log and worse for the day that person leaves. Some tie access to a plan tier, so the properly scoped version costs more than the broad one.

When that happens there are three honest responses, and pretending the constraint does not exist is not among them.

Compensate elsewhere. If a system can only be reached with a broad credential, put the narrowing somewhere you control: a layer in between that only exposes the specific operations the workflow needs, so the broad credential exists in one place and everything else talks to the narrow interface.

Change what the step does. Sometimes the write that requires dangerous access can be replaced by a file the other system imports, or by a person confirming, at a cost of minutes rather than risk.

Or accept it explicitly, in writing, with the reason. A known accepted risk that somebody signed off is a different thing from an unexamined one, and the difference shows up when it eventually matters.

This is also worth raising during procurement, because what a vendor permits decides what is buildable as much for security as for feasibility, and it is a question that can be asked in an email before anything is committed.

The log, and the question it answers

Every action the system takes should be recorded: which step, when, against which record, under which credential, and what the outcome was.

The test for whether this has been done properly is a single question. Six months from now, can you answer which system touched a particular customer record last March and why. A business that can answer has an audit trail. A business that cannot has documentation describing one.

Three uses beyond the obvious. The log is what you need if a customer or a regulator asks how a decision was reached. It is what tells you a credential is being used by something you forgot about, which is the most common way stale access is discovered. And its shape is one of the earliest signals that something has changed, in the same way the shape of the output signals drift.

The review that never happens

Permissions granted at build time are permanent unless something removes them, and nothing removes them by default.

Two habits, both cheap. Twice a year, list every credential the system holds and confirm each one is still used and still correctly scoped. And whenever the workflow changes, check whether the change removed a need instead of only adding one, because steps get replaced and their access stays behind.

The finding, most times this is done, is a credential for something that was decommissioned a year ago and still works. That credential is the one that turns up in an incident report, and finding it takes twenty minutes.

The short version

The question to put to anyone building an AI system for your business is short: what can each step touch, and what happens if it goes wrong four hundred times.

A build with a specific answer, this step reads these records, this step writes only this field, this step sends mail and nothing else, every action logged against the step that took it, has thought about the failure. A build with one credential that reaches everything has optimised for the first week, and the first week is not the part that costs anything.

Read-only until a step earns the write. One credential per step. Scoped to records where the vendor allows it, and compensated for deliberately where it does not. Everything logged. Reviewed twice a year. None of that is difficult, and all of it is much easier to specify before the build than to retrofit after.

What the Agent Is Allowed to Touch