Okay real talk — you know that moment in every office when someone says "can you just give me admin access, it'll be faster"?
Yeah. That's the Iron Throne conversation. Every single time.
"Everyone who wants to sit on the Iron Throne, wants to sit on it because it's what they think they need. Nobody sits on it because they should."
Here's the thing nobody says out loud: the person asking for full access almost never actually needs full access. They need one permission, for one task, right now. But "give me admin" is faster to ask for than "give me exactly what I need," so that's what gets asked. And granting it is faster than saying no. So it gets granted.
And then six months later, nobody remembers who has access to what, or why — everyone's just... sitting on thrones they never should've had.
This isn't an AWS thing, or a security-team thing, or even really a tech thing. It's a people thing. Least privilege isn't a compliance checkbox — it's just... not handing out kingdoms because someone asked nicely.
Why "just this once" never stays "just this once"
You've seen this play out before, even if you never called it the Iron Throne. Someone needs to fix one thing urgently, so they get temporary access. The fix works. Nobody remembers to take the access back. Three months later that "temporary" grant is just... permanent, invisible, and nobody's job to notice.
It's not laziness, exactly. It's that revoking access requires someone to actively decide "you don't need this anymore," and that decision has a social cost that granting access never had. Saying yes is free. Saying "actually, give that back" feels like an accusation.
"The King eats last." — except in most orgs, the person who granted the access eats first, and everyone downstream inherits the mess.
The part that actually costs you later
Every access grant is a tiny bit of trust you can't easily take back. Nobody wants to be "that person" who revokes access — it feels petty, like you're accusing someone of something. So it just... stays. Forever. Until an audit, or worse, an incident, forces the question nobody wanted to ask: wait, why does the intern have prod access?
"Power resides where men believe it resides." — and access resides wherever nobody bothered to clean it up.
This is the part that never makes it into onboarding docs. Nobody sits you down on day one and says "hey, by the way, every permission you're granted outlives its usefulness unless someone actively kills it." So permissions just accumulate, quietly, like sediment. And the org chart of "who can technically do what" ends up looking nothing like the org chart of "who's actually supposed to be doing what."
So what actually works?
Not some grand security overhaul. Not a 40-page access policy nobody reads. Just one habit, repeated constantly: ask "what's the smallest thing that solves this?" before "what's the easiest thing to grant?"
That's it. That's the whole philosophy. It's less exciting than a security framework, and it works better than most of them, because it doesn't rely on anyone remembering to clean up later. It just... never lets the mess start.
The uncomfortable truth is that most of us have been on both sides of this. You've asked for more access than you needed because asking twice felt annoying. You've granted more than someone needed because saying "let me scope this properly" felt like friction nobody had time for. Neither of those decisions feels dangerous in the moment. They only feel dangerous in hindsight, usually during an incident review, usually at a time nobody wanted to be having that conversation.
So — be honest. Have you ever been handed the Iron Throne of some system just because it was easier than figuring out what you actually needed? Or worse, have you been the one handing it out?
#softwareengineering #devops #careeradvice #techculture
Top comments (0)