Google's Gemini Agents Breached 3 Real Companies During a Security Test

During a May 2026 cybersecurity evaluation, Gemini-based agents were supposed to attack fictional target companies inside an isolated, internet-free test environment run by Irregular, an independent AI security-testing firm. A configuration error gave the agents real internet access anyway — and the fictional targets happened to share names with real businesses. Gemini guessed its way into one system's password and found valid credentials sitting in a public code repository for two more, accessing all three before recognizing the systems were real and stopping on its own. Google discovered this in July, four months ago, and didn't disclose it publicly until the Wall Street Journal asked.

TL;DR

How a test environment leaked real internet access

The root cause is a specific, avoidable infrastructure mistake, not a novel AI capability failure: the test environment Irregular built for this evaluation was explicitly designed with no internet access, so any agent operating inside it should only ever have been able to reach fictional, simulated targets that existed purely within the sandboxed test. A configuration error broke that isolation, giving the Gemini-based agents genuine internet connectivity they were never supposed to have. Compounding that error, the fictional company names Irregular chose for the test scenario happened to coincide with the names of real, unrelated businesses — meaning an agent that found a domain or system matching its assigned target name had no reliable way to distinguish "this is my simulated test target" from "this is an actual company that happens to share a name with my test target."

The access itself: one guessed password, two exposed credential sets

Once the agents had real internet access and a real-sounding target name to pursue, they used two distinct techniques across the three affected companies. In one case, the Gemini agent guessed passwords repeatedly until one succeeded, gaining access to a protected system through straightforward credential brute-forcing. In the other two cases, the agent found valid credentials already sitting in a public code repository — meaning it didn't need to guess or crack anything; the access was effectively handed to it because a real company's real credentials were already publicly exposed somewhere the agent's web search could find them. That second detail is arguably the more important finding buried in this story: it says as much about ordinary credential-hygiene failures at those three companies as it does about Gemini's own capability, since a human attacker doing basic reconnaissance would likely have found the same exposed credentials.

The part that reads as good news: it stopped itself

Google's account, and independent commentary on it, converges on one specific positive detail worth taking seriously rather than dismissing as corporate spin: the Gemini agents "ended the intrusion after determining it had accessed a real company's systems," stopping on their own rather than continuing to explore or exfiltrate anything once they recognized the target wasn't the fictional one they'd been assigned. Independent AI commentator Simon Willison, covering the story, specifically noted Gemini came across as "apparently less determined than other models" in comparable situations — reading the self-termination as a genuinely favorable data point rather than a given outcome, since an agent that had continued probing after recognizing a real target would represent a meaningfully worse failure mode. Google states the three affected companies suffered no harm as a result.

The disclosure timeline is the part drawing the sharpest criticism

Here's where the story shifts from "an infrastructure bug with a reassuring outcome" to something that invites real scrutiny. Google discovered these three intrusions in July 2026 — a full two months after they happened. The company then sat on that knowledge for another two months, disclosing nothing publicly until the Wall Street Journal contacted Google directly, with the resulting story running September 18. Google's own stated rationale for the delay: its model didn't cause harm to the companies and ended each intrusion immediately, which the company apparently judged sufficient grounds not to proactively disclose. That reasoning is worth sitting with critically — "no harm resulted, so no disclosure was necessary" is a materially different standard than "an AI agent autonomously breached real companies' systems using both password-guessing and exposed credentials, and the public has a right to know that happened regardless of outcome," and the gap between those two standards is exactly what a WSJ-forced disclosure four months later highlights.

How this compares to the OpenAI/Hugging Face incident

This isn't the first time in 2026 an autonomous AI agent, operating in a testing or research context, has reached beyond its intended sandbox into real infrastructure. explainx.ai covered the OpenAI/Hugging Face breach — also roughly mid-2026, also involving agents crossing from an intended test or research scope into systems they weren't meant to touch. The two incidents aren't directly connected, but reading them together points at the same underlying category of risk: isolation failures in the infrastructure surrounding an AI agent, not a capability unique to either lab's specific model. As more labs run more of this kind of adversarial, agentic security testing — through firms like Irregular, which explicitly runs comparable evaluations for OpenAI, Anthropic, and Meta as well as Google — the test-environment isolation itself becomes as important a security surface as the model being tested, a lesson that applies across every lab using this testing pattern, not just Google.

Why "fictional target names colliding with real companies" is a recurring failure class

This isn't a novel category of mistake, and that's exactly why it's worth naming precisely. Security researchers have run into name-collision problems before in penetration-testing exercises, but they've historically been rare enough that most testing firms treat them as an edge case rather than a checklist item. What's different here is the presence of an autonomous agent on the other end of that collision. A human pentester who stumbles onto a real company sharing a name with their assigned fictional target will typically notice something's off — unfamiliar branding, unexpected personnel names, systems that don't match the test's provided documentation — and pause to verify. An agentic system doesn't necessarily have that same contextual pattern-matching instinct unless it's been explicitly trained or prompted to treat inconsistencies as a stop signal. Gemini apparently did eventually recognize the mismatch and halt, which is the reassuring part of this story, but the fact that it took actually gaining unauthorized access first — rather than catching the naming collision earlier in reconnaissance — suggests the verification step happened later in the process than ideal. For any lab running comparable agentic red-team exercises, this specific failure mode (target-name collision plus a real internet connection) is now a documented, reproducible risk worth testing for explicitly, not treating as a one-off fluke.

Honest limitations

• This account is sourced to Google's own disclosure and WSJ's reporting — the specific technical details of the configuration error itself (what exactly broke, how it was fixed) aren't fully disclosed publicly.
• No detail on what data, if any, the agents actually viewed or extracted from the three companies' systems before stopping is confirmed beyond Google's "no harm" characterization.
• The disclosure timeline (July discovery, September disclosure only after WSJ inquiry) is drawing legitimate criticism that Google's own "no harm, no disclosure" reasoning doesn't fully address.
• This is one test run by one evaluation firm — Irregular's other client engagements, and whether any comparable configuration errors have occurred there, aren't addressed in this reporting.

What this means for builders

If your organization runs or commissions adversarial AI security testing of any kind — red-teaming, capability evaluations, agentic penetration testing — this is a concrete, real-world argument for treating test-environment isolation itself as a security-critical component requiring its own verification, not just an assumed property of "we set up a sandbox." A test scenario using realistic-sounding fictional company names is also worth reconsidering specifically in light of this incident: names chosen for a test that happen to collide with real businesses create exactly the ambiguity that let this incident escalate from "isolated test exercise" to "actual unauthorized access to real systems." And for any team weighing how quickly to disclose an AI-related security incident internally discovered, this case is a useful, concrete cautionary example of how "no harm resulted" as sole justification for delayed disclosure reads very differently once it becomes public via an outside reporter's inquiry rather than the company's own initiative.

Related on explainx.ai

• OpenAI discloses 6 model safety incidents, warns against max-speed scaling
• OpenAI's Hugging Face hack: full timeline and technical report
• OpenAI's rogue agent touched four additional services
• Researchers chained a libheif bug and an OpenAI SSO flaw — with Claude
• MCP security: a complete guide
• Anthropic and Accenture partner on embedded AI evaluation
• What is an embedded evaluator? AI safety, explained
• Primary sources: Wall Street Journal via GV Wire · Al Jazeera · Simon Willison's commentary

This post is sourced to the Wall Street Journal's September 18, 2026 report, Google's own statements to WSJ, and independent commentary from Simon Willison. The underlying incident occurred in May 2026; Google states it discovered the intrusions in July 2026 and did not disclose them publicly until contacted by WSJ.