Every leaked key needs an owner, a clock, and a record

On 1 July, GitHub opened a public preview of credential monitoring across its entire public surface. Every public repository, pull request, issue and discussion on the platform is scanned, any credential found is attributed back to the enterprise it belongs to, and the report arrives in real time at no extra cost for customers who already hold Secret Protection. It is a serious piece of infrastructure, and it lands on a problem whose size is now well documented. GitGuardian counted 28.65 million new hardcoded secrets in public GitHub commits during 2025, a 34% rise in a single year, with credentials for AI services up 81%.

One figure in that report deserves more attention than it has had. Credentials confirmed valid in 2022 were retested in January 2026, and 64% of them still worked. Four years on, roughly two thirds of known-leaked keys were still live. That gap sits entirely on the response side of the problem. Someone has to own the key, decide to revoke it, revoke it, and be able to show the sequence afterwards.

On most teams those four steps belong to four different people. The alert lands in a security channel, the key belongs to a service team, the revocation happens in a cloud console, and the evidence ends up spread across three tools and a thread. Every handoff costs hours, and the hours are what an attacker has to work with.

The same report found that commits written with an AI coding assistant leaked secrets at 3.2%, against a 1.5% baseline across all public commits, and that 24,008 unique secrets were sitting in Model Context Protocol configuration files. Agent tooling multiplies the places a credential can be written down. It also raises the value of a response loop that runs without one person waiting on another.

That loop is the shape of problem this platform was built for. A leaked-credential alert is an event like any other: point your repository host at a data feed, and the alert arrives naming the thing it concerns. A rule pack labels it, and a rule decides what happens — turn off the access, open a ticket, call your own system, or hold the action for a person when the credential is one somebody should sign off on. The action fires in seconds, and every step of it is written to the logbook.

One detail matters more than the speed. The record does not close when the platform dispatches the revocation. It closes when your system confirms the key is dead, carrying your own ticket or change number. If that confirmation never arrives, the record says so. Months later, it answers the question anyone will actually ask about a leaked key: when did it stop working, and who made it stop.