Principle of Least Privilege, Explained

Least privilege sounds obvious once you say it out loud: give an account, process, or user only the access it needs to do its job, nothing more. The gap between saying that and actually running your systems that way is where most breaches turn from a minor incident into a full domain compromise.

What it actually means

The principle of least privilege (PoLP) says every subject in a system — a user, a service account, an application, a container — should operate with the minimum set of permissions required to complete its function. Not the permissions that are convenient. Not the permissions someone granted three years ago and forgot to revoke. The minimum.

This applies at every layer: file system permissions, database roles, API scopes, cloud IAM policies, firewall rules, sudo access. A web server process reading static files doesn't need write access to /etc. A reporting script that only runs SELECT queries doesn't need a database role with DROP TABLE rights. A marketing intern doesn't need domain admin because it was easier than figuring out the right group.

Why it matters more than it sounds like it should

When an attacker compromises an account or a process, they inherit whatever that account can do. If a phished employee's laptop only has access to the file shares relevant to their team, the blast radius of that phish is contained. If that same account happens to have domain admin rights because IT set it up that way once for troubleshooting and never rolled it back, the attacker now owns the network.

This is the logic behind most post-breach forensic reports: initial access was low-value, but lateral movement through over-permissioned accounts turned it into ransomware across the whole environment. Excess privilege doesn't cause the initial compromise, but it's almost always what makes the compromise expensive.

Where it shows up in practice

Cloud IAM. AWS, Azure, and GCP all default to permissive behavior if you're not careful — an IAM policy with "Action": "*" and "Resource": "*" will pass validation and work fine, right up until a leaked access key hands an attacker full account control. Scope policies to specific actions and resource ARNs instead of reaching for wildcards.

Service accounts. These are frequently the worst offenders because nobody reviews them the way they review human accounts. A CI/CD pipeline that deploys to one S3 bucket shouldn't hold credentials that can read every bucket in the account.

Database roles. Separate read-only reporting roles from application roles that need INSERT/UPDATE, and separate those from the DBA role that can alter schema. PostgreSQL and MySQL both support granular GRANT statements — use them instead of handing every app connection the equivalent of root.

Sudo and local admin. Just-in-time elevation (request access, get it for a limited window, lose it automatically) beats standing admin rights every time. Tools like sudo with time-limited rules, or PAM solutions in enterprise environments, exist specifically for this.

The tension with