Least Privilege
When an account is compromised, what decides how much of your system goes with it?
The idea
Give each user and system only the access needed for its task.
In the real world
A reporting account can read sales but cannot issue refunds.
Going deeper
Permissions are usually granted at the moment of setting something up, when the goal is making it work and the cost of over-granting is invisible. They are then almost never revisited, so access accumulates across years while the reasons for it disappear.
The reframe that makes this concrete is to stop asking whether an account will be misused and start asking what happens when it is. A reporting script that only ever read data, but held write access for convenience, has the exposure of the write access. Its restraint was a property of the code, and the code is not what an attacker will run.
Where it stops applying
Taken too far this produces permission sprawl that people route around, usually by sharing a powerful account. Access that is genuinely hard to request tends to get borrowed, which is worse than a slightly generous grant.
Why it matters
It changes the question from whether an account will ever be misused to how much damage it can do when one is.
Try this today
Remove one unnecessary permission from a tool you use.
Test yourself
A reporting script's credentials leak. The script only ever ran SELECT queries, but its account was granted full write access for convenience. What is the actual exposure?
Show the answer
Everything that account could do, not everything it did. Permissions define the blast radius; the script's restraint is irrelevant once someone else holds the key.
Learn this in the feed Answering from memory, then again days later, is what makes it stick.