noticias

Claude Cowork escapou da sandbox e alcançou arquivos do Mac o problema maior não estava apenas no Linux

Pesquisadores de segurança demonstraram que uma sessão local do Claude Cowork podia sair da máquina virtual criada para isolá-la e alcançar arquivos armazenados no Mac do usuário. A cadeia, batizada de SharedRoot, combinava uma vulnerabilidade conhecida do kernel Linux com decisões de arquitetura que deixavam o sistema de arquivos do computador montado dentro da máquina virtual com permissão de leitura e escrita.

Depois de obter privilégios administrativos dentro do ambiente Linux, o agente conseguia atravessar a última barreira e acessar áreas que estavam muito além da pasta originalmente entregue pelo usuário. Chaves SSH, credenciais de serviços em nuvem, arquivos de projetos, configurações de desenvolvimento e outros conteúdos acessíveis à conta do macOS entravam no alcance potencial da sessão, sem um novo pedido de autorização visível.

Isso não significa que Claude tenha desenvolvido consciência, decidido fugir ou atacado espontaneamente o computador. A demonstração exigiu que a sessão executasse uma sequência específica de ações, conduzida pelos pesquisadores dentro de um ambiente preparado para o teste. O episódio pertence menos ao gênero “robô se rebela” e mais à categoria conhecida da segurança de software: uma aplicação poderosa recebeu uma área de isolamento cuja última parede estava apoiada em pressupostos frágeis demais.

A diferença é que aplicações agentivas não apenas exibem conteúdo. Elas leem documentos, executam comandos, instalam ferramentas, alteram arquivos e tomam decisões intermediárias em nome do usuário. Quando a sandbox falha, o erro deixa de ficar contido em uma resposta incorreta e pode transformar-se em uma ação sobre o computador real.

O SharedRoot expõe a questão central da segurança dos agentes de IA: não basta ensinar o modelo a se comportar. É necessário construir a infraestrutura supondo que ele, um arquivo malicioso ou uma instrução escondida tentarão atravessar todos os limites disponíveis.

A Anthropic vende inteligência. Nesse caso, o componente que precisava demonstrar mais desconfiança era a arquitetura ao redor dela.

O que é o Claude Cowork

O Claude Cowork é a camada agentiva da Anthropic voltada a tarefas que ultrapassam uma conversa comum. Em vez de apenas responder a uma pergunta, o sistema pode receber arquivos, organizar projetos, criar documentos, trabalhar com conectores e executar etapas durante períodos prolongados.

Nas sessões locais do aplicativo para macOS, o trabalho não deveria ocorrer diretamente no sistema principal. A Anthropic utiliza uma máquina virtual Linux criada por meio da estrutura de virtualização da Apple. Dentro desse ambiente, cada sessão recebe um usuário sem privilégios administrativos e restrições sobre quais operações podem ser executadas.

A lógica é correta. Caso o agente processe um documento malicioso, execute um pacote comprometido ou interprete uma instrução perigosa, os efeitos deveriam permanecer dentro da máquina virtual e das pastas que o usuário escolheu compartilhar.

Uma sandbox não precisa impedir absolutamente qualquer comportamento inesperado. Precisa limitar o estrago.

O usuário pode permitir que Claude trabalhe sobre uma pasta de projeto sem, teoricamente, conceder acesso ao restante de sua conta. O agente deveria enxergar os arquivos necessários, executar as ferramentas autorizadas e permanecer preso ao espaço que recebeu.

Na arquitetura analisada, porém, existia uma diferença crítica entre o que a sessão comum conseguia visualizar e o que o usuário administrativo da máquina virtual conseguia alcançar. O sistema de arquivos do Mac inteiro estava montado dentro da VM, em modo gravável, embora escondido do usuário sem privilégios.

Enquanto o agente permanecesse limitado, essa montagem parecia inacessível. Quando uma falha permitiu que ele se tornasse administrador dentro da VM, o computador real já estava praticamente esperando do outro lado.

A sandbox possuía várias camadas — e quase todas funcionaram

A descoberta não revela uma máquina virtual completamente improvisada. O Cowork utilizava diferentes mecanismos de segurança.

A sessão era executada por um usuário descartável sem privilégios. Chamadas sensíveis ao sistema eram parcialmente filtradas. As pastas autorizadas chegavam à sessão por uma camada intermediária controlada por um serviço administrativo. A VM separava o Linux do macOS e deveria impedir que processos do agente alcançassem diretamente o computador.

Grande parte desse desenho funcionou como planejado. O ataque precisou combinar várias condições para atravessar todas as barreiras.

Esse detalhe é importante porque vulnerabilidades raramente dependem de uma única decisão desastrosa. Sistemas modernos falham quando pequenas permissões, configurações permissivas e suposições razoáveis se alinham de maneira perigosa.

O SharedRoot precisava que a sessão pudesse criar determinados espaços isolados dentro do Linux, acessar recursos de rede de baixo nível, alcançar um módulo do kernel que não era necessário para o trabalho cotidiano e explorar uma versão vulnerável desse componente.

Depois disso, ainda precisava transformar a falha do kernel em privilégios administrativos dentro da VM. Somente então a montagem do sistema de arquivos do Mac tornava-se visível.

Cada etapa poderia ter encerrado o ataque. Nenhuma encerrou.

A existência de várias camadas não garante defesa em profundidade quando todas dependem, no final, da mesma condição: o processo nunca pode tornar-se root dentro da máquina virtual.

A CVE-2026-46331 abriu a porta administrativa

A vulnerabilidade utilizada recebeu o identificador CVE-2026-46331 e ficou conhecida como pedit COW. Ela estava localizada no subsistema de controle de tráfego do kernel Linux, em uma função usada para editar partes de pacotes de rede.

O defeito envolvia o mecanismo de cópia sob escrita, ou copy-on-write. Esse recurso permite que diferentes processos compartilhem inicialmente uma mesma região de memória e recebam cópias separadas quando um deles tenta modificá-la.

Na implementação vulnerável, determinados deslocamentos não eram considerados corretamente. Em condições específicas, uma escrita podia alcançar uma área que deveria ter sido protegida, afetando páginas mantidas no cache do sistema.

Para o ataque, isso permitia manipular temporariamente a cópia em memória de um arquivo que o usuário da sessão podia ler, mas não deveria conseguir alterar. O arquivo original no disco não precisava ser modificado diretamente, tornando o comportamento menos óbvio.

Os pesquisadores utilizaram essa possibilidade para interferir em um componente posteriormente executado por um serviço que já funcionava como root. Quando o serviço carregava a versão contaminada existente no cache, o código ganhava privilégios administrativos dentro da máquina virtual.

A falha foi registrada pelo projeto Linux em junho de 2026 e recebeu pontuação 7,8 na avaliação publicada pelo responsável pelo kernel. Ela exige acesso local, mas pode comprometer confidencialidade, integridade e disponibilidade do sistema afetado.

No Cowork, o agente já possuía execução local dentro da VM por definição. Aquilo que seria um pré-requisito difícil em um servidor convencional fazia parte normal do funcionamento do produto.

O problema não era a IA descobrir como entrar na máquina. A Anthropic já a havia colocado lá para trabalhar.

Tornar-se root dentro da VM não deveria significar dominar o Mac

Máquinas virtuais existem justamente para que um comprometimento interno não se transforme automaticamente em comprometimento do hospedeiro.

Em um desenho resistente, obter root dentro da VM seria grave, mas o atacante continuaria preso a um ambiente descartável. Poderia destruir arquivos internos, modificar ferramentas e controlar processos daquela sessão, sem alcançar o restante do computador.

No Cowork analisado, o sistema de arquivos do host havia sido compartilhado dentro da VM por meio do VirtioFS. A montagem incluía a raiz do Mac e permitia escrita, embora estivesse configurada para ser visível somente ao root da máquina virtual.

Essa escolha converteu a elevação de privilégio em uma ponte.

Ao tornar-se root no Linux, a sessão não precisava explorar uma nova vulnerabilidade no hypervisor ou romper tecnicamente a virtualização da Apple. Bastava utilizar um recurso que já estava disponibilizado pela própria arquitetura.

Por isso, a expressão “escape da máquina virtual” pode produzir uma interpretação incompleta. O ataque não perfurou diretamente o hipervisor para assumir o macOS. Ele alcançou um compartilhamento preexistente que levava ao sistema de arquivos do host.

A diferença não reduz a gravidade. Ela torna a falha de projeto mais clara.

O equivalente seria guardar documentos importantes em uma sala fechada, instalar uma porta entre ela e o corredor de segurança e confiar que nenhum funcionário do corredor jamais obterá a chave. A porta continua sendo uma porta, mesmo quando a chave deveria estar fora de alcance.

Por que montar todo o Mac dentro da VM?

Compartilhar o sistema de arquivos facilita a integração entre o aplicativo e o ambiente virtual. O serviço administrativo consegue localizar pastas escolhidas pelo usuário, disponibilizá-las para diferentes sessões e transportar arquivos sem criar cópias completas.

Essa conveniência reduz complexidade e melhora a experiência. O usuário seleciona uma pasta no Mac, e Claude trabalha sobre ela dentro do Linux sem precisar perceber que existem duas estruturas diferentes.

O problema não está em utilizar compartilhamento de arquivos. Está na amplitude e nas permissões concedidas.

Em vez de expor somente as pastas aprovadas, a arquitetura mantinha toda a raiz do host disponível para o usuário administrativo da VM. Em vez de tornar áreas não autorizadas inacessíveis, confiava na separação entre o usuário comum e o root interno.

Os pesquisadores defendem que apenas os diretórios explicitamente conectados deveriam entrar na VM. Sempre que possível, essas montagens também poderiam ser somente leitura até que uma tarefa realmente precisasse modificar o conteúdo.

Mesmo que outra vulnerabilidade concedesse root à sessão, o atacante encontraria apenas aquilo que já estava autorizado. A gravidade permaneceria limitada ao projeto aberto naquele momento.

Esse é o princípio do menor privilégio aplicado de forma concreta: não esconder recursos poderosos atrás de uma barreira, mas evitar disponibilizá-los quando não são necessários.

Ocultar a raiz do Mac do usuário comum não era o mesmo que removê-la do ambiente.

O filtro seccomp permitia mais do que a sessão precisava

O Linux oferece o seccomp para limitar quais chamadas de sistema um processo consegue executar. Uma sandbox pode usar esse mecanismo para bloquear operações relacionadas a namespaces, montagem, depuração, criação de determinados sockets e outros recursos desnecessários.

Segundo a análise da Accomplish AI, o filtro usado pelo Cowork adotava uma postura permissiva. Algumas operações específicas eram bloqueadas, enquanto grande parte das demais permanecia disponível.

Isso permitiu que o usuário sem privilégios criasse um namespace próprio e obtivesse, dentro dele, capacidades administrativas relacionadas à configuração de rede. Também permitiu acessar o canal utilizado para solicitar ao kernel o carregamento do módulo vulnerável.

Nenhuma dessas possibilidades era indispensável para um agente que deveria trabalhar com documentos, códigos e arquivos de projeto.

Uma abordagem mais restritiva utilizaria uma lista de operações expressamente permitidas. O agente receberia somente os recursos necessários para seus fluxos legítimos. Qualquer chamada desconhecida seria recusada por padrão.

Esse modelo dá mais trabalho. Aplicações complexas utilizam ferramentas variadas, e filtros rígidos podem quebrar bibliotecas, instaladores e comandos que o produto pretende suportar.

A tentação comercial é abrir o ambiente para evitar que o agente encontre limitações durante o trabalho. Cada compatibilidade adicional, contudo, aumenta a superfície de ataque.

Uma sandbox muito restrita irrita usuários quando algo deixa de funcionar. Uma sandbox permissiva parece excelente até o momento em que funciona também para o exploit.

O módulo vulnerável foi carregado automaticamente

A cadeia dependia de um módulo do kernel chamado act_pedit. O componente participa do sistema de controle de tráfego de rede e não possuía função evidente na atividade comum do Cowork.

Mesmo assim, ele estava disponível para carregamento automático. Quando o processo fazia referência ao recurso, o Linux adicionava o módulo ao kernel.

Essa conveniência é comum em distribuições de propósito geral. O sistema carrega funcionalidades conforme são necessárias, evitando manter todos os módulos ativos o tempo inteiro.

Uma VM criada especificamente para executar agentes deveria seguir outra filosofia. Componentes desnecessários poderiam ser removidos ou explicitamente impedidos de carregar.

Quanto menor o kernel funcional exposto à sessão, menor o número de caminhos que uma vulnerabilidade pode aproveitar.

Os pesquisadores observaram que o próprio ambiente do Cowork já bloqueava o carregamento de outro módulo para mitigar uma falha anterior. Portanto, a técnica de endurecimento não era desconhecida pela arquitetura. Ela simplesmente não havia sido aplicada ao componente utilizado pelo SharedRoot.

Esse é um dos problemas da segurança baseada em listas de vulnerabilidades conhecidas. O fornecedor bloqueia aquilo que já provocou incidente, enquanto dezenas de módulos semelhantes continuam disponíveis.

Corrigir somente a CVE interrompe a demonstração atual. Reduzir toda a superfície desnecessária interrompe famílias futuras de ataques.

Não foi uma “rebelião” do Claude

A imagem de uma IA decidindo fugir da própria prisão é irresistível para manchetes. Não descreve o que aconteceu.

Os pesquisadores controlaram o experimento e forneceram instruções capazes de conduzir a sessão pela cadeia. O modelo funcionou como executor dentro de um ambiente que lhe permitia utilizar ferramentas e comandos.

O risco real não depende de Claude desenvolver vontade própria.

Um agente pode receber comandos perigosos diretamente de um usuário mal-intencionado. Também pode processar conteúdo externo que contenha instruções escondidas, situação conhecida como injeção indireta de prompt.

Um repositório baixado da internet, um documento enviado por e-mail, uma página consultada durante a pesquisa ou um pacote instalado pela sessão podem tentar convencer o agente a executar ações que beneficiam um atacante.

O modelo pode recusar algumas instruções e aceitar outras. Seus filtros comportamentais são uma camada importante, mas não podem funcionar como a principal barreira para proteger credenciais do computador.

Textos maliciosos são construídos justamente para manipular a interpretação do agente. Modelos também mudam entre versões, recebem novos recursos e podem cometer erros inesperados.

A sandbox existe porque não se deve confiar que o modelo distinguirá corretamente toda instrução legítima de toda instrução hostil.

Quando a segurança depende da obediência do agente, já não existe sandbox. Existe esperança com interface gráfica.

Por que agentes são diferentes de chatbots

Um chatbot tradicional recebe texto e devolve texto. Mesmo quando responde algo incorreto, sua capacidade direta de modificar o computador é limitada.

Um agente possui ferramentas. Pode abrir arquivos, editar planilhas, consultar serviços, executar programas, instalar dependências, enviar mensagens e encadear ações sem pedir confirmação a cada etapa.

Esse poder é justamente o que torna sistemas como Cowork úteis. O usuário não quer apenas uma explicação sobre como organizar arquivos; quer que a IA organize os arquivos.

A consequência é que qualquer erro ganha impacto operacional.

Uma alucinação pode criar um documento incorreto. Uma injeção de prompt pode induzir o envio de dados. Um pacote comprometido pode executar código. Uma falha de isolamento pode transformar o agente em caminho para arquivos que o usuário nunca pretendia compartilhar.

A segurança desses produtos precisa ser avaliada em camadas:

o que o modelo aceita fazer;

quais ferramentas consegue utilizar;

que permissões cada ferramenta possui;

onde o código é executado;

quais arquivos entram no ambiente;

quais redes podem ser acessadas;

como as ações são registradas;

e qual é a dimensão do dano se todas as proteções internas falharem.

O SharedRoot atingiu especialmente a última pergunta. Quando o usuário administrativo da VM era comprometido, o dano potencial deixava de estar limitado ao projeto e alcançava a conta do Mac.

Quais arquivos poderiam ser alcançados

Os pesquisadores afirmam que a sessão com privilégios elevados podia ler e escrever conteúdos acessíveis à conta do macOS que executava o aplicativo.

Isso poderia incluir arquivos pessoais, repositórios de código, configurações de aplicativos, credenciais de ferramentas de desenvolvimento, chaves SSH e tokens armazenados em arquivos locais.

O alcance exato dependeria das permissões concedidas ao Claude Desktop e das proteções do próprio macOS. Diretórios submetidos a controles adicionais de privacidade poderiam continuar exigindo autorizações específicas, especialmente quando o aplicativo não possuía acesso completo ao disco.

Ainda assim, ambientes de desenvolvimento concentram segredos em locais previsíveis. Chaves privadas, credenciais de nuvem, tokens de repositórios, variáveis de ambiente e configurações de linha de comando frequentemente ficam dentro da pasta pessoal do usuário.

Uma única chave comprometida pode permitir acesso a servidores, códigos privados e infraestrutura corporativa muito além do Mac original.

O risco também não se limita à leitura. A capacidade de escrita permitiria modificar arquivos, inserir conteúdo em projetos, alterar configurações e criar mecanismos de persistência dentro das áreas alcançadas.

A máquina virtual foi criada para limitar o agente. O compartilhamento transformou o computador em uma extensão silenciosa dela.

Não há evidência pública de exploração contra usuários

A demonstração prova que a cadeia funcionava no ambiente testado. Isso não significa que usuários tenham sido atacados em larga escala.

Até a publicação desta matéria, não existem evidências públicas apresentadas pelos pesquisadores ou pela Anthropic de que o SharedRoot tenha sido explorado maliciosamente contra clientes.

Essa distinção é essencial. Vulnerabilidade demonstrada não equivale a incidente confirmado.

Também não é possível concluir que qualquer arquivo processado pelo Cowork poderia executar automaticamente o ataque. A cadeia dependia de condições específicas, de uma versão vulnerável do ambiente e da execução das ações necessárias.

O valor da pesquisa está em revelar que as barreiras permitiam o comprometimento. Segurança responsável não espera que um criminoso publique uma lista de vítimas antes de corrigir o desenho.

Quando o acesso potencial envolve credenciais de nuvem e arquivos corporativos, a ausência de exploração conhecida é uma oportunidade para reforço, não motivo para ignorar o problema.

A resposta “informativo” não resolve a discussão

A Accomplish AI afirma ter enviado a cadeia ao programa de segurança da Anthropic. O relatório teria sido encerrado como “informativo”.

Segundo os pesquisadores, a vulnerabilidade do kernel estava dentro de uma janela de exclusão aplicada a falhas publicadas recentemente, enquanto as demais observações foram interpretadas como medidas adicionais de endurecimento, e não como vulnerabilidades independentes.

Essa classificação pode fazer sentido dentro das regras de um programa de recompensa. Empresas estabelecem escopos para evitar pagar repetidamente por falhas de terceiros, versões desatualizadas ou recomendações genéricas de segurança.

A avaliação de bounty, porém, não responde à pergunta do usuário: o ambiente local continuava capaz de transformar root dentro da VM em acesso ao Mac?

Um relatório pode estar fora do programa comercial e continuar revelando um risco arquitetural importante.

A Anthropic não publicou, até o fechamento, uma explicação técnica detalhada sobre o caso nem confirmou publicamente quais mudanças foram aplicadas ao ambiente local.

O silêncio não prova negligência. A empresa pode ter atualizado imagens, componentes e configurações sem divulgar cada alteração. Também pode considerar que a correção do kernel e a migração para execução em nuvem reduziram suficientemente a exposição.

O problema é a falta de verificabilidade. Usuários e administradores precisam distinguir entre “a CVE utilizada foi corrigida” e “a arquitetura agora limita o dano caso outra elevação de privilégio apareça”.

São afirmações muito diferentes.

A execução em nuvem evita essa cadeia específica

A Anthropic ampliou o Cowork para sessões executadas em sua própria infraestrutura. Nesse modo, o agente trabalha remotamente, e os arquivos da sessão ficam associados à conta do Claude.

Como o código não é executado dentro de uma VM hospedada no Mac, a cadeia SharedRoot descrita pelos pesquisadores não possui o mesmo caminho até o sistema local.

Isso reduz a exposição do computador, mas não elimina riscos agentivos. Apenas muda o lugar em que eles precisam ser controlados.

Na nuvem, a Anthropic assume a responsabilidade pela separação entre clientes, proteção da infraestrutura, armazenamento dos arquivos e segurança dos conectores. O usuário deixa de expor diretamente o próprio Mac, mas passa a enviar mais conteúdo para um ambiente remoto.

Para organizações, a escolha envolve segurança, privacidade, conformidade e disponibilidade.

Sessões locais oferecem maior proximidade dos arquivos e podem atender políticas que restringem processamento externo. Ao mesmo tempo, colocam uma infraestrutura complexa de virtualização dentro do computador do funcionário.

Sessões em nuvem simplificam o endpoint, mas concentram dados e execução nos sistemas do fornecedor.

Não existe uma opção sem risco. Existe uma troca entre diferentes superfícies de ataque.

O SharedRoot mostra que “local” não significa automaticamente “mais privado e seguro”. Um ambiente local mal isolado pode fornecer ao agente um caminho muito mais amplo do que o usuário imagina.

Atualizar o kernel corrige o exploit, mas não corrige a filosofia

A correção da CVE-2026-46331 impede o método específico de corrupção utilizado na demonstração.

Isso é necessário e deve ser feito. Não é suficiente como única defesa.

Kernels Linux são projetos enormes, com módulos de rede, armazenamento, arquivos, dispositivos e diversas outras áreas sujeitas a falhas. Ambientes de agentes também podem manter imagens internas desatualizadas em relação às correções disponíveis.

Mesmo quando uma vulnerabilidade é corrigida rapidamente, existe um intervalo entre a atualização no projeto original, a incorporação pela distribuição, a criação de uma nova imagem pelo fornecedor e a instalação nos computadores.

Os pesquisadores argumentam que a arquitetura precisa assumir que outra falha de elevação de privilégio eventualmente aparecerá. Root dentro da VM deve ser tratado como possibilidade de ameaça, não como condição teoricamente impossível.

Essa abordagem altera a prioridade. Em vez de tentar garantir que o agente jamais será root, o sistema garante que, mesmo sendo root, ele não encontra a raiz do Mac montada ao lado.

Patches combatem vulnerabilidades. Limites arquiteturais combatem consequências.

O modelo de segurança precisa desconfiar também do root interno

Muitas sandboxes tratam a separação entre usuário comum e root como uma linha fundamental. Em ambientes tradicionais, isso é razoável: conseguir privilégios administrativos já representa uma vitória importante para o atacante.

Em máquinas virtuais que executam conteúdo deliberadamente não confiável, root deve ser considerado parte do adversário.

O hipervisor, os mecanismos do host e as políticas externas à VM precisam manter a fronteira mesmo que todo o sistema convidado seja controlado.

Esse princípio é comum em serviços de computação que executam códigos de clientes diferentes. O sistema convidado pode ser destruído e reconstruído sem comprometer o hospedeiro.

No Cowork, parte da imposição de limites dependia de um serviço administrativo e de uma montagem disponível dentro da própria VM. Quando o ambiente interno foi dominado, as barreiras restantes perderam força.

Projetar para root hostil torna o sistema menos conveniente. Exige compartilhamentos restritos, mediação de operações, validação de caminhos, permissões temporárias e mais separação entre a VM e os arquivos reais.

É justamente esse trabalho pouco visível que transforma virtualização em contenção.

Criar uma VM é fácil. Garantir que ela não possua uma passagem lateral para o computador é o produto de segurança.

Empresas precisam rever como distribuem agentes nos computadores

O SharedRoot importa especialmente para organizações que permitem agentes locais em máquinas com acesso a repositórios, ambientes de nuvem, documentos confidenciais e sistemas internos.

Não basta instalar o aplicativo e confiar na palavra “isolado”.

Administradores precisam saber onde o agente executa código, quais diretórios são compartilhados, que permissões o aplicativo possui, se sessões podem acessar a rede e quais ações ficam registradas.

Credenciais também não deveriam permanecer indefinidamente em arquivos acessíveis à conta do usuário. Tokens com curta duração, cofres corporativos, chaves protegidas por hardware e permissões mínimas reduzem o impacto de um comprometimento.

Máquinas utilizadas por desenvolvedores são particularmente sensíveis porque acumulam acesso a muitos outros sistemas. Um notebook pode possuir credenciais para repositórios, ambientes de teste, serviços de nuvem e pipelines de implantação.

A organização pode acreditar que está autorizando Claude a editar um projeto específico. Na realidade, o endpoint pode funcionar como uma estação de passagem para toda a infraestrutura.

A adoção de agentes precisa vir acompanhada por um inventário de autoridade. Antes de perguntar o que a IA consegue produzir, a empresa deveria perguntar o que ela conseguiria alcançar caso todas as instruções dessem errado.

Permissões contínuas aumentam o risco silenciosamente

Produtos agentivos funcionam melhor quando não interrompem o usuário a cada ação. Por isso, oferecem opções para permitir ferramentas, conectores e pastas por períodos maiores.

A conveniência cria acúmulo de autoridade.

Uma pasta autorizada para uma tarefa pode continuar disponível em projetos posteriores. Um conector habilitado para consulta pode ganhar capacidade de escrita. Uma ferramenta aceita em uma sessão passa a parecer rotineira e recebe permissão permanente.

Quando ocorre uma injeção de prompt ou falha de isolamento, o agente herda esse conjunto acumulado.

O usuário raramente revisa todas as permissões antes de cada execução. A interface transmite a impressão de que Claude está trabalhando sobre o documento atual, embora a aplicação possa possuir acesso histórico a muito mais.

Sistemas seguros precisam tornar permissões específicas, temporárias e visíveis. Também precisam separar leitura de escrita e limitar ações críticas a confirmações contextualizadas.

Uma caixa de diálogo genérica exibida na instalação não representa consentimento adequado para todas as ações futuras.

O agente não deve carregar um chaveiro completo apenas porque talvez precise abrir uma porta depois.

O ponto cego da segurança de IA não está somente no modelo

Grande parte da discussão pública concentra-se no comportamento dos modelos: se eles recusam pedidos perigosos, se podem ser manipulados, se inventam informações ou se demonstram tendências indesejadas.

Essas questões importam. O SharedRoot mostra que uma IA perfeitamente obediente ainda pode operar dentro de uma estrutura insegura.

O modelo poderia seguir exatamente as instruções recebidas. O problema estaria em quem forneceu essas instruções e no alcance permitido pelo sistema.

Segurança agentiva depende de engenharia de sistemas tradicional: kernels atualizados, permissões, compartimentos, montagem de arquivos, isolamento de rede, gerenciamento de segredos e registros de auditoria.

A novidade está na velocidade e na autonomia com que o software consegue explorar essas capacidades.

Um funcionário mal-intencionado precisaria conhecer a infraestrutura e executar o ataque manualmente. Um agente pode receber instruções dentro de um arquivo e realizar diversas etapas sozinho, utilizando ferramentas que já fazem parte de seu fluxo legítimo.

A inteligência artificial não substituiu as vulnerabilidades tradicionais. Deu a elas um operador automático.

A divulgação também favorece uma empresa concorrente

A pesquisa foi publicada pela Accomplish AI, empresa que desenvolve infraestrutura para executar agentes em endpoints corporativos. Seu texto utiliza o SharedRoot para defender a própria arquitetura, construída sem montar o sistema de arquivos do host dentro da VM.

Isso não invalida o resultado. A cadeia foi descrita tecnicamente, a vulnerabilidade do kernel é pública e o ataque foi demonstrado no ambiente dos pesquisadores.

O interesse comercial, porém, merece ser explicitado.

A Accomplish não atua apenas como laboratório acadêmico independente. Possui um produto concorrente e utiliza a descoberta para mostrar por que suas próprias decisões de segurança seriam superiores.

Esse contexto torna ainda mais importante a resposta técnica da Anthropic. Quando apenas uma das partes publica detalhes, o público recebe a análise do pesquisador e a narrativa do fornecedor concorrente ao mesmo tempo.

A avaliação correta não consiste em rejeitar o trabalho por causa disso. Consiste em verificar cada afirmação, separar a demonstração reproduzível das interpretações e evitar transformar recomendações da empresa em consenso automático.

Segurança é um mercado. Vulnerabilidades reais continuam reais mesmo quando também aparecem em apresentações de venda.

O que usuários de Mac devem fazer

Usuários do Claude Cowork devem manter o aplicativo atualizado e evitar versões antigas do ambiente local.

Tarefas que envolvam documentos desconhecidos, repositórios externos ou pacotes não confiáveis merecem cautela adicional. Sempre que a execução em nuvem for compatível com os requisitos de privacidade e da organização, ela evita a cadeia local específica descrita pelo SharedRoot.

Pastas compartilhadas devem conter apenas os arquivos necessários à tarefa. Não é recomendável entregar diretórios amplos por conveniência, especialmente a pasta pessoal inteira.

Credenciais sensíveis não deveriam permanecer em texto simples ou em arquivos acessíveis a qualquer processo executado pela conta. Chaves e tokens antigos precisam ser revogados quando houver suspeita de exposição.

Empresas devem consultar seus registros, verificar quais versões do aplicativo foram utilizadas e revisar se sessões locais trabalharam com conteúdo não confiável durante o período afetado.

A ausência de sinais evidentes não comprova comprometimento, mas também não existe motivo para presumir ataque sem indícios. A resposta deve ser proporcional: atualizar, reduzir permissões, revisar credenciais críticas e acompanhar informações oficiais.

Desinstalar imediatamente toda ferramenta de IA não resolve a classe de risco. Outros agentes utilizam arquiteturas semelhantes e podem apresentar falhas diferentes.

A lição é operar essas ferramentas como software capaz de executar código, não como uma janela de conversa mais simpática.

O próximo exploit pode não precisar da mesma CVE

A correção da pedit COW encerra o caminho exato utilizado pelos pesquisadores. Outra vulnerabilidade pode oferecer privilégio equivalente por uma rota diferente.

O Linux possui subsistemas complexos, módulos carregáveis e interfaces desenhadas para ambientes muito mais gerais do que uma VM destinada a agentes.

Quanto mais recursos permanecem disponíveis, maior a quantidade de caminhos potenciais.

A defesa duradoura é reduzir o ambiente até aquilo que a tarefa realmente exige e manter o limite principal fora do controle da sessão.

Mesmo que o agente assuma toda a VM, não deveria encontrar o sistema de arquivos completo do Mac. Mesmo que contorne o filtro de comandos, não deveria acessar credenciais. Mesmo que interprete uma injeção maliciosa, ações irreversíveis deveriam exigir autorização.

É isso que defesa em profundidade deveria significar: uma falha não transforma automaticamente todas as camadas seguintes em decoração.

No SharedRoot, a vulnerabilidade do kernel abriu a primeira porta importante. A montagem gravável da raiz do Mac havia deixado a última destrancada por dentro.

A confiança nos agentes será decidida pelo tamanho do erro possível

Agentes de IA podem economizar horas, organizar trabalhos complexos e permitir que pessoas automatizem tarefas antes restritas a desenvolvedores.

Essa utilidade depende de acesso. Sem arquivos, ferramentas e serviços, o agente volta a ser apenas um chatbot. Quanto mais acesso recebe, maior a necessidade de limites tecnicamente verificáveis.

O SharedRoot não demonstra que Claude é intrinsecamente perigoso. Demonstra que um produto agentivo não pode tratar sua sandbox como detalhe de implementação.

A fronteira precisa sobreviver ao modelo, ao conteúdo processado, às ferramentas e ao sistema convidado comprometido.

A Anthropic ampliou a execução em nuvem, o que elimina essa rota específica até o Mac. Ainda falta transparência pública suficiente para saber quais modificações protegeram as sessões locais contra a próxima elevação de privilégio.

Esse será um teste recorrente para toda a indústria. Empresas divulgarão agentes capazes de trabalhar durante horas, controlar aplicativos e agir em nome dos usuários. Cada nova capacidade aumentará o valor do produto e a dimensão do erro possível.

O futuro da IA agentiva não será decidido apenas por quantas tarefas o sistema consegue concluir sem supervisão. Será decidido por aquilo que ele continua incapaz de alcançar quando uma tarefa, um documento ou uma dependência tenta levá-lo para fora do caminho.

Claude Cowork foi colocado dentro de uma caixa. O SharedRoot mostrou que a caixa possuía uma passagem para o computador inteiro.

A correção importante não é ensinar Claude a ignorar a passagem. É garantir que ela não exista.

👉 Dúvida? Então veja mais em: https://pixbugtech.com/linksuteis