Least Privilege, the Highest Value Habit

Give every person, and every piece of software, exactly the access needed to do the job, and nothing beyond it.

That is the whole principle. It is unglamorous, no vendor can sell it to you as a product, and it is the single highest value habit in the field, because it is the control that decides how bad your worst day is.

What it actually buys you

Least privilege does not reduce the chance of a breach. Accept that clearly, because it is the source of most arguments against it. Someone will still be phished. The value is in what happens next.

Take a marketing intern who needs to read the campaigns folder.

Without least privilege, their account can also reach the finance share, the customer database and the HR folder, because they were added to a broad group on their first day and nobody revisited it. An attacker who phishes that intern now holds all of it. One junior employee's mistake becomes a company wide data breach with regulatory reporting obligations.

With least privilege, the same account reaches the campaigns folder and nothing else. The same attacker, having run exactly the same successful attack, now holds some draft social media posts. It is a bad afternoon, not a catastrophe.

Identical attack. Identical human error. The difference in outcome was determined months earlier, by whoever set up the account.

Least privilege does not stop the first move. It decides what the first move is worth.

Privilege creep

Nobody deliberately over grants access. It accumulates, through a process that looks reasonable at every individual step.

Someone joins and is added to a broad group because that is quicker than working out precisely what they need. They cover for a colleague on leave and receive temporary access, which is never removed because removing it is nobody's job. They move to a new team and gain that team's permissions while keeping the old ones, because revoking the old set risks breaking something and nobody wants to be responsible for that. Multiply by five years and a few internal moves.

The result is that long serving, well liked, entirely trustworthy employees frequently have the broadest access in the organisation. Attackers know this, which is why long tenured staff are disproportionately targeted. It is not about trust. It is about accumulated reach.

Applying it to AI agents

This principle applied to people for decades. It applies to AI systems more urgently, and the reason is worth stating precisely.

A person with excessive access is a risk if they are careless or compromised. An AI agent with excessive access is a risk if anyone can influence its input, and Module 5 will show that influencing its input is often as easy as sending it a document.

Consider an assistant connected to a shared mailbox.

• Read only. It can summarise and draft. If manipulated, an attacker learns what is in the mailbox, which is serious.
• Read and send. It can now be aimed. A successful manipulation means the attacker sends mail as your organisation, to your customers, from a legitimate address that passes every authenticity check.

The gap between those two configurations is enormous, and the decision is usually made casually, because sending is convenient.

The rule that follows: give an AI system read access when reading is what the job requires, and put a human approval step in front of anything that leaves the building or cannot be undone. This costs a little convenience and removes almost all of the worst outcomes.