Least privilege in practice

The principle, and why stating it isn’t enough

The principle of least privilege says every subject — a user, a service, a process — should hold exactly the permissions it needs to do its job, and not one more. NIST calls it out as a foundation of access control; the OWASP Authorization Cheat Sheet opens with “enforce least privileges” and “deny by default.” Every engineer nods along. Almost no production system actually has it.

The reason is that least privilege is not a property you configure once — it’s a property you have to maintain against constant pressure. Permissions are sticky in one direction. Granting is easy: someone is blocked, you add an allow, the ticket closes, everyone is happy today. Revoking is hard: nobody is blocked by a permission you still have, so there is no pull to remove it, no failing test, no paged alert. The system that grants on demand and never revokes doesn’t drift toward least privilege — it drifts away from it, monotonically. That asymmetry is the whole problem, and it has a name.

Privilege creep: the slow leak

Privilege creep is the gradual accumulation of permissions a subject no longer needs. It comes from a handful of utterly mundane sources, none of which feels like a security decision at the time:

• The role change that adds without subtracting. An engineer moves from the payments team to platform. They get the platform group’s access on day one. The payments access? It’s still there a year later — nobody owns the subtraction, and revoking it might break something, so it stays.
• The expedient wildcard. A deny blocks a release at 4pm. The fix that ships is s3:* / Resource: *, because narrowing it to the three actions and one bucket actually needed takes twenty minutes you don’t have. The wildcard is permanent; the deadline was temporary.
• The standing admin. Break-glass access for a 2am incident is never revoked the next morning. Now it’s just “the access I have,” and three months later it’s load-bearing for some routine task it was never meant for.
• The copied role. New service needs permissions? Clone the role from the service next to it. Now it inherits every grant that service accreted, including the ones nobody can explain.

Each step is locally rational and globally corrosive. The endpoint is a fleet of identities that each hold far more power than their actual job requires — which means the blast radius of any single compromised credential is enormous, and totally invisible until the day it’s exploited.

Deny by default: making “no” the starting point

The structural fix for creep starts at the foundation: deny by default. Authorization begins from a refusal, and access is granted only by an explicit, positive rule that matches the subject, the action, and the resource. Anything not explicitly allowed is denied — including, critically, anything new.

This sounds obvious until you contrast it with the failure mode it prevents. An allow-by-default system (or any allowlist with a wildcard fallback) fails open: add a new endpoint, a new resource type, a new admin action, and it’s reachable unless someone remembered to write a deny rule for it. Deny by default fails closed: the new thing is unreachable until someone writes the allow. The difference is whether a forgotten rule leaks access or merely produces a 403 that someone files a ticket about. Fail-closed turns your omissions into inconveniences instead of breaches.

In practice this means: no Resource: "*" and no action: * in policies you can avoid them in; permissions scoped to specific actions on specific resources; and the default answer to “can this identity do this thing” is no unless a rule says yes. The cost is real — you write more, narrower rules, and you eat more 403s during development. That cost is the point. It’s the friction that keeps the wildcard out.

Just-in-time access: grants that expire on their own

The asymmetry that drives creep is “easy to grant, hard to revoke.” Just-in-time (JIT) access attacks it directly by making revocation automatic: instead of holding a standing permission forever, a subject requests elevated access for a specific task, gets it for a bounded window, and the system takes it back when the window closes — no human has to remember.

The pattern shows up at every layer:

• Human admins: standing administrator membership is removed; an engineer requests elevation (often with a reason and an approval) and gets it for, say, 60 minutes, after which the role membership is automatically stripped. The default state of every human is not privileged.
• Services: instead of a long-lived API key with broad scope baked into the deployment, the workload assumes a role and receives short-lived credentials (minutes to an hour) that auto-rotate and auto-expire. A leaked credential is only useful inside its tiny window.
• Break-glass: emergency access is itself a JIT grant — explicitly requested, time-boxed, loudly logged, and auto-revoked — so the 2am incident doesn’t leave a permanent admin grant behind.

JIT flips the steady state. With standing access, the default is “everyone has more than they need, all the time,” and you spend effort removing excess you’ll never fully catch. With JIT, the default is “nobody has anything until they ask,” and privilege exists only for the minutes it’s actually in use. You’re no longer fighting creep with cleanup — you’ve removed the surface creep accumulates on.

How seniors hold the line

Holding least privilege is an operational loop, not a one-time config. The senior moves: make deny the default so new surface fails closed; make grants narrow (specific actions on specific resources, no reflexive wildcards) and short-lived (JIT with hard expiry) so privilege exists only while it’s used; and close the loop with revocation — when someone changes teams, when a project ends, when break-glass fires, the subtraction must be owned, not left to a quarterly audit that errs toward keeping. The grant that has no expiry and no owner is the one that becomes next year’s s3:* incident.