Least Privilege Wasn't Built for Agents

Jerome Saltzer and Michael Schroeder published their foundational security paper in 1975, establishing the principle that every subject should operate with the minimum set of privileges needed to do its job. Fifty-one years later, the principle holds. The implementation doesn’t.

The principle of least privilege remains sound across security architectures, from NIST SP 800-207 Zero Trust Architecture to modern identity frameworks. But when applied to agents that make thousands of decisions per hour, the implementation gap becomes critical.

Here’s the core problem

Least privilege works when the actor is human. When it’s an agent, everything breaks. Agents make thousands of decisions per hour. Your permission review cycle makes a few per week. That gap is your risk.

Traditional access control assumes a slow, supervised user who acts deliberately. An agent is fast, autonomous, and makes decisions at scale. The tooling that worked for humans doesn’t scale to machines making ten thousand requests in the time it takes you to read this sentence. This mismatch between human-speed governance and agent-speed execution is documented in the OWASP Top 10 for LLM Applications.

The principle of least privilege is sound. The problem is implementation. We designed permission systems for humans, not machines. When an agent can make decisions faster than you can audit them, you need a different kind of guardrail.

What happens when you apply human-speed controls to machine-speed agents?

A typical permission review cycle looks like this: someone requests access, a manager approves it, and a week later the change goes live. That works fine when the user is a person who makes 10 decisions per day.

Now scale it. Your agent makes 10,000 decisions per day. Your review cycle hasn’t changed. Neither has your approval process. The math breaks.

You end up doing one of two things. Either you give the agent more permissions than it needs (because granular access control is too slow to implement), or you audit nothing and hope it works (because auditing 10,000 decisions per hour is impossible without automation). Both are bad.

The speed mismatch creates a governance vacuum. Traditional least privilege assumes you can see and approve all significant actions. Agents blow past that assumption.

Speed limits work because humans can react

Think about how speed limits actually function on a highway. A posted speed limit assumes drivers have reaction times. A human can see an obstacle and brake in a few hundred milliseconds. Speed limits work because they’re set for the physics of human reaction.

Self-driving cars don’t follow the same rules. They process sensory input and make corrections at millisecond scale. They don’t slow down because humans can’t react fast enough. They change the infrastructure itself: sensor-rich environments, communication with other vehicles, dedicated lanes.

Least privilege with agents works the same way. You can’t just apply human-paced permission reviews to machine-paced decisions. You need infrastructure that matches the speed of the system. That means:

• Continuous permission validation, not approval cycles
• Real-time telemetry that flags anomalies, not weekly reports
• Permission boundaries that adapt based on context and risk, not static access lists
• Automation that can handle the decision volume, not humans reviewing spreadsheets

The principle stays the same. The implementation has to change.

What does least privilege actually mean for an agent?

For a human, least privilege means: give them access to the database tables they need, the files they touch, the APIs they call. Audit it once a quarter.

For an agent, it means: define the narrowest decision boundary for each action, validate permissions on every request, log everything, and alert when the pattern changes. Then run that constantly.

Think of it as continuous calibration, not a one-time access grant.

A real example: an agent that sends transactional emails should have permission to call the email API, but only with templates it doesn’t write itself, only to addresses that have opted in, and only within a rate limit that matches business needs. Not “please approve Joe’s access to the email service.” That’s too broad and too slow.

The permission model becomes granular, continuous, and observable. Less like a lock you open once. More like a boundary you monitor continuously.

The test

Here’s how to know if your governance model is built for agents.

Map your agent’s decision rate against your permission review cycle. If your agent makes 10,000 requests per hour and your permission review cycle is one week, you have a gap of roughly 1.6 million to 1.

That ratio tells you how exposed you are. A 100-to-1 gap is tight governance. A 1000-to-1 gap means your system is running faster than you can oversee it.

Fix the gap by changing the implementation, not by limiting the agent. Slower agents are worse agents. Build the infrastructure that lets you govern at speed.

The principle Saltzer and Schroeder described in 1975 is still right. You just need infrastructure that keeps up.

The question shifts from “Is least privilege possible?” to “How do we actually scope it?” That’s where the three-layer model comes in. Thursday, we break down identity, scope, and context. These layers make least privilege work at agent speeds.