Least Privilege
The design principle of giving every user, process, service or agent only the access its task requires, and only for as long as it requires it.
Least privilege is the principle that every subject in a system (a user, a process, a service account, an API token or an AI agent) should hold only the permissions its task requires, and only for as long as it requires them. Saltzer and Schroeder listed it in 1975 among their eight design principles for protecting information, with a simple argument: the less a component is allowed to do, the less damage an error or a compromise can cause. It’s the reason a web server shouldn’t run as root, and a backup job shouldn’t be able to delete the backups.
Three dimensions of privilege
Minimizing privilege is more than picking a smaller role:
- Scope. Which resources: one bucket, not every bucket; one repository, not the whole organization.
- Actions. What it can do with them: read is not write, and write is not delete or share.
- Time. How long it holds the access: standing permissions become just-in-time grants that expire when the task is done.
A credential can be minimal on one axis and wide open on another. A read-only key that never expires is still a long-lived secret worth stealing.
Why it matters for defense
Least privilege doesn’t make a compromise less likely; it makes it smaller. Attackers rarely stop at the first foothold: they look for credentials and permissions that let them move laterally or escalate, and every unused permission is an option handed to them in advance.
It also makes detection easier. An identity that only ever does a narrow set of things gives you a clean baseline, so anything outside that set stands out.
In practice
- Cloud and IAM. Wildcard policies and over-scoped service accounts are a recurring finding in cloud reviews. Roles drift as they pick up permissions for one-off tasks, which is why comparing granted permissions against used ones is a standard hardening step.
- AI agents. An agent inherits every permission of the tools and tokens it’s handed, and it can be steered by prompt injection. OWASP calls the result excessive agency: too much functionality, too many permissions or too much autonomy. At Ekoparty 2026, the same injection run against differently configured agents made the point: the damage followed the permissions, not the payload. And an agent with more access than the person who delegated the task is a confused deputy that needs no exploit to escalate.
- Secrets in tests and pipelines. The cheapest secret to protect is the one a process never receives. To prove an isolation boundary works, inject a known fake value instead of reading the real one.
Common misconceptions
- “It’s about restricting people.” It applies at least as much to machines: service accounts, CI tokens and agents often hold more standing power than any human.
- “Set it once and you’re done.” Privilege drifts. Least privilege needs periodic review against what is actually used.
- “It’s a prevention control.” It’s mainly an impact-limiting control, which is why it pairs with detection and other layers in defense in depth.
Retrieval prompts
Test recall before peeking. Spaced repetition beats re-reading.
What does least privilege mainly limit: the chance of a compromise or its impact?
Mostly the impact, the blast radius. It doesn't make an account or process harder to compromise; it makes a compromised one able to do less, and makes its misuse easier to spot.
Along which three dimensions should privilege be minimized?
Scope (which resources), actions (read vs write vs delete or share) and time (standing access vs just-in-time access that expires).
An AI agent that summarizes support tickets holds a token that can also close tickets and email customers. Which OWASP LLM risk is this, and what's the fix?
Excessive agency (LLM06): excessive functionality and permissions. Give it a read-only token scoped to tickets, and route any write action through a separate step that a human approves.