skip to content

How would you turn the claim that a team follows least privilege into a number you can report and trend?

level: seniorimportance: nice to knowfreq 32%

answer

  1. granted minus exercised
  2. per principal, per owning team
  3. wildcard share needs no usage data
  4. counts breadth, never consequence
  5. same window sensitivity as tightening

basics

~20 s

Count what is granted against what is exercised. Per principal, the permissions allowed but never used in a window, and the share of principals holding a wildcard on any axis, give two numbers that can be trended, attributed to an owner, and argued with.

solid answer

~40 s

The two cheapest honest measures are **unused permissions per principal** — allowed by the grant, never exercised in the observation window — and the **share of principals carrying a wildcard on any axis**. Both are computable from things the platform already has: the grants themselves, and the record of calls. Report them per owning team rather than per account, because a total across an estate is nobody's work item. What they measure is written breadth, not consequence: a principal with one permission that can rewrite what other principals may do outranks a principal with fifty read permissions, and neither number notices. So I would trend them, use them to pick which grants to look at first, and never present them as a safety score.

code

pseudocode · 10 lines
pseudocode
for each principal in account:
    granted = action-and-resource pairs allowed by principal's grants
    used    = distinct pairs in usageRecord(principal, last 90 days)
    unused[principal] = granted - used

report.unusedTotal   = sum over principals of size(unused[principal])
report.wildcardShare = count(principals whose grants contain "*"
                              on action or resource) / count(principals)
report.dormant       = principals where size(used) == 0
report.window        = "90 days"   # the number is meaningless without it

go deeper

for a junior

Recall that the permissions a grant allows can be compared against the ones actually exercised, and that the difference is something you can count.

for a middle

Explain how the two inputs are obtained — the grant documents and the record of calls — and why the observation window has to be stated with the number.

for a senior

Show what the count misses: consequence weighting, effective reach across combined grants, and the incentive to delete dormant principals instead of narrowing the risky grant.

for a principal

Decide what the organisation is allowed to conclude from the number, who owns it, and what sits beside it so a green trend never reads as an assurance.

## Why a number at all "We follow least privilege" is unfalsifiable, which is why interviewers push on it. A number changes the conversation in three ways: it can be trended, so improvement is visible; it can be attributed, so a team owns it; and it can be argued with, which forces the assumptions into the open. None of that requires the number to be a good measure of risk — only a stable, honest measure of something real. ## Two numbers you can actually compute Both come from data the platform already holds: the grant documents, and the record of calls each principal made. - **Unused permissions per principal.** For each principal, the set of action-and-resource pairs its grants allow, minus the set it actually exercised in a window. The size of that difference is the number. - **Wildcard exposure.** The share of principals whose effective grants contain a wildcard on the action axis, the resource axis, or both. This one needs no usage data at all, which makes it the first thing to compute in an estate that keeps no long record. A third, useful once the first two are stable, is **dormancy**: principals that exercised nothing at all in the window. A dormant principal with a live credential is standing exposure attached to no work. ## What makes a metric behave | Property | Why it matters | |---|---| | Attributable | a number without an owning team is a report, not a work item | | Stable window | changing the window changes the number; fix it and state it | | Trended, not absolute | the direction is the signal; the level depends on estate size | | Cheap to recompute | a metric produced by hand quarterly stops being produced | ## What the number does not capture This is the half that separates a candidate who has run the exercise from one who has read about it: - **Consequence is not counted.** Permissions are not interchangeable. One permission that can change what other principals may do, or that can destroy durable data, outweighs a long list of read permissions — and a count treats them identically. - **It measures the written grant, not effective access.** A principal's real reach is whatever all of the grants that apply to it add up to, and a per-grant count can look excellent while the combination does not. - **It is window-sensitive in exactly the way a tightening exercise is.** A permission used once a quarter shows as unused in a thirty-day window, so a metric run on a short window systematically overstates waste. - **It rewards the cheap move.** The fastest way to improve the number is to delete dormant principals nobody defends, not to narrow the wide grant on the busy production workload. That is a real improvement, but it is not the improvement you were after. - **It says nothing about whether a grant is still wanted.** A permission exercised daily by a workload that should not exist at all scores perfectly. ## Reporting it so it actually moves 1. Publish per owning team, with the top few principals named. A team can act on five principals; nobody acts on an estate-wide total. 2. Pair the count with one consequence-weighted list — the principals holding permissions that can destroy durable data or alter other principals' access — and treat that list as the work queue, with the count as the trend line. 3. State the window on every report. A number whose window changed between quarters is not a trend. 4. Expect the first reading to be terrible and say so in advance, so the first report is a baseline rather than an accusation. The honest framing to give an interviewer is this: the count tells you **where to look**, not **how safe you are**. Teams that confuse the two end up optimising a dashboard, and a green dashboard with one administrator-shaped grant left in it is worse than no dashboard, because it has answered the question for people who would otherwise have kept asking.

  • A team halves its unused-permission count in one quarter by deleting dormant principals. Did the estate get safer?
    Somewhat, and less than the number suggests. Removing dormant principals removes standing credentials attached to no work, which is real. But it leaves untouched the wide grant on the busy production workload, which is where the consequence lives. That is why the count belongs next to a consequence-weighted queue: on its own it rewards the cheapest available move.
  • Why report per owning team rather than per account?
    Because the grant is changed by whoever owns the workload, and an account often carries several teams' work. An estate-wide or account-wide total is a report nobody is accountable for; a per-team figure naming its worst five principals is a work item somebody can finish. Attribution is what turns a measurement into a change.

saying these in an interview costs you the question

  • Presents an unused-permission count as a measure of how safe the estate is
  • Reports one estate-wide total with no owning team attached
  • Changes the observation window between reports and still calls it a trend
  • Counts permissions as interchangeable regardless of what they can destroy
  • Assumes a per-grant count reflects the principal's effective reach