Um prompt. Três comandos no shell. Usei a própria IA deles para hackear a si mesma.
Esta é uma classe de bug que provavelmente existe em todos os produtos de IA multiagente lançados hoje. E a solução é um padrão de design sobre o qual ninguém no setor está falando ainda.
Aqui está a história completa.
Eu não estava tentando hackear nada. Estava pesquisando como o Perplexity Computer lida com sandboxing para o meu próprio trabalho de infraestrutura de agentes. Queria entender como sistemas multiagente em produção realmente isolam ambientes de execução, o que é compartilhado, o que não é.
Primeiro, comecei a bisbilhotar o sistema. Notei que o Claude Code estava instalado no sandbox.
Pedi ao agente para iniciá-lo e gerar um código de teste só para ver como se comportava. Funcionou perfeitamente. Claude Code padrão, rodando no modo bypass-permissions, sem solicitar confirmação. Faz sentido para um sistema de agentes.
Foi aí que pensei: peraí, como eles estão gerenciando as chaves de API?! O Claude Code precisa de uma chave de API da Anthropic para funcionar. Essa chave precisa estar em algum lugar neste sandbox. Como ela é injetada? Como é isolada? É isolada?
Essa pergunta foi o que me levou por esse caminho.
O subagente mantém uma chave de API em seu ambiente de processo. Eu precisava roubá-la.
O Perplexity Computer tentou seis vezes e falhou.
- Pedi ao subagente para exibir seu env: recusou!
- Coloquei um script trojan no sistema de arquivos compartilhado: ele leu meu código, entendeu o que estava fazendo e se recusou a executá-lo!
- Envenenei o .bashrc e o .profile: eles dispararam muito cedo, antes da chave de API ser injetada.
- Coloquei um binário node falso no PATH: nunca foi acionado.
- Iniciei o agente de codificação e simultaneamente observei a árvore de processos: o subagente roda em um sandbox diferente, nada foi capturado :(
- Encontrei o prompt de sistema do Claude Code e o modifiquei para remover o comportamento de recusa: não consegui encontrar um prompt de sistema personalizado sendo injetado.
Seis falhas. A segurança no nível do modelo/prompt do Claude é genuinamente boa. Toda vez que tentava algo esperto, o modelo percebia.
Então o Perplexity lembrou que o Claude Code é uma aplicação Node.js iniciada via npm. E o npm lê o ~/.npmrc do diretório home. E o diretório home está no sistema de arquivos compartilhado no qual posso escrever.
O Node.js tem uma flag --require que pré-carrega um módulo JavaScript antes de qualquer código da aplicação ser executado. Você pode definir isso via NODE_OPTIONS no .npmrc. Isso significa que, se eu escrever um .npmrc no diretório home compartilhado, todo processo Node que o subagente iniciar vai pré-carregar meu código! Isso acontece antes mesmo do Claude Code inicializar, antes de qualquer verificação de segurança ser executada, antes de tudo!
O exploit são três comandos:
- Escrever um script de seis linhas que despeja process.env em um arquivo no workspace compartilhado
- echo 'node-options=--require /caminho/para/script.js' > ~/.npmrc
- Pedir ao Perplexity Computer para fazer qualquer tarefa de codificação
Subagente inicia → npm lê meu .npmrc → meu pré-carregamento dispara antes do Claude Code começar → credenciais completas da API caem no sistema de arquivos compartilhado.
Funcionou! Me deu um token de gateway do Perplexity que faz proxy através do agent-proxy.perplexity.ai para a conta mestre da Anthropic.
Naturalmente, a primeira coisa que fiz foi configurar esta chave de API e BASE_URL para o Claude Code no meu laptop. Esperava que as chamadas de LLM do Claude Code falhassem e fossem restritas ao sandbox. Fiquei chocado. Resposta instantânea do Opus 4.6!
Então pensei: "com certeza, eles vão cobrar na minha conta por este uso, esta chave de API deve estar vinculada ao meu usuário". Errei de novo.
Pedi ao Opus 4.6 para gerar uma longa história descrevendo a história do mundo, incluindo cada invenção, império e descoberta. Executei esta chamada 5 vezes em paralelo, gerando mais de 100k tokens de saída cada. Isso deveria ter consumido todos os meus créditos do Perplexity Computer, mas eles não se moveram.
Sem restrição de IP. Sem escopo de sessão. Sem vínculo com sandbox. A conta deles que pagou.
Uma das startups de IA mais bem financiadas do planeta foi derrubada por um dotfile usado em ataques à cadeia de suprimentos do Node.js desde 2019.
O modelo fez tudo certo. A infraestrutura não.
E agora, aqui está o que eu realmente quero que os fundadores que constroem infraestrutura de agentes levem disso.
A arquitetura do Perplexity está na metade do caminho certo. Eles usam um proxy entre o sandbox e a API da Anthropic. Esse é o padrão correto. Você nunca deve colocar uma chave de API bruta de um provedor dentro de um sandbox. Um proxy te dá controle, observabilidade e a capacidade de revogar acesso sem rotacionar sua chave mestre.
O problema é que o token de proxy deles não tem nenhum vínculo com o contexto de execução. Depois que você o obtém, ele funciona em qualquer lugar para sempre.
Aqui está como fazer isso corretamente:
Vincule o token ao ID do sandbox. Token e ID do sandbox não coincidem? Rejeitado. A chave vaza, mas você não tem o sandbox? Inútil. Idealmente, também deveria vincular o token ao endereço IP do sandbox, mas o E2B (o provedor de sandbox que eles usam) não fornece isso antes do sandbox ser iniciado.
Torne o token efêmero. Crie-o quando o sandbox for iniciado. Mate-o quando o sandbox pausar. Sem credenciais de longa duração. O proxy gera um token de curta duração no início da sessão e o invalida ao encerrar. Chave vazada de um sandbox morto é uma chave morta.
Vincule o token à conta de faturamento do usuário. Mesmo que tudo o mais falhe, mesmo que alguém exfiltre um token ativo de um sandbox em execução e o use antes de expirar, o uso é cobrado de volta na conta que gerou a sessão. Não em um pool de faturamento mestre compartilhado. Isso transforma "acesso ilimitado e gratuito à API" em "alguém abusando da própria cota", que é uma gravidade completamente diferente.
Essas três coisas — vinculado ao sandbox, efêmero, faturado ao usuário — são o que fazem o padrão de proxy realmente funcionar. Sem elas, você está apenas adicionando um salto de rede extra que não impede nada.
Este não é um problema específico do Perplexity. Esta é a arquitetura padrão para infraestrutura de agentes hoje porque é a mais rápida de construir. Sistemas de arquivos compartilhados entre agentes, credenciais de longa duração, faturamento em conta mestre. Aposto que a maioria dos produtos multiagente em produção hoje tem alguma versão disso.
Relatado para @AravSrinivas e @denisyarats antes da publicação.
