The Access Audit That Found Five People Who Could Delete Production

# The Access Audit That Found Five People Who Could Delete Production The org chart said two people had production database access: the founding engineer and the infrastructure lead. The IAM console said five. The other three weren't a mystery once traced — they were exactly the kind of access that accumulates when nobody's job is to remove it, only to grant it. ## Access grows by addition and shrinks by nobody's initiative Every one of the three extra grants had a defensible reason at the time it was made. A contractor needed production access for a two-week migration project eight months earlier and the role was never revoked after the contract ended. An engineer was given elevated access during an incident at 2am to unblock a fix, and the temporary grant that incident response used had no expiry set. A former employee's account had been deactivated in the identity provider but the underlying database role — provisioned separately, before SSO was wired up to gate it — was never cleaned up because deactivating the login doesn't touch grants made directly against the database. None of these were audit failures in the sense of someone ignoring a policy. There wasn't a policy that covered them, because access review processes are almost always built around the grant — who requested it, who approved it — and not around the revoke, which nobody is specifically responsible for triggering. A grant has an obvious owner and a clear moment it happens. A stale grant has no owner and no moment; it just persists until someone goes looking. ## The check that actually finds this isn't a policy review Reading the company's access policy would have told me nothing was wrong — the policy was reasonable, and every grant traced back to a legitimate approval at the time it was made. What found the gap was going directly to the source of truth for permissions — the IAM console and the database's own role grants — and diffing that against the current org chart and current active employment status, rather than trusting that the policy being followed implies the state being correct. A policy describes intent. A role grant describes fact. They drift apart continuously, and only one of them is checkable by just looking. ## What "who can delete production" actually has to mean The obvious next question — how many people can delete production — turned out to be harder to answer precisely than expected, because "access" wasn't a single flat list. Some grants were direct database roles, some were IAM policies attached to a broader group, and one was a Kubernetes service account credential that had been checked into a config repo and never rotated, technically usable by anyone with read access to that repo rather than anyone with an explicit human grant. A due-diligence answer to "who can delete production" has to walk every one of those paths independently, because a clean-looking IAM console can still leave a working credential sitting in a place nobody thought to check as an access surface. The fix, once found, was mechanical: revoke the three stale grants, rotate the checked-in credential, and set an expiry on any future incident-response grant so temporary access can't silently become permanent by default. None of that is hard. The hard part is that nobody finds it by reading policy, reviewing an org chart, or asking who has access — you find it by going to every system that can grant access and checking, directly, who currently has a working credential, independent of what anyone believes the current state to be.