What is least privilege?

Least privilege is the security principle that any identity, whether a human user, a machine role, or a service account, should hold only the permissions required to complete its current task, and nothing beyond that. It is the foundational idea behind most modern cloud access control frameworks.

Why is it so hard to get right in practice?

The core problem is uncertainty. When an engineer sets up a new role or grants access to a new service, the correct permission scope is often not obvious. Choosing too narrow a set means getting blocked mid-task and spending time debugging obscure access denied errors. Choosing too broad a set means unblocking yourself immediately.

IAM policies in AWS compound this. The permission space is enormous. A single service can have dozens of distinct actions, and understanding which subset a given task actually requires takes time most teams do not spend. The path of least resistance is s3:* or iam:*, and once those permissions are in place, nobody comes back to tighten them. Studies consistently find that more than 99% of cloud identities use only a fraction of the permissions they hold.

What does least privilege actually scope?

Least privilege applies to three dimensions simultaneously: which actions an identity can take, which resources those actions can target, and under what conditions they apply. Most policy discussions focus only on actions. A policy that restricts to lambda:UpdateFunctionCode is better than lambda:*, but it is still over-permissioned if it applies to all Lambda functions instead of the specific one a pipeline owns.

Conditions matter too. An action allowed only from a specific IP range, or only when a specific tag is present, is meaningfully narrower than the same action allowed unconditionally.

How does it differ from zero standing privileges?

Least privilege is about scope. Zero standing privileges is about duration. An identity can be least-privilege in scope and still hold those permissions permanently, twenty-four hours a day, whether or not any task is running. Zero standing privileges says access should not exist until it is needed, and should disappear when the task ends.

Both principles aim at reducing what an attacker can do with a compromised credential. They are complementary, not redundant. Least privilege limits the blast radius. Zero standing privileges shrinks the window of exposure.

Can guardrails on actions compensate for imperfect permissions?

Yes, and often more reliably. Getting every IAM policy scoped perfectly across a growing organization is a coordination problem that rarely stays solved. A guardrail layer that inspects API calls in real time and blocks anything outside a defined envelope can catch the cases that policy review misses.

This is not an argument against trying to scope permissions correctly. It is an acknowledgment that enforcement at the control plane, where the action actually happens, is a different kind of protection than static policy review. Both belong in a mature access control strategy.

Korvalis combines automated permission analysis with real-time guardrails so teams can narrow scope over time without losing the ability to work, and block dangerous actions even when a policy is temporarily broader than ideal.