Principle of Least Privilege

What is the principle of least privilege?

The principle of least privilege (PoLP) states that every user, service, process, or account should be granted only the minimum access necessary to perform its function — and no more. If a service only needs to read one S3 bucket, it gets read access to that bucket, not full S3 access, and certainly not admin. It’s the single most fundamental and widely-cited principle in security, because it directly limits the blast radius of any compromise: when (not if) an account is breached, least privilege ensures the attacker inherits only that account’s narrow permissions rather than a skeleton key to everything.

Why it matters so much — blast radius

The value of least privilege is entirely about containing damage. Security failures are inevitable — credentials leak, services get compromised, insiders go rogue, SSRF or injection bugs let attackers act as your services. When that happens, the question that determines whether it’s a minor incident or a catastrophe is: what could the compromised identity actually do? If everything runs with broad, admin-level permissions (the convenient default many teams fall into), a single compromise means total compromise — the attacker can read all data, delete backups, create new credentials, and pivot everywhere. If least privilege is enforced, the same compromise is contained: a breached service that could only read one bucket can only… read one bucket. This is why least privilege underpins nearly every security framework and is the foundation of zero-trust (“never trust, always verify, grant minimal access”). It applies everywhere: IAM roles and policies (scope to specific actions and resources), database accounts (an app’s DB user shouldn’t be able to drop tables), API scopes (tokens granting only needed operations), OS permissions (don’t run as root), cross-account roles, and human access. It’s closely related to — and enforced through — mechanisms like RBAC and ABAC, permission boundaries, and SCPs.

Why it’s hard, and how it actually goes wrong

Least privilege is easy to state and genuinely hard to maintain, which is why violations are everywhere. The core tension is convenience vs security: granting broad permissions “just to make it work” is fast and never breaks anything, while scoping tightly requires figuring out exactly what’s needed, risks breaking things when you get it wrong, and demands ongoing maintenance as needs change. So teams over-grant, and the over-grants accumulate. The specific failure patterns: wildcard permissions (Action: "*", Resource: "*" — the “just give it admin” shortcut that defeats the principle entirely); permission creep / privilege accumulation (identities gather permissions over time for various tasks and never lose them, so a long-lived account or a veteran employee accrues far more access than any current need justifies); standing privileges (always-on admin access that’s rarely used but permanently exploitable — mitigated by just-in-time access, granting elevated permissions only temporarily when needed, e.g., via PIM); and unused permissions (granted but never exercised, pure risk with no benefit — tools like AWS IAM Access Analyzer identify these). The right practice is to start from zero and add only what’s proven necessary (default-deny, grant on demonstrated need), regularly review and prune access (access reviews, removing unused permissions), prefer temporary/just-in-time elevation over standing privileges, and scope to specific actions and specific resources. The recurring mistakes are all failures of this discipline: reaching for wildcards/admin for convenience, never revoking permissions as roles change (accumulation), leaving broad standing access that’s rarely used, and never auditing what’s actually being used versus granted.

What people get wrong

• Wildcards for convenience — * permissions or blanket admin “to make it work” throw away the principle entirely, turning any single compromise into total compromise.
• Permission creep: identities accumulate access over time and rarely lose it, so accounts drift far beyond current need — regular reviews and pruning are what keep least privilege real.
• Standing privileges over just-in-time — always-on elevated access is permanently exploitable even when rarely used; grant elevation temporarily, on demonstrated need, and revoke it.

Primary source: NIST / CISA on least privilege