A retired feature's grant is still attached to a live workload — why does nobody remove it, and what does it cost?
answer
- incentives, not ignorance
- risk to remove, nothing to leave
- grant lives outside the deleted code
- unused access is unwatched access
- detach reversibly, delete after a window
basics
~20 sRemoval is all downside for whoever does it: an outage if they are wrong, no visible reward if they are right, and usually no way to prove nothing still calls it. The cost is standing access with no remaining function, unmonitored precisely because nothing legitimate uses it.
solid answer
~40 sThe incentives are asymmetric. Removing a permission risks breaking something on the remover's watch, and succeeds invisibly; leaving it costs that person nothing. On top of that, the grant usually lives somewhere other than the code that was deleted, the person who wrote it has moved on, and nobody can show that nothing still calls it. What remains is access with no corresponding function — and it is the least monitored access in the estate, because no legitimate traffic uses it, so any use of it is anomalous and nobody is watching for anomalies on a permission nobody remembers. The fix is procedural, not technical: an owner recorded on every grant, grant removal on the feature-retirement checklist, removal done reversibly, and an expiry date on anything issued for temporary work.
go deeper
Recall that platform grants persist on their own: deleting a feature's code does not remove the access that was created for it.
Explain why removal keeps not happening — risk lands on the remover, the grant lives in a different system, and nobody can prove nothing uses it.
Show the removal sequence you would actually run: check the record over a stated window, detach rather than destroy, announce a restore window, then delete.
Make the default outcome removal: owners recorded on grants, expiry on temporary ones, grant removal on the retirement checklist, dormancy reviewed on a rhythm.
## Why the grant outlives the feature This is not a knowledge failure. Every engineer involved would agree the grant should go. It stays for structural reasons: - **Asymmetric consequences.** Removing it and being wrong is an incident with your name on it. Removing it and being right produces nothing anyone sees. Leaving it produces nothing either — but costs the remover no risk. - **It lives somewhere else.** The feature was deleted in application code; the grant sits in the platform's access configuration, often in a different repository, changed by a different process, reviewed by different people. Deleting the first does nothing to the second. - **Nobody can prove the negative.** "Does anything still use this?" has no clean answer from inside the code. It can only be answered from the record of calls, over a window long enough to be convincing, and nobody wants to own that judgement for a permission they did not create. - **The author has gone.** Grants routinely outlive the engineer who requested them, and the request's justification — a ticket, a message, a launch deadline — rarely survives attached to it. - **There is no natural expiry.** Grants persist by default. Nothing in the platform reminds anybody that a permission has now been unused for a year. ## What the standing grant actually costs - **Blast radius with no offsetting function.** Every risk calculation for that workload now includes a permission that buys the business nothing. - **It is the least watched access you have.** Alerting is built around normal traffic; there is no normal traffic on this permission. That makes it attractive to anyone who finds it and invisible to everyone who owns it. - **It distorts every later exercise.** The next engineer tightening this workload sees the permission, cannot prove it is unneeded, and keeps it — the grant gets copied forward into the narrow grant that was supposed to replace it. - **It survives the workload.** Grants get copied wholesale when a service is forked or a new environment is stamped out, so one orphan reproduces. ## Making removal a safe, reversible step The reason to spell this out is that "just delete it" is the answer that keeps not happening. Make the removal cheap to reverse and somebody will do it. 1. **Check the record first.** Look for any use of the specific permission over the longest window available, and say what window you checked. This is evidence, not proof — the same one-directional limit applies as when deriving a grant from usage. 2. **Alert before you remove, if the permission is frightening.** Watch for use over an agreed period. Be precise about what this buys: an alert is a **detective** control — it tells you the permission was used, it does not stop the use. Removal is the preventive one, and the alert is only the evidence-gathering step before it. 3. **Detach rather than destroy.** Remove the grant from the principal while keeping the definition, so restoring it is a single reversible step rather than an archaeology exercise. 4. **Announce a restore window.** Tell the owning team the grant is detached and will be deleted after an agreed period, and make restoring it during that period a non-event that needs no approval. 5. **Delete the definition** at the end of the window. ## Preventing the next one - **Record an owner on every grant** — a team, not a person, because people move. - **Put grant removal on the feature-retirement checklist**, next to removing the code, the schedule and the dashboards. The checklist is the only place the cross-system link gets made. - **Give temporary grants an expiry.** A grant issued for a migration should be created with an end date and a named owner, so the default outcome is that it disappears. - **Review dormancy on a rhythm**, so a principal that exercised nothing for a long window becomes a routine work item rather than an archaeology project someone has to volunteer for. The interview point underneath all of this: least privilege is usually discussed as an authoring problem — how narrow do I write the grant — and the grant nobody removed is the reminder that it is at least as much a **lifecycle** problem. A perfectly scoped grant for work that no longer exists is not least privilege at all.
- How do you decide it is safe to remove a permission you did not create and cannot trace?Check the record of calls for that specific permission over the longest window you have, state that window out loud, and treat silence as strong evidence rather than proof. Then make the removal reversible: detach the grant, keep the definition, announce a restore window in which putting it back needs no approval, and delete it at the end. The safety comes from the reversibility, not from certainty.
- Is alerting on use of the suspect permission a substitute for removing it?No. An alert is detective — it tells you the permission was exercised, after it was exercised. Removal is the preventive control that stops the use from succeeding. Alerting is a good way to gather evidence for a period before removing something frightening, but a team that stops at the alert has kept the standing access and added a notification.
A spare key handed to a contractor whose job finished years ago. Nobody is harmed by leaving it, nobody remembers it exists, and no one is watching the door it opens.
saying these in an interview costs you the question
- Explains the orphaned grant as carelessness rather than as an incentive problem
- Says alerting on the permission is as good as removing it
- Deletes the grant outright with no cheap path to restore it
- Assumes deleting the feature's code removed its platform access too
- Keeps the permission forward into a new narrow grant because nobody can disprove it