Journal · The AI Architect · 2026-07-28
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. Most of us hand out access believing the person on the other end is decent, competent, careful. That’s usually true. The problem is that access outlives the moment of trust. A contractor who needed your Wi-Fi password for one afternoon still has it a year later. An intern who needed admin rights for a single project still has them after they’ve moved teams. Trust was correct when granted. It just doesn’t expire on its own, and neither does the key.
So the real question isn’t “do I trust this person.” It’s “what happens if this credential is the one that leaks, gets phished, or gets left on a laptop at a coffee shop.” That’s a different question, and it’s the one worth sitting with before you hand anything over.
Ask what the key actually opens
Before granting access, it helps to picture the key sitting on a table, unattached to any person. What does it unlock? Not “what does this person need to do their job” but literally, mechanically, what does this credential give access to if it falls into the wrong hands.
This reframing matters because we tend to size keys to the relationship, not the task. A trusted colleague gets broad access because they’re trusted, not because the job requires it. That’s backwards. The size of the key should match the size of the job, and the relationship should be irrelevant to that calculation. Trusted people leave laptops on trains too.
Try this: the next time you’re about to share a password, add someone to a shared drive, or grant a permission, write down in one sentence what the specific task is. Then check whether the access you’re about to grant is bigger than that sentence. If someone needs to edit one document, don’t give them the whole folder. If someone needs to see this quarter’s numbers, don’t give them the full historical archive. The mismatch between the task and the access is usually where the risk lives.
Build in an expiration, not just a boundary
Narrow scope handles one dimension of the problem. Time handles the other. A key that’s perfectly scoped but never revisited slowly becomes a liability, because the world around it changes even when the key doesn’t. People change roles. Projects end. Vendors get acquired. The access was right when granted and wrong three months later, and nobody noticed because nothing about the key itself changed.
The fix isn’t clever, it’s just unglamorous: put a date on it. Not “forever until someone remembers to check” but an actual point where the access either gets renewed on purpose or quietly goes away.
Try this: whenever you grant access to something that matters, set a calendar reminder thirty, sixty, or ninety days out that just says “does this person still need this.” Not a big audit, not a formal process, just a nudge to ask the question once. Most of the time the answer will be yes, and you renew it in ten seconds. But the times it’s no are the times that would have otherwise turned into standing risk nobody was tracking.
Make revoking as easy as granting
Here’s the part people skip: narrow access only helps if you can actually take it back cleanly when something goes wrong. A lot of systems make granting access one click and revoking it a multi-step archaeology project, because nobody thought about the exit when they built the entrance.
This is worth checking before you need it, not after. If your instinct is “I’ll figure out how to remove access if it ever becomes a problem,” test that instinct now, while there’s no pressure. Open the settings. Find the button. See how many steps it takes and whether it actually does what you think it does.
Try this: pick one system you use often — a shared document, a team tool, a family account — and actually walk through removing someone’s access, even if nobody needs to be removed right now. If it’s confusing, slow, or unclear whether it worked, that’s useful information. It means the smallest-key idea has a gap on the back end, and it’s better to find that gap on a calm afternoon than during an actual incident.
None of this requires distrust or elaborate systems. It requires treating access as something with a shape and a lifespan, not just a yes or no. The book goes further into how this plays out with teams, tools, and the messier cases where the right scope isn’t obvious right away — but the habit itself starts small, with one key, one task, one honest sentence about what it’s really for.
Go deeper. The full method is in The AI Architect. New here? Start with the free companion pack, or explore the series.