API Key Management for Teams: Rotation, Scopes and Offboarding

API keys are the passwords teams forget are passwords: pasted in chats, committed to repos, shared in docs, and remembered only during the outage they cause. A leaked AI key burns money by the minute while attackers benchmark your budget, and a departed contractor's active key is an audit finding waiting to happen. This guide builds boring, complete key management: where keys live, how they scope and rotate, what happens on leaks and departures, and the quarterly rhythm that keeps all of it true.
Where keys live
Keys live in a vault or managed secret store, injected at runtime into environments that need them. They never live in chat transcripts, documentation pages, repository files or screenshots — every one of those is a breach with a delayed fuse. Per-person keys beat shared keys wherever feasible: narrower blast radius, attributable usage, painless individual rotation.
Audit current storage ruthlessly once, then prevent regressions with pre-commit hooks that reject key patterns and documented policy everyone has actually read. The initial cleanup takes an afternoon; the policy takes a page. Teams that complete both stop thinking about key storage entirely, which is precisely the goal — security that works when nobody is thinking about it.
- Vault as source of truth
- Runtime injection, never files
- Per-person keys preferred
- Chat, docs and code are never storage
Scopes and separation
Scope keys narrowly per use case: read versus write, development versus production, human versus automation. Separate automation keys carry budgets that cap blast radius financially even when all else fails. Least privilege is not a slogan but a configuration — review scopes when creating keys, not during incidents when nobody remembers why a key can do everything.
Distinguish human and machine keys explicitly, with different lifetimes and rotation cadences. Humans authenticate interactively and tolerate friction; automation needs longevity and monitoring instead. Mixing the two models produces keys that are both annoying and insecure — the worst combination available. Design the separation deliberately and the rest of key management gets easier automatically.
- Narrow scopes per use case
- Separate automation keys
- Budgets as blast-radius caps
- Least privilege, actually enforced
Leak response in the first hour
When a key leaks, revoke first and investigate second — every minute of valid leaked credentials burns budget and access simultaneously. Audit usage across the exposure window for anomalies, then rotate with overlapping validity so production never blinks. Post-mortem the leak vector afterward, not during; the priority order is stop, assess, learn, in that sequence.
Rehearse this sequence before needing it: who can revoke, where usage is audited, how rotation propagates. Tabletop the scenario quarterly with the team that would execute it bleary-eyed at midnight. Leaks are inevitable at scale; unpracticed response turns them into incidents, practiced response turns them into anecdotes. The difference is entirely preparation.
- Revoke first, audit second
- Overlapping rotation, zero downtime
- Post-mortem the leak vector
- First hour matters most
Offboarding without orphans
Remove departing members' access same-day as part of the exit checklist: disable personal keys, rotate shared keys they touched, review recent usage for anomalies. Orphaned credentials from past departures are among the most common findings in security audits, and each represents months of unnecessary exposure. Checklists beat memory — memory leaves with the departing member.
Automate what the checklist allows: identity-provider offboarding that cascades to key stores, expiry dates on contractor keys, alerts on dormant credentials. Review access quarterly even without departures; roles change, projects end, access should follow. Boring, complete offboarding is invisible when working and catastrophic when missing — invest accordingly.
- Same-day access removal
- Shared-key rotation on departure
- Usage audit for anomalies
- Checklist, not memory
Rhythm that holds
Calendar quarterly rotation for high-value keys and event-driven rotation for incidents and departures, automated wherever tooling allows. Assign ownership explicitly — unowned rotation schedules decay into never within two cycles. Review all access quarterly: who holds what, why, and whether the reasons still hold. Prune aggressively; every standing credential is risk without current justification.
Fold key management into existing rituals rather than inventing ceremonies: sprint reviews, quarterly planning, offboarding checklists. Small recurring effort beats heroic annual cleanups that everyone dreads and postpones. Teams with rhythm experience key management as background silence. Teams without experience it as periodic emergencies. The choice is entirely procedural.
- Quarterly rotation calendar
- Event-driven rotation always
- Ownership assigned explicitly
- Access review as routine
Frequently asked questions
Where should API keys live?
Vault or secret manager as source of truth, environment injection at runtime, per-person keys where possible, quarterly rotation calendar. Keys in chat, docs or code are incidents waiting for discovery.
Shared keys or per-person keys?
Blast radius: one leaked shared key compromises everything it touches, while per-person keys limit damage to one developer. Prefer personal keys for daily work and narrow shared keys for automation with budgets attached.
What do we do when a key leaks?
Revoke immediately, audit usage for the exposure window, rotate without downtime using overlapping validity, then post-mortem how it leaked. Speed matters more than completeness in the first hour.
How do we offboard API access?
Disable the departed member's keys same-day as part of the offboarding checklist, rotate shared keys they touched, and audit recent usage for anomalies. Access removal is not a quarterly task.
How often should keys rotate?
Quarterly rotation for high-value keys, on-event rotation for incidents and departures, automated where tooling allows. Calendar it explicitly; unowned rotation schedules decay into never.
Related guides
Keep your coding workflow moving
Kintio provides an Anthropic-compatible API for Claude Code and other developer tools. Review the fit for your workload before switching.
Explore Kintio →Last updated: