Least privilege is the principle everyone agrees with and almost nobody implements well. The reason isn't ignorance — it's friction. When the secure path is slow and the insecure path is fast, people route around the controls. Someone gets a broad sudo grant "just to unblock the deploy," and three years later that grant is still there.
Good least-privilege design isn't about saying no. It's about making the right amount of access easy to get, easy to scope, and easy to take away.
Why static roles rot
The classic failure mode is permanent role assignment. An engineer joins the on-call rotation and gets production access. They rotate off — but the grant stays. Multiply that across years of joiners, movers and leavers and you get privilege creep: a fleet where everyone can reach everything and no one can explain why.
Access that never expires is access nobody remembers granting.
A model that holds up
We think about access as a relationship between three things: who (identity), where (which hosts or groups), and what (which actions). Keeping these dimensions explicit is what makes a policy auditable.
- Identity first. Every actor — human, machine or automated agent — is a verified identity, never a shared account. You can't scope access to "the deploy user" if ten people share it.
- Group hosts by purpose. Map roles to host groups (prod-db, staging-web) rather than individual machines, so policy survives infrastructure churn.
- Scope the action. Connecting is different from running privileged commands. Separate the two so read-only investigation doesn't require god-mode.
- Make grants temporary by default. Time-boxed access for the task at hand, expiring automatically when the window closes.
Just-in-time over standing access
The single highest-leverage change is to flip from standing access to just-in-time grants. Instead of permanently holding production privileges, an engineer requests access when they need it, for as long as they need it. When the window closes, the privilege evaporates — no cleanup ticket, no quarterly access review backlog.
This sounds like more friction, but in practice it's less. The request is a click, the approval is fast, and nobody has to remember to revoke anything. The system does it for them.
Break-glass, deliberately
Emergencies happen. A good model includes an explicit break-glass path: elevated access granted instantly, but loudly — logged, recorded, and flagged for review. Make the emergency path available but never silent.
Make the audit trivial
When access is identity-bound, time-boxed and scoped to host groups, your access review stops being archaeology. "Who can reach prod-db right now?" has a precise answer. "Who could last Tuesday at 2 p.m.?" does too. Pair that with full session recording and you can answer not just who could, but who did — and exactly what they ran.
The payoff
Least privilege that people actually use is the version where the secure path is also the convenient one. Verified identity, host-group scoping, action-level granularity and automatic expiry combine into a model that shrinks your attack surface without slowing anyone down.
Want to see Subnomic's RBAC in action? Book a demo or join the waitlist.