Agents Need the Principle of Least Privilege Too
The principle of least privilege is one of the oldest, most boring, and most thoroughly settled ideas in computer security. Grant a process exactly the access it needs to do its job, and no more. The principle is taught in introductory security courses. It is enforced by every reputable identity provider. It is the default posture of every modern operating system. The arguments for it have been made, won, and embedded in the foundation of the industry.
We are in the process of forgetting it. The agent population growing inside enterprise systems is, almost without exception, running with substantially more privilege than the principle would allow. Most teams that built these agents would, if asked, agree that least privilege is correct. The agents have more privilege anyway. The gap between the principle and the practice is wide, growing, and producing a class of incidents that the industry is going to have to live through before it tightens up.
How the Privilege Got So Wide
The privilege creep on agents is not malicious. It is the predictable result of two pressures.
The first is iteration speed. When a team is building an agent for a new workflow, the fastest path to a working prototype is to give the agent broad access – “let it read whatever it needs, write wherever it needs to write” – and worry about restriction later. The prototype works. The prototype gets shown to stakeholders. The stakeholders ask for production deployment. The team moves to production. Restricting the privileges at this point would require redesigning the agent’s data access patterns, retesting against the new restrictions, and likely revealing edge cases the broad-access prototype was silently working around. The cost of restriction, post-prototype, is high. The cost of just shipping the prototype with its broad access is low. Most teams ship the prototype.
The second is the difficulty of specifying agent privileges precisely. A traditional service has predictable access patterns – it touches these tables, calls these APIs, writes to these queues. An agent’s access patterns are determined at inference time by the model’s choices, which means the team designing the privilege model is trying to enumerate every action the agent could plausibly take rather than every action it definitely will take. The conservative path – enumerate everything plausibly needed and grant it – produces a privilege envelope that is much larger than the actions any single agent invocation actually requires.
Combine these two pressures and the steady-state result is agents that have access to most of what they could conceivably need, which is most of the system.
What This Looks Like in Practice
We do not have to speculate about the consequences. We have seen them.
An agent built to draft customer-service responses, granted read access to the entire customer database for “context lookup,” produced a series of responses to one customer that referenced details about another customer’s account. The model conflated records that, in retrospect, the agent should not have had access to in the same context. No security control was bypassed. The agent did exactly what it was permitted to do. The permission envelope was wrong.
A coding agent granted write access to a broad set of repositories, in order to be able to “make small fixes across the codebase,” produced a change to a security-critical repository that the team responsible for that repository did not know was happening. The PR was reviewed and merged before the security team noticed. The merge was caught and reverted within hours, with no production impact. The next time, the timing might be different.
A reporting agent granted read access to a production analytics warehouse for “cross-functional reporting” was, in a routine query, returned a result set that included PII fields the agent’s downstream consumer was not permitted to see. The PII propagated into a report that was distributed to a wider audience than the original data classification permitted. The incident triggered a data-handling review. The agent’s permissions had not been wrong on any specific control; the controls had not been designed for the combinations the agent was producing.
None of these incidents involved a security failure in the traditional sense. The infrastructure was secure. The authentication was sound. The encryption was end-to-end. The principle of least privilege was the missing control, and its absence produced the failures.
What Least Privilege Looks Like for Agents
Translating the principle to the agent context requires three adjustments to how it is traditionally applied.
Privilege scoped to the task, not to the agent. Traditional services are long-lived and have a stable identity. Their privileges are set once, reviewed periodically, and remain in place. Agent invocations are short-lived and execute specific tasks. The right privilege envelope is task-shaped: the privileges granted for a given invocation should be the privileges that invocation specifically needs, and they should be revoked when the invocation ends.
This is harder than it sounds, because the task is defined dynamically. The agent does not know its full task graph at invocation time. The privilege system has to support per-action authorization rather than per-session authorization, with the agent presenting evidence of its current intent and the authorization system verifying that the intent is within scope.
Privilege bounded by the human’s authority. When an agent is acting on behalf of a named human, the agent’s privileges should be the intersection of what the agent’s role permits and what the human is themselves authorized to do. Many agent systems get this backwards: they grant the agent a privilege envelope larger than any of the humans it serves, on the theory that the agent is “system-level” and operates beyond user permissions. This is the opposite of least privilege. The agent should be bounded by the most restrictive permission set among the actors it represents, not the least.
Privilege observable and revocable in flight. A long-running agent action – something that takes minutes or hours – needs to be observable while it runs and revocable in flight. The traditional model, where a service has its privileges and uses them until the next privilege review cycle, does not produce the right operational properties. If an agent is doing something it should not be doing, the team needs to be able to see it and stop it in seconds, not after the next quarterly review.
What Has to Change in the Infrastructure
The infrastructure most teams are running against does not yet support these patterns natively. We have built parts of the missing infrastructure ourselves; some of it is starting to appear in vendor offerings; most of it is still rough.
Action-level audit logs. Beyond the standard access logs, every agent action – the specific record read, the specific query executed, the specific API call made, the specific file written – needs to be logged with sufficient context that the action can be evaluated against the agent’s stated task. This log is often substantially larger than the underlying production traffic, which is one of the reasons teams skimp on it.
Capability tokens, scoped per task. Rather than granting an agent broad access via a service account, the right pattern is to issue the agent a narrowly scoped capability token at task start. The token grants only the access the task requires, expires when the task ends, and is logged in detail. This is the closest analog to how modern systems handle short-lived credentials for human users, applied to agents.
Behavioral envelopes. Beyond per-action authorization, the system needs to monitor aggregate behavior. An agent that is technically authorized for every individual action but is producing an aggregate access pattern that looks anomalous – many more records than usual, records spanning categories that do not normally co-occur, queries that are structurally unlike the agent’s typical queries – should trigger a review. This is the agent equivalent of fraud detection. It is rare in production today. It will not be rare in three years.
Human-in-the-loop escalation paths. Some agent actions should require a human signature before execution. The threshold for “should require” depends on the domain. Production database modifications. External communications. Financial transactions above a defined value. Changes to security-critical code. The system needs to support these escalations without rewriting the agent each time the threshold changes.
Why Teams Resist This
The resistance is not philosophical. The teams we work with understand the principle. The resistance is operational: implementing least privilege for agents is expensive. The infrastructure required is real engineering work. The per-task authorization is more complex than per-service. The action-level logging produces volumes of data that require their own retention and query infrastructure. The behavioral monitoring requires the team to define what “normal” looks like for each agent, which is its own engineering project.
The cost is real. So is the cost of not doing it. The orgs that pay the cost now will be operating on a privilege model that is appropriate for their actor population. The orgs that defer the cost will be running agents with elevated privileges until an incident forces them to retrofit the controls, and retrofitting is more expensive than building correctly the first time.
The board-level conversation about this is rarely happening because the technical detail is too far below the board’s normal altitude. It surfaces only after the first material incident. By that point, the cost has already been paid in a worse currency.
The Honest Statement
The principle of least privilege is settled science. The application of it to agent populations is not. Most agent systems in production today have privilege envelopes that would be considered unacceptable for any equivalent human-driven service, and the gap is widening as more agents come online with broader access.
The fix is not theoretical. It is operational. Build task-scoped privilege. Bound agents by their delegating human’s authority. Log at the action level. Monitor for behavioral anomaly. Escalate the high-stakes actions to human signature. Do it before you need it. Doing it now is engineering work. Doing it after the incident is firefighting plus engineering work plus reputational repair.
The principle is the same as it has always been. The application is the part that has to be earned. Earn it.
