The principle of least privilege gives each person, service, or other requesting subject only the permissions needed for an authorized task. It limits the scope of access rather than treating every employee or resource alike, reducing the chance that sensitive information is exposed to someone with no legitimate need to use it. section 10.1.2 section 1.3.4
Replacing an all-employees permit
A policy that lets every employee view every document appears simple but can expose financial forecasts to interns. A least-privilege alternative limits viewing to documents in one project and requires the requester to be a member of that project. The permission is narrowed by both resource scope and membership. section 10.1.2
permit(
principal,
action == Action::"doc:view",
resource in Document::"alpha" // just project docs
)
when{
Project::"alpha".members.contains(principal) // only project members
};
This policy snippet restricts document viewing to Project Alpha and checks project membership, illustrating explicit least-privilege scope. section 10.1.2
Apply least privilege as a policy-design discipline:
- Start from the smallest group that needs access, then state the resource and conditions explicitly rather than granting a blanket permit to all employees. section 10.1.5
- Use fine-grained scope based on a project, role, or relationship so permissions align with the intended audience. section 10.5
- Prefer durable entities such as teams or projects over changing job titles when those entities better represent the continuing access need. section 10.1.5
- Keep policy rules separate from authoritative identity and relationship data; policies should reference attributes rather than embed frequently changing values. section 10.1.5
- Validate and test policies so the narrow scope still supports intended work and continues to enforce invariants such as project-member-only access. section 10.1.5
Least privilege is not merely a deny-by-default slogan. Effective authorization balances narrow permissions with business usability through appropriate granularity and grouping. Clear, consistent policies, durable access relationships, reviews, versioning, testing, analysis, and decision logging make the resulting access decisions understandable, adaptable, and auditable. section 10.1.6 section 10.4
The principle also supports compliance where access must be limited by work context or data-specific conditions. Examples include limiting patient-record access to a nurse’s assigned patients while on duty, restricting a financial analyst to reports rather than underlying raw data, and considering consent when personal information is requested. section 1.3.4
