What is the principle of least privilege?
By Identra · Updated
The principle of least privilege is a security design rule stating that every identity, human or machine, should hold only the minimum permissions required to perform its current task, and hold them only for as long as the task requires. First formalized by Saltzer and Schroeder in 1975, it limits the damage any single compromised identity can cause.
Key numbers
- Only 2% of granted permissions across human and workload identities were actually used in 2023 (Microsoft State of Multicloud Security Report, 2024)
- More than 51,000 permissions on average were granted to users and workloads per organization (Microsoft State of Multicloud Security Report, 2024)
- Machine identities outnumber human identities 82 to 1 (CyberArk Identity Security Landscape, 2025)
- 42% of machine identities have privileged or sensitive access (CyberArk Identity Security Landscape, 2025)
Where does the principle come from?
Jerome Saltzer and Michael Schroeder named the principle in their 1975 paper The Protection of Information in Computer Systems: every program and every user should operate using the least set of privileges necessary to complete the job. Fifty years later it remains the most widely cited rule in access control design, and it appears in nearly every compliance framework, from NIST 800-53 to PCI DSS to SOC 2.
The logic is blast radius. Any identity can be compromised: a phished employee, a leaked API key, a hijacked AI agent. Least privilege does not prevent the compromise. It caps what the compromise is worth. An identity that can only read one bucket is a contained incident. An identity with administrative rights across three clouds is a breach report.
Why does least privilege decay?
Almost every organization endorses least privilege, and almost none sustains it. Microsoft's 2024 State of Multicloud Security Report found that identities used only 2% of the permissions they were granted, out of an average of more than 51,000 granted permissions per organization. The gap between granted and used is the standing attack surface.
The decay has a name: privilege creep. It happens through ordinary, well-intentioned work rather than negligence.
- People change roles and keep old entitlements because nobody owns revocation
- Incident responders get emergency access that outlives the incident
- Engineers copy IAM policies from a working service instead of scoping new ones
- Teams grant wildcard permissions to stop breakage during launches, then never tighten them
- Quarterly access reviews rubber-stamp lists too long for any human to reason about
Enforcement per identity, not per credential
A common failure mode is enforcing least privilege on credentials instead of identities. A single service account key shared by five microservices carries the union of everything all five need, so each service silently inherits the excess of the other four. The credential may look reasonably scoped on paper while every workload behind it is over-privileged in practice.
Least privilege only holds when the unit of enforcement is the individual identity performing the action: this specific workload, this specific pipeline job, this specific agent, each with its own identity, its own scoped grant, and its own audit trail. Shared secrets collapse that granularity. This matters most for non-human identities, which CyberArk's 2025 Identity Security Landscape counts at 82 for every human identity, with 42% holding privileged or sensitive access. When those identities share credentials, one leaked secret becomes many breached systems.
How do AI agents change least privilege?
Classic least privilege assumes you can predict what an identity needs. A billing service needs the billing database; you scope its role once and review it yearly. AI agents break that assumption. An agent plans its own steps at runtime, and the task it receives at 2 PM may need permissions that the task at 3 PM should never touch. There is no single static role that is simultaneously broad enough to be useful and narrow enough to be safe.
The workable model is dynamic least privilege: grants that are scoped to the task, issued just in time, and expired when the task ends. Delegation adds a second constraint. An agent acting on behalf of a user should operate within the intersection of what the agent is trusted to do and what that user is allowed to do, not the union. Without that, agents become privilege escalation machines that launder user requests through broader machine permissions.
How do you enforce least privilege in practice?
The pattern that works treats least privilege as a continuous control loop rather than a provisioning-time decision.
- Inventory every identity, including service accounts, workloads, and agents, before tuning any permissions
- Rightsize based on observed usage, not on what teams say they need
- Replace standing admin rights with just-in-time elevation and automatic expiry
- Give every workload and agent its own identity so grants and audit trails stay per-actor
- Monitor at runtime, because a permission that is never exercised is a removal candidate and a permission exercised abnormally is an incident
| Static least privilege | Dynamic least privilege |
|---|---|
| Permissions assigned at provisioning | Permissions granted per task, just in time |
| Long-lived credentials and standing roles | Short-lived credentials that expire on their own |
| Quarterly access reviews | Continuous comparison of granted versus used |
| Scoped to roles and groups | Scoped to the individual identity and the current action |
| Human identities prioritized | Human, workload, and agent identities held to the same bar |
How Identra thinks about it
Least privilege is a runtime property, not a provisioning artifact. A policy written at grant time starts decaying the moment it ships, and for AI agents there is often no meaningful grant time at all, because the needed permissions depend on the task the agent picks up next. Enforcement has to happen where actions happen: verify the acting identity, human, workload, or agent, at the moment of each request, scope the grant to that task, and expire it when the task completes. That is the only version of least privilege that survives contact with the non-human majority.
Go deeper: The Non-Human Majority
Frequently asked questions
What is an example of the principle of least privilege?
A billing service gets read and write access to the billing database and nothing else: no customer analytics tables, no infrastructure APIs, no admin rights. If that service is compromised, the attacker gets exactly one database. The counterexample is a shared service account with administrative access across environments, where one leaked credential exposes everything at once.
What is privilege creep?
Privilege creep is the gradual accumulation of permissions an identity no longer needs. People change roles and keep old entitlements, emergency access outlives the incident, and engineers copy permissive policies from working services. Nobody owns revocation, so grants only ever grow. The result is a wide gap between granted and used permissions, and that gap is standing attack surface.
What is the difference between least privilege and zero trust?
Least privilege governs how much access an identity holds: the minimum required for the task. Zero trust governs whether any request is trusted: verify explicitly every time, regardless of network location. They are complementary. Zero trust decides if a request proceeds; least privilege bounds what a verified identity can do once it does. Mature programs enforce both continuously.
How do you implement least privilege in the cloud?
Inventory every identity first, including workloads and service accounts, then rightsize permissions based on observed usage rather than requested access, since most granted cloud permissions go unused. Replace standing admin roles with just-in-time elevation, give each workload its own identity instead of shared credentials, and continuously compare granted versus exercised permissions to catch drift.