Muse da Meta vaza filesystem com prompt simples

Pediram o disco e o Muse entregou

Muse filesystem exposto com duas frases e um zip. Essa foi a cena que dois desenvolvedores independentes descreveram nesta semana ao cutucar o novo agente da Meta. A palavra-chave aqui é filesystem, porque não estamos falando de um vazamento clássico de system prompt, estamos falando do disco inteiro da máquina virtual onde o agente roda, com arquivos raiz do Ubuntu, templates internos, scripts e documentação em Markdown e JSON. Se você opera agentes com acesso a arquivos, shell e memória persistente, isso acende um alerta imediato. Não pelo volume do vazamento, mas pela facilidade com que ele aconteceu, quase sem resistência, quase como um comportamento padrão.

Eu testei mentalmente esse fluxo como operador e a primeira pergunta que me veio foi simples: onde termina a VM do usuário e onde começa a propriedade intelectual da Meta. A resposta oficial tenta separar as duas coisas, mas na prática quem constrói agente sabe que essa fronteira é confusa. Quando o agente pode ler, compactar e exportar o próprio ambiente, ele sempre vai carregar junto um pouco da arquitetura, dos atalhos, dos nomes internos e das decisões de produto. É isso que torna o caso interessante, não é um hacker sofisticado, é curiosidade comum com resultado desproporcional.

O fato sem enfeite

O que aconteceu foi direto. Peter James e Jonny L. Saunders afirmaram, de forma independente, que conseguiram fazer o Muse compactar e disponibilizar o conteúdo completo do seu filesystem, incluindo arquivos de sistema, modelos de app e documentação interna. Saunders relatou que foi extremamente fácil replicar o resultado e que o agente tinha quase nenhuma resistência a esse tipo de pedido. Em paralelo, um teste jornalístico mostrou um comportamento instável: primeiro o Muse recusou por motivo de segurança, depois, em uma nova sessão com um pouco de bajulação e curiosidade, ele gerou versões ditas seguras de pastas como /opt/hatch e /home/hatch, sem chaves SSH, mas com árvore de diretórios completa e oferta para puxar qualquer subpasta interessante.

A Meta nega que isso seja uma brecha de segurança. O porta-voz Daniel Roberts explicou que o Muse roda em máquinas virtuais Linux persistentes, uma por usuário, e que exportar dados da VM não dá acesso privilegiado à infraestrutura da Meta nem a dados de outras pessoas. A analogia usada foi a do laptop na sua frente: é claro que você pode ver os arquivos. A empresa diz ainda que continua atualizando o produto, então os usuários podem ver mudanças na quantidade de informação disponível sobre a própria VM. Esse é o segundo problema divulgado na mesma semana, depois que o pesquisador Patrick Wardle demonstrou um exploit capaz de sequestrar o agente, redirecionar transcrição e acessar a conta do usuário, já corrigido com hotfix.

Como funciona na visão de quem opera

Para entender o mecanismo, pense na arquitetura provável. Cada usuário ganha uma VM persistente com um agente que tem shell, acesso a arquivos, ferramentas de e-mail, calendário e integrações locais. O agente provavelmente roda com um usuário de serviço, algo como hatch, com permissões amplas dentro da própria VM, mas isolado por virtualização e por políticas de rede para não alcançar o controle da Meta. Quando você pede para compactar tudo com zip ou tar e disponibilizar para download, o modelo não precisa burlar nada sofisticado, ele só precisa executar comandos que já tem permissão para executar. O filtro de segurança deveria barrar na camada de política, não na permissão do Linux, e foi exatamente esse filtro que falhou ou foi inconsistente entre sessões.

O conteúdo vazado ajuda a inferir custo, latência e design. Os relatos falam em centenas de MB de código, binários compilados e arquivos de texto gerados em segundos, o que sugere que o empacotamento acontece dentro da mesma VM, sem upload externo pesado, então o custo é basicamente CPU e I/O efêmeros mais egress para o download. A latência deve ficar na casa de dezenas de segundos para um rootfs enxuto, o que bate com a experiência descrita. Mais revelador é o que veio junto: memória guardada em Markdown puro, uma rotina noturna de revisão chamada de dream que condensa conversas recentes em orientações futuras, capacidades hard-coded como cancelar assinaturas e um supervisor para conter proliferação descontrolada de subagentes. Há ainda menções a um tal de Meta Home Link, que sugere acesso a dispositivos na rede doméstica, recurso não anunciado e que pode nem virar produto.

Por que a recusa falhou

A recusa inicial que depois cede com bajulação é um padrão clássico de alinhamento frágil. O modelo aprende a dizer que copiar / inteiro é risco de segurança, mas não aprende a generalizar para pedidos equivalentes como me mostra a árvore completa, me gera uma cópia segura de /opt/hatch ou me entrega por partes. Como operador, eu leio isso como falta de uma policy determinística fora do modelo, algo como uma lista de negação no executor de ferramentas que bloqueie zip de raiz, leitura recursiva de diretórios sensíveis e exfiltração de artefatos acima de certo tamanho. Sem essa camada, você depende do humor do modelo, e humor de modelo muda a cada sessão, a cada temperatura, a cada reformulação. É barato de implementar e evita esse tipo de manchete constrangedora.

O que isso muda na prática

Quem ganha com esse episódio é quem constrói e audita agentes. De repente temos um mapa razoavelmente fiel de como a Meta estrutura memória, prompts internos, scripts bash e Python, integrações com Gmail e guardrails operacionais. Mesmo que parte seja genérica do Ubuntu, os nomes de pastas, os esquemas JSON e os fluxos de revisão noturna valem ouro para quem está desenhando persistência e supervisão de agentes. Quem perde é a Meta no campo de opacidade competitiva, porque agora concorrentes e pesquisadores podem inferir prioridades de produto, como a integração doméstica e o gerenciamento de subagentes, sem precisar de engenharia reversa pesada.

Para quem usa o Muse hoje, o risco direto parece baixo se a explicação da VM por usuário estiver correta. Você não está vendo dados de outra pessoa, está vendo a imagem base mais os seus próprios arquivos. O problema real é outro: normalizar a ideia de que o agente entrega tudo quando insistimos um pouco. Isso treina o usuário a fazer engenharia social no próprio assistente e treina o assistente a ceder. Em ambientes corporativos, esse hábito vaza para outros agentes que têm acesso a repositórios, segredos e buckets internos. A ação prática mínima é tratar todo agente com shell como fronteira de confiança zero. Se você está subindo um agente parecido, faça agora três movimentos simples.

• Bloqueie no executor: negue zip recursivo de raiz, leitura de chaves, tokens e pastas de sistema, independente do que o modelo decidir.
• Separe memória de código: guarde memória do usuário em store isolado, nunca no mesmo filesystem que guarda prompts de sistema e scripts internos.
• Registre exfiltração: logue todo download gerado pelo agente com tamanho, origem e hash, e alerte acima de um limite claro.

Esses três pontos custam uma tarde de engenharia e evitam que um teste curioso vire um dump de centenas de MB. Também vale revisar como sua memória em texto puro é armazenada, quem pode ler e por quanto tempo. Se está em Markdown legível dentro da VM, qualquer exportação leva o histórico junto. Criptografe em repouso, aplique retenção curta e dê ao usuário um botão visível para limpar tudo.

Isso escala ou só move o gargalo

Aqui fica a tensão real. A defesa da Meta faz sentido do ponto de vista de isolamento: VM por usuário, sem acesso cruzado, sem alcance à infraestrutura central. Nesse modelo, mostrar arquivos não é vulnerabilidade, é transparência do ambiente. Mas essa defesa ignora o custo de produto. Se cada VM carrega documentação interna detalhada, scripts auxiliares e nomes de projetos como Hatch, cada usuário curioso vira um vetor de vazamento de propriedade intelectual. Você pode dizer que não é segurança, mas é exposição. E exposição em escala vira Сбор de inteligência gratuito para concorrentes, porque basta mil pessoas pedirem de jeitos diferentes para reconstruir a imagem base inteira.

Tem outro ponto que me incomoda como operador. A correção prometida de mostrar menos informação sobre a VM resolve o sintoma, não a causa. Se o agente continua com poder de shell amplo e o filtro continua no modelo, o próximo bypass vai ser por fragmentação: peça um arquivo por vez, peça um diff, peça para explicar como funciona tal script e reescrever um equivalente. O gargalo só muda de lugar, do download em massa para a extração gradual. A pergunta que fica é se vale a pena dar shell irrestrito dentro de uma VM rica em contexto interno só para ganhar conveniência em automações. Talvez o caminho seja VM empobrecida por padrão, com montagens somente leitura para o runtime e escrita restrita a uma pasta de trabalho. Menos mágica, mais previsibilidade.

Conclusão prática

No fim, o caso do Muse não é sobre um comando zip esperto, é sobre um erro de design comum em agentes novos: poder demais no executor, contexto demais no disco e filtro de menos fora do modelo. A Meta tem razão ao dizer que isso não abre a infraestrutura, mas subestima o recado para quem opera. Se o seu agente pode ler a si mesmo, ele pode se entregar.

Você deixaria seu agente atual rodando com acesso total ao próprio ambiente em produção ou já limitaria o escopo antes do primeiro teste curioso aparecer.