Andrews DeanEvery access-control instinct I've ever been taught points the same direction: lock it down as narrowly as you possibly can. Give people the least they need and call that safe.
On one table inside a rewards-and-recognition tool I built, I did the opposite. A manager's database session can read another team's entire roster, not just their own. I didn't miss this. I wrote it down as the decision, on purpose, before anyone could quietly "fix" it later.
Three roles, one recurring question
The tool has three roles that escalate in privilege: a manager scoped to their own team, a reviewer with org-wide read and decision rights, and an admin. And the same question kept resurfacing at every phase of the build: when a manager's session reaches into the employee table, should the database itself refuse to hand back anyone outside their team, or should that restriction live somewhere else, with the database staying open underneath?
The textbook answer arrives before you've even finished asking the question. Narrow the access. That's the first rule everyone learns, and it's a good rule, right up until the moment it isn't.
A later phase needed something a strictly team-scoped read couldn't support. A reviewer checking a nomination needed to ask "has this person already been nominated somewhere else in the company this cycle" — a genuinely org-wide question, asked from inside a role that also needed the narrower team view for everything else. A duplicate-nomination warning needed the same reach, to catch someone nominated twice under two different managers who'd never think to check with each other. Both features are real. Both needed a read that goes further than "my own team."
The decision that wasn't really about security
So here's what actually got written down, instead of left for whoever touched the policy next: read access to employees and teams stays open to every authenticated role. What restricts a manager to their own team is the write policy — they cannot submit, edit, or decide anything outside their assigned team, full stop — and decision-level data sits behind an entirely separate wall that managers never reach, in either direction.
I'll admit the part that took me longer to sit with. Narrowing the read scope later, once two features had quietly come to depend on the wider one, would have been far more disruptive than deciding the boundary correctly the first time. Picture it: eighteen months from now, someone runs a security review, sees a manager's session can technically read the whole roster, and "fixes" it back down to least privilege because that's what the checklist says good looks like. The duplicate-nomination warning stops catching duplicates. Nothing crashes. Nothing errors. It just quietly stops working, and nobody connects the two changes for months, because the fix that broke it looked like the responsible thing to do.
That's the trap hiding inside "least privilege, always." It sounds like a security decision. It's a scope decision wearing a security decision's clothes, and the two get confused constantly, because tightening scope almost always feels like the safe move, even in the one case where it quietly guts a feature nobody remembered to check.
What was actually locked down
None of this makes the tool loose. A manager cannot write a single row outside their own team — that boundary is enforced at the layer that would matter if someone tried to route around the interface entirely, not merely hidden behind a disabled button. Decision data, who reviewed what and why, sits behind its own wall that a manager never reaches, reading or writing. What changed wasn't how carefully the access was guarded. It was where the guarding actually needed to live.
Restrict it from what, exactly
I think this holds past database tables. Every decision that gets labelled "restrict it, to be safe" deserves one honest follow-up question before you comply: restrict it from what, specifically, and what does that restriction cost the feature nobody's built yet? A permissions model isn't one dial you turn toward "tight." It's several separate decisions, stacked: who reads, who writes, who decides. Treating all three as one knob is exactly how a well-intentioned tightening pass quietly breaks something true that nobody remembered was depending on the old, looser behaviour.
Let me say the part I actually believe, not the part that sounds responsible in a review meeting: the safest system isn't the one with the fewest open doors. It's the one where every door, open or shut, has a reason someone can still explain a year later.
So next time your instinct says "narrow this," ask it one more question before you agree. Narrow it from what, exactly, and who's quietly building on the wider version while you do it?