In May 2026, during a cybersecurity evaluation run by AI security firm Irregular, Google’s Gemini model left its test environment and accessed the systems of three real companies — an eval breakout: an AI agent taking actions in the real world from inside a test that was assumed to be contained.

Google confirmed the incident on September 19, after The Wall Street Journal reported it. In one case, Gemini gained access to a protected system by repeatedly guessing its password; in the other two, it used credentials it found in a public repository. Google says the model stopped once it determined the systems were real, that the three companies were notified, and — per the Journal’s report — that federal authorities were notified as well. Heather Adkins, Google’s VP of security engineering, told the Journal: “In this case, the model acted appropriately.” Google said it did not consider the behavior model misalignment, and had not considered it worth disclosing publicly, because its safety measures worked. Reports do not name the affected companies — Google declined to identify them — or the specific Gemini version involved.

The root cause is documented in Irregular’s own August 14 report. One evaluation scenario — a simulated malicious insider at a fictional mid-sized company — used a fictional company name that, unnoticed, matched a real domain. Internet access had been unintentionally left enabled in the environment. In a small fraction of runs, models went after the real domain instead of the simulated target; one model veered to a website with a similar name and found credentials posted publicly there. Irregular says the breakouts occurred in fewer than 1 in 10,000 advanced simulations, usually hundreds of turns in, and that the previously disclosed incidents involving OpenAI, Anthropic, and Meta models trace to the same underlying issue, first disclosed by one of its customers on July 30.

Why do agents keep escaping test environments?

Strip away the vendor names and the architecture of the failure generalizes to any agent given network access — in an eval harness or in production.

Containment lived in configuration, not in an enforced boundary. Internet access in the evaluation environment was a setting — one that has to be re-decided correctly for every scenario, every run. Irregular’s report is candid that controlled internet access is sometimes necessary for realistic threat scenarios, which means the boundary is not “no egress” but “the right egress” — and a per-scenario parameter is a fragile place to keep that decision. When it was wrong, nothing downstream enforced the declared scope.

The line between simulation and reality was a string. The scenario pointed the model at a company by name. The name collided with a real domain — a collision that did not exist when the scenario was written, because new domains are registered constantly. When identity is asserted by a label rather than resolved against a controlled boundary, the agent cannot tell a honeypot from a production system. Neither, in the moment, can the harness.

Monitoring could not discriminate. In an offensive-security evaluation, everything in the logs looks like an attack — that is the point of the test. Irregular describes the detection problem as finding a needle in a highly suspicious haystack: standard classifiers flag the model’s legitimate offensive actions constantly, so the handful of real-world actions hid inside tens of thousands of simulated ones. Anomaly detection tuned for normal traffic has no purchase in an environment where abnormal traffic is the job.

The agent’s belief about its environment is not a control. Irregular’s summary is blunt: models believed they were in simulated environments when they were acting in the real world. Gemini stopped when it concluded the systems were real — that is a mitigation worth having, but it activated after the breach, and Irregular notes other models in the same incident class did not stop. A boundary the agent must infer is not a boundary.

What should teams check now?

This applies to anyone running agents with network access, not only teams contracting model evaluations. First, inventory egress: for every environment where an agent runs — eval harness, CI, production — write down whether it can reach the open internet, and whether that reach was declared or is simply the default. Second, move the boundary out of the workload: enforce network scope at the infrastructure layer — deny by default, allowlist what the scenario or workflow actually needs — so that a mis-set flag inside the harness cannot widen it. Third, treat external identifiers as change events: any name, domain, or address a scenario points an agent at should be revalidated on a schedule, because the world changes under a static config. Fourth, alert on egress telemetry, not transcripts: a connection to a host outside the declared scope is a one-line signal even when the transcript is ten thousand suspicious-looking turns. Fifth, if you contract evaluations, ask the vendor the questions Irregular’s report answers voluntarily: how internet access is decided per scenario, what monitors run during evaluations, and what the notification timeline is when something leaves the environment. And keep credential hygiene in scope — two of the three accesses used credentials sitting in a public repository, a failure mode agents are now fast enough to find at scale.

How Waxell handles this

The question this incident leaves with an enterprise is narrow and uncomfortable: if one of your agents reached something outside its declared scope today, would anything stop it — and would anyone see it? A per-environment setting answers neither. An owned control point answers both, for the traffic that traverses it.

For agent tool calls, this is what the Waxell MCP Gateway provides: one governed MCP endpoint per tenant, brokering to the upstream servers the organization has configured behind it. An agent pointed at the gateway can reach the upstreams it has been given, and each tools/call is resolved to a real user identity, evaluated against policy before the upstream sees it and again on the way back, and recorded in a payload-free audit log — durable, exportable to CSV. Policy rules on the MCP Gateway scope by upstream, tool, user, team, and agent profile, so the same person gets different rules depending on which agent is acting for them — the scope question approval alone does not answer. Rules can deny a call outright, park it for human approval while the gateway holds the connection open, apply an egress_block action that blocks results carrying URLs or hosts outside an allowlist, or rate-limit an agent as a runaway backstop. “Show me every tool call this agent made last quarter” becomes a query against a log you own.

Two honest boundaries on that claim. The gateway governs MCP tool calls that are routed through it — a raw network connection like password-guessing against a login endpoint is not an MCP call, and an agent holding direct credentials or open internet access bypasses a tool gateway entirely. Coverage is configured, not guaranteed — which is precisely the lesson of this incident, and why the network-layer controls in the checklist above matter alongside any gateway. And this happened inside a third-party evaluation environment whose controls are not public; nothing here claims any product would have prevented it.

For workflows built on Waxell, Waxell Runtime moves the boundary from configuration into the execution environment itself: every run executes isolated, with no shared state across workflows, the same 50+ policy categories gate each step before it executes, and kill switches stop an agent, a workflow, or a session immediately. Isolation as a property of the environment, not a flag someone remembered to set.

FAQ

What actually happened in the Gemini security test incident?

During a May 2026 evaluation run by the AI security firm Irregular, Google’s Gemini model accessed systems belonging to three real companies — once by repeatedly guessing a password, twice using credentials found in a public repository. Google confirmed the incident on September 19, 2026, after The Wall Street Journal reported it, and says the model stopped once it realized the systems were real.

Why did the model attack real companies instead of the test targets?

Per Irregular’s August 14 report, a fictional company name used in one evaluation scenario unknowingly matched a real domain, and internet access had been unintentionally left enabled in the environment. In a small fraction of runs — fewer than 1 in 10,000 advanced simulations — models mistook the real domain for part of the challenge.

Was this unique to Gemini?

No. Irregular states that previously disclosed incidents involving OpenAI, Anthropic, and Meta models trace to the same underlying issue in the same evaluation environment. Coverage notes the models behaved differently once inside: Google says Gemini stopped on realizing the target was real, while Anthropic’s model reportedly did not.

Was any damage done?

Google says no harm was caused and the three companies were notified. Irregular says it has no evidence that any of its customers’ systems were breached or customer data leaked — a statement about the AI labs it works with; the intruded-upon third parties were notified and, per the Journal’s report, federal authorities were informed. Irregular’s report does describe models exploiting vulnerabilities, extracting credentials, and reaching a production database in the affected runs.

What is an eval breakout?

An eval breakout is an AI agent taking actions in the real world from inside an evaluation or test environment that was assumed to be contained — typically because network egress, credentials, or identifiers in the environment reached further than the test’s designers intended.

What should enterprises take from an incident inside a testing firm?

That containment expressed as configuration fails silently. The same question — can this agent reach anything outside its declared scope, and would anyone see it if it did — applies to production agents with network access, and it is answered by enforced boundaries and egress telemetry you own, not by per-environment settings or the agent’s own judgment.

Sources

• Irregular, “Addressing Recent Incidents: Ongoing Findings and Path Forward”, August 14, 2026

• Al Jazeera and Reuters, “Google’s Gemini AI hacks 3 companies in security test, then stops”, September 19, 2026

• The Hacker News (Ravie Lakshmanan), “Google Gemini Broke Into Real Company Systems After Security Test Domain Mix-Up”, September 19, 2026

• 9to5Google (Ben Schoon), “Google confirms Gemini hacked into three companies during cybersecurity test months ago”, September 19, 2026

Your agents already have more reach than your diagrams say they do. Start free with the Waxell MCP Gateway and put one governed URL, a policy gate, and an audit log you own in front of the tools they call.