Origin
Pranay has watched the same scene play out at a dozen companies in the past year. The IT team pulls API keys from every system they can think of: cloud consoles, CI/CD platforms, SaaS admin pages, internal services. The list is always longer than expected. Most of the keys have no documented owner. A meaningful fraction belong to people who left months or years ago. The team didn't know any of this until they looked.
An API key is an identity. It authenticates a caller, it carries permissions, it leaves an audit trail. It just sits outside the identity governance model because the model was built around humans logging in through an IDP. The cost of that exclusion shows up reliably when companies finally run the audit.
The three categories every audit surfaces
When you actually look, the orphaned keys cluster into three predictable shapes.
The personal-cloud-access key. An engineer created a personal IAM user in AWS, generated an access key, used it for a script, and never cleaned it up. They left 18 months ago. The key still has the permissions it had on day one.
The "temporary" integration. Someone built a Slack notifier during an incident, generated a webhook token, shipped it, moved on. The script still runs. The token never rotates. Nobody currently on the team built it or knows it exists.
The shared service-account key. A team needed automation, created a key, dropped it in a password manager titled "production secrets," and divided up access by who had the password. People rotated through the team. The key didn't.
The third category is the one nobody catches in standard offboarding, because it was never attached to a person in the first place.
Why they don't get cleaned up
Three reasons consistent across every company we've sat with:
The offboarding checklist doesn't include API keys. SSO is disabled, app accounts get deprovisioned, the cloud IAM user might get disabled. But the access keys attached to that user, or sitting under their service accounts, don't get audited. The IT team running offboarding doesn't have visibility into them.
The keys don't live in one place. At the average mid-sized company, API keys exist in cloud consoles (AWS, GCP, Azure), in CI/CD tools, in SaaS admin pages (Stripe, Datadog, Twilio, the dozen others a real stack contains), in internal service registries, and in shared password managers. No single inventory exists. Nobody has built one.
Nobody owns "API keys" as a category. Cloud team owns cloud. App admins own their apps. Security may audit annually. No team owns the lifecycle of every credential string that touches a production system.
What the audit looks like
A 110-person engineering company. Three years operating. Roughly 1,200 active API keys across the systems the team could enumerate. 280 of them with no clear owner. 65 belonging to people who had left. Some with admin-level scope to production systems.
The audit took two engineers a week. The remediation took longer. Building the practice that keeps it from accumulating again is what most teams still don't have.
What changes when you treat them as identities
Every key has an owner. Every key has an expiry. Every key gets revoked when its owner leaves or its purpose ends. That isn't a sophisticated program. It's just including the keys in the lifecycle that already exists for everyone else.
Teams that close this gap describe a different audit on the second run: not "where are all these keys?" but "are all of them current?" That's a maintenance question, not an investigation.