Least Privilege Was Built for People Who Pause
Every access model you run assumes a human is standing at the moment of action. Agents void that assumption.
Every access control system you have ever run carried an assumption it never bothered to write down. The assumption was that a human being would be standing at the moment of action, deciding whether to actually go through with it.
That assumption is so deep we stopped seeing it. We talk about permissions as if they were the control. They were never the control. The control was the person — the one who had the access, noticed the request was strange, hesitated over the unfamiliar recipient, and chose not to send. The permission set drew the outer wall. Human judgment did the real work inside it, quietly, every single day, for free.
Agents inherit the wall. They do not inherit the judgment. And the moment that happens, a lot of governance that felt solid turns out to have been resting on something we never accounted for.
The contract nobody signed
Least privilege is usually explained as a defense against malice. Give people only the access their job requires, so a bad actor — or a stolen credential — can do less damage. True enough. But that framing hides the part that actually carried the weight.
Most people in most organizations are over-permissioned, and it almost never matters. A paralegal can probably open far more of the document system than any single matter requires. A developer can usually reach systems they have not touched in a year. We tolerate that gap between granted access and needed access because a human sits in it, applying discretion at the point of use. The gap is wide, and the judgment is what keeps the width from being dangerous.
That is the contract nobody signed. Access can be loose because judgment is tight. Take the judgment out of the moment of action, and the looseness you have lived with comfortably for twenty years becomes the exposure.
What the agent removes
Consider what Microsoft’s Copilot Cowork can do once it is running in someone’s context. It drafts and sends email, creates and edits and deletes documents, posts in collaboration channels, searches across the enterprise, and reaches the document system through the same connectors a person uses. It does all of this as the user, with the user’s permissions, not a narrower set of its own.
To Microsoft’s credit, it pauses before the riskiest actions and asks for approval, with a risk indicator attached. That sounds like the missing judgment, restored. It is not. The approval is one click, it leans on the same human attention least privilege already assumed, and it never changes what the agent is able to reach. Ask a person to approve twenty actions a day and you have not added judgment — you have manufactured a reflex. The prompt becomes a turnstile that everyone learns to push through.
This is not a worry confined to my own corner of the world. A 2025 Cloud Security Alliance survey of 445 security professionals found that ninety percent of deployed AI agents carry more access than their assigned task requires, and nearly half of organizations had already experienced a security incident involving one. The over-permissioned agent is not the edge case anyone is bracing for. It is the normal state of deployment.
From governing files to governing the factory
There is an idea moving through software circles that you are no longer building the product, you are building the factory that builds the product — and that you have to govern the factory accordingly. The same shift is happening to ordinary professional work. Increasingly the thing you build is not the document or the policy. It is the process, and the agent, that produces them.
Once you see governance that way, least privilege stops being an IT setting and becomes a design decision about the machine. You are no longer asking what a given person should be able to do with a given file. You are asking what the agent — its tools, its reach, its standing permissions — is structurally allowed to do with every file it can touch. The security community is converging on the same point from its own direction: the OWASP work on agentic applications now frames the goal as Least Agency — autonomy that is earned, scoped, and bounded, rather than granted by default because the underlying account happened to have it.
The instinct, having seen all this, is to lock everything down. Resist it. Maximal restriction kills the serendipity and cross-pollination that made these tools worth adopting in the first place. The discipline is to draw the line at the boundary of what a role would ever genuinely need — and to leave a deliberate margin on the generous side of strict minimum. There is a line. It sits a little wider than the tightest possible setting, and a great deal narrower than what most people hold today.
If that feels premature — if the honest objection is that nothing has gone wrong yet — look at the shape of the bet. Over-restrict and the cost is friction and a few frustrated colleagues. Under-restrict and the cost is the kind that ends up in a regulator’s letter or a headline. When the downside is that asymmetric, waiting for proof is not caution. It is a slow decision to do nothing.
The part that isn’t technical
If the argument stopped there, it would be an engineering problem, and engineering problems are the easy kind. The hard part is everywhere the technology isn’t.
People want a voice in how they get restricted, and they are right to. When word gets out that access is going to change, the reasonable reaction is not gratitude — it is a request to be consulted about a wall being built around your own work. Then there are the old records sitting under a practice area that no longer has an active owner: cut access and you might orphan something that still matters; leave it and you have proven the point about exposure. There are whole areas of a business with no clear owner at all. And underneath all of it sits the least glamorous question in governance — who approves access, by what process, on what timeline, without slowing the work that pays for everything.
None of that is a permission toggle. That is the actual work, and it is the work least likely to get done, because it is political and procedural rather than technical, and it does not demo well.
So the line I gave my colleagues, the one that sounded extreme, was never an accusation. Treat every internal user as malicious is a design stance, not a character judgment. It says: stop architecting around who you trust, because trust was a statement about intent, and intent is no longer the variable that determines the outcome. Architect around what the machine can do on their behalf.
Build for what can happen, not for what anyone means to do. Intentions don’t matter. Outcomes do.