The Principle of Least Privilege
The principle of least privilege is one of the simplest ideas in security and one of the most violated. It says that every identity, whether a person, a device, an application, or an automated agent, should have only the minimum access it needs to do its job, and nothing more. That is the whole rule. The difficulty is living by it.
The principle of least privilege is one of the simplest ideas in security and one of the most violated. It says that every identity, whether a person, a device, an application, or an automated agent, should have only the minimum access it needs to do its job, and nothing more. That is the whole rule. The difficulty is living by it.
The reason it matters is not that least privilege prevents breaches. It does not. It decides how bad a breach becomes once it happens.
Why it matters
| What least privilege limits | How |
|---|---|
| Attack surface | Fewer permissions per identity means fewer ways in and fewer things to exploit. |
| Blast radius | If an account is compromised, strict limits contain the damage to its narrow scope. |
| Lateral movement | An attacker in one account cannot reach systems that account never needed. |
| Standing risk | Just-in-time and per-session access removes always-on privileges attackers love. |
Permissions are exposure. Every right an identity holds is something an attacker inherits if they take it over. Least privilege is the discipline of keeping that inheritance small.
Putting it into practice
Least privilege is less a project than a habit. It is enforced one grant at a time, and undone one “temporary” exception at a time.
[[INSIGHT: The most dangerous permission is the one nobody remembers granting. A service account given admin rights “just for debugging” at 11 p.m. becomes a standing liability the moment everyone forgets it. Least privilege is really a discipline of revoking, not just granting.]]
See it in action: when an account is compromised
Least privilege does not stop a breach. It decides how far the breach can go. The scenarios below are illustrative.
- The service was given full read, write, and delete on all storage ‘to save time’.
- A bug in it lets an attacker wipe the company’s data.
- ScopeThe service can only read one bucket and write the resized copy.
- ContainThe same bug now exposes one folder, not everything.
- The account carried admin rights it never used.
- The attacker inherits the keys to the kingdom.
- LimitThe account has only what the role requires.
- JITElevated access is granted per session, not standing.
- Least privilege grants every identity only the minimum access it needs.
- It shrinks the attack surface and the blast radius when an account is compromised.
- Strict limits prevent lateral movement to systems the account never needed.
- It is most often violated by temporary grants that quietly become permanent.
- It applies to service accounts and automated agents, not just people.
Frequently asked questions
What is the principle of least privilege?
Granting every identity, whether a user, device, application, or non-human identity, only the minimum access and permissions needed to do its legitimate job, and nothing more.
Why does least privilege matter?
It shrinks the attack surface and the blast radius of an incident. If an account is compromised, strict permission limits contain the damage and prevent lateral movement to other systems.
How is least privilege commonly violated?
Through ‘temporary’ fixes that become permanent, like giving a service account admin access while debugging and never revoking it. Regular audits catch these over-privileged accounts.
Does least privilege apply to non-human identities?
Yes. Service accounts, workloads, and AI agents are frequent targets. An over-privileged non-human identity lets an attacker exploit excessive permissions for lateral movement, so they need least privilege too.
