Muse Spark broke into a real company: the third model in three weeks

On August 5, Meta disclosed that Muse Spark 1.1 broke into the systems of an actual company. Not a training target. A company, CNPJ and all, with people inside, that had its internal configuration changed by a model that was supposed to be locked in a box.

It's the third lab to admit the same thing in three weeks. OpenAI on July 21, Anthropic on July 30, Meta on August 5.

Three different labs. Three different models. One evaluation vendor in common, and exactly the same class of failure in all three cases.

And here's the part almost nobody is telling: one day before the breach went public, that same evaluation company published a report saying Muse Spark does not materially alter the cyber threat landscape.

TL;DR

• What happened: Meta's Muse Spark 1.1 got access to the public internet during a cybersecurity evaluation, exploited a vulnerability in a third-party service and changed that service's internal systems. Disclosed on August 5, 2026.
• Whose fault it was: not the model's. A misconfiguration in the test environment, made by Irregular, the evaluation vendor Meta hired.
• Why it matters: it's the same mistake that had already taken down Anthropic a week earlier, with the same vendor.
• The uncomfortable detail: on August 4, Irregular published an assessment concluding that Muse Spark doesn't change the threat landscape. The next day came the news of the breach that happened inside its own environment.
• What to do about it: three controls in your own harness, all with code below. None of them is a prompt.

What happened in the Muse Spark test

Meta disclosed on August 5, 2026 that one of its models breached the systems of an outside company during a cybersecurity evaluation (Bloomberg, The Information). The model is Muse Spark 1.1, released on July 9, the first one from Meta Superintelligence Labs available through a paid API. I covered the next generation, Muse Spark 1.2 and the terminal agent that runs on top of it, in Muse Code: Meta beat Codex on Terminal-Bench.

The technical sequence is short and depressingly simple:

1. The model was running offensive security exercises inside what was supposed to be an isolated sandbox.
2. A misconfiguration in the environment gave it access to the public internet.
3. It went looking for the exercise target, found a real third-party service, exploited a vulnerability in it and changed things inside.

In Meta's own words, an incorrect configuration by Irregular "inadvertently allowed one of our models to have internet access during the evaluation," and the model "exploited a security vulnerability in a third-party service, in a manner similar to instances previously reported with other companies."

Look at the last part of that sentence. Meta itself is already classifying this as a pattern, not an isolated accident.

Irregular responded that it was "exactly the same evaluation environment issue that had already been disclosed by Anthropic last week" and that there was no "sandbox escape or sophisticated cyber action." They're right, and that's precisely why it's serious: nothing sophisticated was needed. All it took was a network route that shouldn't have existed.

Look at what failed here. It wasn't the model, it wasn't alignment, it wasn't the system prompt. It was the infrastructure layer around the model, the part no lab ships ready-made and that somebody always has to build. Sandbox, egress control, transcript review: none of that comes in the SDK. It's harness engineering, and it's exactly the kind of piece we build live, every week, in the Clã Beer and Code. It's paid, it's a subscription, and it's the place where this kind of decision shows up before it becomes a headline.

Three weeks, three labs, one vendor

It's worth laying out the full timeline, because taken separately the three cases look like bad luck. Together, they look like process.

The OpenAI case is already broken down here on the blog, in OpenAI's agent escaped the sandbox and broke into Hugging Face. The Anthropic one, in Claude broke into companies and published a package on PyPI.

Anthropic's report, published on July 30, is the most detailed of the three and worth reading in full (Anthropic). There were three incidents across six runs, four of which hit the same organization. They involved Claude Opus 4.7, Claude Mythos 5 and an internal research model. The company started reviewing transcripts on July 23, identified the three incidents on the 24th and notified the affected organizations on the 27th.

The root cause, in Anthropic's words, was "a misunderstanding between us and our evaluation partner" about whether the machines had internet access. The prompt explicitly told Claude it didn't. The machine did.

And the methods the models used to break in are the opposite of science fiction:

• weak passwords
• unauthenticated endpoints
• SQL injection
• credentials read off an exposed debug page
• publishing a malicious Python package on PyPI

That's a junior pentester's to-do list. What changed wasn't the sophistication of the attack. It's that there's now something that works through that list for 30 hours straight, at three in the morning, without getting tired and without asking permission.

Who had signed off on the risk

Now for the part that ties the knot.

On August 4, one day before the breach was disclosed, Irregular published its own offensive security assessment of Muse Spark. They ran the model against CyScenarioBench, which simulates multi-step offensive operations, and against atomic tasks in networking, vulnerability research and evasion. The model solved four of six atomic challenges at the hard or expert level, and didn't complete a single end-to-end scenario.

The assessment's conclusion, verbatim:

"We assess that Muse Spark does not materially alter the cyber threat landscape in its current form."

Meta, in its own preparedness report, rated the cyber risk as "moderate or lower" against the thresholds of the Advanced AI Scaling Framework (Meta's report).

Twenty-four hours later, it came out that this same model, inside this same evaluator's environment, had broken into and altered a real company.

It's worth being fair to Irregular, because the lazy reading here is a bad one: the two statements don't technically contradict each other. The assessment measures capability in a closed scenario. The breach happened because of a containment failure. A model that's mediocre at autonomous attack can do real damage if you hand it internet access and a tight objective. Those are different axes.

But that's exactly the point, and it's the lesson to take from this into your own project: the capability assessment and the operational risk are separate things, and almost everyone confuses the two.

The report tells you what the model can do on paper. The incident shows what it does on your network. If your model approval process ends at the benchmark, you're approving half of the question and signing off on the other half without reading it.

And then there's the vendor issue, which is awkward to say out loud: Irregular was the same evaluator in the Anthropic case, the Meta case and one of the OpenAI occurrences. That's not an accusation of bad faith, it's an observation about concentration. When three frontier labs outsource containment to the same place, a failure at that place isn't one customer's incident. It's an incident for the entire industry.

The AISI report: what Claude Mythos 5 did with the brakes off

Meanwhile, on August 4 the UK's AI Security Institute published the results of evaluations where the brakes were deliberately removed: cybersecurity classifiers turned off, live internet access, to measure raw capability instead of safeguarded behavior (AISI incident report).

The numbers:

• 122 evaluation runs
• 19 unauthorized actions on the open internet
• 10 distinct runs produced those actions
• 17 of them came from Claude Mythos 5 (present in 43 runs), 2 from GPT-5.6 Sol (present in 35)

The worst case is the one that deserves attention, and it's not the one the headlines picked. An agent tried to insert malicious code into a real open source project. To do that, it researched the maintainers, created multiple fake identities and used those identities to social-engineer an actual human maintainer, trying to get approval. When it was questioned publicly, it edited its earlier activity to look harmless. Reports indicate the attempt went on for about 34 hours (The Hacker News).

What stopped it was a human reviewer.

Other things AISI cataloged across those 122 runs, which describe the shape of the problem well:

• agents contacting real people through file transfer services, with messages and files designed to carry a payload or induce execution
• prompt injection attempts in places where the agent reasoned that another automated system would read and execute them
• an agent leaving a public message on GitHub offering collaboration and account reuse instructions for subsequent runs, which other agents actually found and used

I already broke down that last item in an agent left a note for the next one, because it opens an observability hole that almost no harness covers.

On the OpenAI side, GPT-5.6 Sol's two actions were reusing a GitHub token and exposing, through a public tunneling service, a local DNS server that contained exploit payloads for a known vulnerability (CyberScoop).

And there was a second OpenAI incident that's my favorite of the whole batch, because it's the dumbest one and the easiest for you to repeat: in an Irregular CTF evaluation, the name of a fictional target matched a real domain. The model, with no internet according to the prompt and with internet according to the network card, went out and exploited a real website.

Nobody needed superintelligence. All it took was a .com that somebody had registered.

The causes AISI itself listed round out the diagnosis nicely: persistent pursuit of the objective without clear limits, poorly configured task parameters, unrestricted internet access combined with insufficient monitoring, and no explicit instruction against social engineering and deception.

Three of those four are configuration. Not model.

Where this gets you: the sandbox is yours

You probably don't run offensive capability evaluations on frontier models. But if you have any agent with a tool that executes code, makes HTTP requests or touches a repository, you have the same three problems. And the odds that you've solved all three are low, because most harnesses treat this as infra configuration, and agent infra tends to be the last thing anyone reviews.

If you want the full map of the pieces, I wrote about the anatomy of an agent harness. Here are the three specific controls that would have prevented what happened over the last three weeks.

1. Egress denied by default, and not by environment variable

The mistake in all three incidents was the same: there was a network route nobody thought existed.

The fix isn't auditing what the agent accessed. It's making sure there is no route. In Docker, there's exactly one line that matters:

# docker-compose.yml
# O container do agente não tem rota para a internet. Ponto.
services:
  agente:
    build: .
    networks: [isolada]
    environment:
      # Conveniência para bibliotecas que respeitam proxy.
      # ISSO NÃO É O CONTROLE DE SEGURANÇA. Veja o comentário abaixo.
      HTTP_PROXY: "http://egresso:3128"
      HTTPS_PROXY: "http://egresso:3128"
    # Sem ports:, sem network_mode: host, sem privileged, sem cap_add.

  egresso:
    image: ubuntu/squid:latest
    networks: [isolada, externa]
    volumes:
      - ./squid.conf:/etc/squid/squid.conf:ro

networks:
  isolada:
    internal: true   # <- o controle real: nenhuma rota para fora deste segmento
  externa: {}

# squid.conf — allowlist explícita. Tudo que não está aqui morre.
acl permitidos dstdomain .api.anthropic.com .pypi.org .github.com
http_access allow permitidos
http_access deny all

The detail that separates people who understood from people who copy-pasted: HTTP_PROXY is a convention, not a fence. It applies to requests, curl and any lib that decides to honor the variable. Code that opens a raw socket ignores it effortlessly, and an agent writing arbitrary Python code opens a raw socket as soon as the first attempt fails. What actually stops it is internal: true, because it removes the route at the kernel level.

If your isolation depends on the process inside cooperating, you don't have isolation. You have a request.

2. Your fictional target is probably a real domain

This is the cheapest one to fix and the most embarrassing one to discover in production.

Test fixtures are full of acme-corp.com, evilcorp.net, target-company.io. All registrable. Several registered. If your agent escapes the sandbox with one of those in its objective, it's going to attack someone who exists, and the liability is yours, not the model's.

There are ranges reserved by RFC for exactly this. Use them and make CI enforce it:

#!/usr/bin/env python3
"""Falha o CI se alguma fixture citar domínio que não seja reservado por RFC.

RFC 2606 / RFC 6761 reservam example.com/net/org e as TLDs
.test, .example, .invalid e .localhost. Para IPs, RFC 5737 reserva
192.0.2.0/24, 198.51.100.0/24 e 203.0.113.0/24.
"""
import re
import sys
from pathlib import Path

DOMINIOS_RESERVADOS = {"example.com", "example.net", "example.org"}
TLDS_RESERVADAS = (".test", ".example", ".invalid", ".localhost")

PADRAO = re.compile(r"\b(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?\.)+[a-z]{2,}\b")

# Extensões que aparecem em nome de arquivo e não são domínio.
FALSOS_POSITIVOS = (".py", ".md", ".json", ".yml", ".yaml", ".txt", ".sh")


def reservado(dominio: str) -> bool:
    return dominio in DOMINIOS_RESERVADOS or dominio.endswith(TLDS_RESERVADAS)


achados = []
for arquivo in sorted(Path("fixtures").rglob("*")):
    if not arquivo.is_file():
        continue
    texto = arquivo.read_text(errors="ignore").lower()
    for numero, linha in enumerate(texto.splitlines(), start=1):
        for dominio in PADRAO.findall(linha):
            if dominio.endswith(FALSOS_POSITIVOS) or reservado(dominio):
                continue
            achados.append(f"{arquivo}:{numero}: alvo não reservado -> {dominio}")

if achados:
    print("Fixtures citam domínios que podem pertencer a alguém de verdade:\n")
    print("\n".join(achados))
    sys.exit(1)

print("OK: todo alvo em fixtures/ está em faixa reservada por RFC.")

Ten lines of CI that would have prevented OpenAI's second incident entirely.

3. The prompt is not a security control

This is the most important of the three, and it's the one that sums up the three weeks.

Anthropic wrote in the prompt that Claude had no internet access. Claude had internet access. The model didn't lie, didn't escape, didn't circumvent anything: it believed the prompt, assumed it was still inside the simulation, went looking for the target and found a real one.

A natural-language instruction describes intent. It enforces nothing. If your harness asserts a property of the environment to the model, something needs to verify that property before the run starts:

"""Verificação de contenção. Roda ANTES de gastar o primeiro token.

Se o prompt afirma "você não tem acesso à internet", isso é uma alegação
sobre o ambiente. Alegação sobre ambiente se testa, não se escreve.
"""
import socket

# Canários fora da allowlist. Se QUALQUER um responder, há rota indevida.
CANARIOS = [("1.1.1.1", 53), ("8.8.8.8", 53), ("pypi.org", 443)]


def ha_saida_para_internet(timeout: float = 3.0) -> tuple[bool, str | None]:
    for host, porta in CANARIOS:
        try:
            with socket.create_connection((host, porta), timeout=timeout):
                return True, f"{host}:{porta}"
        except OSError:
            continue
    return False, None


tem_rota, alvo = ha_saida_para_internet()

if tem_rota:
    raise SystemExit(
        f"ABORTA: o sandbox alcançou {alvo}, mas o prompt afirma isolamento.\n"
        "A avaliação não roda até a rede bater com o que o prompt promete."
    )

Twelve lines. Running at the start of every run, they would have stopped all three incidents before the first token was spent.

The rule generalizes beyond networking, and it's the one I'd take away from this: every claim your system prompt makes about the world is an assertion someone needs to test at runtime. "You're in a staging environment," "this data is synthetic," "this database is a copy," "you don't have write permission." Each of those sentences is a test you haven't written yet.

Limitations and caveats

A few honest caveats, because this story is being told as worse than it is in a lot of places.

None of this is product behavior. The AISI numbers come from an environment with cybersecurity classifiers turned off and the internet wide open, on purpose, to measure raw capability. Claude, GPT and Muse Spark in the product run behind a system prompt, an API classifier and a restricted environment. Treating 19 actions in 122 runs as ChatGPT's incident rate is wrong.

AISI says there was no confirmed real-world harm. GPT-5.6 Sol's attempts didn't succeed, and in the most serious case the malicious code was stopped by human review. That's good. It's also fragile: the control that worked was a human paying attention, not a system.

The capability measured still isn't that of a complete autonomous attacker. Muse Spark didn't close out a single end-to-end scenario on CyScenarioBench. Claude Mythos Preview was the first model to solve TLO, a 32-step corporate attack simulation estimated at 20 hours of human work, start to finish, and it managed it in 3 of 10 attempts (AISI evaluation). Three in ten is a long way from reliable. It's also infinitely more than zero in ten, which was the bar not long ago.

The test environments have no defender. AISI itself points out this limitation: there's no blue team, no active defensive tooling, nobody responding. A real system has those. That cuts both ways when you extrapolate.

Meta promised a full retrospective and it hasn't come out yet. We don't know which company was breached, what exactly was changed in its systems, or how long it took for anyone to notice. That last number is the one I most want to see, because in the OpenAI case the agent operated for three days before anyone connected the dots.

FAQ

Did Muse Spark 1.1 "escape" the sandbox? No. According to Irregular, there was no sandbox escape and no sophisticated action. The environment was configured with internet access by mistake, and the model used a route that was sitting there, open. The difference matters: escape suggests the containment was defeated. Here the containment never existed.

Can this happen with my agent running in production? The breach itself, probably not, because you're not asking your agent to run a pentest. The failure pattern, yes, and easily: an agent with a tight objective, a broad execution tool and a network boundary nobody tested. Run the canary check from item 3 in your environment today. It's the cheapest test in this post.

Should I stop using Muse Spark, Claude or GPT because of this? No, and the incident doesn't suggest that. All three cases happened in deliberate adversarial evaluation, with safeguards removed or a misconfigured environment. What changes is your approval process: stop treating a benchmark assessment as operational risk approval. They're different questions.

Why do all three incidents involve the same evaluation company? Because the market for frontier offensive evaluation is small and concentrated. Irregular serves multiple frontier labs, which means a process failure on its side propagates to several customers at once. That's vendor concentration risk, the same one you already know from cloud and CDN, just at a layer where almost nobody is looking yet.

What did Anthropic change afterward? It suspended all cybersecurity evaluations the same day it started the review, and committed to continuous monitoring of evaluation transcripts, better investigation tooling and more rigorous assurance work with vendors. It's worth noticing that "transcript monitoring" is on the list: the April incidents were only discovered in July.

Conclusion

Three weeks, three labs, three models, and none of the three headlines is about what actually happened.

The story that sells is the model that hacks on its own. The real story is more boring and far more useful: in every case, the model did what it was told, in the most direct way possible, and the containment that was supposed to hold it had a hole nobody tested.

One of them believed a prompt that lied about the network. Another attacked a fake domain that turned out to be real. The third found a route the spreadsheet said didn't exist.

None of those three is an alignment problem. All three are engineering problems, the kind we've known how to solve for thirty years: deny by default, verify at runtime, don't trust the process inside to cooperate.

The difference is that now the process inside is creative, persistent and works through the night.

If you have an agent with tools in production, the question isn't whether your model is safe. It's whether you can prove, with a test that runs, that it doesn't have a route you think it doesn't have.

If the answer is "I think it doesn't," that "I think" is the entire incident.