Least Privilege
Least privilege grants identities only the permissions needed for a task, for only as long as needed, reducing the blast radius of mistakes and compromise.
Definition
Least privilege is the principle that every user, service, and process should have only the permissions required to perform its current task, and only for the duration required. Permissions are scoped by resource, action, and time. Broad roles, wildcard permissions, and long-lived credentials violate the principle even when they are convenient.
Context and scope
Least privilege applies to cloud IAM, database users, service accounts, API tokens, filesystem access, and administrative tooling. It is a core control for limiting lateral movement and accidental damage.
Common misconceptions
- Least privilege means never granting admin — it means granting admin only when justified, scoped, and time-bound
- A service account is safe because it is not a human — machine credentials are often broader and less monitored
- Removing permissions is risk-free — removing a permission can break an undocumented dependency, so test and observe
Anti-patterns
- Wildcard actions on all resources for application service accounts
- Shared credentials used by multiple services with different needs
- Long-lived access keys that are never rotated or reviewed
Related concepts
Related examples
Authoritative source
Scope by action and resource
A role that can read one bucket prefix is different from a role that can read every bucket. A database user that can select from two tables is different from one with ALL PRIVILEGES. Define permissions in terms of the exact actions and resources the service needs, and test that a denied action actually fails.
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": ["s3:GetObject"],
"Resource": "arn:aws:s3:::app-uploads/tenant-42/*"
}]
}The example is an AWS policy. The principle is portable: action, resource, and condition, not *:*.
Make grants time-bound
Standing access accumulates. Prefer short-lived credentials, just-in-time elevation, and approval workflows for privileged operations. A human admin should not need permanent production write access; a service should use workload identity rather than a static key. Every grant should have an owner, a reason, and an expiry or review date.
Verify and remove
Use audit logs to see which permissions are actually exercised. Remove unused roles and keys, narrow wildcards, and separate duties so one identity cannot both approve and execute a sensitive change. Removing access can break a system, so roll out changes with monitoring and a rollback path.
When to use it
Use least privilege for every identity that touches production data or infrastructure. The advantage is a smaller blast radius and clearer accountability; the drawback is more configuration and the risk of breaking hidden dependencies. Compared to broad roles, least privilege requires an inventory and a review process, but it limits the damage of a compromised credential.