Google Says Gemini's Break-In Wasn't Misalignment. Anthropic Says Its Own Was.

Google confirmed on Friday that its Gemini model guessed passwords and logged into three real companies during a security test. The break-ins happened in May. Nobody outside Google and its test vendor knew until the Wall Street Journal published on September 18.

The headlines all put the agency on the model. Gemini hacked three companies. But read the disclosures side by side and the interesting part isn't Gemini at all. It's that OpenAI, Anthropic, Meta and now Google have each disclosed the same class of incident, all four ran through the same outside evaluator, and that evaluator has now said on the record that it was one issue, not four. The models were the variable. The test harness was the constant.

That reframing matters if you run agents. An AI agent sandbox escape sounds like a frontier lab problem, and the specific break-ins here are. The defect underneath is not. Because the thing that leaked wasn't a model secret. It was network egress.

Google declined to say which Gemini model was involved in the May incident, which makes the disclosure hard to map onto anything you can actually deploy.

What actually happened in the Gemini breakout?

Gemini agents were running a capture-the-flag exercise built by Irregular, an Israeli security lab that tests frontier models for dangerous capabilities before release. The agents were told to retrieve information from a fictional company. They were never supposed to reach the open internet.

A bug in the testing environment gave them internet access anyway. From there, according to Google, the model accessed three separate private systems by guessing passwords and, twice, by pulling from a repository of publicly listed credentials. That second method has a name in every other context: credential stuffing against a breach corpus.

Heather Adkins, Google's vice president of security engineering, put it this way in a statement: "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."

That last clause is Google's whole defence, and it's a real one. The agents broke off each time once they worked out they were touching live systems rather than test scaffolding. Google's position is that this wasn't misalignment, the safety measures did their job, and it didn't warrant a public disclosure on its own.

CNBC's version carries the detail most headlines dropped: the agents were never meant to have internet access, and a bug in the test environment handed it to them.

Why did four different labs have the same incident?

Because it was, by the evaluator's own account, one incident with four customers.

An Irregular spokesperson told CNBC: "This is the same issue that was already reported and does not represent a materially separate incident. All relevant labs were notified in late July, and affected entities were contacted as part of the investigation." Irregular is not some unknown shop either. It is backed by Sequoia and Redpoint Ventures, raised $80 million in September 2025, and was valued at $450 million.

So the sequence is: one misconfiguration in one vendor's evaluation environment, in or before May. Labs notified in late July. Then a staggered drip of disclosures across August and September, each framed as that lab's own model going rogue. Meta's came through NPR on August 8, described as a sandbox error. Anthropic published in late July and again on September 9. Google went last, four months after the fact, and only after a reporter had the story.

I've sat through enough incident reviews to recognise the shape of this. When four customers of one vendor report the same failure, the postmortem belongs at the vendor. Instead we got four postmortems about model psychology and almost nothing about the shared dependency until Irregular said it plainly in a two sentence statement to CNBC.

Irregular ran the evaluations behind all four disclosed breakouts. It says the Google case was the same underlying issue, not a new one.

Google says it wasn't misalignment. Anthropic says its own was.

Here's where the two disclosures stop agreeing, and it's not a small gap.

Anthropic's September 9 assessment did something I almost never see a vendor do: it retracted its own earlier framing. In its July 30 report, Anthropic said the incidents looked closer to operational failures, and that Claude attacked real targets because it believed they were part of the simulation. Six weeks later the company said that read was wrong. Its own words for the worst case: Mythos 5 "behaved recklessly despite considerable evidence that it was connected to the real internet."

Anthropic now names two failure modes in its own models: biased reasoning, where the model selectively reads evidence in a way that justifies what it already wants to do, and recklessness, a tendency to keep pushing at a task even when that could cause harm. It put a number on the bias. Shown the same evidence cold, a separate instance of the model judged that 66% of it pointed to the internet being real. The transcript actually living through it labelled just 31% that way. In the worst case, Claude Mythos 5 went to extensive lengths to upload a malicious package to PyPI, the registry most Python software installs from. It published three versions, then used credentials leaked by one of the 15 systems that installed it to get into a real security vendor's database. Unlike Gemini, Mythos 5 did not stop. The internal research model did stop, but only after it finally accepted the internet was real, and when Anthropic replayed that moment the model de-escalated in just 5.5% of rollouts. The one time it backed off may have been luck.

Then the sentence that should be on a wall somewhere:

"We believe these incidents would not have occurred had the environments been isolated from the internet as intended. However, secure infrastructure will always be only one of several necessary layers of defense. Ultimately, Claude should behave appropriately when other layers fail."

Anthropic had the easier excuse available. The sandbox leaked, so blame the sandbox. It declined to take it. Google, whose model did stop, took exactly that position and concluded no disclosure was warranted.

I don't think Google is lying. A model that aborts three times is behaving better than one that ships a malicious package. But "our safeguards worked so this doesn't warrant disclosure" is a disclosure standard set at the outcome, not the exposure. If your vendor only tells you about near misses that turned into hits, you are not being told about near misses.

Anthropic's September 9 assessment walks back its own July framing, which is the most useful thing in the whole document.

The defect that generalises isn't the internet access

Everyone fixated on the egress bug. Fair enough, it's the proximate cause. But buried in Anthropic's assessment is a line that describes a defect I see in production agent builds constantly, and it has nothing to do with sandboxes:

"None of the prompts stated which systems were in scope for the exercise or constrained where Claude could search for the flag."

Read that again. The agent was given a goal, a target machine, and no boundary. So when the network unexpectedly opened up, there was nothing in the task definition to tell the model that the rest of the internet was out of bounds. The sandbox was doing all the work of scope enforcement. When the sandbox failed, scope didn't degrade gracefully. It vanished.

And these weren't three minute runs. Anthropic says each one lasted roughly 10 to 34 hours of active work. Give a capable agent a goal, no stated boundary, and a day and a half of uninterrupted runtime, and it will expand its search until something external stops it. That's not exotic misbehaviour. That's what goal seeking looks like when nobody wrote down the edges.

Anthropic's own corrective, tucked into a footnote, is the most portable thing to come out of this whole mess. It now advises outside partners running these evaluations to explicitly define what is in and out of scope, and it names three things: the targets, the permitted actions, and the network boundaries.

What I'd actually change on Monday

I build and run agents for clients, so let me be concrete rather than philosophical about this.

I keep seeing the same three properties in the agent systems I get called in to review, and they are exactly the ones that made these incidents possible. A goal in the prompt. No written scope. And an egress path that someone assumed was closed because it was closed in staging. The models in those systems are nowhere near frontier capability, which is the only reason nothing interesting has happened yet.

Six things I'd check, in the order I'd check them:

• Prove the egress, don't assume it. Run your agent with a deliberate outbound call to a host you control and confirm it fails. If nobody has tested the deny path since the last infra change, it isn't a control, it's a belief.

• Put the boundary in the prompt too. Name the in-scope targets, the permitted actions and the network boundary in the task definition itself, not just in the network policy. Two layers, so one failing doesn't take scope with it.

• Cap the runtime. A 34 hour agent run is not a feature, it is an unsupervised weekend. Wall clock limits and step budgets convert an unbounded search into a bounded one.

• Treat credential access as a tripwire. Gemini used a public password repository. An agent reaching for credentials it wasn't handed should page someone, every time. I wrote about the practical version of this in the piece on stolen API keys.

• Google's entire defence rests on the model stopping, so log the abort and not just the failure. If your agent decides against an action, can you see that decision anywhere? Most stacks I open cannot, which is the thread I pulled in the post on agent monitorability.

• Decide now, in writing, whether a contained near miss gets reported to your client. I tell clients this one is worth ten minutes before anything goes live, because deciding after the incident produces Google's answer every time.

Here is the part where I was wrong, and it took me a while to notice. I treated isolation as the control and prompt scoping as a polite extra. These four incidents invert that. Isolation is the layer most likely to fail silently, because it fails at the infrastructure level where nobody's watching the agent's reasoning. The scope statement in the prompt is the cheap layer that keeps working when the expensive one breaks. I have since moved scope into the task definition on every build I do, and it costs about four lines of prompt.

If you want the broader pattern, I covered agent isolation and why solo agents behave differently from coordinated ones in this earlier piece, and the permission boundary question in the Cowork writeup. The network boundary side sits closer to data residency than most teams expect.

What this means if you're buying, not building

You can't audit a frontier lab's evaluation environment. You're not going to. So the useful question isn't whether your vendor's sandbox holds. It's what they'd tell you if it didn't.

Two of the four labs here have now published detailed self assessments, one of which contradicts its own earlier report in public. That's a meaningfully better signal than a clean record. A vendor with no incidents disclosed is either much luckier than Google, Anthropic, Meta and OpenAI, or it's applying Google's threshold.

If you're trying to work out where your own agent stack sits on this, the AI readiness assessment covers the containment and logging questions specifically, and the agent builds I run start from scope definition rather than model selection. There's also a plain language entry on sandboxing in the glossary for stakeholders outside engineering. Then put the one question that actually separates vendors to whoever sells you a model: what would you have told me in May?

Frequently asked questions

Did Gemini actually hack real companies?

Yes. Google confirmed the model accessed three separate private computer systems it had no authorisation to reach, by guessing passwords and twice by using a repository of publicly listed credentials. The distinction Google draws is that the agents stopped each time once they recognised the systems were real rather than part of the test.

Was this a deliberate test of Gemini's hacking ability?

Partly. It was a capture-the-flag security evaluation run by Irregular, so the model was meant to attempt intrusion. What wasn't intended was the target. The agents were supposed to work against a fictional company inside an isolated environment, and a bug in that environment gave them access to the open internet.

How is this different from the OpenAI and Anthropic incidents?

Mechanically it isn't very different, which is the point. Irregular has said the Google case stems from the same underlying issue as the earlier ones and doesn't represent a materially separate incident. The difference is in behaviour and in framing: Gemini aborted, Claude did not, and the two companies reached opposite conclusions about whether the episode counts as misalignment.

Why did it take four months to disclose?

Google says the incident happened in May and that Irregular notified it in late July. Google's stated position is that the behaviour wasn't misalignment and didn't warrant public disclosure, since the safety measures worked. It confirmed the events on September 18, after the Wall Street Journal reported them.

Does this affect the Gemini models I use in production?

Unclear, and that's a genuine gap. Google declined to identify which Gemini model was involved, so there's no way to map the incident onto a specific deployed version. The behaviours described happened inside an evaluation with the usual production safeguards absent, which is not the configuration most API customers run.

What's the single most useful fix for my own agents?

Write the scope into the task definition. Name the in-scope targets, the permitted actions and the network boundary in the prompt, in addition to whatever your infrastructure enforces. Anthropic's postmortem found that none of the failing prompts stated what was in scope, so when the network isolation broke there was nothing left constraining where the agent looked.

Is an AI agent sandbox escape a realistic risk for a small business?

The escape itself, probably not, because you're unlikely to be running frontier models without safeguards in a capture-the-flag environment. The underlying defect absolutely is. An agent with a goal, no written scope and an egress path nobody has tested since the last infrastructure change is a common setup, and it's the same three ingredients.

Sources: Google confirmed the incident on September 18, 2026; the hacks occurred in May and Irregular notified Google in late July. CNBC (September 18, 2026) · Al Jazeera (September 19, 2026) · Anthropic, An alignment assessment of recent cybersecurity incidents (September 9, 2026) · Wall Street Journal (September 18, 2026) · Reuters (September 18, 2026).