Every program and every privileged user of the system should operate using the least set of privileges necessary to complete the job. Saltzer and Schroeder stated this in 1975 as one of eight design principles for protection mechanisms in computer systems. It remains the foundation of the entire least/necessary taxonomy.
Least privilege considers individual permissions in isolation. A user needs read access to a file — grant read access, not read-write. A program needs to open a network socket — grant socket access, not root. The analysis is local: examine what one entity needs, grant exactly that, deny everything else.
This locality is both the principle’s strength and its limitation. It produces clean, auditable permission sets. But it does not account for what happens when permissions compose — when a user who can run a program that can access a resource effectively has authority over that resource through the program. That transitive dimension is where Miller’s Principle of Least Authority picks up the thread.
Least privilege is the first column of Allen’s 2x3 taxonomy: the restrictive pattern at the privilege scope. Its inside-out counterpart is Necessary Privilege, which asks not “what should we deny?” but “what does the user actually need to do their work?” The two patterns address the same design space from opposite directions — least privilege sets ceilings, necessary privilege sets floors.
The lineage runs: Least Privilege (1975, permissions) → Principle of Least Authority (2006, transitive authority) → Principle of Least Access (2023, data exposure). Each expansion widens scope without invalidating what came before.