Em 25 de maio, a Anthropic publicou a frase mais honesta do debate atual sobre segurança de agentes: a primeira arquitetura desktop do Claude Cowork rodava dentro de “uma máquina virtual completa”, usando o framework Virtualization da Apple no macOS e HCS no Windows, com seu próprio kernel Linux, sistema de arquivos e tabela de processos (Anthropic). Duas semanas depois, o Hacker News discutia por que o Claude Desktop no Windows podia iniciar uma VM Hyper-V de 1,8 GB mesmo quando o usuário só queria conversar (Hacker News).
Isso não é coincidência. É a conta do produto chegando.
A história confortável é que a Anthropic lançou um bug — e sim, existe um relatório de bug. A história mais afiada é que agentes desktop seguros estão forçando empresas de modelos a virar fornecedoras de runtime. Quando um agente consegue ler arquivos locais, executar código, chamar ferramentas e manter estado entre sessões, “segurança de IA” deixa de ser um problema de model card. Vira um problema de sistema de arquivos, kernel, hipervisor, política de rede, identidade, auditoria e monitoramento de endpoint.
A VM Não É Acidental
A arquitetura pública da Anthropic é clara. O Claude Cowork não é só uma caixa de chat com upload de arquivo. A Help Center diz que o Cowork usa dois ambientes de execução: o loop do agente roda nativamente no dispositivo, enquanto comandos de shell e código gerado executam em uma VM Linux dedicada, isolada pelo Apple Virtualization.framework no macOS e pelo Hyper-V no Windows (Claude Help Center).
Esse desenho é defensável. Na verdade, é a parte em que mais confio.
O post de engenharia da Anthropic explica por que o Claude Code pode se apoiar em um fluxo de aprovação humana, enquanto o Cowork não pode. Usuários do Claude Code são desenvolvedores. Eles muitas vezes conseguem inspecionar um comando bash antes de aprová-lo. O Cowork mira um trabalho de conhecimento mais amplo, em que pedir para um usuário avaliar find . -name "*.tmp" -exec rm {} \; é teatro. A barreira certa para esse usuário não é um prompt assustador. É uma sandbox sempre ativa.
A Anthropic também traz números úteis. Usuários aprovaram cerca de 93% dos prompts de permissão do Claude Code. Adicionar uma sandbox em nível de OS reduziu os prompts de permissão em 84%. O modo automático do Claude Code captura cerca de 83% dos comportamentos “excessivamente zelosos”, com a nota da Anthropic dizendo que cerca de 17% ainda passam (Anthropic). A lição é direta: prompts são sugestões de política. Sandboxes são aplicação de política.
Este é o trade-off de contenção que a Anthropic está realmente fazendo:
| Superfície do produto | Limite de runtime | Principal custo de segurança |
|---|---|---|
| execução de código no claude.ai | Contêiner gVisor no servidor | Menos capacidade local |
| Claude Code | Sandbox de OS mais aprovações | Usuário precisa entender o risco |
| Claude Cowork | VM Linux local | Inicialização, memória, disco, visibilidade de TI |
A VM existe porque a Anthropic está levando a sério o raio de explosão local. O workspace selecionado e a pasta .claude são montados. Credenciais ficam no chaveiro do host. A saída de rede é restrita. A Anthropic até chama atenção para validação de symlinks e modos de montagem: somente leitura, leitura e escrita, e leitura e escrita sem exclusão.
Isso é engenharia de verdade. E também tem custos reais.
A Comunidade Está Irritada Com a Conta, Não Com o Limite
A issue do GitHub que chegou ao HN foi aberta em 26 de fevereiro de 2026. O autor descreve um laptop Razer Blade com Windows 11 Pro 25H2 e 16 GB de RAM, com VirtualMachinePlatform habilitado e Hyper-V, WSL, Docker e Windows Sandbox desabilitados. Depois que o Cowork ou o modo agente foi usado uma vez, o Claude Desktop supostamente passou a iniciar uma VM Hyper-V em toda abertura, mostrando Vmmem em torno de 1.796 a 1.846 MB (GitHub).
Isso importa porque 1,8 GB não é uma abstração. Em um laptop de 16 GB, é mais de 11% da RAM antes mesmo de o usuário pedir ao agente para fazer trabalho de agente. A mesma issue diz que a memória ociosa subiu de cerca de 50% para 62%, depois para 70–75% sob carga normal de aplicativos. O autor também encontrou 2.689 arquivos de sessão obsoletos em %APPDATA%\Claude\local-agent-mode-sessions\.
A solução alternativa não era bonita:
Disable-WindowsOptionalFeature -Online -FeatureName "VirtualMachinePlatform" -NoRestart
Stop-Process -Name vmwp -Force
Stop-Process -Name vmcompute -ForceIsso não é workaround de consumidor. É chamado de TI.
A thread do HN fez o que o HN faz: algumas pessoas culparam desleixo, outras defenderam a necessidade de uma sandbox, e várias fizeram a pergunta de produto que a Anthropic deveria responder diretamente: por que o Cowork não é simplesmente opt-in? Um comentarista enquadrou o meio-termo útil: existe um espectro entre dar tudo a um agente e não dar nada (Hacker News). Esse é o enquadramento correto.
A frustração no Linux vem do mesmo lugar. A página oficial de instalação da Anthropic lista apenas macOS 11+ e Windows 10+, com opções de instalação para “macOS” e “Windows” (Claude Help Center). Enquanto isso, threads no Reddit seguem perguntando por que não existe app desktop para Linux, especialmente porque o Claude Desktop já distribui uma VM Linux para execução local de agentes (Reddit). A reclamação comum não é só “suportem meu OS”. É: se o runtime seguro é Linux, por que usuários Linux recebem o menor suporte desktop oficial?
A resposta pode ser empacotamento, implantação corporativa, integração com chaveiro, sandboxing de app, carga de suporte ou a falta de uma API única de segurança para desktop Linux. São motivos sérios. Mas a ótica de produto é ruim. Desenvolvedores conseguem ver a VM. Conseguem ver o Hyper-V. Conseguem ver pastas de sessão obsoletas. Conseguem ver projetos não oficiais de reempacotamento para Linux. Eles sabem quando a abstração vaza.
Segurança Virou um Problema de Runtime
A parte mais importante do post da Anthropic não é a VM. É o modo de falha.
A Anthropic descreve uma divulgação de terceiro em que a allowlist de saída do Cowork fez exatamente o que estava configurada para fazer. Ela permitiu tráfego para api.anthropic.com, porque o produto precisa dessa API. Um arquivo malicioso no workspace montado incluía instruções ocultas e uma chave de API controlada pelo atacante. O Claude leu arquivos e os enviou pela Files API da Anthropic para a conta do atacante. O resumo da Anthropic é devastador: a sandbox funcionou, e os dados ainda assim saíram (Anthropic).
Esse é o problema de segurança de agentes em um único incidente. Allowlists de domínio não bastam porque um domínio não é uma permissão. É um pacote de capacidades. Permitir api.anthropic.com significa permitir toda operação alcançável por trás dessa API, a menos que o runtime entenda proveniência, escopo de token, headers e intenção.
A correção da Anthropic foi um proxy man-in-the-middle defensivo dentro da VM, que só deixa passar requisições com o token de sessão provisionado da própria VM e rejeita chaves embutidas pelo atacante. Isso é bom. Também é uma placa de sinalização para todos que estão construindo agentes desktop: a sandbox precisa entender identidade e capacidade, não só endereços IP e caminhos.
Aplicativos desktop tradicionais não precisavam de tanta maquinaria porque não decidiam autonomamente abrir arquivos, sintetizar comandos, encadear ferramentas e contornar permissões ausentes. Uma sandbox de navegador isola páginas web não confiáveis. Um contêiner isola um serviço. Uma sandbox de agente desktop precisa isolar um operador semiautônomo que pode ler instruções de documentos hostis e então usar ferramentas legítimas para fazer a coisa errada.
É por isso que isso está virando uma camada de OS/runtime.
O OS já é dono da maioria dos primitivos: isolamento de processos, permissões de sistema de arquivos, armazenamento seguro de credenciais, filtragem de rede, logs de auditoria, notarização, hooks de EDR, gerenciamento de dispositivos. A empresa do modelo é dona do loop do agente e da intenção de política. O produto que falta é o contrato entre os dois.
A TI Corporativa Paga Duas Vezes
A VM dá à Anthropic um limite duro de contenção. Ela também esconde atividade das mesmas ferramentas de segurança das quais empresas dependem.
A Anthropic diz isso diretamente. No FAQ da arquitetura do Cowork, “Ferramentas de detecção de endpoint (EDR) conseguem inspecionar atividade dentro da VM?” é respondido com “Não.” A VM é isolada de ferramentas de segurança baseadas no host por design (Claude Help Center). O post de engenharia acrescenta que a mitigação atual são exportações OTLP pull-based para administradores, o que não é o mesmo que monitoramento ao vivo (Anthropic).
Isso significa que a TI paga duas vezes.
Primeiro, paga o custo de recursos: bundles de disco, inicialização da VM, pressão de RAM, conflitos de virtualização, problemas de rede e scripts de helpdesk. Segundo, paga o custo de visibilidade: o que torna o agente mais seguro em relação ao host também o torna mais opaco para o monitoramento baseado no host.
Isso não é motivo para rejeitar VMs. É motivo para parar de fingir que “roda em uma VM” é o fim da história de segurança. Para uma implantação corporativa, uma VM selada sem telemetria de primeira classe é uma caixa-preta com um perímetro bonito.
A lacuna de auditoria é ainda mais aguda porque a Help Center diz que a atividade do Cowork “não está atualmente” capturada em logs de auditoria, na Compliance API ou em exportações de dados, e direciona admins para OpenTelemetry como orientação de monitoramento (Claude Help Center). Se um funcionário humano usasse um shell, copiasse arquivos ou chamasse uma API, empresas esperariam logs. Se um agente faz isso dentro de uma VM, “confie na gente, está contido” não sobreviverá ao procurement.
O Que Desenvolvedores Devem Exigir
O debate da comunidade está focado demais em se 1,8 GB é “demais”. Isso depende da máquina e da tarefa. A exigência real deveria ser controle.
Fornecedores de agentes desktop deveriam expor o estado da sandbox como uma superfície de produto, não enterrá-lo no AppData e no Gerenciador de Tarefas. Desenvolvedores e admins deveriam pedir cinco coisas.
Primeiro: inicialização sob demanda. Chat não deveria iniciar uma VM. Cowork deveria. Tarefas agendadas podem justificar um runtime aquecido, mas isso deveria ser visível e configurável.
Segundo: um painel da sandbox. Mostre status da VM, memória, uso de disco, pastas montadas, sessões ativas, política de saída e última limpeza. Se o Docker Desktop consegue mostrar contêineres, o Claude Desktop consegue mostrar seu runtime de agente.
Terceiro: escolhas explícitas de instalação. Se o Cowork precisa de um bundle na casa dos 10 GB em alguns sistemas, diga isso antes do download. Deixe usuários escolherem o local. Deixe removerem sem quebrar o chat.
Quarto: política como código. Desenvolvedores deveriam conseguir inspecionar e versionar a política efetiva da sandbox: montagens, destinos de rede, permissões MCP locais, escopos de token e regras de exclusão. Um painel vago de “configurações de saída” não basta para equipes entregando trabalho real.
Quinto: hooks de observabilidade ao vivo. Exportação OTLP é um começo. O nível deveria ser logs por chamada de ferramenta, eventos de acesso a arquivos, ações negadas, decisões de rede, identidade de sessão e códigos de motivo legíveis por admins. Cegueira de EDR não pode ser varrida para baixo do tapete como o custo do isolamento.
O pedido por Linux também pertence aqui. Um app desktop Linux não é só um agrado à comunidade. É uma chance de construir sobre a plataforma em que muitos primitivos de sandboxing, fluxos de trabalho de desenvolvedores e modelos mentais de contêiner já são nativos. Se a parte difícil é integração desktop, digam isso. Se a parte difícil é suporte corporativo entre distros, digam isso. O silêncio deixa usuários inferirem descaso.
A Conclusão Certa
A Anthropic merece crédito por publicar detalhes desconfortáveis. O post inclui números reais, riscos reais que passaram batido e trade-offs reais. A maioria dos fornecedores teria parado em “sandbox segura”. A Anthropic explicou onde a sandbox falhou, onde a aprovação do usuário falhou e onde o isolamento por VM piorou o monitoramento corporativo.
Mas a raiva no HN também é justificada. Custos de segurança não desaparecem porque o diagrama de arquitetura é sólido. Eles vão parar no laptop do usuário, no plano de implantação do admin e no fluxo diário do desenvolvedor.
A VM do Claude Cowork é o futuro chegando cedo: agentes locais precisarão de limites rígidos de runtime, identidade com escopo, mediação de rede e execução de ferramentas auditável. Os vencedores não serão os fornecedores que escondem essa maquinaria. Os vencedores a tornarão legível, ajustável, observável e entediante.
Um agente desktop que pode operar seus arquivos e ferramentas não é mais só um app. É um pequeno ambiente operacional. Trate-o como tal.
Leitores que quiserem testar o Claude Fable 5 por conta própria podem usá-lo via Claude Fable 5 on OneHop, um endpoint drop-in com preço cerca de 30% abaixo da tabela. Novas contas podem começar com US$ 10 grátis, sem precisar de cartão.
Leitura complementar: Primeiros passos com Claude Fable 5.
