A inteligência artificial está deixando de ser apenas uma ferramenta que sugere código para se transformar em um agente capaz de executar comandos, manipular arquivos e trabalhar praticamente sozinho dentro do computador de um desenvolvedor. Essa evolução aumenta a produtividade, mas também amplia significativamente as consequências de uma falha de segurança.
Pesquisadores da startup de cibersegurança Accomplish identificaram vulnerabilidades envolvendo os mecanismos de isolamento de Claude Code, da Anthropic; Codex, da OpenAI; e Cursor, três ferramentas amplamente utilizadas no desenvolvimento de software com inteligência artificial.
Os problemas estavam relacionados às chamadas sandboxes, ambientes criados justamente para impedir que códigos ou agentes tenham acesso irrestrito ao computador onde estão sendo executados.
Segundo a investigação divulgada pela Accomplish e reportada pela Upstarts Media, determinadas condições permitiam ultrapassar essa barreira e executar ações fora do ambiente que deveria estar isolado.
Mais preocupante do que a existência das vulnerabilidades foi a diferença no tempo de resposta dos fornecedores.
Cursor corrigiu o problema comunicado pelos pesquisadores em aproximadamente uma semana. A OpenAI também solucionou duas vulnerabilidades reportadas em agosto em período semelhante.
No caso da Anthropic, entretanto, uma das falhas levou aproximadamente 50 dias e dezenas de atualizações do Claude Code até chegar a uma correção completa, segundo a reportagem.
O que significa “escapar da sandbox”?
Uma sandbox funciona como uma área de contenção.
Imagine que um agente de IA precise executar comandos para testar um programa. Em vez de permitir que ele opere livremente em todo o computador, o sistema limita aquilo que o agente consegue acessar.
A ideia é simples:
se algo der errado dentro da sandbox, o problema deveria permanecer dentro dela.
Esse mecanismo ganha importância especial com agentes de programação porque eles possuem capacidades muito maiores do que um chatbot tradicional.
Ferramentas desse tipo podem executar comandos de terminal, modificar arquivos, instalar dependências, utilizar Git, rodar testes e interagir com diferentes partes do ambiente de desenvolvimento.
Se uma vulnerabilidade permite atravessar essa barreira, o modelo de segurança muda completamente.
Um código que deveria permanecer confinado pode alcançar recursos existentes no sistema operacional do usuário.
Um repositório malicioso poderia virar a porta de entrada
A vulnerabilidade detalhada pela Accomplish no Claude Code recebeu o nome de Beltdown.
Segundo os pesquisadores, um repositório não confiável poderia utilizar uma configuração maliciosa do Git para provocar execução de comandos fora da sandbox do Claude Code em um Mac.
O problema envolvia o comportamento do próprio ambiente que executava determinadas operações do Git fora da área protegida.
Isso criava uma situação perigosa: o agente permanecia aparentemente dentro da sandbox, mas uma ferramenta utilizada por ele podia iniciar uma operação fora dela.
Em outras palavras, o ataque não precisava necessariamente “quebrar” diretamente a sandbox.
Era possível explorar a interação entre componentes confiáveis executados dentro e fora dela.
E esse detalhe é importante porque mostra que o problema pode ser mais estrutural do que uma única vulnerabilidade.
O Git apareceu como elemento crítico
Uma das técnicas identificadas explorava configurações controladas pelo próprio repositório.
O Git possui uma enorme quantidade de funcionalidades e configurações. Algumas delas podem determinar a execução de processos auxiliares.
No caso investigado pela Accomplish, uma configuração relacionada ao core.fsmonitor poderia ser manipulada.
O Claude Code realizava determinadas operações do Git fora da sandbox. Um repositório preparado maliciosamente poderia aproveitar essa condição para fazer com que um comando controlado pelo atacante fosse executado também fora da área de isolamento.
Esse tipo de ataque é particularmente preocupante porque desenvolvedores trabalham constantemente com código criado por terceiros.
Clonar um repositório desconhecido é uma atividade absolutamente comum.
Projetos open source, testes técnicos, contribuições externas e análises de código frequentemente começam exatamente dessa maneira.
A falha poderia executar comandos com privilégios do usuário
Segundo a Accomplish, no cenário demonstrado para o Claude Code, o código conseguia executar comandos no computador com os privilégios do usuário conectado, sem que aparecesse a solicitação de permissão que deveria funcionar como uma barreira adicional.
Isso não significa que qualquer usuário do Claude Code tenha sido automaticamente comprometido.
Também não há, nas informações publicadas até agora, evidência de uma campanha ampla explorando especificamente a vulnerabilidade divulgada pela Accomplish.
O que os pesquisadores demonstraram foi que existia um caminho tecnicamente viável para ultrapassar o isolamento prometido pelo produto.
Essa distinção é essencial.
Uma vulnerabilidade comprovada não significa necessariamente que ela tenha sido explorada em larga escala.
Mas significa que o risco existia.
Anthropic levou semanas para concluir a correção
A cronologia do caso envolvendo o Claude Code chama atenção.
A Accomplish afirma ter comunicado a vulnerabilidade à Anthropic em 13 de julho.
Uma primeira correção foi disponibilizada em 6 de agosto, mas os pesquisadores consideraram que ela não eliminava completamente o problema.
A correção completa teria chegado em 26 de agosto.
A cronologia detalhada pela própria Accomplish aponta aproximadamente 44 dias entre a comunicação inicial e a solução completa. A Upstarts Media arredondou o período para cerca de 50 dias, destacando que aproximadamente 30 versões do software teriam sido disponibilizadas nesse intervalo.
Portanto, os “50 dias” apresentados na publicação que viralizou devem ser entendidos como uma aproximação.
A cronologia técnica disponível aponta um período ligeiramente menor.
OpenAI e Cursor reagiram mais rapidamente
A comparação chamou atenção porque outros fornecedores responderam em períodos menores.
Segundo a Upstarts Media, a Accomplish comunicou uma vulnerabilidade ao Cursor em julho, e a empresa disponibilizou uma correção aproximadamente uma semana depois.
Duas vulnerabilidades também foram reportadas à OpenAI em agosto e solucionadas em aproximadamente uma semana.
A OpenAI confirmou à publicação que havia realizado as correções e afirmou estar reforçando continuamente seus mecanismos de sandbox, incluindo controles relacionados aos locais onde os agentes podem gravar arquivos.
Anthropic e Cursor não haviam fornecido comentários oficiais à reportagem até sua publicação.
Isso não permite concluir que uma empresa seja necessariamente “segura” e outra “insegura”.
Mas introduz uma métrica que deverá ganhar importância na contratação de agentes corporativos:
quanto tempo o fornecedor leva para corrigir uma vulnerabilidade crítica depois que ela é confirmada?
Cursor também apresentou uma variante do problema
A Accomplish posteriormente publicou detalhes de outra pesquisa, chamada Beltdown2, envolvendo o Cursor CLI.
Nesse caso, um diretório de projeto controlado por um atacante e contendo determinadas configurações do Git poderia escapar da sandbox utilizada pelo Cursor no macOS.
A vulnerabilidade foi comunicada à Anysphere, desenvolvedora do Cursor, corrigida e posteriormente verificada pelos pesquisadores antes da divulgação pública.
Mais interessante do que a vulnerabilidade individual é a conclusão técnica apresentada pela Accomplish.
Para os pesquisadores, não se trata simplesmente de “um bug do Claude” ou “um bug do Cursor”.
Existe uma classe de vulnerabilidades relacionada à arquitetura desses agentes.
O problema pode estar na própria arquitetura dos agentes
Um agente de programação não funciona isoladamente.
Existe o modelo de inteligência artificial, mas também existe uma camada de software ao redor dele.
Essa camada pode executar Git, acessar arquivos, iniciar processos, consultar a internet e administrar permissões.
O risco aparece quando parte dessas operações acontece dentro da sandbox e outra parte acontece fora dela.
A Accomplish descreve três elementos particularmente perigosos quando aparecem juntos: sandbox aplicada apenas a determinadas ferramentas, operações internas executadas pelo próprio agente fora desse isolamento e configurações controladas pelo repositório capazes de influenciar processos executáveis.
Isso cria uma espécie de ponte entre os dois ambientes.
O modelo pode estar isolado.
Mas a ferramenta que ele chama talvez não esteja.
O agente não precisa ser “malicioso”
Esse ponto muda bastante a maneira como o risco precisa ser entendido.
Não é necessário que uma inteligência artificial decida conscientemente escapar da sandbox.
Um atacante pode manipular arquivos ou configurações de um projeto para fazer com que o agente execute determinada sequência de operações.
O agente simplesmente realiza seu trabalho.
Abre o projeto.
Analisa os arquivos.
Executa Git.
Roda testes.
E justamente essa automação pode acionar o mecanismo preparado pelo atacante.
Portanto, o problema não depende necessariamente de uma IA “rebelde”.
Ele pode ser explorado através de técnicas tradicionais de cibersegurança combinadas com o comportamento automatizado dos agentes.
Prompt injection torna esse cenário ainda mais delicado
Existe uma segunda camada de risco.
Agentes de IA também podem interpretar conteúdo não confiável.
Um arquivo, página da internet, documentação ou repositório pode conter instruções criadas especificamente para manipular o comportamento do modelo.
Esse fenômeno é conhecido como prompt injection.
Separadamente, uma prompt injection pode convencer um agente a executar alguma ação indesejada.
Separadamente, uma falha de sandbox pode permitir que determinada ação alcance partes do sistema que deveriam estar protegidas.
Quando essas duas categorias aparecem juntas, o impacto potencial aumenta.
A prompt injection fornece o caminho para influenciar o agente.
A vulnerabilidade de isolamento pode fornecer o caminho para transformar essa influência em execução fora do ambiente protegido.
Agentes estão ampliando a superfície de ataque
Essa é uma diferença fundamental entre a geração anterior de ferramentas de IA e os novos agentes.
Um chatbot recebe uma pergunta e produz uma resposta.
Um agente recebe um objetivo e executa ações.
Quanto mais ações puder realizar, maior será sua superfície de ataque.
Se possui acesso ao terminal, existe risco relacionado à execução de comandos.
Se possui acesso ao navegador, existe risco relacionado ao conteúdo da web.
Se acessa repositórios, existe risco relacionado a arquivos não confiáveis.
Se utiliza credenciais, existe risco de exposição dessas credenciais.
Se possui acesso à infraestrutura de nuvem, as consequências podem alcançar ambientes corporativos inteiros.
Por isso, o modelo de segurança utilizado para um chatbot tradicional não é suficiente para agentes.
Empresas precisam tratar agentes como usuários privilegiados
Para organizações que estão adotando ferramentas como Claude Code, Codex e Cursor, existe uma consequência prática importante.
Agentes precisam ser tratados como software capaz de executar ações privilegiadas, e não apenas como assistentes inteligentes.
Isso significa aplicar princípios já conhecidos da cibersegurança.
Menor privilégio.
Separação de ambientes.
Credenciais temporárias.
Segmentação.
Controle de acesso.
Monitoramento.
Atualizações rápidas.
Auditoria de comandos.
E, sempre que possível, isolamento em nível de sistema ou máquina virtual.
A própria Accomplish argumenta que uma arquitetura mais robusta é executar todo o agente dentro de uma máquina virtual, de forma que processos auxiliares iniciados pelo sistema também permaneçam confinados.
“Sandbox” não deve ser interpretada como garantia absoluta
Talvez essa seja a principal lição do episódio.
A palavra sandbox transmite uma sensação de segurança bastante forte.
Mas existem diferentes maneiras de implementar isolamento.
Uma sandbox pode controlar apenas determinados comandos.
Outra pode isolar processos inteiros.
Outra pode utilizar containers.
Outra pode utilizar virtualização completa.
Para uma empresa avaliando agentes de IA, portanto, perguntar apenas “o produto possui sandbox?” começa a ser insuficiente.
As perguntas precisam ser mais específicas:
o que exatamente está isolado?
Quais processos podem executar fora da sandbox?
O agente possui acesso à rede?
Onde ficam as credenciais?
O que acontece quando ele abre um repositório não confiável?
E quanto tempo o fornecedor leva para corrigir uma falha crítica?
A velocidade dos patches passa a fazer parte da segurança da IA
Existe uma conclusão especialmente relevante no caso da Anthropic.
Nenhum software complexo está livre de vulnerabilidades.
Portanto, medir segurança apenas pela quantidade de falhas encontradas pode produzir uma visão distorcida.
A velocidade de resposta também importa.
Uma vulnerabilidade conhecida durante algumas horas representa uma exposição.
Durante uma semana, representa outra.
Durante várias semanas, o risco aumenta significativamente — especialmente quando a ferramenta está instalada em ambientes corporativos e possui acesso a código-fonte, credenciais e sistemas internos.
O episódio envolvendo Claude Code, Codex e Cursor mostra que a próxima grande discussão sobre segurança de agentes de IA talvez não esteja apenas nos próprios modelos.
Ela estará também em tudo aquilo que existe ao redor deles.
A IA está ganhando mãos — e isso muda a segurança
Durante muito tempo, o principal risco associado à inteligência artificial era receber uma resposta errada.
Os agentes mudaram essa equação.
Eles transformam respostas em ações.
Podem escrever código, modificar arquivos, utilizar ferramentas e executar comandos.
Isso significa que uma alucinação, uma prompt injection ou uma vulnerabilidade tradicional pode deixar de produzir apenas texto incorreto e começar a provocar consequências reais dentro de um computador.
As vulnerabilidades encontradas pela Accomplish não demonstram que Claude Code, Codex ou Cursor sejam inerentemente inseguros. Os problemas divulgados foram comunicados aos fornecedores e corrigidos.
Mas demonstram algo mais importante.
À medida que entregamos mais autonomia aos agentes, a fronteira de segurança entre a IA e o restante do computador precisa se tornar mais forte — não mais fraca.
Porque a próxima geração de inteligência artificial não estará apenas dizendo ao usuário o que fazer.
Ela estará fazendo.
E quando uma IA ganha acesso ao terminal, aos arquivos e às credenciais de uma empresa, uma sandbox deixa de ser apenas uma funcionalidade técnica.
Ela passa a ser uma fronteira de segurança.
