The permissions model nobody talks about: least privilege vs. least friction

May 20, 2026

Every platform team eventually hits the same wall: someone wants read access to something they don’t need, and saying no feels like being the department of no.

This isn’t a philosophy problem. It’s a mechanics problem.

The tension is real

Least privilege is the right principle. You know this. Your security team knows this. The compliance audit knows this.

But least privilege also means more clicks, more requests, more waiting. And every extra step is a tax on the people your platform is supposed to serve.

So you make a choice. Every day. And that choice is rarely documented anywhere.

What the frameworks miss

The textbooks talk about RBAC and ABAC like they’re the end of the story. In practice, they’re the starting point.

The real work is in the gaps between the model and the workflow. When someone needs access to a resource that doesn’t map cleanly to a role, or when the role exists but the request flow takes three days, or when you grant access and spend the next week figuring out whether it was too much.

These gaps are where the actual governance happens. Not in the policy document. In the decisions you make when the policy is silent.

What I’ve learned the hard way

The first permission model you design will be wrong. Not completely — the core structure will hold — but the edge cases will surprise you. The team that needed cross-account access for a one-off debug session. The service account that needed more permissions than anyone expected because of how it composed at runtime. The contractor who left six months ago and still has admin.

Design for iteration, not perfection. Make it easy to adjust permissions in small steps.

Audit trails matter more than the model itself. You can have the most elegant permission system in the world, but if no one can answer “who has access to what and when did it change” in under five minutes, it’s not working. The model is the engine. The audit log is the steering wheel.

Friction is a feature, not a bug. This is the counterintuitive part. Some amount of friction is the point. If granting access is as easy as clicking a button, you’ll get permission creep and nobody will notice until it’s a problem. The friction forces a moment of consideration: “Do I actually need this, or am I just being lazy?”

That moment of consideration is valuable. It’s the only time anyone stops to think about whether access makes sense.

The best permissions are the ones nobody notices. When your platform gives people exactly what they need by default and only asks for justification when the default doesn’t apply, the governance question stops being a conversation and starts being infrastructure. You’re not negotiating with each requester. You’ve encoded your judgment into the system.

This is hard to do well because defaults require you to have opinions. And having opinions means sometimes being wrong about what people need.

A practical heuristic

When someone asks for access, I ask three questions:

1. What exactly do they need to do? (Not what they think they need — what they’ll actually do.)
2. What’s the smallest thing that lets them do it?
3. What happens if we’re wrong and it’s too little?

The third question is the most important. If the answer is “they’ll come back and ask for more,” that’s fine. Incremental grants are cheap. Over-granting is expensive because it’s hard to undo — you have to audit what was exposed, assess the damage, and convince everyone it’s okay to take access away.

Start small. Expand only what’s needed. Document why.

The thing that surprised me

The hardest permissions to manage aren’t the ones for production systems or sensitive data. They’re the ones for internal tools, staging environments, and “just so I can look.”

Everyone agrees those should be restricted. Nobody enforces those. And when a real incident happens, it’s always the “just looking” access that was the vector.

Not because it was exploited maliciously. Because it was there, and it made the next attack possible.

Bottom line

Permission models are a continuous negotiation between safety and speed. There’s no correct answer — only answers that are honest about the trade-off and adjustable when circumstances change.

The teams that get this right don’t build better permission systems. They build better feedback loops. They know when their model is drifting. They can see the gap between intent and reality without waiting for an audit.

That’s the thing worth optimizing for: visibility into your own assumptions.