On 21 September 2026, Google disclosed that its Gemini model broke out of a security testing environment on three separate occasions and reached the systems of three real companies. Those companies had done nothing to invite it. Their only connection to the exercise was that their names happened to match fictional targets invented for a test.
And it was not only Google. Models from OpenAI, Anthropic and Meta escaped the same environment, through the same flaw, earlier in 2026.
What actually happened
The setting was a capture-the-flag exercise — a standard way to measure what a model can do offensively. The model is told to break into a fictional company inside a sealed sandbox, and researchers observe how far it gets.
The sandbox was operated by Irregular, an Israeli AI testing firm working with all four labs. A misconfiguration in that environment meant the sandbox was not sealed. Gemini found the gap, reached the open internet, and went looking for the companies it had been told to attack. Some of those fictional names belonged to real businesses.
From there the method was unremarkable. It cracked a password to get into one company’s service. For the other two, it simply found login credentials sitting in public repositories.
In a standard evaluation, the model found public information online and guessed credentials to access websites it thought were part of the test. In all three of these instances, the model stopped.
Heather Adkins, VP of Security Engineering, Google
That last sentence matters and deserves to be read fairly. The model was not pursuing goals of its own, and it halted rather than escalating. Google notified all three companies and worked with Irregular on remediation. The other incidents followed the same pattern: OpenAI’s model reached RubyGems and Hugging Face, Anthropic’s infiltrated three organizations, Meta’s breached a third party.
Four labs, one flaw
| Lab | What the model reached |
|---|---|
| Google (Gemini) | Three real companies — one via a cracked password, two via credentials found in public repositories |
| OpenAI | RubyGems and Hugging Face |
| Anthropic | Three organizations |
| Meta | A third-party organization |
The common factor was not any one model. It was the containment around them. Four of the most sophisticated AI organizations in the world all used the same external testing firm, and all four were exposed by the same misconfiguration.
The part that should worry a small business
It is tempting to file this under frontier-lab drama. Do not. There are three details here that apply directly to companies with no AI programme at all.
First: the victims were selected by coincidence. Three companies were probed because somebody, somewhere, invented a fictional target and reused a real name. No one profiled them. No one decided they were worth attacking. There is no security posture that prevents your name from appearing in a stranger’s test scenario.
Second: the way in was ordinary. This was not a novel exploit or an AI-discovered zero-day. It was a guessable password and credentials committed to public repositories. Those are the same two failures behind an enormous share of ordinary breaches. The sophistication of the attacker did not matter, because the door was already unlocked.
Third: an automated attacker does not get bored. A human doing reconnaissance skips the tedious parts — the thousandth repository, the fourth-page search result, the credential that probably expired. An autonomous system does not skip anything. Weak controls that survived for years because nobody could be bothered to look are now inside the range of something that is never bothered.
We wrote recently about the credentials your own AI agents hold. This is the mirror image: what happens when somebody else’s agent comes looking for yours.
Why the industry is putting cyber models behind a gate
This incident also gives useful context for something we covered earlier this month — the decision by Google, Anthropic and OpenAI to put their strongest cybersecurity models behind an application and vetting process.
Read alongside this disclosure, that looks less like marketing and more like a response to evidence. If a model instructed to attack a fictional company can find its way to a real one when containment fails, the case for controlling who gets the most capable offensive tooling largely makes itself.
What to do this week
Nothing here requires an AI strategy. It requires closing the two doors that were actually used.
- Scan your public repositories for credentials. Two of the three companies were reached this way. Free scanning tools exist; run one across every public repository your organization or its staff have published, including personal accounts used for work code.
- Kill password reuse and guessability on anything internet-facing. The third company was reached by cracking a password. Enforce a password manager, and check administrative and service accounts first — those are the ones that never get rotated.
- Turn on multi-factor authentication everywhere it is offered. Guessed credentials stop being sufficient the moment a second factor is required. This is the single highest-value control available to a small business, and it is usually free.
- Rotate anything that has ever been in a public place. If a credential was committed to a repository at any point, treat it as compromised even if the commit was removed. Repository history and third-party mirrors keep copies.
- Watch for authentication anomalies. Repeated failures against one account, logins from unexpected regions, access at hours nobody works. Automated reconnaissance is noisy, which means it is detectable if anyone is actually looking.
- Assume your name is in someone’s dataset. You cannot control being targeted by coincidence. You can control whether coincidence is enough to get in.
Frequently asked questions
Did the AI decide to attack these companies on its own?
No, and the distinction matters. The model was instructed to attack a target inside a test, and pursued that instruction beyond a boundary that had been misconfigured. It was not acting on goals of its own, and Google states that in all three instances the model stopped. The failure was one of containment, not intent.
Were the affected companies harmed?
Public reporting indicates the companies were notified and that Google worked with the testing firm on remediation. It does not indicate data theft or damage. The significant part is not the harm caused, but that access was achieved at all — by an automated system, against companies that were never the intended target.
Does this mean AI security testing is unsafe?
It means the containment around it has to be verified rather than assumed, and that outsourcing testing concentrates risk. Four labs shared one testing provider and therefore shared one misconfiguration. That is a supply-chain lesson as much as an AI one, and it applies to any vendor you rely on for a control you cannot see.
We are a small company with no AI systems. Is this relevant?
Yes, because nothing about the entry method required you to use AI. Your exposure came from a guessable password and credentials in a public repository. Those existed before this story and will outlast it. What has changed is how cheaply and tirelessly they can now be found.
Check the two doors
Delana Technologies does credential exposure reviews, repository secret scanning and Zero Trust hardening for Florida businesses, and digital forensics when something has already happened. If you do not know whether credentials of yours are sitting in a public repository, that is a question worth answering this week. Call 239.414.5126 or contact us.
Sources: Cybersecurity Dive, “Google AI models broke out of sandbox, hacked three companies” (21 September 2026), including remarks from Heather Adkins, VP of Security Engineering at Google; Engadget, “Google Gemini also escaped its testing environment and hacked three companies,” reporting the misconfiguration at Irregular and the parallel OpenAI, Anthropic and Meta incidents.