How fast are leaked API keys found?

The short answer: minutes#

Several security teams have tested this directly by planting working but harmless credentials in public repositories and watching what happens. The credentials are wired up so that any use is logged, which turns "how fast" into a measured number rather than a guess. The results line up closely, and they are measured in minutes.

Figures from published honeypot experiments run between 2017 and 2023; sources listed at the end.

The spread is easy to explain. Comparitech recorded abuse of an exposed AWS key inside a minute. Orca Security's 2023 cloud honeypot study saw a key on GitHub used within two minutes, and found exposed secrets on GitHub discovered in under five. One developer's canary-token experiment recorded an automated alert at seven minutes and the first unauthorized use at eleven, followed by repeat use from several countries within hours. In a 2018 experiment, Project Spacecrab found that 82 percent of keys posted to a code-hosting service were used, almost all of them picked up about thirty minutes after posting.

However you average it, the conclusion is the same. On public GitHub, discovery and first use cluster in the low single digits of minutes. The threat is not a person browsing code; it is an automated script that is already watching and reacts within minutes, faster than you can.

This is not only historical. In February 2026, Cyble found ChatGPT API keys leaking across more than 5,000 public repositories and roughly 3,000 live sites, with automated scanners narrowing the window between exposure and abuse to hours or minutes.⁵

How do bots find leaked keys so quickly?#

GitHub publishes a live feed of every change pushed to any public repository, and anyone can read it. Attackers run programs that watch this feed without stopping, grab each new change, and test any string that looks like a credential against the matching service. The requests come from many different internet addresses using ordinary software tools, so a single program can try a key from dozens of addresses in seconds.

There is one small built-in buffer: the feed is delayed by roughly five minutes, which is why some experiments record first use at six or eleven minutes rather than instantly. That delay is the only margin you have before the scanners see the key.

The same feed is watched by the other side. GitHub itself looks for keys in known formats and warns the service they belong to, and some services act on their own: AWS, for example, can automatically invalidate a key it spots in a public repository. Companies like GitGuardian watch the feed too and send an alert within minutes. So sometimes the service rescues you before an attacker gets there. But that is luck, not a plan, and it does nothing for the kinds of keys nobody is watching for.

This is also why deleting the file and pushing again does not help. By the time you notice and react, the original commit has already gone out on the feed and been grabbed. Removing it from the latest version does not call back the copies the bots already took.

Are private repositories safer?#

Yes, for this specific risk. A private repository is not on the public feed, so these bots are not scanning it. In one experiment that committed a key to a private repository on a different service, the key remained unused for a week. The minutes-long window is a public-repository problem.

Safer is not safe, though. The key is still present in your history in plain text, where every current and future collaborator can read it. Private repositories get copied to laptops and build systems, exposed in data breaches, made public by accident, or read by someone who should not have access. Any of those turns a private leak into a public one, and the key stays valid the whole time. The right move is the same, with less time pressure: treat any committed secret as exposed and replace it.

Should you replace the key or rewrite history first?#

You do not have time to fix this by editing your git history. Rewriting it and overwriting the copy on GitHub takes longer than a bot needs, and it cannot reach copies that already left your repository. Invalidating the key is the one action that makes the exposure harmless no matter who already has a copy, because an invalidated key grants no access to anyone.

So the order is fixed: replace the key first, then optionally rewrite the history. If you have just committed a key and want the full sequence, see our step-by-step guide to what to do.

How do you prevent the leak in the first place?#

The only reliable defense is to never push the key in the first place, so it never reaches the feed. Keep credentials out of the code, in the environment your program reads when it starts or in a separate tool built to store secrets, and add a check that runs on every commit and blocks it if a secret is present. A blocked commit never becomes a push, and a key that is never pushed is never exposed. With Trestle:

From then on, the key that would have started a minutes-long scramble never leaves your machine.

Frequently asked questions#

How fast are leaked API keys found on GitHub?#

On a public repository, usually within minutes, and often within a single minute. Automated bots watch GitHub's public events feed continuously, so discovery can be nearly immediate.

How do bots find leaked keys so quickly?#

GitHub publishes a public feed of every change pushed to a public repository, delayed by only about five minutes. Bots read that feed continuously and test any new string that looks like a credential against the service it belongs to.

Are private repositories safer?#

For this specific risk, yes: a private repository is not on the public feed, so the minutes-to-discovery problem does not apply. It is not safe, though, because the key can still leak through a later visibility change, a fork, a breach, or a collaborator's machine.

Should you replace the key or rewrite Git history first?#

Replace the key first. The moment it was pushed to a public repository, treat it as compromised. Rewriting history afterward does not undo a leak the bots may already have caught.

How do you stop API keys from leaking in the first place?#

Use a check that scans every commit and blocks it before a secret reaches GitHub. A key that is never pushed never reaches the feed, so it is never exposed to the scanners.

Sources#

1. Comparitech, GitHub honeypot experiment
2. Orca Security, 2023 Honeypotting in the Cloud Report
3. Canary-token experiment write-up (dev.to)
4. Bourke and Grzelak, Project Spacecrab, Black Hat Asia 2018
5. Cyble, The Rising Risk of Exposed ChatGPT API Keys, February 2026