API key callbacks: the leaked-key alarm you should wire up

Most API key leaks are discovered by whoever reads the bill, not by whoever owns the key. The timeline is usually the same: a key ends up in a public repository, a log file, or a prompt that a model pasted into a shared thread. Nobody notices. Then, weeks later, a charge shows up on a statement for compute nobody ran, or an email arrives saying a token was found “in the wild.” The key is not the problem — the delay is. A key leaked on day one and revoked on day twenty-one is not an incident; it is three weeks of someone else spending your quota and reading your data.

Rotation only works when an alarm fires first. That alarm is the callbacks.

What a key callback is

A callback, in leak-detection terms, is a mechanism that tells you a key was exposed without you looking for it. Two directions exist.

Scanner-side: you get called. GitHub’s secret scanning watches repositories for supported key patterns — on by default for public repositories — and raises alerts that committers and admins can see. Register the secret_scanning_alert webhook on your organization and every new finding is POSTed to an endpoint you control instead of sitting in a UI tab. That endpoint is your alarm: it can page the right person, open an issue, or drop a message into the same channel your CI uses. Push protection goes one step further: for most provider patterns it blocks the push outright, so the commit never lands and no callback is needed.

Provider-side: they get called, then they call you. This is the direction most people never think about. GitHub runs a partner program: when its scanners match a supported provider’s secret format in a public repository, it sends the finding directly to that provider’s endpoint. The provider validates the string against its own records, then revokes the secret, issues a new one, or contacts you directly. Your key was found by a scanner you do not run, and the alarm reached you through an account email you actually read — as long as the key was issued to a reachable account and the provider knows who holds it.

What to wire up

Three things, in order of effort:

1. Turn on push protection for your repositories and treat bypasses as incidents. A bypass is a leak in progress, not a workflow convenience.
2. Register a secret_scanning_alert webhook (organization level) and route it somewhere a human sees within minutes — not the security tab nobody opens.
3. Run your own scanner (gitleaks and its relatives) in CI and on a schedule, with findings to the same channel. Provider scanning covers public code; your scanner covers the private repositories, gists, and log dumps they cannot see.

The mix matters: provider callbacks catch the key that left your organization, your own scanner catches the one that never left.

When the alarm fires

Revoke first, investigate second. The impulse is to find the exposure scope before touching the key; that is backwards — every minute the key stays valid, the attacker keeps using it. Revoke, then rotate, then check the audit trail: which services held the key, what they called, and what came back. If an AI agent ever touched it, assume the value also ended up in a session store and sweep those files, not just the repository.

Prevention makes callbacks rare, but they still need to exist. The fewer places a key lives, the less often you need the alarm — trustless is a single-binary credential broker for AI agents that keeps keys out of agent contexts and redacts them from tool output, so they never reach the places that trigger callbacks in the first place.

When a leaked key finally reached you — a bill, an email, a scanner alert — how long had it been exposed before you knew?