Every account, service and API key you create is a door. The principle of least privilege asks a simple question about each one: if this door is opened by the wrong person, how much of the building can they reach? The answer should always be "only what that door was for".
What least privilege means
Least privilege has two dimensions:
- Scope: grant only the permissions needed for the task. Read-only if writing isn't needed; one table, not the whole database; one bucket, not every bucket in the account.
- Time: grant permissions only for as long as they're needed. Remove access when people change roles or leave, and prefer temporary elevation to permanent admin rights.
The goal isn't to stop compromise, which is the job of other controls. It's to limit the blast radius when compromise happens anyway. That makes least privilege one of the most important layers of defense in depth.
Where it applies
People are the obvious case, but most privilege in a modern system belongs to machines:
| Identity | Over-privileged | Least privilege |
|---|---|---|
| Employee | Everyone in engineering has production admin | Read-only by default, time-limited elevation with approval |
| Application | Connects to the database as the owner role | A role that can only run the queries the app needs |
| CI/CD pipeline | One cloud key with full admin rights for every job | Per-job short-lived credentials, deploy rights only on the deploy job |
| Third-party integration | An API token with every scope ticked | Only the scopes the integration uses |
| Container | Runs as root with the host's network | Non-root user, read-only filesystem, network policy |
Why privileges creep
Almost no one sets out to over-privilege a system. Privileges accumulate: a developer gets admin rights to debug an incident and keeps them; a service account gets an extra permission for a feature that was later removed; two services share a database role because creating a second one was a ticket nobody had time for. Access only shrinks when something actively removes it, which is why access reviews and expiring grants matter as much as the initial design.
Worked example: Invoicely
The most surprising finding in the Invoicely threat model was a least-privilege failure. The internal admin console used by support staff connects to the database with the same role as the customer-facing API. That produced threat T5:
A support agent can read or change any customer's data because the console shares the API's database role.
It scored 15 (high). The fix is to give the console its own role that can read only the fields support needs and write nothing without an audited workflow. That one change shrinks the insider branch of the attack tree to what an agent's job legitimately requires, and it also limits the damage if a support account is phished.
How to apply it in a threat model
- Label the identity on every flow. On the data flow diagram, note which credential or role each process uses to reach each data store.
- Look for sharing. Two processes with different trust levels using the same credential is the classic finding.
- Ask "what if this is compromised?" For each process, list what an attacker could reach with its permissions. If the list is much longer than the process's job, that's an elevation-of-privilege threat.
- Check the lifecycle. Who removes this access, and when?
Related principles
Least privilege was one of eight design principles in Saltzer and Schroeder's 1975 paper on protecting information in computer systems. Two of its companions are worth knowing alongside it:
- Separation of duties: no single person can complete a sensitive action alone, such as both creating and approving a payment.
- Fail-safe defaults: access is denied unless explicitly granted, so a missing rule fails closed rather than open.
Common mistakes
- Applying it to people but not services. Machine identities usually outnumber human ones and are rarely reviewed.
- Least privilege on paper only. A fine-grained role model is pointless if everyone is in the admin group "temporarily".
- Making it so painful people work around it. If getting access takes a week, people share credentials. Fast, audited, temporary elevation beats slow permanent grants.
Key takeaways
- Least privilege means minimum access, for minimum time. Its goal is a small blast radius when something is compromised.
- It applies to services, CI pipelines, database roles and API keys as much as to people.
- Shared credentials and shared database roles are the most common violations, and threat models find them quickly.
- Privileges grow over time unless something removes them: review access regularly and prefer just-in-time elevation over standing admin rights.
Frequently asked questions
What is an example of least privilege?
A reporting service that only needs to read sales data gets a read-only database role limited to the sales tables, instead of the application's full read-write role. If the reporting service is compromised, the attacker can't change or delete anything.
Who created the principle of least privilege?
It was set out by Jerome Saltzer and Michael Schroeder in their 1975 paper "The Protection of Information in Computer Systems", as one of eight design principles for secure systems. Most of the others, such as fail-safe defaults and separation of privilege, are still taught today.
What is the difference between least privilege and zero trust?
Least privilege is a principle about how much access to grant. Zero trust is an architecture that never grants access based on network location and verifies every request. Zero trust relies on least privilege, but also covers continuous verification and device posture.
What is just-in-time access?
Just-in-time (JIT) access grants elevated permissions only when they are needed, for a limited time, often with approval, instead of leaving them permanently assigned. It reduces the number of standing admin accounts an attacker could steal.