What is least privilege? (and why it's hard at small scale)
The principle of least privilege means every user, service, and process gets only the access it needs to do its job, and nothing more. The point is to shrink the blast radius: if an identity is stolen, misused, or makes a mistake, least privilege limits how much damage it can do. It’s one of the oldest ideas in security, and one of the least consistently followed, because doing it properly is genuinely hard.
Why least privilege is hard to implement
The idea is simple; making it real is a grind. Working out the exact permissions a service needs means watching what it actually does, and that changes every time the code changes. Cloud IAM is famously fiddly, and a broad grant that just works is always easier than a precise one you have to maintain.
So people reach for wildcards. Under a deadline, s3:* ships and a tightly-scoped policy waits for a quiet week that never comes. This is how you end up with an account where, as Palo Alto Networks’ Unit 42 has reported, around 99% of cloud identities are over-permissioned. Least privilege loses to whatever is faster, one reasonable shortcut at a time.
Least privilege vs zero standing privileges
Least privilege limits how much access an identity has; zero standing privileges limits how long it has it. Least privilege gives an identity only the permissions it needs. Zero standing privileges says it shouldn’t hold those permissions at all until a task requires them.
They work together. You can scope a key tightly and still leave it sitting around forever, which least privilege allows and zero standing privileges removes. One shrinks the grant, the other shrinks its lifespan.
What small teams can actually do
Chasing perfect least privilege across a whole account will burn a small team out and still leave gaps. A more honest approach is to spend the effort where the damage would be worst, and accept “good enough” elsewhere.
Cut standing admin first. Prefer read-only, since most people need to look far more often than they need to change. Grant write and delete access per task, expiring on its own, rather than as a permanent role. And accept that you won’t reach perfect permissions, which is exactly why the next part matters.
Guardrails on actions, not just permissions
Here’s the shift that helps a small team more than chasing perfect IAM: put guardrails on the destructive actions themselves. Least privilege tries to make sure the wrong action is never possible. That’s worth doing, but it will always be incomplete, because the person who deletes production usually had the permission to do it. Watching what a session actually does catches the destructive action even when the permissions were, technically, allowed.
That’s what Korvalis adds. It hands out access that expires on its own, which does the practical part of least privilege for you, and it watches live sessions and cuts off a destructive one before the command finishes, whether it comes from an engineer, a stolen key, a contractor, or an AI agent. It installs inside your own cloud account, with no proxy to route around.
Frequently asked questions
What is the principle of least privilege? Every identity gets only the access it needs and no more, to limit the damage if it’s misused, stolen, or mistaken.
Why is it hard? Working out exact permissions is tedious and constantly changing, over-scoped access is easier than precise access, and teams under pressure reach for wildcards.
How is it different from zero standing privileges? Least privilege limits how much access an identity has. Zero standing privileges limits how long it has it.
If perfect permissions feel out of reach, see how Korvalis guards the actions instead or join the waitlist.