Least privilege people can actually work with

Least privilege gets debated as though the difficulty were deciding how little to grant. It is not. Almost everybody agrees, in the abstract, on roughly the right answer: people should hold what the job needs. The difficulty is privilege, specifically the part where the person needs something the design did not anticipate, at 4pm, with a customer waiting.

• A control that is right and slow will be circumvented by people who are neither careless nor malicious, and who will describe what they did openly if you ask.
• A control that is loose and fast will be praised for a year and then found by an auditor, at which point the correction is usually an over-tightening that starts the cycle again.
• The stable version is neither. It is a design that anticipates most needs, plus a fast, logged, expiring path for the rest.

That last line is the whole session. Everything else is how to build the fast path so that it closes behind itself.

• Friction budget - the working time a set of controls costs the people subject to them, per week. It is spent whether or not anybody has ever counted it, and it is finite.
• Shadow path - what somebody does instead when the sanctioned route costs more than the shortcut is worth. Not a policy violation in anybody's mind at the time.
• Break-glass - a deliberately powerful grant, available immediately, for a situation nobody could predict. It is a legitimate mechanism and its whole value is in the closing.
• Just-in-time elevation - access granted for a stated reason and a stated window, then removed automatically. The generalisation of break-glass to ordinary work.
• Standing privilege - a column a role can read in clear that the design does not mark clear for that role. It does not matter whether anybody has read it; capability is the exposure.

Take one control and price it honestly. An access request that needs two approvers and takes three days does not cost three days of anybody's salary, but it does cost the requester a context switch, a chase, and usually a day of doing something less useful while they wait. Multiply by the number of requests a quarter and you have a real figure.

The budget is finite in a way that matters. People will absorb a certain amount of this and keep using the sanctioned path, because the path is the path. Past some point they stop, and the point is not where you think it is: it moves with how urgent the work feels, not with how sensitive the data is.

An access request queue is usually treated as an operational annoyance to be cleared faster. Read the other way round it is the most honest specification you will ever get: it is people telling you, at their own expense, what the design failed to anticipate.

• The same request three times is not three requests. It is one missing line in the access design, being paid for repeatedly by three different people. Approving it a fourth time is choosing not to fix it.
• Requests cluster by job, not by person. When every new support agent asks for the same two columns in their first week, that pairing belongs in the support role and the queue should never see it again.
• Volume is a design metric, not a service metric. A team proud of clearing requests in four hours has optimised the symptom. The number worth watching is how many requests arrive at all, and whether it is falling.
• The requests that never arrive are the expensive ones. People stop asking after two refusals. Silence from a team is not the absence of a need, it is the presence of a workaround.

A useful habit is to review the queue quarterly as a group, not to audit the decisions but to look for repeats. Every repeat is either a role that should exist or an attribute that should be driving a policy, and both are cheaper than the tenth approval.

Stated plainly: any control whose friction exceeds the value of a shortcut gets routed around, and the routes are always worse. Worse is not a moral judgement. It is a factual comparison on three dimensions that anybody can check.

The screenshot is the worst of the three and it is also the one nobody thinks of as a data movement. It defeats every column policy, every classification scan and every deletion request, and it takes four seconds.

You do not need instrumentation to get a defensible number. Three measurements, each of which takes under an hour.

• Time one request end to end, yourself. Not from approval to grant, which is the number the platform team reports. From the moment somebody realises they are blocked to the moment they are working. The gap between those two figures is usually a factor of five and it is where the whole argument lives.
• Count repeats in one quarter. Group the queue by what was actually asked for rather than who asked. Any group with three or more entries is a line missing from the design.
• Ask three people what they do instead. Phrase it without judgement and you will get an honest answer, because nobody involved thinks they are doing anything wrong. They are right, mostly. The control made the shortcut rational.

Write the three figures next to the three counters from session 1. A monthly report that shows leaks falling while request time triples is describing an estate that is about to develop shadow paths, and it is worth being the person who says so before it does.

Break-glass is a good mechanism. Something will go wrong that nobody anticipated, somebody will need power they do not normally hold, and a design with no answer for that moment will be overridden in a way nobody records. The failure is never the opening. It is that the glass is never replaced.

The grant that reverts automatically is the only kind that reverts. A grant that depends on somebody remembering to revoke it, during the week after an incident, while writing the postmortem and catching up on everything they missed, is a permanent grant with an optimistic label. This is not a discipline problem and it will not be fixed by reminding people harder.

• Put the expiry in the grant, not in a calendar. The mechanism has to be the same mechanism, or the two will diverge and the calendar will lose.
• Make the window short and the renewal cheap. Fourteen days with a one-click renewal is enforceable. Ninety days is a way of pretending there is an expiry.
• Expect renewals and do not treat them as failures. A grant renewed three times is telling you it belongs in the design. That is the queue signal again, arriving through a different door.
• Alert on the use, not the grant. A break-glass role that is held quietly is one thing. A break-glass role that is used at 3pm on a Tuesday is worth a message the same afternoon.

Elevation generalises break-glass to ordinary work: the person holds their normal access, and steps up for a stated purpose and a stated window. The mechanics are the easy half. The half that decides whether this is useful in a year is capturing the reason at the moment of the request.

A reason written at request time costs the requester fifteen seconds and is specific, because they are in the middle of the thing. The same reason reconstructed a month later is unrecoverable. Nobody is being evasive; they genuinely cannot remember which of four investigations that Tuesday belonged to, and what gets written into the review is a plausible guess.

The second one is not bureaucracy, it is the artifact that lets somebody defend the decision later without relying on memory. It is also, quietly, the thing that makes the grant removable: a reason tied to a closed incident is a reason that has visibly expired.

Saltbox's opening state is one shared analyst role carrying 30 standing privileges. The finished design carries 0. Nothing in between is exotic: the ladder goes 30, then 25, then 17, then 1 after the role split, then 0 once the modelling view is pseudonymised.

The point worth sitting with is not the shape of the ladder. It is where those 30 came from. Every one of them started as somebody being unblocked. Not one was granted by a person who thought they were creating a permanent exposure. Each was a reasonable answer to a real request, on a day when the requester needed to get on with something, and the only thing missing was an end date.

Which means the counter is not a measure of how disciplined your team is. It is a measure of whether your grants have expiry dates, and that is a design decision somebody can make this month.

Every platform has one role that sits above the model. In Snowflake it is ACCOUNTADMIN, which combines the system and security administration roles; other warehouses have an equivalent under a different name. It should be held by two named humans, for break-glass only. Two, because one is a single point of failure and three is a habit.

The reason for the severity is measurable. Take Saltbox's finished design, with every masking policy, every row policy and the five-way role split still defined and deployed, and grant one person the top role. The score returns to 109 leaks and 30 standing privileges, which is identical to the opening state before any policy existed at all.

The practical move is short. Write the two names. Write the list of everybody else who currently holds it. For each of those, write what they were unblocked for, because that is the role you actually need to create.

An expiry policy fails when it is written to be defensible rather than to be followed. Four questions decide whether yours will hold.

• What is the default window, and does it apply to everybody. One default, with named exceptions that have reasons. A policy with per-team windows is four policies and they will drift.
• What happens on the expiry date. Automatic revocation, or a notification to a human. Only one of those is an expiry policy. The other is a reminder, and reminders are ignored during exactly the weeks that matter.
• Who can extend, and how many times. Unlimited renewals are fine if each one is logged and the third one triggers a design conversation rather than an approval.
• What is exempt, and is that written down. Service accounts and standing job roles usually are, legitimately. An exemption list nobody has enumerated is not an exemption, it is a gap.

One test before you commit to a window: would you enforce it during your busiest week of the year, on the person you can least afford to block. If the honest answer is no, the window is too short and you have just discovered the number you can actually hold.