Protection objective
Each user, service, process, and session should have only the authority needed for its current function. Limit authority by resource, action, context, and time. Remove or reduce it when the function changes or ends.
The principle
Least privilege limits the credible damage from error, stolen credentials, compromised software, and misuse. It applies to users, workloads, administration, policy changes, data, keys, and recovery systems. It is more precise than assigning a broad low-privilege role.
Derive narrow authority
Start from the required task. Name the resources and actions. Add conditions such as device state, network path, approval, or time when they reduce a real threat. Use temporary elevation for exceptional work. Review actual use and identity changes, then remove unused or obsolete access.
Failure and limits
The minimum necessary authority can change. Overly narrow access can block safe operation and drive shadow bypasses. Least privilege cannot prevent harmful use of an action that is legitimately allowed. Shared roles can hide which permission a task needs.
Pomerium boundary
Pomerium policies can limit protected routes by user, group, device, request facts, and external context. The upstream application must limit record and action permissions that Pomerium cannot represent. Operators must expire temporary policy and protect the policy administration path.
Evaluation checklist
- Is each grant tied to a current task, resource, and action?
- Can broad roles be replaced by narrower permissions or time-bound elevation?
- Does access change after joiner, mover, and leaver events?
- Can a legitimate allowed action still cause unacceptable harm?
- Is emergency authority attributable, expiring, and reviewed?
