Leaked AI API key: an immediate containment and recovery case
A retrospective on the decision chain when an API key is found in a public location, covering revocation, replacement, historical exposure search, and the post-incident defenses that prevent recurrence.
The scenario: an API key appears in a public repository, log, screenshot, CI output, ticket, or shared document. The critical realization is that deleting it from the latest commit is not enough—any historical exposure means the key must be treated as compromised. We have seen cases where a key committed once and deleted immediately still generated thousands of dollars of unauthorized usage from cached copies.
The containment chain: revoke the key immediately in the provider console and create a replacement for legitimate services. Inspect recent usage, billing, source IPs, and unusual time windows to assess damage; pause the affected workload if necessary to stop further charges. Then search every location the key may have existed: Git history, build artifacts, CI logs, server logs, chat messages, tickets, and shared documents.
A new commit that removes the key cannot erase historical exposure. If the key entered Git history, follow the organization's history-cleaning process and notify all collaborators to re-pull. This step is often skipped under time pressure, which is why leaks recur. After recovery, implement separate keys per project and environment, server-side secret management, least-privilege scopes, spending limits, and anomaly alerts. Rotate long-lived keys on a schedule.
The lesson: the damage from a leaked key is proportional to how long it goes undetected after exposure, not how quickly it was deleted from the latest code. If unauthorized charges occurred, preserve evidence and contact the provider through its official support channel. The limitation: some exposure surfaces (third-party mirrors, cached logs) may be outside your control to clean completely.