Journal · The AI Architect · 2026-08-23
Lend the smallest key that does the job. Narrow access means small damage if anything ever slips.
Lend the smallest key that does the job. Narrow access means small damage if anything ever slips.
The tension isn’t really about trust versus paranoia. It’s about time. Every access request arrives wearing a deadline, and the person asking is almost never the person who’ll clean up if the permission turns out to be too broad. So the easy move, the one that keeps projects moving, is to grant more than necessary and figure out the boundaries later. Later rarely comes. The access just sits there, wide open, waiting for the day something goes wrong.
Ask what the task actually touches
Most over-permissioning happens because we grant access to a system when the task only needs access to a slice of it. Someone needs to update a spreadsheet, so they get edit rights to the whole drive. A contractor needs to test one feature, so they get admin on the whole environment. The gap between what’s needed and what’s granted is where damage grows.
The fix is a habit, not a policy document: before you grant anything, name the specific action the person or process needs to perform, and grant only that. Not “access to the customer database” but “read access to the fields required for this report.” Not “deploy permissions” but “permission to deploy this one service.” It takes an extra minute to think it through. That minute is cheap insurance.
Try this: the next time you’re about to share a login, add a collaborator, or approve an API key, write down the single sentence describing the task first. If the access you’re about to grant is bigger than that sentence, shrink it before you hand it over.
Assume the key will be used wrong someday
Not because anyone involved is careless, but because systems drift, credentials get phished, laptops get stolen, and well-meaning people click things they shouldn’t. Once you accept that some key, somewhere, will eventually be used by someone other than the person you gave it to, the whole calculus changes. The question isn’t “do I trust this person” — you probably do. The question is “what happens on the day that trust doesn’t matter anymore, because the key is in someone else’s hands.”
This is where the smallest key really earns its keep. A narrow key that leaks costs you an afternoon. A broad key that leaks can cost you the business. The scope of the key determines the size of the story you’ll be telling afterward, and that story is usually written long before the actual failure — it’s written the day the key was issued.
Try this: for any access you currently have, or currently grant to others, imagine it’s compromised tomorrow. Write one line describing the worst realistic outcome. If that line makes you wince, the key is too big, and you don’t need to wait for an incident to fix it.
Revisit access on a schedule, not a whim
Small keys solve the moment of granting access. They don’t solve the slower problem, which is that access tends to outlive its purpose. The contractor’s project ends but the login stays active. The intern’s temporary edit rights become permanent because nobody remembered to remove them. Old permissions accumulate quietly, and each one is a door nobody’s watching.
The solution isn’t vigilance — vigilance fades — it’s a rhythm. Pick a cadence, monthly or quarterly, and actually look at what access exists and whether it’s still needed. This is unglamorous work. It won’t feel urgent, right up until the day it was the whole point.
Try this: put a recurring note on your calendar, once a season, that simply says “review who has keys to what.” When it comes up, go through your systems — shared drives, admin panels, API tokens — and revoke anything that no longer maps to an active need. If you can’t remember why someone has access, that’s usually your answer.
Narrow access is a discipline more than a rule, and disciplines only hold if they’re practiced somewhere ordinary, not just in the moments when the stakes feel high. The book goes further into how this plays out in real systems — where the smallest key gets chosen under pressure, and what it looks like when teams build the habit into how they work rather than treating it as a one-time cleanup. This piece is just the doorway into that conversation.
Go deeper. The full method is in The AI Architect. New here? Start with the free companion pack, or explore the series.