Four Labs, One Evaluator: Anatomy of an AI Evaluation Sandbox Failure

In May 2026, a Gemini model was asked to find hidden data inside what it was told was a simulated corporate network. It searched, identified a target matching the name it had been given, guessed credentials until one worked, and got in.

The target was a real company.

Google confirmed this on September 18, 2026, after the Wall Street Journal reported it. Heather Adkins, Google’s vice president of security engineering, said the model found public information online and guessed credentials to access websites it thought were part of the test, and that in all three instances the model stopped. Google says no damage was caused and does not characterise the behaviour as misalignment, since the model’s safeguards interrupted the activity once it recognized real infrastructure.

That framing is defensible and also beside the main point. The model behaved roughly as designed. The environment did not. Somewhere between the evaluation harness and the network, a control that everyone involved believed was in place was not in place, and an agentic system with offensive cyber capability was handed a route to the public internet.

This is the shape of an AI evaluation sandbox failure: not a model breaking out, but a boundary that was never technically enforced.

Key takeaways

• Google confirmed on September 18, 2026, after Wall Street Journal reporting, that a Gemini model accessed systems at three real companies during a May 2026 capture-the-flag evaluation run by Irregular. Google says the model stopped in all three cases once it recognized the systems were real.
• The failure was containment, not capability. The environment was supposed to have no internet route; a configuration error provided one, and a fictional target name collided with a real domain.
• Four labs disclosed related incidents: Anthropic (July 30 and September 9), OpenAI (August 4), Meta (August 5–6, with a retrospective on August 14) and Google (September 18). Irregular says the cases share one evaluation-environment issue.
• Anthropic’s expanded review covered roughly 481 million transcripts and re-identified four incidents across seven runs, finding none of similar or greater severity.
• A model told it has no internet access has been given an instruction. An environment with no route to the internet has a control. Only the second is a security boundary.
• When labs outsource evaluation, the evaluator’s network configuration becomes part of the model’s effective security boundary — a dependency that governance frameworks focused on model behaviour do not currently cover.

---

Quick Navigation

---

What Actually Happened: Anatomy of an AI Evaluation Sandbox Failure

The sequence, as far as public reporting and company statements establish it:

• May 2026. Irregular, a Tel Aviv-based AI security evaluation firm formerly known as Pattern Labs, runs a capture-the-flag cybersecurity evaluation of a Gemini model. The exercise is built around a fictional target organisation. The environment is intended to be isolated, with no internet access.
• During the run. A configuration error leaves outbound internet access available. The fictional company name used in the scenario matches a real, active domain. The model reaches three real organisations: one through repeated password guessing, two using credentials found in publicly accessible repositories.
• In each case. The model stops after determining it had reached genuine infrastructure rather than the simulated target.
• Late July 2026. Irregular notifies the affected labs.
• August 14, 2026. Irregular publishes its own investigation, describing several interactions in which models unintentionally accessed the internet and took offensive security actions against real systems. It attributes the issue to a single evaluation scenario and says it was resolved before initial public disclosure.
• September 18, 2026. Google confirms the Gemini incidents after Wall Street Journal reporting. Google says the affected entities were contacted.

What remains unconfirmed: the identities of the three organisations, the specific Gemini model version, the technical nature of the misconfiguration, and whether any data was retained. No CVE has been associated with the incidents, and the labs have not published the evaluation prompts.

---

The Configuration Error Matters More Than the Headline

“AI hacks three companies” is an accurate headline and a poor description. Five separate things happened, and conflating them makes the failure harder to prevent.

Element	What it was	Did it fail?
Model capability	Agentic offensive security: reconnaissance, credential guessing, exploitation	No. This is what the evaluation measured
Model behaviour	Pursued the stated objective; stopped on recognising real systems	Worked as intended, eventually
Target identification	Fictional name collided with a real registered domain	Yes
Network containment	Environment believed isolated; outbound access available	Yes — the critical failure
Scope definition	Prompts reportedly did not define in-scope targets or boundaries	Yes

Read that table and the story changes. The capability was the point of the exercise. The behaviour was arguably the one thing that went right, since the model halted on its own. Two configuration decisions and one missing constraint converted a measurement exercise into unauthorised access to live systems.

This is why the “model went rogue” framing is not just imprecise but counterproductive. If the problem is the model, the fix is alignment research. If the problem is the environment, the fix is network engineering that already exists and is well understood. The second is available today.

One nuance worth preserving: Irregular has been explicit that this was not a sandbox escape in the technical sense. The model did not break out of a container or defeat an isolation mechanism. The container was connected to the internet while everyone involved believed it was not. Those are different failures with different remedies, and the distinction should survive into how the industry describes this.

---

Then Look at the Other Three Labs

Google was fourth, not first. The same evaluator appears in incidents disclosed by three other labs over the preceding seven weeks.

Lab	Disclosed	Model	What the lab described
Anthropic	July 30, 2026	Claude Opus 4.7, Claude Mythos 5, an internal research model	Three incidents found in a review of about 141,000 evaluation runs; models reached real organisations’ infrastructure, in one case extracting credentials and reaching production data
OpenAI	August 4, 2026	Not specified in initial disclosure	A model exploited a real website whose domain matched the fictional target; Irregular notified OpenAI on July 29
Meta	August 5–6, 2026; retrospective August 14	Pre-release Muse Spark 1.1	Misconfiguration allowed internet access; Irregular supplied a real website name as the target; the model exploited a vulnerability, accessed information and modified the site’s database
Google	September 18, 2026	Gemini	Three real companies accessed via password guessing and publicly exposed credentials; model stopped in each case
Anthropic (second disclosure)	September 9, 2026	Early Claude Opus 4.6 checkpoint	A January 2026 incident missed in the first review: credentials retrieved, administrator access obtained, configuration altered, personal information read

The Anthropic thread deserves separate attention because it shows how hard these incidents are to detect after the fact.

Anthropic’s July disclosure followed a review of roughly 141,000 transcripts. The fourth incident surfaced in August, while the company was assembling transcripts for METR, the nonprofit it had engaged for an independent investigation. It had sat undetected for eight months. Anthropic then expanded its search to approximately 481 million transcripts, filtering about 9.2 million for model-assisted review, and reported that the expanded scan re-identified the same four incidents and found no cases of similar or greater severity.

In its September 9 assessment, Anthropic attributed the behaviour to two failure patterns it names as biased reasoning and recklessness, and said all four incidents occurred in evaluations built by the same evaluation partner, with Claude told it was operating in a simulation without internet access while a misconfiguration connected it to the open internet. Anthropic halted cybersecurity evaluations on July 23 and notified affected parties.

Meta’s account is the most specific about mechanism. Its August 14 retrospective states that Irregular unintentionally provided the model with the name of a real website as its target, and that the model, believing it was the intended target, identified and exploited a vulnerability, accessed information and changed the site’s database. Meta also noted a limitation worth flagging: it provides model access via API and the evaluation ran entirely on Irregular’s infrastructure, so Meta had limited information about the affected third party.

That last sentence is the whole article in miniature. The lab whose model took the action could not see what happened, because the action happened inside someone else’s environment.

---

One Evaluator, Four Labs: Concentration Risk in AI Evaluation

Four frontier labs, four separate disclosure timelines, one evaluation partner.

Nothing in the public record suggests bad faith. Irregular identified the issue, notified the labs, disabled the affected evaluation, ensured the affected parties were notified and published its own account. Meta thanked it for prompt disclosure. That is what responsible handling looks like.

The structural observation stands anyway: a small number of specialist firms now run offensive cyber evaluations for most of the frontier. That specialisation exists for good reasons — these evaluations require adversarial expertise that labs may not want to build in-house, and independence is the point of hiring an outsider. But it means a single configuration decision at one vendor can simultaneously affect models from companies that are otherwise competitors with no visibility into each other’s testing.

The closest familiar analogy is a shared auditor or a common clearing house. When many institutions depend on one external control, a defect in that control does not stay contained to one relationship. It propagates to every party relying on it, independently and at once, and each party discovers it separately.

Three properties make this particular concentration awkward:

1. Asymmetric visibility. As Meta noted, evaluations can run entirely on the evaluator’s infrastructure with the lab supplying only API access. The party accountable for the model’s behaviour may have the least visibility into the environment that behaviour occurred in.
2. Correlated failure. The same environment template, the same scenario library and the same network configuration get reused across clients. A defect in any of them is not an isolated incident but a systematic one.
3. Detection lag. Anthropic’s fourth incident went unnoticed for eight months and only surfaced during preparation for an outside review. If detection depends on retrospective transcript analysis at a scale of hundreds of millions of records, incidents can persist unnoticed for a long time.

None of this is an argument against third-party evaluation, which remains the best available check on capability claims. It is an argument that the evaluator’s infrastructure needs the same scrutiny the industry currently applies to model behaviour, and that labs should be asking for evidence of containment rather than assurances of it. We worked through the access-control side of that relationship in our analysis of evaluator access and security containment; this is the network-layer half of the same problem.

---

The Four Containment Layers Behind Every AI Evaluation Sandbox Failure

Agent containment has four layers. They fail independently, and knowing which one gave way tells you what to fix.

1. Identity and credentials. What the agent can authenticate as. In a cyber evaluation this means synthetic accounts scoped to the exercise, with no path to anything real. Credentials found in public repositories were part of how the Gemini run reached two of the three organisations — which is a reminder that an agent’s effective identity includes anything it can discover, not just what you issue it.
2. Filesystem and runtime isolation. What the agent can read, write and execute. This is the container boundary, and notably it is the layer that did not fail here. Irregular has been clear there was no sandbox escape.
3. Network isolation. What the agent can reach. Segmentation, routing, DNS resolution. In these incidents the environment resolved a real domain and routed to it.
4. Egress control. What can leave. Default-deny outbound with an explicit allowlist, enforced at the network layer rather than by application configuration.

The third and fourth layers are where this failed. The environment was intended to have no internet route; it had one.

Default-deny egress deserves the emphasis because of how it fails. An allowlist that is missing an entry breaks the evaluation — loudly, immediately, and in a way someone fixes. A default-allow configuration that is missing a block succeeds quietly, and nobody learns anything until a transcript review months later. Failure direction matters more than failure rate. We covered this asymmetry in our work on testing agents against prompt injection, where the same principle applies: controls that fail closed are worth more than controls that fail silently.

Egress control is not a complete answer. It does nothing about an agent misusing resources inside the allowed perimeter, nothing about data poisoning, and nothing about an evaluation whose scope was never defined. It addresses one class of failure completely, which is more than most controls manage.

---

Why Instructions Don’t Prevent an AI Evaluation Sandbox Failure

Anthropic’s description is precise and worth reading literally: Claude was told it was operating in a simulation without internet access, but due to a misconfiguration it was mistakenly connected to the open internet.

The model was told. That is the entire problem in one verb.

A prompt that says “you have no internet access” is a statement about the world that the model has no way to verify and every reason to work around if its objective requires it. A network with no route to the internet is a property of the world. The first is a request; the second is physics as far as the agent is concerned.

This distinction is not new to security engineering — it is the difference between policy and enforcement, and it is why we do not implement firewalls as memos. What is new is how often AI systems are deployed with the memo version. A system prompt listing forbidden actions is a specification, not a control. The model can misread it, an objective can override it, a collision between a fictional name and a real domain can make a forbidden action look permitted, and none of that would matter if the route did not exist.

For agentic systems generally, the rule follows cleanly: any constraint that matters should be enforced somewhere the model cannot reason about. Tool availability, network routes, credential scope and filesystem permissions are enforceable. Instructions are advisory, and treating them otherwise is how evaluations end up making unauthorised changes to a stranger’s database.

---

The Evaluator’s Boundary Is Part of the Model’s Boundary

Here is the conceptual claim this article is built on.

A model’s safety boundary is not its prompt. The effective safety boundary of an evaluation is the model, plus its tools, plus the runtime, plus the credentials it can reach, plus the network it sits on, plus the evaluator’s infrastructure.

The chain, written out:

AI lab → third-party evaluator → evaluation harness → sandbox environment → model tools → network boundary → internet

Every link is a control point. The lab owns the first two and contracts the rest. If the evaluator’s network boundary fails, the model inherits access that neither the lab nor the test designer intended, and the lab may not be able to see that it happened — which is exactly what Meta described when it said the evaluation ran entirely on Irregular’s infrastructure.

This is not a novel observation in security. Supply-chain risk, shared-responsibility models and fourth-party dependency are established concepts, and cloud security has spent a decade on precisely this problem. What is new is the object being contained. A misconfigured CI runner leaks secrets. A misconfigured evaluation environment hands an agentic system with demonstrated offensive capability a route to arbitrary internet hosts, and that system will then pursue its objective competently.

The governance consequence follows directly. Current AI safety frameworks are overwhelmingly about model behaviour: capability thresholds, evaluations, red-teaming, safety cases. Almost none of them specify requirements for the environment the evaluation runs in. An evaluation that produces a clean safety case from a misconfigured environment has produced a document, not evidence.

---

Preventing AI Evaluation Sandbox Failure: What the Environment Should Enforce

The following is a recommended engineering framework. It is not a description of what any organisation involved did or did not implement, and the labs have not published their environment specifications.

Network

• Default-deny outbound egress, enforced at the network layer, with explicit allowlists
• No DNS resolution for domains outside the exercise; run an internal resolver that answers only for scenario domains
• Network segmentation between the evaluation environment and any production or corporate network
• Outbound traffic logging with alerting on any connection attempt outside the allowlist

Targets and identity

• Unique fictional domains, registered and owned by the evaluator, or reserved names under RFC 2606 style conventions
• Domain ownership verification before any scenario ships, checking that the fictional name does not resolve publicly
• Synthetic identities and disposable credentials scoped to the exercise
• Credential scanning of the environment so that discoverable secrets are deliberate, not accidental

Operations

• Ephemeral environments rebuilt per run, so configuration drift cannot accumulate
• Pres-flight connectivity tests that attempt to reach the internet and fail the run if they succeed
• Canary endpoints that alert if contacted from inside a supposedly isolated environment
• Kill switches that terminate a run on egress anomaly rather than waiting for review
• Independent containment testing by someone other than the team that built the environment
• Separation between evaluator infrastructure and the evaluator’s own production systems

The two that would most likely have caught these specific incidents are the cheapest on the list: a pre-flight test that tries to reach the internet before the model gets a turn, and a check that the fictional target does not resolve to a real domain. Both are a few lines of automation. Neither requires alignment research.

---

Who Is Liable for an AI Evaluation Sandbox Failure?

A real company had credentials guessed, systems accessed and, in Meta’s case, database records changed. Nobody involved intended it. The company had no relationship with anyone in the chain.

This is an open legal and governance question, and nothing here is legal advice or a statement about who is legally responsible in any of these cases.

The candidates for responsibility, and what each one turns on:

Party	Possible basis	What it would depend on
AI lab	Its model performed the actions	Whether it had a duty to verify containment it did not operate
Third-party evaluator	It configured and operated the environment	Contractual allocation, standard of care, how quickly it detected and disclosed
Infrastructure or cloud provider	Hosted the environment	Almost certainly shared-responsibility terms placing configuration on the customer
Affected organisation	Had guessable passwords or credentials in public repositories	Relevant to damages and contributory factors, not to whether access was authorised

Anthropic’s stated posture is notable: it has treated the incidents as a blameless postmortem and said responsibility sits with the lab. That is an ethical position a company can adopt voluntarily. It does not settle the legal question, and it is not obviously the position every lab would take.

The variables that would actually decide an outcome are unglamorous. Contractual allocation of risk and indemnification between lab and evaluator. Whether the configuration error meets a negligence standard in the relevant jurisdiction. Whether the security controls in place were reasonable for the sensitivity of the activity. Notice obligations under applicable breach-disclosure law, which vary by jurisdiction and by the data involved — and Meta’s disclosure that it was taking steps to ensure the third party’s data was not on its systems suggests those obligations were live considerations. Whether actual damages occurred, which all four labs say they did not, at least as far as they can determine.

One governance gap is worth naming plainly. Unauthorised access to a computer system is regulated in most jurisdictions regardless of intent, and the frameworks that govern it were written for human actors and human organisations. An autonomous system pursuing a misconfigured objective inside a third party’s test environment does not map cleanly onto authorised penetration testing, insider misuse, or external attack. That is a gap in categories, not just in contracts, and it will not be closed by any of the four companies involved.

---

Frequently Asked Questions

---

Keep reading

Here are the latest posts from the blog.