Six months of read records show an admin tool's wildcard grant touching four names — what narrower rule do you write?
answer
- evidence, not intent
- a lower bound on need
- unused in the window is not unused
- the annual path never appeared
- attach the derivation to the rule
basics
~20 sWrite the four observed names in explicitly, but treat the record as a lower bound on need rather than a full picture: extend the observation past the slowest cycle the tool takes part in, and keep a fast way back, before enforcing.
solid answer
~40 sObserved reads are a lower bound on need, not the need itself. Write the candidate rule as those four names listed explicitly, then ask what the window could not have contained: work on a cycle longer than the window, routes that run only during a failure or a recovery, and work the tool is expected to do but has not done yet. Cover that gap before you cut over — extend the window past the slowest scheduled job, ask the owner which paths run rarely, and keep the old rule verbatim so a miss is a rollback rather than a stuck outage. Attach the derivation to the rule: the window, the names, the date, who confirmed the gaps. A grant you can explain that way is defensible in a review; `*` never is.
code
yaml · 18 lines# before - one rule, open-ended
- grantedTo: internal-admin-tool
scope: "billing/*" # every name on the branch, including tomorrow's
rights: [read]
# after - derived from the access record, with its derivation attached
- grantedTo: internal-admin-tool
scope:
- billing/ledger-db
- billing/mailer
- billing/report-store
- billing/statement-signer
rights: [read]
derivedFrom:
windowDays: 184 # two quarter-ends, no year-end
distinctNamesRead: 4
rarePathsConfirmedBy: billing-platform-owner
decidedOn: "2026-09-19"go deeper
Know what a wildcard grant actually covers: everything under a branch of names, including names created after the rule was written. Reading a grant and saying out loud what it reaches is the first skill here.
Explain why recorded reads bound need from below only, and name at least two kinds of path an observation window will not contain — work on a longer cycle, and routes that run only when something fails.
Show how you cut over without an outage: the window you chose and why, who confirmed the rare paths, what you kept in order to reverse, and where the first denial is going to surface.
Argue the estate-wide version: how much evidence justifies funding a narrowing, who carries the breakage budget, and whether every grant must ship with its derivation so the next review is cheap instead of another gamble.
## What a wildcard grant and an access record each say A wildcard grant over a branch of names — one rule whose scope ends in `*` — is a statement about the future as much as the present. It covers every name filed under that branch today **and every name anyone files under it tomorrow**, with no further decision by anyone. That is why it never needs maintenance and why it never stops growing. An access record is the opposite kind of object: a list of reads that actually happened, inside one window, by one identity. Laying the two side by side is the whole of this exercise, and the first discipline is being exact about what the comparison licenses. - The record **establishes a lower bound on need**: those four names are required, because the tool read them. - The record **cannot establish an upper bound**. "Not read in the window" means only that: not read in the window. - The record describes the tool **as it behaved**, not as it is meant to behave. A path that is broken, disabled, or waiting on an upstream system looks identical to a path that does not exist. - A record of successful reads proves the grant was **wide enough**. Nothing in it says the grant was not wider than required. Those are different claims, and only the first is evidenced. Platforms differ in how much help you get here: some will propose a narrower rule from the recorded reads, others hand you only the raw reads and the derivation is yours. The reasoning above is the same either way, and a proposed rule inherits every blind spot of the window it was derived from. ## Writing the candidate rule 1. **Enumerate the names.** Four names listed explicitly cannot silently acquire a fifth; a shorter prefix can, which is how the grant you are replacing became wide in the first place. Where a branch genuinely grows by design, say so deliberately rather than by default. 2. **Attach the derivation to the rule** — the window, the count of distinct names, the date, and the person who confirmed what runs rarely. A rule carrying its own evidence can be re-attested in minutes. A rule without one is tomorrow's unattributable grant: possibly correct, unexplainable, and therefore permanent. 3. **Record what you deliberately excluded**, so the next reviewer inherits a decision instead of a mystery. ## The blind spots of any observation window 184 days contains two quarter-ends and no year-end. That arithmetic is the whole risk, and it generalises: | what the window missed | why | what covers it | |---|---|---| | work on a cycle longer than the window | an annual reconciliation has had no chance to run | extend past the slowest scheduled job, or state out loud that you are deciding on a quarter's evidence | | failure and recovery routes | they run only when something fails, and nothing failed | read the recovery procedure and take the names out of it | | work not yet shipped | it has never run at all | make the rule quick to change, and know who may change it | | a path that broke before the window opened | a disabled job reads exactly like an unused one | check whether "unused" means never called, or called and failed | ## Cutting over without an outage Keep the wide grant in place while the candidate is written and evidenced — a narrowing is a change you schedule, not one you slip in. Extend the observation past the longest cycle the tool takes part in, or accept the shorter window explicitly. Then make the change reversible: keep the old rule verbatim, announce the window, and alert on every denial of that identity. The reason the alert matters is the shape of the failure. The paths a window misses are by definition infrequent, so the first denial arrives quietly, weeks late, and far from anything that looks like a cause. A denial you see within minutes is a rollback; a denial nobody notices until a monthly report is missing is an incident with a cold trail. ## Why an evidenced rule is worth the work Deriving the rule changes what a later review can do with it. You can state what it covers, why, on what evidence, and who confirmed the gaps — so the next reviewer re-attests it instead of inheriting the same gamble you inherited. Drift also becomes visible: with an enumerated rule, a new name on the branch needs a change and a reason, and that request is exactly the signal a wildcard suppresses. The wildcard is not dangerous because it is wide today. It is dangerous because it makes every future widening invisible.
- The narrowed rule has run for a month with no denials. What can you still not conclude?Only that nothing on a cycle shorter than a month was missed. An annual path, and any route that runs only during a failure, has not yet had a chance to fail. Keep the rollback and the alert on denials until at least one run of the slowest job has passed inside the enforced rule.
- The tool's owner cannot say which paths run rarely — the last three owners have left. What now?Stop asking people and read artefacts: scheduled job definitions, recovery procedures, and the names they mention. Failing that, keep the wide grant live and record reads for a longer window, or fence only the names whose loss you could not accept. Do not enforce a rule derived from a window nobody can vouch for.
- Why attach the window, the record and the confirming owner to the rule itself?Because the next reviewer's question is "why this scope?", and a rule carrying its own derivation can be re-attested in minutes. A rule without one becomes precisely the grant you are trying to remove: plausible, unexplainable, and therefore never touched again.
saying these in an interview costs you the question
- Six months of reads proves the other names are unneeded.
- Enumerate what was read and enforce it the same day.
- Nothing broke in the first week, so the rule is right.
- A wide grant is harmless because the store authenticates every caller.
- The tool is internal, so the width of its grant does not matter.