Least Privilege

Give each user, process, or component only the access it needs to do its job, and no more. Privileges should be the minimum required, granted for the shortest time, and scoped as narrowly as possible, so that if a component is compromised or misbehaves, the damage it can do is bounded.

Why it Matters

Excess privilege turns a small compromise into a large one: a breached component with broad access becomes a path to everything. Least privilege bounds the blast radius by construction, so a failure or attack is limited to what that one component could touch, which is often the difference between an incident and a catastrophe.

Signals

• Components run with scoped, minimal permissions rather than broad or administrative ones.
• Access is granted per need and revoked when no longer required.
• A compromise of one part does not hand over the rest.

Benefits

Contained blast radius, a smaller attack surface, easier reasoning about what each part can affect, and failures that stay local instead of cascading through inherited access.

Risks

Over-broad grants for convenience ("just give it admin"); privileges that accumulate and are never revoked; scoping so tight it breaks legitimate work, which pressures teams to widen access again.

Tensions

Tighter privilege is safer but adds friction and administrative overhead, while broad access is convenient until it is catastrophic. The balance is the least access that still lets the work happen, revisited as roles change.

Examples

A service that can read one bucket rather than the whole store; a deployment credential scoped to a single environment, so leaking it does not expose production.