When a breached provider stored your API keys: containment, replacement and billing checks

Goal

Status as of 25 October 2026. Contain API keys potentially exposed by a service that stored them, then restore authorized access and reconcile usage. Re-check that service's latest notice and each issuer's revocation, rotation and billing documentation. This protocol does not establish that a particular breach occurred.

Prerequisites

Use a trusted administration environment with issuer-side credential controls, the affected project identifiers, application owners, and access to audit and billing records. Record the notice revision and exposure window, including timezone; mark an unknown start as unknown. Keep credential values out of the incident ticket.

Steps

1. Map the exposure. Identify which keys the provider held and every legitimate consumer sharing them. Record identifiers, permissions and owners. For Google Cloud, the documented inventory command is gcloud services api-keys list --project=PROJECT_ID; replace the placeholder with your project identifier. A key inventory identifies candidates, not proof of theft. CLI reference.

2. Contain before restoring. Suspend the affected integration and revoke exposed keys at their issuer. Removing a saved copy is not issuer-side revocation. OWASP's incident procedure prioritizes immediate revocation, followed by replacement and cleanup. Accept a controlled interruption rather than continue using an exposed credential. Prevent the affected service from receiving replacement secrets until its recovery is established. OWASP secret response.

3. Replace through trusted paths. Issue replacements and update each authorized consumer. Google Cloud also documents staged API-key rotation: create the replacement, update applications, then delete the previous key. If using such an overlap to preserve availability, explicitly account for the period when the exposed key remains usable. Do not silently treat creation of a new key as revocation of the old one. Issuer procedure.

4. Investigate the account. Search available audit records from the earliest plausible exposure through containment. Look for unexpected calls, new credentials, identities and resource changes; Google Cloud directs this investigation to Cloud Logging and Security Command Center. Preserve relevant evidence before removing unauthorized access. Separately compare usage and billing with expected workloads, and send disputed request identifiers, timestamps and charge records through authenticated support. Do not assume reimbursement. Investigation guidance.

5. Constrain future access. Separate integrations and environments, grant only required permissions, and prefer short-lived credentials where supported. Google Cloud recommends API and application restrictions to reduce key misuse. Scope restrictions to the legitimate consumer and verify it still works. Key restrictions, secret lifecycle.

6. Set and distinguish cost controls. Configure issuer-enforced spending caps or quotas where available, plus alerts delivered to a monitored channel. Confirm which settings actually stop requests. AWS Budgets explicitly warns that delayed billing and notifications can allow spending beyond an alert threshold. Test alert delivery without deliberately generating excess charges. Budget limitations.

7. Verify closure. Check issuer-side invalidation, successful authorized use of replacements, and continued usage review as billing catches up. Record unresolved log gaps and suspicious account changes. Escalate evidence of host compromise to a separate recovery investigation before reinstalling credentials there.

Expected result

The exposed credentials are invalid, legitimate consumers use restricted replacements, and an evidence-backed usage review has an owner and recorded findings.

Limits and test basis

This is a proposed operational synthesis, not a tested recovery. Missing logs cannot establish absence of abuse. Google Cloud warns that already-issued service-account tokens have separate lifetimes: investigate derived access rather than assuming parent-key replacement invalidates it. No affected software version or fixed release is asserted.