Vivendo perigosamente com Claude

Vou falar sobre duas coisas esta noite…

Por que você deveria sempre usar --dangerously-skip-permissions. (Isso atraiu aplausos da sala cheia de entusiastas do Claude Code.)

E por que você deveria nunca usar --dangerously-skip-permissions. (Isso não foi aplaudido.)

--dangerously-skip-permissions é um pouco complicado, então vou usar seu nome melhor, “modo YOLO”, para o resto desta apresentação.

Claude Code rodando neste modo realmente parece um produto completamente diferente do código Claude normal e padrão.

O modo padrão exige que você preste atenção constante a ele, rastreando tudo o que faz e aprovando ativamente alterações e ações a cada poucos passos.

No modo YOLO, você pode deixar Claude sozinho para resolver todos os tipos de problemas complicados enquanto você faz algo totalmente diferente.

Suspeito que muitas pessoas que não apreciam o valor dos agentes de codificação nunca experimentaram o modo YOLO em toda a sua glória.

Mostrarei três projetos que concluí com o modo YOLO nas últimas 48 horas.

Escrevi detalhadamente sobre isso em Fazendo o DeepSeek-OCR funcionar em um NVIDIA Spark por meio de força bruta usando Claude Code.

Eu queria experimentar o modelo DeepSeek-OCR recém-lançado em um NVIDIA Spark, mas para fazer isso é necessário descobrir como executar um modelo usando PyTorch e CUDA, o que nunca é fácil e é muito mais difícil em um dispositivo ARM64.

Eu fiz SSHd no Spark, iniciei um novo contêiner Docker e disse a Claude Code para descobrir. Demorou 40 minutos e três instruções adicionais, mas resolveu o problema, e pude tomar café da manhã e mexer em alguns outros projetos enquanto ele funcionava.

Este projeto começou no Claude Code para web. Estou eternamente interessado em opções para executar código Python do lado do servidor dentro de uma sandbox WebAssembly, por vários motivos. Decidi ver se o aplicativo Claude para iPhone poderia iniciar uma tarefa para descobrir isso.

Eu queria ver como era difícil fazer isso usando o Pyodide rodando diretamente no Node.js.

Claude Code fez funcionar e construiu e testou este script de demonstração mostrando como fazê-lo.

Comecei um novo repositório simonw/research para armazenar os resultados desses experimentos, cada um em uma pasta separada. Já são 5 projetos de pesquisa concluídos e eu os criei há menos de 2 dias.

Aqui está o meu favorito, um projeto desta manhã.

Decidi que queria experimentar o SLOCCount, uma ferramenta Perl da era de 2001 para contar linhas de código e estimar o custo para desenvolvê-las usando os salários dos desenvolvedores de 2001 nos EUA.

.. mas eu não queria rodar Perl, então decidi pedir a Claude Code (para web e mais tarde em meu laptop) que tentasse descobrir como executar scripts Perl no WebAssembly.

TLDR: chegou lá no final! Acontece que alguns dos scripts de suporte no SLOCCount foram escritos em C, então foi necessário compilá-los também no WebAssembly.

E agora tools.simonwillison.net/sloccount é um aplicativo baseado em navegador que executa Perl + C de 25 anos em WebAssembly em código colado, referências de repositório GitHub e até mesmo arquivos zip cheios de código.

O mais incrível é que todos esses três projetos nem eram uma prioridade para mim – eram missões secundárias, representando pura curiosidade que eu poderia terceirizar para Claude Code e resolver em segundo plano enquanto estivesse ocupado com outra coisa.

Realizei muito trabalho útil paralelamente a esses três vôos de fantasia.

Mas há uma razão --dangerously-skip-permissions tem aquele nome assustador. É perigoso usar Claude Code (e outros agentes de codificação) desta forma!

A razão para isso é injeção imediataum termo que criei há três anos para descrever uma classe de ataques contra LLMs que aproveitam a forma como o conteúdo não confiável é concatenado com instruções confiáveis.

(É nomeado após injeção SQL, que compartilha uma forma semelhante.)

Esta continua sendo uma vulnerabilidade incrivelmente comum.

Cunhei outro termo para tentar descrever um subconjunto comum de ataques de injeção imediata: a trifeta letal.

Sempre que um sistema LLM combina acesso a dados privados com exposição a conteúdo não confiável e o capacidade de se comunicar externamentehá uma oportunidade para os invasores enganarem o sistema e fazê-lo vazar esses dados privados de volta para eles.

Esses ataques são incrivelmente comum. Se você estiver executando agentes de codificação YOLO com acesso a códigos-fonte privados ou segredos (como chaves de API em variáveis ​​de ambiente), você precisa se preocupar com o potencial desses ataques.

Esta é a regra fundamental da injeção imediata: qualquer um quem pode colocar seus tokens em seu contexto deve ter controle total sobre o que seu agente fará a seguir, incluindo as ferramentas que ele chama.

Algumas pessoas tentarão convencê-lo de que os ataques de injeção imediata podem ser resolvidos usando mais IA para detectar os ataques. Isso não funciona de forma 100% confiável, o que significa que não é uma defesa de segurança útil.

A única solução credível é execute agentes de codificação em uma sandbox.

Os melhores sandboxes são aqueles que rodam no computador de outra pessoa! Dessa forma, o pior que pode acontecer é o computador de outra pessoa ser adquirido.

Você ainda precisa se preocupar com o vazamento do seu código-fonte. De qualquer forma, a maior parte do meu material é de código aberto, e muito do código em que tenho agentes trabalhando é código de pesquisa sem segredos proprietários.

Se o seu código for realmente sensível, você precisará considerar as restrições de rede com mais cuidado, conforme discutido em alguns slides.

Existem muitos sandboxes excelentes que rodam nos computadores de outras pessoas. OpenAI Codex Cloud, Claude Code for the web, Gemini Jules são excelentes soluções para isso.

Também gosto muito dos recursos de interpretação de código integrados aos aplicativos de consumo ChatGPT e Claude.

Há dois problemas a serem considerados com o sandbox.

A primeira é fácil: você precisa controlar quais arquivos podem ser lidos e gravados no sistema de arquivos.

A segunda é muito mais difícil: controlar as conexões de rede que podem ser feitas por código rodando dentro do agente.

A razão pela qual o acesso à rede é tão importante é que ele representa a etapa de exfiltração de dados da trifeta letal. Se você puder impedir a comunicação externa com um invasor, ele não poderá roubar suas informações privadas, mesmo que consiga inserir suas próprias instruções maliciosas.

Claude Code CLI desenvolveu um novo recurso de sandbox ontem, e a Anthropic lançou uma nova biblioteca de código aberto mostrando como funciona.

A chave para a implementação – pelo menos no macOS – é o pouco conhecido, mas poderoso, da Apple sandbox-exec comando.

Isso fornece uma maneira de executar qualquer comando em um sandbox configurado por um documento de política.

Essas políticas podem controlar quais arquivos estão visíveis, mas também podem incluir conexões de rede na lista de permissões. O Anthropic executa um proxy HTTP e permite que o ambiente Claude Code se comunique com ele e, em seguida, use o proxy para controlar com quais domínios ele pode se comunicar.

(Usei o próprio Claude para sintetizar este exemplo a partir da base de código da Anthropic.)

… a má notícia é que sandbox-exec foi marcado como obsoleto na documentação da Apple desde pelo menos 2017!

Também é usado pelo Codex CLI e ainda é a maneira mais conveniente de executar um sandbox em um Mac. Espero que a Apple reconsidere.

Então vá em frente e viva perigosamente!

(Mas faça isso em uma caixa de areia.)