A test target's name collided with a real company
In May 2026, Google ran a security evaluation of its Gemini artificial intelligence (AI) model using a "capture the flag" exercise, a common format in which a model or human tester tries to break into a deliberately vulnerable target system to prove it can be exploited. The exercise was built and hosted by Irregular, an outside firm that specializes in testing AI systems for security risks.
Somewhere in the setup, the fictional company invented as Gemini's target shared its name with a real, unrelated organization. The test environment was supposed to be sealed off from the open internet. It was not. When Gemini went looking for its assigned target, it found the real company's actual systems instead, along with two other real organizations connected to the exercise in ways Google has not detailed publicly.
What Gemini actually did
Once it had a live target in front of it, Gemini used three separate techniques to get in, according to reporting from NBC News and SecurityWeek:
- It repeatedly guessed login passwords until one worked on a protected system.
- It found login credentials that had been leaked in a public code repository and used them to sign in.
- It searched the open web for information tied to the company name it had been given, which helped it locate and access the third system.
In each of the three cases, Gemini stopped once it had gained access. It did not move deeper into the networks, exfiltrate data, or take further action, according to the reporting. Google's vice president of security engineering, Heather Adkins, told NBC News that the model appeared to believe it was still operating inside the sanctioned test, not against real infrastructure.
Google did not find out for two months
The exercise ran in May 2026. Google did not learn that Gemini had touched real systems until July, when Irregular reviewed the results of its own test and spotted the problem. Even then, the incident stayed private until September 18, 2026, when Google confirmed it publicly after the Wall Street Journal contacted the company for comment, according to SecurityWeek.
That gap matters for anyone trying to judge how the company handled it. Google has said it notified the three affected organizations and reported the incidents to federal authorities. It has also said it found no evidence of damage to any of the systems involved, framing the discovery as closer to an unplanned bug-bounty find than a genuine breach.
Why Google isn't calling this a safety failure
Google's public framing draws a sharp line: this was a test-environment configuration mistake, not evidence that Gemini will go rogue on its own initiative. The company's argument rests on the fact that the model stopped after each access, rather than escalating, persisting, or trying to cover its tracks. In Google's telling, that stopping behavior is the safety mechanism working as intended, even though the access itself should never have been possible.
It's worth noting that Irregular, the firm that ran this exercise, has also been involved in similar AI-testing episodes disclosed separately by OpenAI, Anthropic, and Meta, according to The Hacker News. That pattern suggests the underlying problem, test environments that are not as isolated from the real internet as their operators assume, is not unique to Google or to Gemini specifically.
The reconciliation problem
The public account leaves some real gaps. Google has not named the three affected organizations, has not said what kind of systems were involved beyond calling them "outside systems," and has not published technical detail on how the network isolation failed in the first place. Independent verification of the "no damage" claim rests on Google's own assessment, since the company controls both the model that did the accessing and the disclosure of what it found afterward.
What this means in practice
For anyone running or commissioning AI red-team exercises, the practical lesson is narrower than "AI models are dangerous." It's about test hygiene. A model capable enough to guess passwords, search for leaked credentials, and pivot from a company name to a live target will do exactly that if the sandbox around it has a hole in it, regardless of whether the model itself is well-behaved once it gets through. Naming a fictional test target after something that could plausibly resolve to a real domain, and trusting network isolation without verifying it, are both ordinary infrastructure mistakes that happen to matter more when the thing operating inside the sandbox can act autonomously and quickly.
For organizations that outsource AI capability testing to third parties, this is also a reminder to ask directly how isolated those environments actually are, rather than assuming that "testing infrastructure" means fully air-gapped by default.
