The permission nobody remembers granting

Almost every access review I have run turns up the same shape of problem. Not an attacker, not a clever exploit — just a permission somebody granted for a good reason, on a Tuesday, eighteen months ago, and then nobody removed.

The contractor who needed read access to one bucket, and got the wildcard because it was faster. The service account created for a migration that finished a year ago. The former employee whose SSO was revoked but whose personal access token still works. Individually each is defensible. Collectively they are the reason a small compromise becomes a large one.

Why it accumulates

Granting access is a one-minute task with an obvious requester. Removing access is a zero-minute task with no requester at all. Nobody files a ticket asking you to take their permissions away, so the ratchet only turns one direction.

The second reason is that access is granted under time pressure and reviewed under none. The broad permission gets approved because the narrow one would take an afternoon to work out and someone is blocked right now. That is a real tradeoff, and the mistake is not making it — it is never revisiting it.

The review that actually finds things

Tool-generated reports are a starting point, not an answer. What works better is asking four questions of every non-human identity you can enumerate:

1. What was this created for? If nobody can answer, that is the finding.
2. When did it last authenticate? Most cloud providers expose last-used data for keys and roles. Anything dormant past 90 days is a candidate for removal.
3. What can it reach that it has never touched? Compare granted permissions against actually-used ones. The gap is almost always enormous, and it is the cheapest least-privilege win available.
4. Who would notice if it stopped working? If the answer is “nobody,” disable it and find out.

Human accounts get the same treatment, plus one more: does this person still do the job they had when the access was granted? Internal transfers are a bigger source of privilege accumulation than departures, because departures at least trigger a process.

Making it stick

A one-time cleanup feels great and decays immediately. What changes the trajectory is making the ratchet turn both ways:

• Expiry by default. Time-bound grants for anything non-permanent. If it matters, the renewal is trivial; if it does not, it disappears on its own.
• Access as code. Permissions in version control get reviewed like code, and the diff makes accumulation visible instead of invisible.
• A scheduled review with an owner. Quarterly, on a calendar, assigned to a person. Not a policy document — a recurring meeting that ends with things being removed.

None of this is clever. That is rather the point. The interesting security work is downstream of getting the boring bookkeeping right, and most organizations never get to the interesting part because the boring part is still undone.