A Deleted Key Is Still in Your Git History: What the Gemini Incident Means for Public Repos

In short, as of 22 September 2026: Google has confirmed that one of its Gemini models, during an outside security evaluation in May, got into systems at three real organizations that it wrongly believed were part of the test. In one case it guessed passwords. In the other two, it used credentials it found in a public code repository. Google says the model stopped each time once it had access, and that the three organizations were informed. The lesson for everyone else is not about AI. It is about keys left in public code, and especially the ones people believe they already deleted.

What happened

According to Google's statement, reported by NBC News, AFP and ABC News on 18 and 19 September 2026:

• ✓The evaluation was run in May 2026 by Irregular, an independent company that tests the cybersecurity capabilities of AI models. It was a capture-the-flag exercise: the model was asked to retrieve information from software run by a fictional company inside the test environment.
• ✓The model reached three real outside systems that it took to be part of the test. ABC News reports that in one case it guessed passwords until it got in, and in the other two it found credentials in a public repository.
• ✓Google learned of the intrusions in July, informed the organizations involved and, according to NBC News, federal authorities. It did not name the organizations.
• ✓Heather Adkins, Google's vice president of security engineering, said the model thought the outside systems were part of the test, and that it stopped before doing anything further with its access.

Why the repository part matters more than the AI part

An AI model reading public code is not doing anything new. Automated tools have searched public repositories for leaked keys for years, and they do not stop politely when they notice they are inside a real company. What this incident adds is a clear, confirmed example: a key sitting in a public repository was enough to get into a protected system, twice.

The trap: deleting the key does not remove it

The most common "fix" for a committed key is to delete it in the next commit. The file looks clean, a search of the current files finds nothing, and the problem feels solved. It is not. Git keeps every version of every file, so the key is still in the history, and anyone who clones the repository gets the history too.

We tested this on 22 September. In a throwaway repository we committed a fake AWS key, deleted it in the next commit, and confirmed the working tree was clean. A scan of the current files found nothing. A scan of the history found both lines, in the commit where they were added. It found them again when we scanned a bare mirror clone, which is how an automated job usually stores a repository.

What we found when we checked our own repositories

The same morning, we listed every repository on our GitHub account: 82 in total, 78 private, 4 public. The public four are the ones that matter for this kind of exposure.

GitHub's built-in secret scanning reported zero open alerts for three of them. For the fourth, an archived repository, the request did not return a list of alerts at all. That is not the same as zero. A script that simply counts whatever comes back can turn a failed request into any number, including a reassuring zero, so we treated it as unverified and scanned that repository's full history ourselves. The full scan of all four repositories with gitleaks, an open-source secret scanner, found nothing.

How to check your own repositories

gitleaks is free and runs locally. For a repository you have cloned, this scans every commit on every branch and hides the secret values in the output:

gitleaks detect --source . --log-opts=--all --redact

The command above is for gitleaks 8.16, the version Ubuntu 24.04 ships. Newer versions may name the subcommands differently, so check gitleaks --help if it complains.

Three things make the check worth trusting:

1. ✓Scan the history, not the files. A key that was ever pushed is in the history, whatever the current files say.
2. ✓Recognize three results, not two. Clean, leak found, and could not check. A clone that failed or a scanner that crashed must never be reported as clean.
3. ✓List your public repositories every time you check. A repository that is made public next month needs to be scanned next month, not only the ones that were public when the check was written.

We now run exactly this every night, on every public repository we have, with an alert only when something is found or when the check itself fails. We proved it catches a planted key before we relied on it.

If you find a key

Rotate it first, then clean the history. Once a key has been pushed to a public repository, assume someone has it. Revoke or rotate it with the provider, check the provider's logs for use you do not recognize, and only then rewrite the history to remove it. Cleaning the history without rotating the key leaves a working key in every copy that was cloned before you cleaned.

What we cannot tell you

We cannot tell you whether your repositories contain secrets, or whether any key of yours has been used. We have not scanned anyone else's code, and this article is not a security audit. It collects what the sources say and what we did on our own account, so you know what to check. The answer for your code lives in its full history.

Sources

NBC News, "Google says its AI model gained unauthorized access to three outside systems", September 2026: nbcnews.com. ABC News, "Gemini hacked three companies in first known breakout by Google's AI", 19 September 2026: abc.net.au. AFP via TechXplore, "Google's Gemini AI carried out cyberattacks, guessed passwords", September 2026: techxplore.com. The original report was published by The Wall Street Journal. All read on 22 September 2026. If you find a difference from the source, write to us and we will correct the article.