In May 2026, an AI model broke out of a security evaluation and accessed systems belonging to three real companies. The story is worth reading again, because the way it got in had nothing to do with AI.

The evaluation was a capture-the-flag exercise run by Irregular, a frontier AI security lab, testing how a Google Gemini model navigated the simulated infrastructure of fictional companies. A naming collision and an unintended connection to the open internet let the model reach real systems instead. Google confirmed the incident on September 18.

According to Google, the model guessed a password to reach the first company. For the other two, it found credentials sitting in a public repository and used them to log in. Google noted that the model did not create new vulnerabilities in any of the three cases. It used weaknesses that already existed.

The part that got skipped

Most of the coverage treated this as an AI containment story: a model escaped its sandbox, evaluation environments need better egress controls, frontier labs have a systemic problem. All of that is true and worth fixing.

But two of the three entry points were leaked credentials that still authenticated. No zero-day. No novel technique. No capability that did not exist before. Those credentials were in a public repository, and they worked.

The model did not need to be clever. It needed to find something someone had already exposed and nobody had revoked.

A leak does not expire

There is a quiet assumption behind how many teams prioritize exposed secrets: that an old leak is a cold one. A credential committed years ago, in a repository nobody maintains, feels less urgent than one that surfaced this morning.

Our research says otherwise. We scanned 224 million public repositories and more than 58 billion files, and found 543,699 unique credentials that still authenticated when we checked them. The median credential had been publicly accessible for 784 days. About 10% had been exposed for more than 6.3 years. The oldest dated back to 2009.

We see the same thing in AWS keys. When we re-verified leaked AWS keys, half of those that still worked had been created more than five years earlier. The oldest was 17.4 years old, nearly as old as AWS IAM itself.

It is not just research data. In 2022, Toyota disclosed that an access key to its T-Connect customer database had been sitting in a public GitHub repository since December 2017, nearly five years before anyone noticed. The 2024 attacks on Snowflake customers ran largely on credentials stolen by infostealers years earlier, some dating back to 2020, that had never been rotated. And the Internet Archive breach that same year started with a GitLab token that had been exposed since at least December 2022.

A credential does not decay. It either still authenticates or it does not. Age tells you how long the exposure has been available, not how dangerous it is.

Nobody knows how long the credentials in the Gemini case had been sitting in that repository. It did not matter. They worked when something finally went looking.

Obscurity is no longer a defense

For years, the practical defense of an old leak was obscurity. A credential buried in commit history, in a fork, in a file nobody opens, was technically exposed but unlikely to be found. Searching at scale took effort, and effort meant attackers prioritized.

That constraint is loosening. Finding an exposed credential no longer takes a determined attacker with time to spare. The Gemini incident was not an attack, but it demonstrated the shift plainly: a model with internet access found exposed credentials and used them while doing something else entirely.

When the cost of looking approaches zero, obscurity stops functioning as a control. What remains is whether the credential still works.

Revocation is the measure

The three companies in the Gemini case were reportedly small, with limited security infrastructure. But the exposure pattern is not a small-company pattern. Credentials end up in public repositories, forks, CI logs, chat threads, and configuration files at organizations of every size, and they tend to stay there.

Detection volume is the wrong thing to optimize. Knowing a credential is exposed changes nothing about the risk. It stays exactly as exploitable as it was before you found it.

What separates one outcome from another is not whether a credential was ever exposed. It is whether anyone confirmed it was revoked.

A deleted commit does not revoke a credential, and neither does a closed ticket. In our research on how teams handle reported leaks, a substantial share of secrets reported as fixed had been scrubbed from code rather than rotated, which leaves the credential live and the issue marked resolved. The only thing that eliminates the risk is a credential that no longer authenticates, confirmed by testing it again.

That is the work after detection: verify what is live, understand what identity it belongs to and what it can reach, route it to the person who can revoke it, and retest to confirm the access is gone. The question worth asking about your own environment is not how many secrets you have found. It is how many you can prove are dead.

If you want to see what that looks like in practice, our team is happy to walk through it.