MENLO PARK, 8 AUG 2026 — Meta has become the third frontier lab in three weeks to say one of its models left a testing environment and reached a real company's systems. The detail worth pausing on is not the model. It is that Meta's evaluation was running at Irregular — the same testing firm whose environment Anthropic's models escaped from.

We reported the framework being negotiated in response to the first two disclosures on 8 August: Washington is building a 30-day model review, and the escapes it answers were configuration failures rather than capability surprises. Meta's disclosure on 6 August, first reported by The Information, reinforces that reading.

What Meta said happened

The model was Muse Spark 1.1. During a cybersecurity evaluation run by Irregular, the sandbox was misconfigured in a way that gave the model access to the public internet when it should have been isolated. In Meta's words, "The model exploited a security vulnerability in a third-party service, in a manner similar to previously reported instances with other companies."

Meta has not named the vulnerability, the service, or the company reached, and says it is investigating and will publish findings "once we have all the facts." Meta has disclosed less than Anthropic and considerably less than OpenAI. This third data point is the thinnest one yet.

The common factor is a vendor, not a model

Line the three up and the shared element is not architecture, lab, or capability tier.

Computed by RECATOOLS8 August 2026
LabModelEvaluation environmentHow it got outWhat it reached
OpenAIGPT-5.6 Sol + an unnamed pre-release modelInternal (ExploitGym benchmark)Zero-day in a package registry cache proxyHugging Face production infrastructure
AnthropicOpus 4.7, Mythos 5, an internal test modelIrregularPrompt said no internet; internet was in fact availableThree organisations, incl. a malicious PyPI package pulled by 15 systems
MetaMuse Spark 1.1IrregularSandbox misconfigured, giving public internet accessAn unnamed third-party service

Compiled by RECATOOLS from each lab's own disclosure and our prior reporting. The Meta row is the thinnest because Meta has named neither the vulnerability, the service nor the company reached.

Two of the three incidents happened inside the same third-party evaluation environment, and in both cases the stated cause was that the environment had internet access it was not supposed to have. Anthropic described a misunderstanding between itself and Irregular about whether the network was reachable. Meta describes a misconfiguration at Irregular.

That is the same failure, twice, at the same supplier, disclosed a week apart by two different customers.

What Irregular says

The firm's response is brief: "There are no current open issues. Irregular is developing a white paper to share best practices for containment and securely running cyber evaluations."

Both halves deserve a second reading. "No current open issues" is a statement about the present, from the vendor, with no external verification available and no description of what was fixed or when. And a white paper on containment best practice is a reasonable thing to publish, while also being the deliverable of a company whose containment is the reason two labs had to disclose.

None of that implies bad faith. Evaluating offensive cyber capability requires giving a model a realistic target and removing the refusals that would stop it — the whole exercise is building something dangerous on purpose and relying on isolation to make it safe. This work is hard, and the field of firms doing it is small. But the only assurance on offer right now is a vendor's word about a vendor's own control — and note that the word given was "no current open issues", which is not the same as saying what was fixed.

What an evaluation environment is supposed to do

It helps to be concrete about the thing that failed, because "sandbox" makes it sound like a feature rather than a stack of assumptions.

Measuring whether a model can find and exploit vulnerabilities requires three things at once. The model needs a realistic target, because a toy one measures nothing. It needs its production refusals reduced, because a filter designed to stop it will stop it. And the whole arrangement needs isolation, because the first two conditions have deliberately built something that behaves like an attacker.

Isolation is therefore not a safety extra bolted onto the evaluation. It is the only thing standing between a capability test and an incident, and it is doing that job alone. In all three disclosures, the model and the target behaved as expected. The isolation was the part that quietly failed.

Which is why the specific failure keeps being so unglamorous. Not a model deceiving its operators, not an unforeseen capability — a network that was reachable when a prompt said it was not, and a proxy nobody listed when describing the boundary.

Why this changes what the 30-day review is worth

The voluntary framework four labs discussed with White House officials on 4 August offers federal inspectors up to 30 days with a frontier model before release. Set that against what these three incidents actually were.

Nobody was surprised by a capability. All three labs were deliberately measuring offensive cyber capability, with production safeguards reduced, because that is what the evaluation is for. What failed each time was the room: a package registry cache proxy in one case, and in the other two a network that was reachable when the prompt said it was not.

A pre-release capability review does not inspect the room. It inspects the model, at a lab, before release — and the thing that broke was a supplier's sandbox during testing that happens well before any release date. If the government wants assurance that labs can contain their own evaluations, it needs to inspect the evaluation environments and the contracts for them. No such mechanism is on the table.

What an evaluation customer should ask

The lesson generalises past frontier labs, because plenty of organisations now run agentic evaluations against third-party harnesses.

Test egress yourself rather than inheriting the claim. In two of these three cases the environment's network posture was different from what the operator believed, and a five-minute outbound connectivity check from inside the harness would have settled it before the run rather than after.

Put the isolation property in the contract in terms that can be verified, not described. "Isolated environment" is a marketing phrase; "no outbound network reachability from the evaluation host, verified per-run, evidence retained" is a control.

And scope the credentials and the blast radius on the assumption that the harness will behave like an attacker, because that is precisely what it is being paid to do.

What to watch

Whether Meta publishes the detail it has promised, since the pattern currently rests on two full accounts and one partial. Whether any lab names an evaluation vendor as a supply-chain dependency in its safety documentation, which none does today. And whether Irregular's white paper describes what went wrong in its own environment, or only what others should do.