The Principle of Least Privilege

Least privilege is simple to state and surprisingly hard to practice: every component should have exactly the access it needs to do its job, and nothing more. The principle is decades old, but the reason it keeps mattering is that the cost of getting it wrong is paid at the worst possible moment — after something has already been compromised.

Why it pays off after the breach

You cannot prevent every breach. Credentials leak, dependencies have vulnerabilities, and people make mistakes. Least privilege accepts this and asks a different question: when an attacker does get a foothold, how far can they go?

A tightly scoped credential turns a total compromise into a contained one. That containment is the entire point — it is the difference between rotating one key and rebuilding an environment.

What it looks like in practice

Scope grants to specific actions and specific resources, not broad wildcards:

const policy = {
  actions: ["s3:GetObject"],
  resource: "arn:aws:s3:::my-bucket/public/*",
};

Notice what this policy does not allow: it cannot write, cannot delete, and cannot touch anything outside public/. If the service holding it is compromised, the blast radius is one prefix of one bucket.

Habits worth building

• Prefer short-lived, automatically rotated tokens over long-lived static keys
• Grant to roles and workloads, not to individual humans sharing credentials
• Audit grants on a schedule and revoke anything unused — permissions accrete silently
• Start from zero and add access as features need it, rather than starting broad and trimming

The goal is a system where a breached component can do almost nothing, and where "almost nothing" is something you designed on purpose.