Principle of Least Privilege

Saltzer and Schroeder’s 1975 principle limits damage from accidents and errors and reduces unnecessary interactions among privileged programs. Reading a report does not inherently require modifying every record or administering all accounts.

The boundary concerns authority actually available, not intended code paths. A process able to delete all data is not equivalently constrained by a promise that its usual code only reads; faulty or hijacked execution may still exercise its authority.

References: [1]

An RBAC session can activate a subset of assigned roles, separating routine work from occasional administration. Narrower authority can therefore apply to a session instead of accumulating every role a person ever performs.

Delegated tokens can also be narrowed. RFC 9700 restricts access-token targets, resources and actions to the use case, rather than treating one approval as unlimited authority across services. Reading one resource need not imply modifying others.

References: [2] [3]

A completed task, personnel change or resource reclassification can make earlier authority unnecessary. Central role or attribute management helps only if assignments and cached information are maintained.

Least privilege therefore needs reliable enforcement and updates. It limits reachable damage without proving that inputs are correct, software is flawless or every policy is sound. The authority to grant, alter and revoke rights is itself part of the boundary.

References: [4]