Definition
The principle of least privilege is the security rule that every process, user account, and software component should operate with the minimum set of permissions required to perform its function — and nothing more. A web server that only needs to read static files should not have write access to the filesystem. A backup script that only needs to read user data should not run as root. A library function that only needs to parse text should not have network access. The smaller the privilege surface, the smaller the damage when something goes wrong.
The principle was articulated by Saltzer and Schroeder in 1975 as one of eight design principles for secure computer systems. Half a century later it is still the most violated and the most useful security rule in practice — most catastrophic breaches involve a component that had more power than its job demanded.
Why it matters
How it works
On Unix-like systems the principle is enforced through several mechanisms. Discretionary file permissions (rwx for user / group / other) limit which processes can read, write, or execute which files. Process ownership and the setuid bit control whose privileges a running program inherits. The sudo mechanism lets specific users execute specific commands with elevated privileges without giving them root permanently. Linux capabilities split the historical "root or not" binary into fine-grained powers (CAP_NET_BIND_SERVICE, CAP_SYS_ADMIN, and so on) that can be granted individually.
The practical workflow is to start with no privileges and add only the ones a task actually needs. A new daemon runs as its own dedicated unprivileged user. A container is launched with --read-only and --cap-drop=ALL. A cloud IAM role grants exactly the API actions the application calls. The principle works because each restriction is cheap to add at build time and expensive to recover from if absent at exploit time.