What is least privilege access and how do you apply it?

Least privilege is the principle that every user, service or process gets only the access needed to do its assigned task, and no more. It limits the damage when an account is stolen or a mistake is made. Apply it first to administrators, service accounts and automation tokens.

What do the standards say?

NIST's glossary defines it as a security principle that a system should restrict the access privileges of users, or processes acting on their behalf, to the minimum necessary to accomplish assigned tasks. In NIST SP 800-53 Rev. 5 it appears as control AC-6, which asks organizations to employ the principle of least privilege, allowing only the authorized accesses that are necessary for assigned organizational tasks.

The supplemental guidance adds two points teams often miss. It applies to system processes as well as people, so processes should run at privilege levels no higher than needed. And it applies to development and operations, since organizations consider creating additional processes, roles and accounts as necessary to achieve it.

OWASP's authorization guidance says least privileges must be applied both horizontally and vertically: an accountant and a sales representative at the same level still need different resources.

Why does it matter?

Every privilege is attack surface. If a stolen account can read one project, the loss is one project. If it can read everything, the loss is everything. Least privilege does not prevent the theft. It limits the blast radius and makes the unusual access easier to spot.

What does it look like in practice?

A constructed example. A build pipeline uses a token that can write to every repository in the organization, because that was easiest to set up. A malicious dependency in one project reads the token from the build environment.

With organization-wide write, the attacker can alter any repository. With a token scoped to one repository and read-only except for the release branch, the same compromise stays inside one project. Nothing about the dependency changed. The token scope did.

Where do teams start?

Highest risk first.

1. Administrator accounts. Separate daily accounts from admin accounts, and grant admin rights just in time.
2. Service accounts and API keys. Give each a single purpose, an owner and an expiry.
3. CI and deployment tokens. Scope to one repository or one environment.
4. Cloud roles. Replace broad wildcards with the specific actions used.
5. Database access. Use separate read-only and write roles, and keep applications away from owner accounts.
6. AI agents and automation. Give them narrow tool permissions and no standing access to secrets.

How to check or apply this

1. List privileged accounts and tokens, with owners. Orphans are findings.
2. For each, record what it actually uses. Many platforms show last-used permissions.
3. Remove unused permissions in small steps and watch for breakage, so you can add back what was truly needed.
4. Replace standing admin rights with time-limited elevation and approval.
5. Define roles by job function and review membership on a schedule, quarterly for privileged roles.
6. Deny by default. OWASP advises that an application must always make a decision, and should be configured to deny access unless a rule permits it.
7. Alert on use of privileged accounts outside expected times.
8. Record exceptions with a reason and an end date.

What are the trade-offs?

Too tight and people cannot work. Teams then share credentials or request blanket access, which is worse. The remedy is a fast, simple path to get more access when it is justified, together with automatic expiry. Speed of granting is part of the control.

Least privilege also takes upkeep. Roles drift when jobs change, which is why the identity lifecycle and regular reviews matter as much as the first design.

Quick check

Sources

• NIST CSRC glossary: least privilege
• NIST SP 800-53 Rev. 5, AC-6 Least Privilege (CSF Tools reference)
• OWASP Cheat Sheet: Authorization

Last reviewed: 18 October 2026.