The principle of least privilege states that every user, service, process, and credential should be granted the minimum access required to perform its function — no more, and only for as long as it is needed. A read-only reporting job gets read-only database credentials, not admin. A microservice that calls one API gets a token scoped to that API alone, not a wildcard key. A contractor who needs one folder gets that folder, not the whole share. The principle is deliberately narrow because its power comes from containment: when — not if — something is compromised, least privilege determines how far the damage spreads. It is the single most effective control for limiting the blast radius of a breach, which is why it appears in nearly every security framework and secure-design standard ever written.
Why It Matters
Breaches are rarely a single event; they are a chain. An attacker phishes one credential, lands on one machine, and then moves laterally — escalating privilege, reaching new systems, and exfiltrating data. Least privilege breaks that chain at every link. If the compromised credential could only read one bucket, the attacker got one bucket, not the whole account. The initial foothold still happened, but the catastrophe did not.
This is why least privilege is often called the most important security principle: it is the one that decides how bad a bad day gets. Every other control aims to prevent compromise; least privilege assumes prevention will sometimes fail and limits what failure costs. It also produces cleaner systems — narrowly scoped access is easier to audit, reason about, and revoke than a tangle of broad grants, and it turns the question "who can touch this?" from a research project into a short list.
How to Do It
Least privilege applies across several dimensions of access. The table maps each to a concrete over-privileged pattern and its minimal fix.
| Dimension | Over-privileged anti-pattern | Least-privilege fix |
|---|---|---|
| Identity | Shared admin account for a team | Individual accounts with role-scoped rights |
| Service | One API key with full access | Per-service tokens scoped to needed calls |
| Data | App reads and writes every table | Grants limited to the tables it uses |
| Network | Service reachable from anywhere | Reachable only from callers that need it |
| Time | Standing admin access, always on | Just-in-time elevation that expires |
| Build | CI can publish and read all secrets | Per-pipeline credentials, minimal scope |
Implement it as a default posture, not an afterthought:
- Start from deny. Grant nothing by default and add access only when a concrete need is demonstrated. This is far safer than starting broad and trimming later, because trimming rarely happens.
- Scope every credential to its job. For each token, role, and account, write down what it must do, then grant exactly that. If you cannot name the need, do not grant the access.
- Prefer short-lived and just-in-time. Standing privileges are standing risk. Use expiring credentials and on-demand elevation so access exists only during the window it is used.
- Separate duties for sensitive actions. No single identity should be able to complete a high-impact operation — like deploying to production or moving money — entirely alone.
- Review and revoke on a cycle. Access that was minimal at launch decays as roles change. Periodically re-verify that every grant still maps to a current need and revoke what does not.
A useful mental filter: for any access request, ask "what is the least this actor needs to do its job, and for how long?" The answer is the grant.
Common Pitfalls
- Privilege creep. The most common failure. Access accumulates as people change roles and teams add "just one more scope," and nobody ever removes anything. Least privilege granted once erodes into over-privilege within months without periodic review.
- Convenience over-provisioning. Granting admin because scoping the exact permission is tedious. The five minutes saved becomes the difference between a contained incident and a full compromise.
- Ignoring machine identities. Teams scope human access carefully and then hand service accounts and CI pipelines god-mode tokens. Machine identities vastly outnumber humans and are prime lateral-movement targets.
- Standing access that should be temporary. Permanent admin rights "in case they are needed" are a leaked credential waiting to matter. Just-in-time elevation removes the standing target.
- No revocation path. Granting access is easy; the failure is having no process to take it back when the need ends, so grants only ever accumulate.
How It Connects to Supply Chain Security
Least privilege applies with special force to the software supply chain, because build and deployment systems are high-value targets that too often run with sweeping access. A CI job that can publish to production registries, read every secret, and push to any repository is a catastrophic single point of failure — compromise it once and the attacker owns everything downstream. Several of the most damaging supply chain attacks succeeded precisely because a build system or automation token was far more privileged than its actual task required.
Applying least privilege here means per-pipeline credentials scoped to the specific artifacts a job produces, secrets partitioned so one leaked token unlocks one thing, and publish rights separated from build rights. It also means treating your dependencies as untrusted code running inside your trust boundary and limiting what that code can reach. Software Composition Analysis shows you exactly which third-party components — direct and transitive — are executing in your environment, so you can reason about what privileges that code inherits. Griffin AI helps prioritize which over-privileged, reachable paths actually matter, and dynamic testing validates that access controls hold against a running system rather than only on paper. See how these fit together on our comparison page, or browse the concepts library for related principles.
Least privilege is not a state you reach and forget. It is a property you maintain against constant drift — every new role, integration, and pipeline pushes toward more access, and the discipline is pushing back.
Create a free account to see what your dependencies can reach, or read the documentation.
Frequently Asked Questions
What is the difference between least privilege and zero trust?
Least privilege is a principle about how much access to grant — always the minimum. Zero trust is a broader architecture that assumes no implicit trust based on network location and verifies every request. Least privilege is one of the core building blocks zero trust relies on; you cannot do zero trust well without it, but least privilege applies even in traditional architectures.
Doesn't least privilege slow teams down?
It can add friction if implemented as manual approval gates for everything. Done well — with role-based defaults, self-service scoped requests, and just-in-time elevation — it adds little day-to-day cost while dramatically reducing breach impact. The friction of scoping access is small compared to the cost of an uncontained compromise.
How does least privilege apply to service accounts?
Exactly as it does to people, and it matters more because machine identities outnumber humans and are prime targets for lateral movement. Each service should hold credentials scoped only to the specific calls and data it needs, ideally short-lived, so a stolen service token unlocks one narrow function rather than the whole system.
How do I stop privilege creep?
Make access expire by default and require periodic re-justification rather than relying on someone to remember to revoke it. Combine short-lived and just-in-time grants with scheduled access reviews that compare every standing grant against a current, named need, and remove anything that cannot justify itself.