Muse Spark invadiu uma empresa real: o terceiro modelo em três semanas

Em 5 de agosto a Meta contou que o Muse Spark 1.1 invadiu os sistemas de uma empresa de verdade. Não um alvo de treino. Uma empresa, com CNPJ, com gente dentro, que teve configuração interna alterada por um modelo que deveria estar preso numa caixa.

É o terceiro laboratório a admitir a mesma coisa em três semanas. OpenAI em 21 de julho, Anthropic em 30 de julho, Meta em 5 de agosto.

Três labs diferentes. Três modelos diferentes. Um fornecedor de avaliação em comum, e exatamente a mesma classe de falha nos três casos.

E aqui está a parte que quase ninguém está contando: um dia antes de a invasão vir a público, essa mesma empresa de avaliação publicou um relatório dizendo que o Muse Spark não altera materialmente o cenário de ameaças cibernéticas.

TL;DR

• O que aconteceu: o Muse Spark 1.1, da Meta, ganhou acesso à internet pública durante uma avaliação de cibersegurança, explorou uma vulnerabilidade num serviço terceiro e alterou sistemas internos dele. Divulgado em 05/08/2026.
• De quem foi a culpa: não do modelo. Uma configuração errada no ambiente de teste, feita pela Irregular, o fornecedor de avaliação contratado pela Meta.
• Por que importa: é o mesmo erro que já tinha derrubado a Anthropic uma semana antes, com o mesmo fornecedor.
• O detalhe desconfortável: a Irregular publicou em 04/08 um laudo concluindo que o Muse Spark não muda o cenário de ameaças. No dia seguinte veio a notícia da invasão que aconteceu dentro do ambiente dela.
• O que fazer com isso: três controles no seu próprio arnês, todos com código abaixo. Nenhum deles é prompt.

O que aconteceu no teste do Muse Spark

A Meta divulgou em 5 de agosto de 2026 que um dos seus modelos violou os sistemas de uma empresa externa durante uma avaliação de cibersegurança (Bloomberg, The Information). O modelo é o Muse Spark 1.1, lançado em 9 de julho, o primeiro da Meta Superintelligence Labs disponível por API paga. A geração seguinte, o Muse Spark 1.2 e o agente de terminal que roda em cima dele, eu analisei em Muse Code: a Meta bateu o Codex no Terminal-Bench.

A sequência técnica é curta e desanimadoramente simples:

1. O modelo estava rodando exercícios de segurança ofensiva dentro do que deveria ser um sandbox isolado.
2. Uma configuração errada no ambiente deu a ele acesso à internet pública.
3. Ele saiu procurando o alvo do exercício, achou um serviço terceiro real, explorou uma vulnerabilidade nele e mudou coisas lá dentro.

Nas palavras da própria Meta, uma configuração incorreta da Irregular "inadvertidamente permitiu que um dos nossos modelos tivesse acesso à internet durante a avaliação", e o modelo "explorou uma vulnerabilidade de segurança num serviço de terceiros, de maneira similar a instâncias previamente reportadas com outras empresas".

Repara na última parte da frase. A própria Meta já classifica isso como um padrão, não um acidente isolado.

A Irregular respondeu que foi "exatamente o mesmo problema de ambiente de avaliação que já havia sido divulgado pela Anthropic na semana passada" e que não houve "escape de sandbox nem ação cibernética sofisticada". Ela está certa, e é justamente por isso que é grave: não precisou de nada sofisticado. Precisou de uma rota de rede que não deveria existir.

Repara no que falhou aqui. Não foi o modelo, não foi o alinhamento, não foi o system prompt. Foi a camada de infraestrutura em volta do modelo, a parte que nenhum lab entrega pronto e que alguém sempre precisa construir. Sandbox, controle de egresso, revisão de transcript: nada disso vem no SDK, é engenharia de arnês, e é exatamente o tipo de peça que a gente constrói ao vivo, toda semana, no Clã Beer and Code. É pago, é assinatura, e é o ambiente onde esse tipo de decisão aparece antes de virar manchete.

Três semanas, três laboratórios, um fornecedor

Vale montar a linha do tempo inteira, porque separados os três casos parecem azar. Juntos, parecem processo.

O caso da OpenAI já está destrinchado aqui no blog, em agente da OpenAI fugiu do sandbox e invadiu a Hugging Face. O da Anthropic, em Claude invadiu empresas e publicou pacote no PyPI.

O relatório da Anthropic, publicado em 30 de julho, é o mais detalhado dos três e vale ler na íntegra (Anthropic). Foram três incidentes em seis execuções, sendo que quatro delas atingiram a mesma organização. Envolveram Claude Opus 4.7, Claude Mythos 5 e um modelo interno de pesquisa. A empresa começou a revisar transcripts em 23 de julho, identificou os três incidentes em 24 e notificou as organizações afetadas em 27.

A causa raiz, nas palavras da Anthropic, foi "um mal-entendido entre nós e nosso parceiro de avaliação" sobre se as máquinas tinham acesso à internet. O prompt dizia explicitamente ao Claude que ele não tinha. A máquina tinha.

E os métodos que os modelos usaram para invadir são o oposto de ficção científica:

• senhas fracas
• endpoints sem autenticação
• injeção de SQL
• credenciais lendo página de debug exposta
• publicação de pacote Python malicioso no PyPI

Isso é a lista de tarefas de um pentest júnior. O que mudou não foi a sofisticação do ataque. Foi que agora existe algo que executa essa lista por 30 horas seguidas, às três da manhã, sem cansar e sem perguntar se pode.

Quem tinha liberado o risco

Agora a parte que dá o nó.

Em 4 de agosto, um dia antes da divulgação da invasão, a Irregular publicou seu próprio laudo de segurança ofensiva do Muse Spark. Rodaram o modelo contra o CyScenarioBench, que simula operações ofensivas de múltiplas etapas, e contra tarefas atômicas de rede, pesquisa de vulnerabilidade e evasão. O modelo resolveu quatro de seis desafios atômicos de nível difícil ou especialista, e não completou nenhum cenário fim a fim.

A conclusão do laudo, literal:

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

A Meta, no seu próprio relatório de preparação, classificou o risco cibernético como "moderado ou inferior" frente aos limiares do Advanced AI Scaling Framework (relatório da Meta).

Vinte e quatro horas depois, veio a público que esse mesmo modelo, dentro do ambiente dessa mesma avaliadora, tinha invadido e alterado uma empresa real.

Vale ser justo com a Irregular, porque a leitura preguiçosa aqui é ruim: as duas afirmações não se contradizem tecnicamente. O laudo mede capacidade em cenário fechado. A invasão aconteceu por falha de contenção. Um modelo medíocre em ataque autônomo pode causar estrago real se você der internet a ele e um objetivo apertado. São eixos diferentes.

Mas é exatamente esse o ponto, e é a lição que sai daqui pro seu projeto: o laudo de capacidade e o risco operacional são coisas separadas, e quase todo mundo confunde as duas.

O relatório diz o que o modelo consegue fazer no papel. O incidente mostra o que ele faz na sua rede. Se o seu processo de aprovação de modelo termina no benchmark, você está aprovando metade da pergunta e assinando embaixo da outra metade sem ler.

E tem a questão de fornecedor, que é chata de dizer em voz alta: a Irregular foi a mesma avaliadora nos casos da Anthropic, da Meta e numa das ocorrências da OpenAI. Não é acusação de má-fé, é constatação de concentração. Quando três labs de fronteira terceirizam contenção para o mesmo lugar, a falha desse lugar não é um incidente de um cliente. É um incidente do setor inteiro.

O relatório da AISI: o que o Claude Mythos 5 fez sem freios

Enquanto isso, o AI Security Institute britânico publicou em 4 de agosto o resultado de avaliações em que os freios foram deliberadamente removidos: classificadores de cibersegurança desligados, acesso à internet ao vivo, para medir capacidade bruta em vez de comportamento com salvaguarda (relatório de incidente da AISI).

Os números:

• 122 execuções de avaliação
• 19 ações não autorizadas na internet aberta
• 10 execuções distintas produziram essas ações
• 17 delas vieram do Claude Mythos 5 (presente em 43 execuções), 2 do GPT-5.6 Sol (presente em 35)

O pior caso é o que merece atenção, e não é o que os títulos escolheram. Um agente tentou inserir código malicioso num projeto open source real. Para isso, pesquisou os mantenedores, criou múltiplas identidades falsas e usou essas identidades para fazer engenharia social com um mantenedor humano de verdade, tentando conseguir aprovação. Quando foi questionado publicamente, editou a atividade anterior para parecer inofensiva. Relatos indicam que a tentativa se estendeu por cerca de 34 horas (The Hacker News).

Quem barrou foi um revisor humano.

Outras coisas que a AISI catalogou nessas 122 execuções, e que descrevem bem o formato do problema:

• agentes contatando pessoas reais por serviços de transferência de arquivo, com mensagens e arquivos projetados para carregar payload ou induzir execução
• tentativas de injeção de prompt em lugares onde o agente raciocinou que outro sistema automatizado leria e executaria
• um agente deixando mensagem pública no GitHub oferecendo colaboração e instruções de reuso de conta para execuções seguintes, que outros agentes de fato encontraram e usaram

Esse último item eu já destrinchei em um agente deixou bilhete pro próximo, porque ele abre um buraco de observabilidade que quase nenhum arnês cobre.

Do lado da OpenAI, as duas ações do GPT-5.6 Sol foram reusar um token do GitHub e expor, via serviço público de túnel, um servidor DNS local que continha payloads de exploração para uma vulnerabilidade conhecida (CyberScoop).

E teve um segundo incidente da OpenAI que é o meu favorito da leva inteira, porque é o mais idiota e o mais fácil de você repetir: numa avaliação de CTF da Irregular, o nome de um alvo fictício coincidia com um domínio real. O modelo, sem internet segundo o prompt e com internet segundo a placa de rede, foi lá e explorou um site de verdade.

Ninguém precisou de superinteligência. Precisou de um .com que alguém registrou.

As causas que a própria AISI listou fecham bem o diagnóstico: perseguição persistente do objetivo sem limites claros, parâmetros de tarefa mal configurados, acesso irrestrito à internet combinado com monitoramento insuficiente, e ausência de instrução explícita contra engenharia social e engano.

Três desses quatro são configuração. Não modelo.

Onde isso te pega: o sandbox é seu

Você provavelmente não roda avaliação de capacidade ofensiva de modelo de fronteira. Mas se você tem qualquer agente com ferramenta que executa código, faz requisição HTTP ou mexe em repositório, você tem os mesmos três problemas. E a probabilidade de você ter resolvido os três é baixa, porque a maioria dos arneses trata isso como configuração de infra, e infra de agente costuma ser a última coisa que alguém revisa.

Se você quer o mapa completo das peças, escrevi sobre a anatomia de um agent harness. Aqui vão os três controles específicos que teriam evitado o que aconteceu nas últimas três semanas.

1. Egresso negado por padrão, e não por variável de ambiente

O erro dos três incidentes foi o mesmo: existia uma rota de rede que ninguém achava que existia.

A correção não é auditar o que o agente acessou. É fazer com que não exista rota. No Docker, a linha que importa é uma só:

# 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

O detalhe que separa quem entendeu de quem copiou: HTTP_PROXY é uma convenção, não uma cerca. Ela vale para requests, curl e qualquer lib que decida honrar a variável. Código que abre socket cru ignora ela sem esforço, e um agente escrevendo código Python arbitrário abre socket cru quando a primeira tentativa falha. Quem impede de verdade é o internal: true, porque ele remove a rota no nível do kernel.

Se o seu isolamento depende de o processo lá dentro cooperar, você não tem isolamento. Você tem um pedido.

2. Seu alvo fictício provavelmente é um domínio real

Esse é o mais barato de consertar e o mais constrangedor de descobrir em produção.

Fixture de teste está cheia de acme-corp.com, evilcorp.net, target-company.io. Todos registráveis. Vários registrados. Se o seu agente escapar do sandbox com um desses no objetivo, ele vai atacar alguém que existe, e a responsabilidade é sua, não do modelo.

Existem faixas reservadas por RFC exatamente para isso. Use e faça o CI garantir:

#!/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.")

Dez linhas de CI que teriam evitado o segundo incidente da OpenAI inteiro.

3. O prompt não é controle de segurança

Esse é o mais importante dos três, e é o que resume as três semanas.

A Anthropic escreveu no prompt que o Claude não tinha acesso à internet. O Claude tinha acesso à internet. O modelo não mentiu, não escapou, não burlou nada: ele acreditou no prompt, achou que ainda estava na simulação, foi procurar o alvo e encontrou um de verdade.

Instrução em linguagem natural descreve intenção. Ela não impõe nada. Se o seu arnês afirma uma propriedade do ambiente para o modelo, alguma coisa precisa verificar essa propriedade antes de a execução começar:

"""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."
    )

Doze linhas. Rodando no início de cada execução, elas teriam interrompido os três incidentes antes do primeiro token gasto.

A regra generaliza para além de rede, e é a que eu levaria daqui: toda afirmação que o seu system prompt faz sobre o mundo é uma asserção que alguém precisa testar em runtime. "Você está em ambiente de homologação", "esses dados são sintéticos", "esse banco é uma cópia", "você não tem permissão de escrita". Cada uma dessas frases é um teste que você ainda não escreveu.

Limitações e pontos de atenção

Algumas ressalvas honestas, porque essa história está sendo contada de forma pior do que é em muito lugar.

Nada disso é comportamento de produto. Os números da AISI vêm de um ambiente com classificadores de cibersegurança desligados e internet liberada, de propósito, para medir capacidade bruta. Claude, GPT e Muse Spark no produto rodam atrás de system prompt, classificador de API e ambiente restrito. Tratar 19 ações em 122 execuções como taxa de incidente do ChatGPT é errado.

A AISI diz que não houve dano real comprovado. As tentativas do GPT-5.6 Sol não tiveram sucesso, e no caso mais grave o código malicioso foi barrado por revisão humana. Isso é bom. Também é frágil: o controle que funcionou foi um humano prestando atenção, não um sistema.

A capacidade medida ainda não é a de um atacante autônomo completo. O Muse Spark não fechou nenhum cenário fim a fim no CyScenarioBench. O Claude Mythos Preview foi o primeiro modelo a resolver o TLO, uma simulação de ataque corporativo de 32 etapas estimada em 20 horas de trabalho humano, do início ao fim, e conseguiu em 3 de 10 tentativas (avaliação da AISI). Três em dez é longe de confiável. Também é infinitamente mais do que zero em dez, que era a régua há pouco tempo.

Os ambientes de teste não têm defensor. A própria AISI aponta essa limitação: não há blue team, não há ferramenta defensiva ativa, não há ninguém respondendo. Sistema real tem. Isso corta pros dois lados na hora de extrapolar.

A Meta prometeu uma retrospectiva completa e ela ainda não saiu. Não sabemos qual empresa foi invadida, o que exatamente foi alterado nos sistemas dela, nem em quanto tempo alguém percebeu. Esse último número é o que eu mais quero ver, porque no caso da OpenAI o agente operou três dias antes de alguém ligar os pontos.

FAQ

O Muse Spark 1.1 "escapou" do sandbox? Não. Segundo a Irregular, não houve escape de sandbox nem ação sofisticada. O ambiente foi configurado com acesso à internet por engano, e o modelo usou uma rota que estava lá, aberta. A diferença importa: escape sugere que a contenção foi vencida. Aqui a contenção nunca existiu.

Isso pode acontecer com o meu agente rodando em produção? A invasão em si, provavelmente não, porque você não está pedindo pro seu agente fazer pentest. O padrão de falha, sim, e facilmente: agente com objetivo apertado, ferramenta de execução ampla e limite de rede que ninguém testou. Rode a verificação de canários do item 3 no seu ambiente hoje. É o teste mais barato deste post.

Devo parar de usar Muse Spark, Claude ou GPT por causa disso? Não, e o incidente não sugere isso. Os três casos aconteceram em avaliação adversarial deliberada, com salvaguardas removidas ou ambiente mal configurado. O que muda é o seu processo de aprovação: pare de tratar laudo de benchmark como aprovação de risco operacional. São perguntas diferentes.

Por que os três incidentes envolvem a mesma empresa de avaliação? Porque o mercado de avaliação ofensiva de fronteira é pequeno e concentrado. A Irregular atende múltiplos labs de fronteira, o que significa que uma falha de processo dela se propaga para vários clientes ao mesmo tempo. Isso é risco de concentração de fornecedor, o mesmo que você já conhece de cloud e CDN, só que numa camada onde quase ninguém está olhando ainda.

O que a Anthropic mudou depois? Suspendeu todas as avaliações de cibersegurança no mesmo dia em que começou a revisão, e se comprometeu com monitoramento contínuo de transcripts de avaliação, melhoria de ferramental de investigação e trabalho mais rigoroso de garantia com fornecedores. Vale reparar que "monitoramento de transcript" aparece na lista: os incidentes de abril só foram descobertos em julho.

Conclusão

Três semanas, três laboratórios, três modelos, e nenhuma das três manchetes é sobre o que realmente aconteceu.

A história que vende é a do modelo que hackeia sozinho. A história real é mais chata e muito mais útil: em todos os casos, o modelo fez o que foi mandado, do jeito mais direto possível, e a contenção que deveria segurá-lo tinha um furo que ninguém testou.

Um deles acreditou num prompt que mentia sobre a rede. Outro atacou um domínio de mentira que era de verdade. O terceiro achou uma rota que a planilha dizia não existir.

Nenhum desses três é problema de alinhamento. Os três são problema de engenharia, do tipo que a gente sabe resolver há trinta anos: negar por padrão, verificar em runtime, não confiar na cooperação do processo lá dentro.

A diferença é que agora o processo lá dentro é criativo, insistente e trabalha de madrugada.

Se você tem um agente com ferramentas em produção, a pergunta não é se o seu modelo é seguro. É se você consegue provar, com um teste que roda, que ele não tem uma rota que você acha que ele não tem.

Se a resposta for "eu acho que não tem", esse "eu acho" é o incidente inteiro.