Someone left three months ago. Their SSO account is disabled, their laptop is back, their GitHub access is revoked — and an OpenAI key they created is still making calls, billed to a card nobody is reviewing.
This is a common failure and it is structural rather than careless. Offboarding checklists are built around identity: the systems you can see in your IdP. Third-party developer accounts, created ad hoc with a corporate card, are not in the IdP and therefore are not in the checklist.
Why these accounts exist at all
Nobody sets out to create shadow infrastructure. The sequence is almost always the same.
An engineer needs to try something. Going through procurement takes two weeks; signing up with a work email and a corporate card takes two minutes. The experiment works, gets embedded in something real, and the account never gets migrated to the organisation.
The account is now load-bearing and owned by one person. When that person leaves, the workload keeps running and the ownership does not transfer.
Finding what is out there
Four sources, in order of what they reveal.
Card and expense statements. The most reliable, because payment is the one thing that cannot be hidden. Pull twelve months of card transactions and expense claims, filter for anything that looks like a developer tool or cloud provider, and compare against your known provider list. Anything unaccounted for is a lead.
Provider consoles you already know about. Inside each, audit key and member ownership. Most provider consoles show who created a key and when it was last used. A key created by a departed employee and still active is your answer.
Your email domain. Many providers let you see all accounts registered to a domain, or will tell you on request. Worth asking your main providers directly.
DNS and egress logs. If you have outbound traffic logging, calls to provider API endpoints reveal integrations you did not know existed. This is the only method that finds accounts paid for personally and expensed as something else.
The order of operations matters
The instinct is to revoke immediately. Resist it for a moment, because a key that has survived three months is almost certainly doing something.
Determine whether it is in use. Check last-used timestamps in the provider console and recent spend. A key with no usage in ninety days can be revoked without ceremony.
If it is in use, find the caller before revoking. Search the codebase and secret store for the key prefix, and check which service the calls originate from. Revoking a live production credential to solve a cost problem is a poor trade.
Reissue as a service credential, then revoke. Create an organisation-owned key, deploy it, confirm traffic has moved, then revoke the personal one. This is the only sequence that does not risk an outage.
Transfer the account, don't recreate it. Most providers support transferring billing ownership. Recreating loses usage history, which you will want the first time someone asks what the trend looks like.
The cost angle nobody quantifies
The spend on an orphaned key is usually not the main cost. Three others are larger.
It is unmonitored by definition. Nobody holds the number, so it has no baseline and no alert. If it doubles, nothing fires.
It is a security exposure. A credential whose owner has left is a credential nobody rotates. It sits in whatever secret store or environment variable it was placed in, indefinitely.
It fragments the total. The main harm to cost management is not the amount, it is that your organisation-wide AI figure is wrong, and therefore every forecast built on it is wrong.
Fixing it permanently
Add third-party developer accounts to the offboarding checklist. Explicitly, by name — the providers you know about, plus a card-statement reconciliation step.
Move to organisation accounts with service credentials. The rule that prevents recurrence is that no production credential is owned by a person. Keys belong to services; people get access to the console, not to the credential.
Make the sanctioned path faster than the unsanctioned one. These accounts exist because procurement is slower than a corporate card. If getting a project onto the org account takes a day, people will use it. If it takes a fortnight, they will not.
Reconcile quarterly. Card statements against tracked providers. It takes an hour and it is the only method that reliably catches what the other controls miss.
Bring every provider into one view. Once accounts are consolidated, connect them all so there is a single total with a baseline per provider. StackSpend connects providers with read-only access, so a sysadmin can wire up the whole estate without a security review — and an account that appears from nowhere becomes visible rather than merely expensive.
FAQ
How do I find API keys created by a former employee?
Check each provider console for key ownership and last-used timestamps, then reconcile twelve months of card and expense statements against your known provider list. The statements catch accounts you did not know existed; the consoles catch keys inside accounts you did.
Should I revoke an orphaned API key immediately?
Only if it shows no recent usage. An active key is running something in production, so find the caller, issue an organisation-owned replacement, confirm traffic has moved, and then revoke.
How do I stop personal provider accounts being created?
Make the organisation-owned path faster than a corporate card. Policy alone does not work, because these accounts are created under time pressure — the alternative has to be genuinely quicker.
Can I transfer a provider account to the organisation?
Most major providers support transferring billing ownership or migrating a project into an organisation. Prefer transferring to recreating, because recreating discards the usage history you will want for forecasting.
