Least Privilege

What is least privilege?

Least privilege says every identity — human, service, agent — should hold exactly the permissions its task requires, no more, and ideally only while it requires them. It’s the principle that turns a compromised credential from a catastrophe into an incident: the blast radius of stolen access is whatever that access could touch, and least privilege is blast-radius engineering.

Why everyone endorses it and few achieve it

Privilege accumulates through rational local decisions: the deadline demands AdministratorAccess “temporarily”; the wildcard s3:* makes the error go away; the role copied from another team carried its history along. Each grant is defensible; the sum is an account where dozens of identities can delete everything. The empirical signature shows up in access analysis everywhere: most granted permissions are never used. That gap — granted minus used — is pure risk, purchased for convenience.

Making it real rather than aspirational

The practices that survive contact with deadlines: start from generated policies, not from scratch (IAM Access Analyzer builds policies from actual CloudTrail usage — retrofit least privilege from evidence); time-bound elevation instead of standing admin (just-in-time access, approval-gated, auto-expiring); permission boundaries and SCPs as ceilings so even over-granted roles hit guardrails; and scheduled pruning of unused permissions as routine hygiene, not a post-breach project. For AI systems the principle is newly urgent: an LLM agent’s tool credentials define what a prompt injection can steal — least privilege is the primary containment.

What people get wrong

• Treating it as a one-time setup — privilege drifts; only continuous review holds the line.
• Applying it to humans but not workloads: service accounts and CI roles are where the god-mode credentials actually live.
• All-or-nothing thinking — cutting the unused 80% of permissions is achievable this quarter; perfection is not the bar.

Primary source: NIST SP 800-53 — AC-6, Least Privilege

Why Least Privilege Erodes Over Time

Even organizations that start with carefully scoped, minimal permissions tend to see privilege creep accumulate over time — an engineer temporarily granted broader access to debug an incident who never has that access revoked afterward, a role whose permissions were widened to unblock a deadline and never narrowed back down, or a service account granted broad access because scoping it precisely would have taken more time than the task allowed. This is why least privilege is treated as an ongoing operational discipline requiring periodic access reviews and automated tooling to detect unused permissions, rather than a one-time configuration exercise — the principle is easy to state and genuinely difficult to sustain without deliberate, recurring effort against the natural tendency for permissions to expand and rarely contract.