Give everything only the keys its job needs

In 2013, attackers stole around 70 million customers’ card details from a major retailer. They did not break in through the payment system. They got in through the company’s air-conditioning contractor, whose login had access to far more of the network than a heating-and-cooling vendor could ever need. That gap between what an account could do and what it needed to do is the whole subject of this post. The principle that closes it is called least privilege, and it is one of the highest-value security ideas a beginner can hold, because it is less about clever defence and more about a habit.

Only the keys the job needs

Least privilege means every identity gets the minimum access required to do its job, and nothing more. “Identity” is broad on purpose: a human user, a background service, an API token, a database login, your app’s own code, an AI agent. Each should be able to reach exactly what its task requires, and be locked out of everything else.

The everyday picture is a hotel key card. Yours opens your room and the gym, and that is it. It does not open every other room, the manager’s office, or the safe. If you lose it, whoever finds it gets into your room, which is bad, but they do not get the whole building. The card was scoped to your stay. That is least privilege.

Why it is really about the day something leaks

Here is the reframe that makes it click. You do not apply least privilege because you expect an account to misbehave today. You apply it because credentials leak, and when one does, the access you granted becomes the access the attacker has. The question least privilege answers ahead of time is: when this leaks, how much can it reach? That reach has a name, the blast radius.

flowchart TD
  L[One leaked credential] --> B{How far can it reach?}
  B -->|broad access| Big[Database, secrets, other users, production: the whole building]
  B -->|least privilege| Small[Only its one job: a single room]

The air-conditioning vendor is the classic example: a credential that should have reached a vendor portal instead reached the network where card data lived. Over-permissioned accounts turn a small leak into a large breach, and tightly scoped ones keep the same leak boring. You cannot prevent every leak, but you decide the blast radius in advance.

It is not just people: tokens, services, and your code

Beginners think of this as a user-account thing, but the biggest wins are on the non-human identities that quietly run everything.

• API tokens should be scoped to specific actions and, where possible, short-lived. A token that can read one thing for one hour is a far smaller prize than a permanent key that can do anything.
• Service accounts (the logins your background jobs use) should have their own narrow permissions, not a shared admin login.
• Your database user should be allowed exactly the tables and operations the app uses.
• An AI agent gets only the tools its task needs, which is the same rule from giving a model hands: an agent you would not trust with the whole system should not hold the keys to it.

-- too much: this login can do anything to everything
GRANT ALL ON ALL TABLES TO app_user;

-- least privilege: exactly the tables and actions this app needs
GRANT SELECT, INSERT ON orders TO app_user;
GRANT SELECT ON products TO app_user;

Deny by default, then grant narrowly

The way you actually build this is a default and a direction. Deny by default: nothing is allowed unless something explicitly grants it, the same rule from the security baseline. Then grant narrow, specific permissions on top, scoped to real job functions rather than handing out broad admin.

A useful pattern for the rare case someone truly needs more is just-in-time access: grant the elevated permission temporarily, for the task, and let it expire, instead of leaving a standing admin right switched on forever. The access exists when the work does, and not a moment longer.

The quiet way access creeps wide

Here is the maintenance catch, and it is the reason least privilege is a habit and not a one-time setup. Access only ever gets added. Someone needs a permission for a project, gets it, the project ends, and the permission stays. Do this for two years across a team and everyone can reach almost everything, which is exactly the state least privilege was meant to prevent. This slow widening is called privilege creep.

The tools you actually reach for

You rarely need special software. Least privilege lives in the access controls of the tools you already use.

Assume it leaks, and decide how far it reaches

The lesson is that least privilege is not paranoia, it is planning for a certainty. Credentials will leak, tokens will be stolen, an account will be phished, and the only thing you control in advance is how much any single one of them can touch. Give every user, service, token, and agent only the keys its job needs, deny everything else by default, and prune access as jobs change. Do that, and a leak stays a leak instead of becoming the headline. Skip it, and your air-conditioning vendor becomes someone’s way into 70 million card records.

Scope the keys now, so a leak later stays small.

Sources

• Delinea: principle of least privilege examples for the definition, blast radius, and the Target HVAC-vendor breach
• Palo Alto Networks: what is the principle of least privilege for reducing attack surface and limiting lateral movement
• Security Boulevard: designing least privilege access using IAM and RBAC (2026) for scoped tokens, short-lived credentials, and roles around job functions
• Microsoft Learn: increase application security with the principle of least privilege for deny by default and scoping application permissions