A Meta tirou
as chaves
do agente

A arquitetura começa desconfiando do modelo

Em 8 de setembro, a Meta apresentou o Muse, um agente pessoal capaz de navegar, preencher formulários, realizar compras, trabalhar em segundo plano e coordenar subagentes. A lista chama atenção, mas a decisão mais importante está no documento de segurança: por mais forte que seja o modelo, um agente como esse ainda erra e pode ser atacado pelos dados que lê. O Muse foi projetado sob a hipótese de que o agente pode estar comprometido.

Essa frase muda a arquitetura. Em vez de entregar ao modelo uma máquina, credenciais e acesso direto à internet e depois pedir que ele se comporte, a Meta dividiu o sistema em domínios de confiança. O Muse propõe trabalho dentro de uma célula isolada. Serviços fora dessa célula decidem quais segredos podem ser usados, qual código privilegiado pode executar e se uma ação pode atravessar a rede.

O produto é vendido como um agente. O sistema se parece mais com uma pequena plataforma de computação com um processo não confiável no centro.

Uma VM por usuário, dois domínios na mesma máquina

Cada usuário recebe uma máquina virtual Linux dedicada com navegador, armazenamento e recursos para executar código, criar ferramentas, manter tarefas programadas e operar subagentes. Isso separa usuários, mas a fronteira mais interessante existe dentro da própria VM.

O harness do Muse, chamado internamente de Hatch, o espaço de trabalho e os binários executados pelo agente ficam numa célula criada com systemd-nspawn. O root do contêiner é mapeado para um usuário sem privilégio no host. A célula recebe sistema de arquivos próprio, interface virtual de rede, chamadas de sistema filtradas e capacidades reduzidas. A Meta cita explicitamente a remoção de io_uring, CAP_SYS_PTRACE e CAP_NET_ADMIN.

Isso não torna código gerado pelo agente seguro. Limita seu alcance. Se o Muse executar um pacote comprometido ou obedecer a uma instrução maliciosa, o processo permanece num domínio que não deveria controlar a rede do host, inspecionar outros processos ou acessar diretamente as credenciais.

Fora da célula ficam classificadores, workers de conectores, armazenamento de segredos, Sentinel, banco de estado e proxies limitados para inferência e telemetria. Eles se comunicam por sockets Unix com identidade de processo verificada pelo kernel e listas de acesso. A intenção é impedir que o processo que interpreta conteúdo não confiável também controle os mecanismos necessários para ampliar seus privilégios.

O Sentinel é o plano de controle

Quando o Muse quer usar um conector, ele não chama diretamente a API externa. Envia ao Sentinel uma solicitação com o conector, o método, a classe da ação, o escopo e o contexto do pedido. O Sentinel confronta essa solicitação com a política do usuário e pode permitir, negar ou pedir aprovação.

A mesma fronteira governa todo o tráfego de saída. Um proxy inspeciona hostname, endereço IP resolvido e final, porta, protocolo, método HTTP, caminho e requisição decodificada. A checagem do IP depois da resolução tenta impedir SSRF por redirecionamento de um nome aparentemente público para infraestrutura privada.

Uma lista de domínios sozinha seria insuficiente: um nome permitido pode redirecionar, resolver para outro endereço ou aceitar dados num caminho não autorizado. O Sentinel decide sobre a requisição concreta no ponto de saída, quando destino e operação já podem ser observados.

Nos conectores de API, os tokens reais entram somente nessa fronteira. O código recebe um token substituto do authd; depois da autorização, o Sentinel o troca pelo segredo real ao montar a requisição. Segundo a Meta, o modelo nunca vê o token verdadeiro.

Esconder a credencial reduz roubo do segredo, mas não elimina abuso da conta. Um agente comprometido ainda pode pedir uma ação aparentemente válida com objetivo malicioso. Por isso, segredo e autorização de uso permanecem controles separados.

O kernel acompanha quando o dado deixa de ser limpo

Pedir aprovação para cada acesso destruiria a utilidade do produto. Aprovar tudo automaticamente recriaria o risco. A solução mais original do Muse é o que a Meta chama de tainted egress.

Cada processo começa limpo. Se lê dados do usuário, torna-se contaminado. Requisições limpas, estreitas e previamente permitidas podem sair sem interrupção; processos contaminados ou de origem incerta perdem o caminho automático e voltam ao fluxo normal de aprovação.

A implementação declarada usa eBPF associado a cgroups para interceptar rede e atribuir a requisição ao processo responsável. Programas ligados aos hooks do Linux Security Module propagam a marca quando os dados atravessam processos. A política desce para baixo do modelo: o agente pode justificar qualquer coisa, mas o kernel ainda observa qual processo tocou dados privados antes de liberar uma saída.

O anúncio não publica implementação, matriz de propagação, testes de cobertura nem taxas de erro. Também não demonstra formalmente que toda rota entre processos preserva a marca. É uma arquitetura relevante, ainda não uma garantia reproduzida de forma independente.

Conectores e navegador são tratados como fronteiras diferentes

Nos conectores nativos, a CLI dentro da célula interpreta argumentos e encaminha parâmetros tipados. A lógica capaz de usar credenciais executa em workers privsep fora do runtime. Cada worker tem identidade de cgroup e lista explícita de segredos. Um worker de calendário não deveria obter uma credencial de e-mail trocando um parâmetro.

O Chromium roda atrás de um broker que mantém o Chrome DevTools Protocol fora da célula. O subagente recebe uma árvore de acessibilidade, não o DOM bruto; não pode executar JavaScript na página nem abrir DevTools. Quando o usuário assume o navegador ou preenche uma credencial, o agente é pausado.

Classificadores procuram injeções em texto, imagens e arquivos, formulários de alto risco e envio de dados sem relação com a tarefa. No e-mail, filtros tentam retirar códigos de uso único e links de redefinição de senha antes que virem contexto.

O navegador não é apenas outro conector: processa conteúdo adversarial, mantém sessão, executa código de terceiros e oferece muitas rotas de comunicação. Reduzir sua interface diminui o número de ações que uma instrução maliciosa pode converter em execução.

A aprovação humana virou uma capability

Quando o Sentinel precisa do usuário, a execução para e o pedido aparece numa interface estruturada, fora da conversa. A resposta vai diretamente ao Sentinel. A autorização pode valer uma vez, por sessão, tarefa, período ou permanentemente, vinculada ao destino e ao tipo de ação.

Isso é diferente de perguntar “você autoriza?” no chat. Uma capability define exatamente o que foi concedido e por quanto tempo, sem depender da interpretação do agente.

O problema humano permanece. Muitas interrupções produzem fadiga; poucas tornam a política permissiva. Compras recebem outro limite: cartão de uso único vinculado ao comerciante, valor e janela de tempo, além de aprovação em cada transação.

Onde o desenho ainda pode falhar

O Muse combina a “tríade letal” dos agentes: conteúdo não confiável, dados privados e comunicação externa. A Meta tenta quebrar a cadeia no momento da ação com isolamento, classificação, taint tracking, política e intervenção humana.

Essa defesa também cria um plano de controle grande. Kernel, contêiner, broker do navegador, authd, privsep, Sentinel, classificadores, políticas e interface compõem a base confiável. Uma falha entre essas camadas pode ser tão importante quanto uma falha do modelo.

O Sentinel é descrito como agente separado, não como monitor inteiramente determinístico. Modelos e classificadores também podem errar. Rede, credenciais e capabilities oferecem contenção concreta; interpretar semanticamente o propósito da ação continua probabilístico.

Há ainda diferença entre conectores nativos e ferramentas escritas pelo próprio Muse. A Meta detalha os primeiros, mas não publica o mesmo nível de garantia para cada conector personalizado.

Na privacidade, políticas restringem funcionários, mas não impedem tecnicamente a Meta de acessar a VM para operar ou proteger o serviço. A Confidential VM, destinada a bloquear esse acesso criptograficamente, está prometida para mais tarde em 2026. Segundo a Meta, seu desenho e código-fonte começaram a ser disponibilizados a auditores externos.

Conversas, chamadas de ferramentas e handoffs podem ser sanitizados e usados para treinamento por padrão, com opção de recusa. A Meta diz não enviar conversas ou dados da VM aos anúncios, mas reconhece que a navegação do Muse aparece como atividade do usuário e pode influenciá-los indiretamente.

A lição transferível

O Muse ainda pode errar. A própria Meta diz que prompt injection permanece um problema aberto. O que merece atenção é a consequência de engenharia tirada dessa incerteza.

Um agente com ferramentas deve ser tratado como processo não confiável. Não precisa conhecer a credencial para usá-la, nem decidir se sua justificativa autoriza uma ação. Também não deveria controlar a camada que registra, limita e interrompe sua execução. Aprovação humana precisa virar permissão estruturada, não uma frase no contexto.

Esse é o avanço mais importante do Muse. O modelo continua no centro da experiência, mas deixa de ocupar o centro da confiança. A Meta não tornou o agente seguro por convencimento. Construiu uma arquitetura na qual o agente pode estar errado e, ainda assim, não possuir sozinho as chaves, a rede e a última palavra.