Leaked API Key Response: Revoke, Rotate, and Verify

When an API key leaks, contain the access at its provider, replace the credential where it is still needed, and verify both outcomes. Deleting a file or closing a secret-scanning alert does not establish that the exposed credential stopped working. If it could create other tokens or sessions, those access paths need their own assessment.

This leaked API key response checklist is for an authorized developer, IT administrator or incident lead handling a suspected disclosure. It separates the urgent containment decision from service recovery, misuse investigation and repository cleanup. Official guidance was checked on October 30, 2026. The worksheets and fictional example are preparation aids; we have not run them in your environment.

Open a credential incident record without copying the secret

Start a restricted incident record and assign someone to coordinate it. Identify the provider, credential type, owning team, affected environment and management identifier. Record where the exposure was found and when it was reported, with a time zone. A repository commit reference or alert ID can identify the evidence without putting the credential value into another message.

Distinguish what you know from what you are still checking. A scanner finding is a lead about a particular location; it does not describe every place the credential was used. The earliest exposure you have found may also differ from the earliest exposure that occurred. Preserve that distinction when building the timeline.

Use this compact incident card:

• Identity: provider, credential identifier, principal, owner and environment.
• Exposure: known location, first known exposure, discovery time and evidence reference.
• Authority: incident lead, administrator who can contain access and person who can approve service interruption.
• Scope: permissions, known consumers, sensitive resources and unresolved dependencies.
• Next decision: containment action, responsible person and next checkpoint.

Keep the actual secret out of ordinary tickets, screenshots, AI prompts and shared command transcripts. Evidence containing it belongs in the organization’s controlled evidence process. Responders need a reliable reference and appropriate access, rather than a new copy in every tool.

If authority or provider responsibilities are unclear, use the small-business incident response plan to resolve the handoff. Do not let a credential-specific ticket become a substitute for activating the broader plan when privileged access, sensitive data or important services may be affected.

Choose containment with the service owner

GitHub’s leaked-secret remediation guide prioritizes provider-side revocation for high-risk exposure and also recognizes that replacing a credential before revocation can help manage service downtime. OWASP’s secrets-management guidance emphasizes rapid containment. These are reasons to make an explicit operational decision, rather than applying one rotation order to every incident.

Have the authorized incident and service owners assess whether access should be blocked immediately, accepting the resulting interruption, or whether a rapid, controlled replacement can be completed first. Consider observed misuse, privilege, public exposure and the consequences of interrupting the affected service. An unfamiliar production dependency calls for urgent escalation, not an unrecorded delay.

For a replacement-first decision, write down the exact consumers being changed, the person authorizing the overlap and the condition that ends it. Keep that interval as short as the approved response permits. Do not turn “we are still finding dependencies” into an indefinite exception that leaves a compromised credential active.

The containment record should say what changed at the provider and when. Updating a vault entry or application setting describes a consumer change; it does not prove the issuing service invalidated the old credential. Confirm the provider’s actual state through its supported management process.

Do not assume an automated notification also completed containment. Assign someone to verify disposition even when a platform reports that it has detected or handled a leak. If your team lacks the necessary access, contact the credential owner or provider through the established incident route.

Check the access that outlives the original key

Ask three separate questions: Can the original credential still authorize a request? Could it already have produced another usable token or session? Can an unauthorized identity still obtain fresh access? A single “key rotated” checkbox leaves the second and third questions unanswered.

Provider behavior matters. Google Cloud’s compromised-credentials guide treats service-account key files and already-issued service-account access tokens separately. Removing the key is not the complete response to a copied service-account token. The documented blocking options can also interrupt legitimate workloads, so the responsible cloud administrator needs to apply the procedure for the actual credential type.

AWS’s IAM role-session revocation documentation describes denying permissions to sessions issued before a cutoff. It warns about the impact on legitimate sessions and explains that later role assumptions are outside that cutoff. Different procedures apply to some role types. Revoking older sessions therefore needs to be considered alongside the route that permits new sessions.

These examples explain why a generic revoke command is unsuitable for a cross-provider checklist. Record the relevant credential, token or role types; the administrator’s selected controls; their scope; and any remaining access that needs investigation. If the team cannot establish the effect of a change, keep that uncertainty open and obtain specialist help.

Reconcile every consumer before calling recovery complete

Give each known consumer its own row. An application, background worker, scheduled export and external integration may have different owners and deployment paths even when they shared one credential. A successful website request cannot stand in for all of them.

The following is an original recovery worksheet. Keep secret values in the approved credential store; this table records references and observations.

Check the running workload, not just the proposed configuration. Ask how it loads credentials and whether the saved change has reached the instance, job or integration that actually performs the work. Have its owner exercise an appropriate operation or identify precisely why that cannot yet be done.

For infrequent tasks, choose between an authorized controlled run and a clearly recorded pending check. Do not silently mark a monthly job recovered because it did not produce an error during today’s observation period. The final recovery statement needs to distinguish verified consumers from those still awaiting evidence.

Use a provider-supported status check and, where appropriate and authorized, a narrowly scoped verification of the old credential’s rejection. Avoid sending it to an unrelated online validator or exposing it through a command argument or debug log. A network failure, wrong endpoint or unrelated permission error does not demonstrate the intended containment control.

Record the expected result, observed result, target, time, tester and supporting event reference. Confirm that the replacement performs the required task with the intended scope. Do not broaden its permissions simply to make a recovery test pass without reviewing the actual requirement.

Investigate misuse and record what you cannot see

Containment limits further access; investigation asks what happened before and around it. Have the technical lead review the relevant provider, application and repository records for the credential’s permissions and exposure window. Protect evidence before normal retention or cleanup removes it.

GitLab’s incident-response guidance recommends documenting exposure and revocation times and reviewing relevant activity. It identifies possible persistence through new users, tokens or keys, as well as suspicious pipeline and settings changes. Its CI guidance also points to external provider logs when third-party credentials are exposed through a pipeline.

Build an investigation question list around what this identity could do. Which resources could it read or change? Could it create another identity, alter a deployment or modify an integration? Which records would show those actions? Assign each question to someone with access to the relevant evidence, and separate confirmed observations from working explanations.

A useful finding states its limits. “No suspicious activity identified in the available application records for this interval” is narrower than “the key was never used.” Document missing logs, unavailable event types, retention gaps and uncertainty about the exposure start. Those limits affect the incident lead’s next decisions.

Use the security logging and alerting guide when evidence is missing between the originating system and the responder. Restoring collection now can improve future visibility; it cannot recreate events that were never retained. Bring sensitive-data and notification questions to the appropriate legal or incident specialists rather than drawing a legal conclusion from a quiet dashboard.

Clean the exposure after containing access

Remove the unsafe secret handling from the affected source, configuration, job output or artifact. Coordinate that work with evidence preservation. A hurried cleanup should not destroy the only record investigators need to understand the event.

For Git repositories, GitHub’s sensitive-data removal guidance explains that history rewriting can change commit references, disrupt collaborators and leave copies in other clones or forks. Decide with maintainers whether that work is warranted and how to carry it out. A force push does not establish that every historical copy disappeared.

Consider the exposure mechanism beyond the current file. If a build process printed the value, identify the relevant logs and artifacts under the organization’s access and retention procedures. If a workstation or runner may still be compromised, have the technical lead address that environment before trusting it with a replacement.

GitLab cautions that masked CI variables can still reach artifacts or remote systems. Masking is therefore one protection to review, not evidence that a replacement cannot leak. Check the actual command, error handler or export that caused the disclosure instead of merely hiding its most obvious output.

Work through a fictional three-consumer incident

Imagine a retailer discovers that a production integration credential appeared in a public build log. It serves a checkout integration, a queue worker and a scheduled shipping export. These details are invented to illustrate decisions, not a completed customer response.

The incident lead records the provider’s credential identifier and the log reference in a restricted ticket. The value itself is not copied into the team chat. The service owner and provider administrator assess the exposure and choose immediate invalidation under the company’s response plan, accepting a temporary interruption while recovery proceeds.

The checkout owner deploys the replacement and completes a controlled test transaction under the approved test arrangements. That verifies one consumer. The worker owner checks the relevant processing operation separately, including whether work accumulated during the interruption. Neither owner signs for the shipping export, which follows a different configuration path.

The export’s usual operator is unavailable. Rather than inventing a successful result, the incident lead assigns a deputy to review its credential reference and arrange an authorized test. Until that evidence arrives, the record says two consumers verified and one pending. The amber item in the consumer diagram represents that kind of unresolved work.

Meanwhile, the cloud administrator determines whether this particular identity could issue additional access and records the applicable session controls. The investigator reviews available activity and notes that part of the earlier exposure interval lacks the required telemetry. Service recovery can progress while the scope investigation remains open; the completion record must make both states visible.

The value of the worksheet is that these statements cannot collapse into “IT rotated the key.” Each has a different owner, observation and unfinished question. When the deputy supplies the final consumer result, that closes the recovery gap without erasing the investigation’s evidence limitation.

Close against evidence, then fix the cause

NIST SP 800-61 Revision 3 calls for protecting incident records and evidence, investigating scope and persistence, and confirming restored operations with system owners. Apply those principles to this credential’s record rather than treating the provider’s rotation timestamp as the whole incident.

Before declaring the response complete, have the responsible reviewers address four outcomes:

1. Access contained: the exposed credential’s state is established, relevant derived access is addressed, and unauthorized routes to new access have been assessed.
2. Consumers accepted: owners have verified required work under the replacement; any exception has an explicit decision and follow-up.
3. Scope documented: investigation findings, evidence locations and visibility limits are recorded, with specialist questions handed off.
4. Cause addressed: the disclosure mechanism has a corrective action, an owner and a way to check the saved change.

Separate recovery rollback from credential reuse. If the replacement deployment fails, the response plan needs an authorized recovery option that does not quietly restore a known exposed credential. Keep the incident lead involved when availability pressure changes the original decision.

After containment, consider a longer-term identity change where the service supports it. The GitHub Actions OIDC migration guide addresses one planned path for reducing stored cloud deployment credentials. That architectural work deserves its own change process and verification; it should not delay today’s containment.

Method and limits: This is a documentation-led synthesis of official GitHub, Google Cloud, AWS and GitLab guidance, OWASP recommendations and selected NIST sections. Provider examples explain different access behavior; they are not interchangeable instructions. No actual credential, tenant, pipeline or recovery procedure was tested, and the example is fictional.

Start with the incident card and one known consumer. Establish who can contain the access, what the provider now reports and which observation will demonstrate recovery. Expand that record until every relevant consumer and remaining access path has a documented disposition.