Guide / incident response

A coding agent leaked an API key to GitHub. Do this first.

Revoke or rotate the credential before cleaning Git history, then audit use, update every legitimate consumer, and close the path that allowed plaintext into the repository.

01

Short answer

Revoke or rotate the exposed credential first. Deleting the line, closing the pull request, making the repository private, or rewriting Git history does not make the old value safe. Assume anyone with access to the commit, a fork, a clone, a cache, or a notification could have copied it.

After the provider confirms the old credential no longer works, identify every legitimate workload that used it, replace those references, review provider and repository audit logs, and decide whether history rewriting is worth its coordination cost.

  • The provider reports the old credential as revoked, disabled, or replaced.
  • Production, CI, local development, and integrations use the replacement credential.
  • Usage since the first exposed commit has been reviewed for unexpected activity.
  • The agent workflow no longer has a path that writes raw values into repository files.
02

Action plan

  1. 01

    Contain the credential

    Revoke, disable, or rotate it in the issuing provider. If the key controls rotation itself, escalate through that provider's incident process.

  2. 02

    Find the exposure window

    Record the first commit, branch, pull request, logs, forks, and time range in which the value was accessible.

  3. 03

    Audit use

    Review provider activity, billing, IP addresses, repository audit events, and affected application logs for actions outside the expected pattern.

  4. 04

    Replace legitimate consumers

    Update CI, deployments, developer environments, and integrations with a new, narrower credential. Confirm each consumer before removing temporary compatibility.

  5. 05

    Clean history and prevent recurrence

    Follow GitHub's coordinated history-removal guidance if necessary, then enable push protection and change the agent's credential path.

03

What to know

Why rotation comes before deletion

Git is designed to preserve content. A secret removed from the current branch can remain in earlier commits, local clones, forks, pull request references, or caches. History rewriting changes commit identifiers and requires coordination, but it still cannot erase copies outside your control.

Provider-side revocation changes the security fact that matters: whether the exposed string still authorizes access. GitHub's own removal guidance therefore says to revoke or rotate a secret before considering history cleanup.

Treat the agent as one source, not the whole cause

The immediate event may be agent-generated code, but the system allowed a reusable credential to enter a writable or readable path. Look for raw keys in prompts, MCP results, shell output, copied dashboard values, generated configuration, test fixtures, and logs.

Fix the narrowest root cause that blocks the class of incident. A lint rule helps with recognizable patterns. Push protection can stop supported secrets at push time. A vault or broker can keep the value out of the file-generation path entirely.

What to document

Write down when the key was created, first exposed, revoked, and replaced. Record the permissions it held and what systems were reachable. Preserve non-secret evidence needed for an investigation without copying the key into the incident document.

  • Provider credential identifier and scope, never the full value.
  • Repositories, branches, pull requests, forks, and build logs involved.
  • Expected consumers and the time each received the replacement.
  • Suspicious use, billing changes, or access from unknown networks.
04

Where Trusty Squire fits

Trusty Squire can reduce a repeat when the leaked credential originates in a website setup flow. The agent can ask Trusty Squire to capture the generated value directly into its vault instead of copying it through chat or a generated file.

If a scoped Trusty Squire app grant leaks, that grant can be revoked without immediately rotating the underlying provider key. A leaked provider key still requires provider-side revocation or rotation.

Limits to keep in view
  • Trusty Squire cannot invalidate a third-party provider key unless that provider operation is available and authorized.
  • Repository cleanup remains a GitHub and Git coordination task.
  • Secret scanning does not recognize every credential format and should not be the only preventive control.

Install Trusty Squire when the missing piece is the website work or a credential boundary for your coding agent.

Frequently asked questions

Is deleting the GitHub commit enough after an API key leak?
No. Copies may remain in Git history, clones, forks, pull request references, caches, or notifications. Revoke or rotate the credential at the provider first so the exposed value no longer grants access.
Should I make the repository private before rotating the key?
You can restrict further viewing immediately, but do not delay revocation or rotation. Anyone who already saw or copied the key can keep using it until the provider rejects it.
Do I always need to rewrite Git history?
Not always. Once the secret is revoked, history rewriting may add coordination cost without reducing active credential risk. Use GitHub's guidance to weigh forks, cached views, compliance needs, and the disruption of changed commit hashes.
How do I stop a coding agent from leaking the next key?
Keep raw values out of prompts and file-writing tools, use a vault or broker with non-reading operations, enable GitHub push protection, and test whether logs, screenshots, and shell commands can still disclose the value.
05

Primary sources

Official documentation used for the factual claims on this page.

06
Keep the replacement key out of contextBuild a boundary that gives the agent an operation instead of plaintext.Store keys for agent workflowsChoose a storage and delivery pattern after containment.Use a revocable app grantKeep the provider credential out of the consuming application.