Um prompt. Três comandos de shell. Usei a própria IA deles para hackeá-la.
Este é um tipo de bug que provavelmente existe em todo produto de IA multiagente lançado hoje. E a correção é um padrão de design que ninguém no setor está discutindo ainda.
Aqui está a história completa.
Não estava tentando hackear nada. Estava pesquisando como o Perplexity Computer lida com sandboxing para meu próprio trabalho de infraestrutura de agentes. Estava tentando entender como sistemas multiagente de produção realmente isolam ambientes de execução, o que é compartilhado, o que não é.
Primeiro, comecei a fuçar o sistema. Percebi que o Claude Code estava instalado no sandbox.
Eu fiz o agente iniciá-lo e gerar um código de teste só para ver como se comportava. Funcionou bem. Claude Code padrão, rodando em modo bypass-permissions, sem pedir confirmação. Faz sentido para um sistema agêntico.
Foi quando pensei: espera, como eles estão lidando com as chaves de API? O Claude Code precisa de uma chave API da Anthropic para funcionar. Essa chave tem que estar em algum lugar no sandbox. Como ela está sendo injetada? Como é escopada? É isolada?
Essa pergunta 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 despejar seu env: recusou!
- Plantei um script trojan no sistema de arquivos compartilhado: ele leu meu código, entendeu o que estava fazendo e se recusou a executar!
- Envenenei .bashrc e .profile: eles dispararam cedo demais, antes da chave de API ser injetada.
- Coloquei um binário falso do node no PATH: nunca foi acionado.
- Spawn o agente de codificação e simultaneamente observo a árvore de processos: o subagente roda em um sandbox diferente, nada foi capturado :(
- Encontrar o prompt de sistema do Claude Code e modificá-lo para remover o comportamento de recusa: não consegui encontrar um prompt de sistema personalizado sendo injetado.
Seis falhas. A segurança em nível de modelo/prompt do Claude é genuinamente boa. Toda vez que tentava algo esperto, o modelo percebia.
Então o Perplexity lembrou que o Claude Code é um aplicativo Node.js iniciado via npm. E o npm lê ~/.npmrc do diretório home. E o diretório home está no sistema de arquivos compartilhado no qual posso escrever.
Node.js tem uma flag --require que pré-carrega um módulo JavaScript antes de qualquer código do aplicativo ser executado. Você pode definir isso via NODE_OPTIONS no .npmrc. O que significa que se eu escrever um .npmrc no diretório home compartilhado, todo processo Node que o subagente criar irá pré-carregar meu código! Isso acontece antes mesmo de o Claude Code inicializar, antes de qualquer verificação de segurança, 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 de API caem no sistema de arquivos compartilhado.
Funcionou! Me deu um token de gateway do Perplexity que faz proxy através de agent-proxy.perplexity.ai para a conta mestre da Anthropic.
Naturalmente, a primeira coisa que fiz foi definir essa chave de API e BASE_URL para o Claude Code no meu laptop. Eu 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 esse uso, essa chave de API deve estar vinculada ao meu usuário". Estava errado novamente.
Fiz o Opus 4.6 gerar uma longa história descrevendo a história do mundo, incluindo cada invenção, império e descoberta. Executei essa chamada 5 vezes em paralelo, gerando 100k+ tokens de saída de cada. Isso deveria ter consumido todos os meus créditos do Perplexity Computer, mas eles não se moveram.
Não restrito por IP. Não escopado por sessão. Não vinculado ao sandbox. A conta deles pagou.
Uma das startups de IA mais bem financiadas do planeta foi dominada por um arquivo dotfile que é usado em ataques à cadeia de suprimentos do Node.js desde 2019.
O modelo fez tudo certo. A infraestrutura não.
Agora, aqui está o que realmente quero que os fundadores que estão construindo infraestrutura de agentes levem disso.
A arquitetura do Perplexity está meio certa. 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 provedor dentro de um sandbox. Um proxy lhe 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 tem, 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 correspondem? Rejeitado. A chave vaza, mas você não tem o sandbox? Inútil. Idealmente, deve vincular o token ao endereço IP do sandbox também, 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 no encerramento. Chave vazada de um sandbox morto é uma chave morta.
Vincule o token à conta de cobrança do usuário. Mesmo que tudo mais falhe, mesmo que alguém exfiltre um token vivo de um sandbox ativo e o use antes de expirar, o uso é cobrado de volta para a conta que gerou a sessão. Não para um pool mestre de cobrança 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, cobrado do 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 para nada.
Este não é um problema específico do Perplexity. Esta é a arquitetura padrão para infraestrutura de agentes no momento, porque é a mais rápida de construir. Sistemas de arquivos compartilhados entre agentes, credenciais de longa duração, cobrança 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.
