Principle of Least Privilege
Every user, process, and component should have only the access strictly necessary for its task, and no more.
The Minimum Necessary
The principle of least privilege holds that any entity, a person, a program, a service account, should be granted only the permissions its legitimate function requires, for only as long as it needs them. Excess privilege is latent risk: it is access an attacker can inherit by compromising that entity, and it is a mistake waiting to happen. Least privilege shrinks the blast radius of every compromise.
Where It Applies
- Users: access scoped to job function, not convenience
- Service accounts: narrow permissions for a specific automated task
- Processes: run with the least authority needed, not as administrator
- Network: reach only the systems a role must contact
- Time: elevated access granted just in time and then revoked
Why Excess Privilege Persists
Privileges tend to accumulate: people change roles but keep old access, temporary grants are never revoked, and it is easier to over-provision than to determine the exact minimum. This privilege creep steadily enlarges the attack surface. Countering it requires periodic access reviews and automated expiry rather than standing grants.
Just-in-Time Access
A strong pattern grants elevated privileges only for the moment they are needed, through a request-and-approve flow, then withdraws them automatically. Standing administrative access, always on, always a target, is replaced by ephemeral access that exists only during the task.
Fusion Context
Least privilege runs throughout the Hyperion breeder and burner security designs: command authority over safety-relevant systems is narrowly held, service accounts are scoped to single functions, and elevated access is time-bounded. This principle underlies role-based access control, network segmentation, and the separation of command authority from audit authority, so that no single compromised entity inherits broad control.