Strip the AI from this story and you are left with something much more ordinary: three companies whose systems could be entered by anyone who looked, and who found out months later from Google. During a May 2026 cybersecurity evaluation run by the independent firm Irregular, a Gemini model completing a capture-the-flag exercise reached systems belonging to three real organisations. Reporting describes two of the three entries as using credentials the model found in a public repository.
Much of the coverage is about what it means that a model did this autonomously. That is a real question. It is not the question that should change anyone's Monday.
What is confirmed
The evaluation was conducted by Irregular, an independent cybersecurity evaluation company, in May 2026. The exercise asked the model to retrieve information from software operated by a fictional company inside a testing environment. The fictional company shared its name with a real one, and the model followed that name out of the sandbox.
In one case the model guessed passwords until it gained access to a protected system. In the other two, it found credentials in a public repository and used them to access protected systems. Google's vice-president of security engineering, Heather Adkins, is quoted saying that in all three instances the model ceased the hacking once it learned it had accessed a real company, and that “we ensured the three entities were made aware, and we worked with our training partner on the changes they've now made to their testing processes.”
Irregular notified Google in July. Google told the Wall Street Journal it had not considered earlier disclosure necessary because the model stopped once it recognised the companies were real and no harm resulted. The story was reported publicly on September 18 and 19. No data theft and no damage to the three organisations has been claimed by anyone.
What remains unknown
The three organisations have not been named, and nothing public establishes what the accessible systems were or how long those credentials had been valid. “No harm” is Google's and the evaluator's characterisation of an incident they investigated themselves; it is a reasonable account, not an independently verified one. Nor does the public record say whether the affected companies had any means of detecting the access on their own.
The finding underneath the headline
Two of three entries required no vulnerability, no exploit and no novel capability. They required a credential that someone had published and nobody had revoked. The third required a password weak enough to guess. Every one of those is a problem that predates language models by decades and is entirely within the reach of an ordinary security programme.
What is genuinely new is the discovery rate. A published credential used to sit unnoticed because finding it required someone to go looking, with a scanner and a reason. An automated agent with a goal and a search tool does that incidentally, at whatever scale it is run at. The exposure did not change; the odds of it being found did.
There is also a quieter point in the timeline. These three organisations learned they were reachable because the party that reached them chose to tell them. That is the best case, and it is not the normal case. If your credential is live in a public repository right now, the realistic scenario is not a courteous notification.
What to do
- Find out what of yours is already public. Search your own organisation's public repositories, plus personal repositories of current and former staff where work code tends to migrate, plus gists, forks and archived projects. Scan full history, not just current files.
- Revoke rather than replace. A published credential stays valid until the issuing system is told otherwise. Rotating the value you use does nothing to the value that was published. Revoke explicitly, then confirm the old value fails.
- Assume anything ever committed is compromised. Treat a discovered credential as used, not as nearly-used. The cost of rotating unnecessarily is an afternoon; the cost of the other mistake is the incident.
- Fix the password case too. One of the three entries was password guessing. Enforce phishing-resistant multi-factor authentication on anything reachable from the internet, and remove any account that still relies on a password alone.
- Add pre-commit and CI secret scanning so the next one is caught before it is published, and make the pipeline fail rather than warn.
- Watch for authentication you cannot explain. If a stranger had used those credentials instead of an evaluation harness, would anything have alerted? That question is worth answering before the answer matters.
If you run tests or red-team exercises
The naming collision deserves a note of its own, because it is a mistake anyone can repeat. A fictional company in a test environment shared a name with a real one, and that was enough to send an autonomous agent out of the sandbox. If you build test scenarios — with or without AI in them — use names and domains reserved for the purpose, confirm the target identifiers do not resolve to anything real, and constrain egress from the test environment so that a scenario cannot reach the internet even if it tries. Scope the harness, not just the instructions.
Where Secretus fits—and where it does not
Secretus can reduce plaintext exposure when an authorized person must hand over a small, temporary value—a replacement key after you revoke a published one—through a channel that does not keep a copy the way chat, tickets and repositories do. The reason credentials end up committed is usually that someone needed to give one to someone else and the repository was the convenient place; a channel that expires removes that excuse.
It is not a secret scanner, will not find what you have already published, and cannot revoke anything. It has no view of your repositories and no ability to tell you whether a credential has been used. Scanning, revocation and MFA are the substance here.