Principle of Least Privilege (PoLP)
The concept that a user, program, or process should have only the bare minimum privileges necessary to perform its function.
Detailed Explanation
Following PoLP minimizes the 'blast radius' of a security breach. If a developer's account is compromised, but they only had access to one specific database, the attacker cannot access the rest of the system. This principle applies to human users, server service accounts, and cloud IAM policies.
Quick Summary
Grant every user, service, and process the minimum permissions it needs to do its job, nothing more. PoLP is the single most effective way to limit blast radius when, not if, something is compromised.
Key Takeaways
- Applies to humans (engineers' prod access), workloads (service accounts), and tokens (scoped API keys).
- Start from zero permissions and add; never start from admin and remove.
- Use just-in-time elevation for rare operations rather than permanent broad access.
- Service accounts should never share credentials with humans or each other.
- Pair PoLP with audit logging, knowing who had which permission when is critical for incident response.
When to use it
- Cloud IAM: write tight policies scoped to specific resources, actions, and conditions.
- CI/CD: deployment tokens that can push to one project, not the whole org.
- Database access: read-only replicas for analytics; write access only where strictly required.
- Mobile app keys: separate dev/staging/prod with disjoint permission sets.
Common Mistakes
- Wildcard permissions (`*:*`) "to unblock the team", they outlive the urgency by years.
- Long-lived credentials shared via Slack or env files; rotate to short-lived, scoped tokens instead.
- Granting prod access for one-time debugging without revoking it after.
- Treating PoLP as a one-time setup; permissions accumulate, so they need periodic review.
Principle of Least Privilege (PoLP), Frequently Asked
How do I balance least privilege with developer velocity?
Default to the minimum, but make elevation cheap and audited, break-glass workflows, JIT access tools (e.g. ConductorOne, AWS Identity Center temporary access). The friction should be on the elevation, not the day-to-day work.
Does PoLP apply to internal services?
Yes, especially. Internal service-to-service traffic is the path attackers use to move laterally after an initial foothold. Service A should only be able to call the specific endpoints of service B that it needs.