The Principle of Least Privilege Was Written for Humans. AI Agents Are Breaking It.

Why a 50-year-old security concept just became the most important control in your AI stack

In 1975, Jerome Saltzer and Michael Schroeder published a paper on the protection of information in computer systems. Buried inside it was a design principle that would quietly become one of the most repeated phrases in security: every program and every user of the system should operate using the least set of privileges necessary to complete the job.

Fifty years later, that sentence is having a second life not because it changed, but because the thing it's supposed to constrain changed completely.

What Least Privilege Actually Means

Strip away the jargon and the principle of least privilege (PoLP) is a simple question you ask before granting any access: what does this actually need, right now, for this specific task? Not what it might need someday. Not what would be convenient. What it needs.

You see it everywhere once you know to look for it:

• Your laptop's regular user account can't install system-wide software without you explicitly elevating to admin because if malware compromises that account, you don't want it holding the keys to the whole machine.
• A web application's database login typically gets SELECT, INSERT, and UPDATE on the tables it actually touches not DROP TABLE, and not read access to a customer table it has no business querying.
• A flashlight app asking for your contacts list is a least-privilege violation you can spot with your gut. It has no legitimate reason to need that.

The value isn't abstract. Least privilege does three concrete things:

1. It limits the blast radius of mistakes. A junior engineer who fat-fingers a command with a narrowly-scoped account can't take down production.
2. It limits the blast radius of compromise. If an attacker steals a low-privilege credential, they inherit a small foothold, not the keys to the kingdom.
3. It makes audits legible. When access maps cleanly to need, unusual access stands out immediately instead of hiding in noise.

For decades, the actors this principle governed were relatively predictable: employees with defined roles, and service accounts that called the same handful of APIs on a fixed schedule. You could map "what does this need" once, encode it into a role, and revisit it periodically.

Then the actor changed.

The New Kind of Identity

AI agents don't behave like static service accounts. They plan. They select their own tools mid-task. They chain actions together read this, then decide, then write that, then call a third system based on what the second one returned often without a human reviewing each individual step.

This is exactly what makes them useful. It's also exactly what breaks the assumptions least privilege was built on.

Security researchers now describe agents as a new category of non-human identity digital actors with credentials, access rights, and an exposure surface, but without the predictable behavior patterns that made traditional access reviews tractable. And the scale is moving fast: organizations that ran a handful of agents in production in 2025 are running dozens across finance, healthcare, and industrial workflows now. Most traditional IAM tooling wasn't built to see this category of identity, let alone govern it.

The common failure pattern is depressingly familiar, just faster: an agent gets granted broad access so it can do its job without friction. It uses a sliver of that access once. The rest sits open indefinitely, because nobody's running an annual access review on an agent that was spun up for a one-off task three weeks ago. Privilege creep, but on agent-timescales instead of human-timescales.

The Part That's Genuinely Different

Here's the distinction that matters most, and the one most teams get wrong first: a prompt is not a security boundary.

You can write "only access customer records for accounts assigned to you" directly into an agent's system instructions. That instruction is advisory. It shapes behavior under normal conditions. It does nothing to prevent an action if the agent is manipulated through prompt injection, if it hallucinates a plan that seems locally reasonable, or if a chain of tool calls produces a side effect nobody anticipated.

The only thing that actually stops an agent from taking an action is whether its credentials technically permit that action. Not what it was told. What it's authorized to do at the infrastructure layer.

This reframes the entire problem. You're not trying to make the agent behave correctly 100% of the time that's not achievable given the current state of prompt injection defenses, and pretending otherwise is a planning error. You're trying to make sure that when it doesn't behave correctly, the damage is bounded by what its access allows.

Excessive Agency: The Vulnerability With a Name

OWASP formalized this exact failure mode as LLM06:2025 Excessive Agency, and it's worth understanding its anatomy because it maps directly onto how you fix it.

Excessive Agency happens when an AI system is granted more power, permissions, or autonomy than the task in front of it actually requires so instead of just generating text, the model can take real, consequential actions: updating records, sending messages, executing transactions, modifying files.

OWASP traces it to three distinct root causes, and they require three distinct fixes:

Excessive functionality — the agent has access to tool capabilities beyond what its task needs. Classic example: you need an agent to read documents from a repository, but the extension you wired up also happens to support modifying and deleting them. The unused capability doesn't help anyone. It's pure downside risk sitting there waiting for a bad day.

Excessive permissions — the agent (or its tools) operate with privileges broader than the specific action requires. This is the direct IAM analog of the classic least-privilege violation, just applied to a non-human actor that can decide, on its own, which of its available permissions to exercise.

Excessive autonomy — high-impact or irreversible actions execute without any checkpoint. The agent doesn't just have the capability, it also has unmediated authority to use it.

What Fixing This Actually Looks Like

This isn't a policy document problem. It's an architecture problem, and the controls are specific:

Dedicated identity per agent. No shared, all-purpose service credential passed around between agent instances. Each agent gets its own identity, which is also what makes auditing and revocation possible in the first place.

Default-deny tool allowlisting. Instead of "give it broad system access and trust the prompt to constrain it," you give it a specific, narrow set of callable functions a scoped send_email(), not shell access; a scoped read_customer_record(id), not raw database credentials. Open-ended tools like "run a shell command" or "fetch any URL" are exactly the capabilities that turn a contained mistake into an uncontained one.

Short-lived, task-bound credentials. Just-in-time provisioning over standing keys. Credentials get minted when a task starts and expire when it ends, so there's no permanently-live high-privilege key sitting around waiting to be exfiltrated.

Complete mediation. This is the principle most teams skip, and it's the one that matters most: the LLM itself is never the authorization check. Every downstream system independently verifies whether an action is permitted, regardless of what the model decided. The model's output is a request. It is never, on its own, a permission slip.

Human-in-the-loop, scoped narrowly. Gate approval specifically on high-impact, hard-to-reverse actions sending external communications, deleting data, financial transactions rather than requiring blanket approval on everything, which just defeats the speed advantage agents exist to provide in the first place.

Behavioral monitoring, not just static audits. An agent's permission set can look perfectly reasonable on paper and still be exploited through a sequence of individually-authorized actions that add up to something nobody intended. Mapping activity against threat-informed frameworks like MITRE ATLAS and flagging when an agent's behavior drifts from its established baseline catches what a point-in-time access review can't.

Why It Compounds in Multi-Agent Systems

Single-agent least privilege is hard enough. Multi-agent pipelines make the stakes worse, because a single loosely-governed node doesn't just create risk for itself it widens the attack surface for the entire workflow downstream of it. A compromised or manipulated agent early in a pipeline can trigger a cascade of "correctly authorized" actions in every agent that trusts its output. The chain is only as tightly scoped as its weakest link, and in a system with a dozen agents, weak links are easy to miss.

This is why enforceable, infrastructure-level policy has to replace natural-language task boundaries the moment you're coordinating more than one agent. "I told it not to" doesn't survive contact with a manipulated upstream input.

The Honest Trade-off

None of this is free. Tight tool allowlists mean more upfront engineering to define exactly what each agent can touch. JIT credentials mean more provisioning infrastructure than a static API key. Human-in-the-loop gates, even narrowly scoped, mean some latency on the highest-stakes actions.

But weigh that against the alternative: an autonomous system, acting faster than any human review cycle, with standing access to more than its current task requires, and no infrastructure-level backstop if something goes wrong. That's not a hypothetical. Tool misuse and privilege escalation are already the most commonly reported category of agentic AI security incidents more common than the flashier failure modes like memory poisoning, even if those carry more severe consequences when they do happen.

The Bottom Line

Least privilege was never really about the normal case. Nobody violates it and gets away with it during business as usual the entire point of the principle is what happens on the bad day, the day something goes wrong that nobody planned for.

AI agents just made "something goes wrong that nobody planned for" a lot more likely, and a lot faster-moving, than it used to be. A prompt can be injected. A model can hallucinate a plan. A tool chain can produce an outcome nobody anticipated. None of that is fully preventable with today's defenses.

What's fully within your control is how far the damage can travel when it happens. That's what least privilege has always been for. It just went from being good hygiene to being the load-bearing wall.

If you're building or securing agentic systems, I'd be curious how you're handling credential scoping in practice — per-agent IAM roles, gateway-level allowlisting, something else entirely. Drop a comment; this space is moving fast enough that the real answers are still being figured out in production, not in the standards documents.