A standing grant on a departed contractor's identity has no owner and no ticket — how do you decide whether to remove it?

## Why unattributable grants survive Nothing about this grant is technically hard. It survives because of an asymmetry in who carries the consequences. - If you remove it and something breaks, the breakage is **attributable to you, today**, with your name on the change. - If you leave it and it is abused, the harm is attributable to **nobody**, later, and probably to someone else. - Every reviewer before you faced the same arithmetic and reached the same answer, which is why the grant is three years old. So the real question is not "is this safe to remove?" — you cannot know that — but "how do I make removal cheap enough to be worth attempting?" Everything below serves that. ## What the record can and cannot attribute | what the record shows | what it means | what you do next | |---|---|---| | no reads across a full business cycle | the strongest available evidence of a dead grant | remove, reversibly, with a window and an alert | | reads in recent days or weeks | something still runs as a person who left | stop; this is an investigation, not a cleanup | | reads months ago, on one or two names | a real but infrequent consumer exists | find the job behind those names before touching anything | | reads by an identity you cannot map to anything | the grant is unattributable in the strict sense | the strongest case for removal, and the weakest for waiting | What the record will never tell you is **why** the grant was created or **who** would notice its removal. That information was in someone's head, and the someone has gone. Waiting for it is how the grant reaches four years. ## Make the removal reversible rather than safe 1. **Disable the identity's ability to authenticate** rather than deleting rules. The denial a consumer experiences is identical; your path back is not. 2. **Keep the grant's exact text** — scope, rights, date, whatever conditions it carried. Change history sometimes records that a rule existed without preserving precisely what it said, and reconstructing scope during an outage is slow and error-prone. 3. **Announce a window** to the teams that could plausibly own the consumer, and say what you will do if something breaks. 4. **Alert on denials for that identity**, so a failure is loud and immediate instead of a report that quietly stops arriving. 5. **Delete properly once the window closes**, and record the decision and its evidence so the next reviewer inherits a conclusion rather than a fresh gamble. ## Removing the grant is not the same as ending the access These are three different actions with three different effects, and conflating them is the common error: - **Deleting the rule** changes what future checks decide. It binds the next call, not the last one. - **Disabling the identity** stops it obtaining anything new, which is usually the fastest blunt stop. - **Withdrawing what was already handed out** is a separate action against whatever accepts that credential. A credential already issued may keep working until it expires, depending on the design, so removal can have a lag. Deleting is not withdrawing. If the concern is abuse rather than tidiness, say which of the three you actually performed. ## The default that clears the backlog The policy worth arguing for is simple and unpopular: **unattributable and unused loses.** The burden of proof sits on keeping the grant, because a grant nobody will own cannot be attested at this review or any future one — it will survive the next round for exactly the reason it survived this one, and the estate accumulates standing access at the rate people leave. A full business cycle is the honest window, and for most organisations that means a year, because of annual reconciliations, renewals and year-end work. If you cannot wait a year, remove on a quarter's evidence — but say so in the record, so the risk you accepted is written down next to the decision, and so the person who gets paged in month eleven knows why.