Authors
Contents
Find out what your AI bill could drop to
Someone on your team hands in their notice. IT disables their email, their Slack and their laptop. The shared Claude login they used every day for a year is not on IT's list, because it was never an account in the person's name. This post is about that gap.
The problem with a shared password
A shared login belongs to nobody, so it is nobody's job to revoke it. The leaver knows the password. They may have it saved in a browser on a personal machine. They were signed in on a phone. Any of these keeps working until someone changes the password, and changing it means re-sending the new one to everyone who is still on the team, which puts it back in a chat where it can be copied again.
The chat history is the second problem. Everything the leaver pasted into the shared account is still in it, and everything everyone else pasted is visible to the leaver until the moment the password changes.
What offboarding looks like today
For many companies it looks like this. Someone remembers, usually a week late, that the leaver had the AI logins. An admin changes the passwords on five plans. They paste the new ones into the team channel. Two people are locked out for a day because they missed the message. Nobody checks whether the leaver had also created a personal API key on one of the accounts.
No log exists of what the leaver used the account for, so if a client asks, the honest answer is a shrug. This is not a failure of the people involved. It is what a shared password forces.
What it looks like with a key per person
With Proxen, the leaver has one key in their name. On their last day an admin revokes it. That is the whole procedure.
- Their requests stop at the gateway from that moment, on every tool and every device.
- Nobody else's key changes. No password is rotated, nothing is re-sent.
- The provider accounts are untouched, because the leaver never held the provider keys.
- Their usage log stays, with their name on it, for as long as your retention setting says.
The provider's own documentation describes exactly this split: "the provider key stays server-side; developers hold gateway credentials instead" (Anthropic, Claude Code LLM gateway docs). Revoking a gateway credential is a one-person change by design.
A short offboarding checklist
Add these lines to whatever leaver checklist IT already runs.
- Revoke the person's Proxen key.
- Check the log for the last 30 days of their usage and note anything a client might ask about.
- If they were a team admin, remove their admin role in the console.
- If any shared consumer plans still exist, treat their password as compromised and retire the plan rather than rotate it.
- Confirm no raw provider keys were ever shared with the person. If one was, rotate it at the provider.
Steps one to three take a few minutes. Steps four and five are the reason to finish moving off shared logins before the next leaver, not after.
The leaked key case
Leavers are the predictable case. Leaks are the unpredictable one, and they show why caps matter as much as revocation. In March 2026 The Register reported a Gemini API key that leaked and was charged $82,314 in 48 hours, on an account whose normal bill was about $180 a month. A raw provider key has no limit of its own. A per-person key with a hard cap stops at the cap, whoever is holding it.
Do it before you need it
The right time to replace shared logins is while nobody is leaving. Moving a team of 20 to per-person keys is a one-week job (we wrote the plan down in Rolling out per-person AI keys: a one-week plan). The first offboarding after that takes one click. Talk to us if you want to get it done before your next leaver.
