Meta's Muse Spark Makes Four — and the Common Factor Isn't the Model

On 5 August 2026, Meta confirmed that Muse Spark 1.1 — the model it positions as its most capable for real-world coding and agentic work — reached the public internet during a cybersecurity evaluation, exploited a vulnerability in a third party's service, and made changes to that company's internal systems. The model was supposed to be in a sealed environment. It was not, because the evaluation firm running the test, Irregular, had misconfigured the sandbox.

That makes four labs in roughly three weeks. We have written about the other three: OpenAI reaching Hugging Face on 22 July, Anthropic's three intrusions on 31 July, and the AISI incident report on 4 August. A fourth entry in a series earns its place only if it adds something, so here is what is actually new — and it is not “another model went rogue”.

Nobody escaped anything

The framing that has followed these disclosures around is the interesting model breaking out of its box. In every case so far, that is not what the evidence says.

Meta's incident involved no sandbox escape and no zero-day. The internet access came from a configuration error, and the vulnerability the model then exploited was a basic one. An Irregular spokesperson described it as the “exact same evaluation-environment issue” disclosed previously, and said it did not involve a “sandbox escape or a sophisticated cyber action”.

OpenAI's account of its own Irregular incident says the same thing: a basic vulnerability, no zero-day, no escape. The models were running capture-the-flag exercises and had been told they had no internet access.

So the recurring failure is not model capability. It is the network boundary. Each time, an agent behaved exactly as a competent agent should — pursue the objective, use what is reachable — and what was reachable was wrong.

The detail everyone should read twice

Buried in OpenAI's disclosure is the single most instructive fact in this entire saga. In one capture-the-flag challenge, the fictional target's name happened to match a real registered domain. With the sandbox leaking, the model resolved that name, found a real website, and attacked it — “mistakenly believing it was still in a test environment”.

It found and used credentials for the site. OpenAI says it also attempted to recover accounts and to reach a DNS server holding malicious payloads intended to exploit a software vulnerability, adding that “the setup did not work, there is no evidence any real resolver queried it, and the infrastructure was removed when the evaluation ended”.

Sit with the mechanism rather than the outcome. Somebody invented a plausible company name for a training scenario. Plausible names are, by construction, the names real companies have. Nobody checked whether it resolved, because inside a sealed environment it could not have mattered. Two independently reasonable decisions — invent a realistic name, seal the environment — and the safety of the first depended entirely on the second holding.

This is not an AI problem. It is the oldest test-fixture bug there is, and every engineer reading this has shipped a cousin of it: the staging job that emailed real customers, the seeded database with a live API key, the load test pointed at production by a copied hostname. What is new is the blast radius when the thing consuming the fixture is autonomous, persistent, and good at finding a way in.

Four practices, in order of how much they would have helped

Invented names must come from reserved space. RFC 2606 and RFC 6761 exist precisely for this: example.com, example.net, example.org, and the .test, .invalid, .example and .localhost top-level domains can never be registered by anyone. A fixture name drawn from that space cannot collide with a real target no matter what the network does. This one convention, applied to one CTF challenge, would have prevented the most alarming incident in the set.
Enforce egress outside the thing being contained. The sandbox configuration was the component that was wrong. A restriction the sandbox applies to itself is worth nothing in exactly the case you need it — when the sandbox is misconfigured. Deny by default at a layer the workload cannot influence: a network policy, a firewall, a VPC with no route out, allow-listing only what the evaluation genuinely requires.
Prove the isolation before every run, not once at setup. Have the harness try to reach a known external endpoint and fail the run if it succeeds. This is the whole lesson in one line: a control that is not exercised is indistinguishable from a control that works, and the difference only surfaces when it matters. Every one of these incidents was a sealed environment that everybody reasonably believed was sealed.
Telling the model it has no internet is not a control. OpenAI's models were informed they had no access. That is a prompt. Prompts describe the world to a model; they do not constrain it. If the only thing standing between an agent and the open internet is a sentence in its context, there is nothing standing there.

The detection problem is the quieter finding

Anthropic found its incidents by reviewing 141,006 test sessions after the fact. Irregular notified OpenAI and Meta. AISI's security team spotted data leaving over Tor, and a volunteer maintainer caught the malicious contribution.

Read that list again as a list of detection mechanisms and it is uncomfortable. Retrospective log review, a third party's phone call, an anomaly that happened to be conspicuous, and a human being paying attention on an ordinary afternoon. Not one of these is a control that fires while the thing is happening.

To be fair to everyone involved: all four organisations disclosed publicly, in detail, when saying nothing was an available option. That is the behaviour you want from this industry, and it is why we know enough to write any of this down. The criticism worth making is narrow and structural — detection is running behind capability, and the gap is currently being covered by luck and diligence.

One vendor, more than one lab

Irregular's misconfiguration sits behind both the OpenAI capture-the-flag incident and Meta's, and Irregular has characterised Anthropic's as the same class of problem. The firm says all identified issues are no longer active and that safeguards have been added. OpenAI has committed to reviewing its third-party testing procedures, focusing on higher-risk evaluations, and assessing requests from evaluators to enable internet access at all.

The concentration is the part worth noticing, because it generalises well beyond AI. A small number of specialist firms test a large share of the industry's highest-consequence systems, which means one team's configuration defect propagates across competitors who share nothing else. Every lab here had its own safety programme. None of that helped, because the defect was in a layer they had collectively outsourced.

If you use third parties for security testing — penetration tests, red teams, evaluations — the transferable question is not whether they are competent. It is which of your controls exist only inside their environment, and what happens to you when one of those is wrong. Their misconfiguration becomes your incident, and your customers will not find the distinction interesting.

Where this leaves you

If you do not run frontier model evaluations, the temptation is to file this as somebody else's problem. It is not, and the reason is mundane: if your engineers use a coding assistant with shell access, you are running agents against real systems today. You simply have not framed it as an evaluation.

The questions are the same ones the labs are now answering in public. What can that agent reach from where it runs? Is that boundary enforced by a network control or by an instruction? When did you last verify it by trying to cross it? And if the agent did something unexpected right now, what would tell you — during, rather than in next quarter's log review?

Four organisations with serious safety teams got the same answer wrong in the same month. The useful response is not alarm about model capability. It is checking whether the boundary you believe in has been tested since the day it was built.