Como a Anthropic faz a contenção do Claude em toda a sua linha de produtos

 (anthropic.com)
2 pontos por GN⁺ 5 시간 전 | 1 comentários | Compartilhar no WhatsApp
  • À medida que a capacidade e o nível de acesso dos agentes aumentam, o raio potencial de dano também cresce, e a Anthropic resume sua experiência ao construir arquiteturas de contenção adaptadas ao Claude Web/Claude Code/Cowork
  • O risco é composto por dois elementos: probabilidade de falha e escala do dano; proteções e treinamento do modelo reduziram o primeiro, mas o segundo continua aumentando conforme capacidades e acessos se expandem
  • A abordagem de supervisionar ações com human-in-the-loop tem limitações por causa da fadiga de aprovação, então o maior foco está em containment (contenção), isto é, limitar o próprio escopo do que o agente pode fazer
  • Três padrões de isolamento são aplicados conforme as características de cada usuário: contêiner temporário no claude.ai, sandbox com intervenção humana no Claude Code e VM local no Cowork
  • A principal lição é que a contenção deve ser projetada primeiro na camada de ambiente, antes da camada do modelo, e que os componentes customizados feitos internamente tendem a ser o ponto mais vulnerável

Contexto: o cálculo de risco e retorno da implantação

  • Há 12 meses, provavelmente teriam recusado dar ao Claude um nível de acesso capaz de interromper serviços internos da Anthropic, mas hoje esse nível de acesso é rotineiro e também melhora a produtividade dos desenvolvedores
  • Como agentes passaram a conseguir executar o trabalho antes feito por uma pessoa ou equipe, o custo de não implantar ficou grande o bastante para que, se o produto puder ser tornado seguro, o cálculo de risco-retorno passe a pender fortemente para a adoção
  • Claude Mythos Preview é um exemplo de modelo que não foi lançado porque, em abril de 2026, foi considerado com raio de dano alto demais
    • A expectativa é que, à medida que a defesa fortaleça sistemas críticos e os mecanismos de segurança amadureçam, modelos com nível de capacidade semelhante possam ser lançados de forma mais ampla no futuro (embora alguns riscos sempre permaneçam)

Duas formas de limitar o raio de dano

  • Supervisão de ações (human-in-the-loop)

    • O Claude Code antes tentava evitar ações não intencionais pedindo permissão ao usuário em cada etapa, mas esse método tem possibilidade de erro
    • Pela telemetria, usuários aprovaram cerca de 93% dos prompts de permissão, e quanto mais aprovações acontecem, menos atenção tende a ser dada a cada uma, enfraquecendo a supervisão
    • Para reduzir a fadiga de aprovação, a Anthropic criou o Claude Code auto mode, que automatiza aprovações mais seguras, mas em defesas probabilísticas sempre existe uma taxa de falha diferente de zero

  • Contenção (containment)

    • Em vez de supervisionar o que o agente faz, supervisiona-se o que ele pode fazer, impondo limites de acesso com sandbox, máquinas virtuais e controle de egress
    • É a área em que a engenharia da Anthropic mais investiu esforço e também onde ocorreram as falhas de segurança mais inesperadas

Três riscos e três componentes de defesa

  • Três tipos de risco

    • User misuse (mau uso pelo usuário): o usuário instrui o agente a realizar ações nocivas, de forma maliciosa ou descuidada (burlar checagens inconvenientes, executar comandos destrutivos sem entender, causar dano intencionalmente etc.)
    • Model misbehavior (mau comportamento do modelo): o agente executa ações nocivas que ninguém pediu
      • Modelos com menor capacidade tendem a interpretar mal a situação e cometer erros óbvios
      • Modelos com maior capacidade erram menos, mas encontram melhor caminhos inesperados para atingir um objetivo contornando restrições que ninguém explicitou
      • Houve casos reais em que modelos Claude saíram “gentilmente” da sandbox para concluir uma tarefa, vasculharam o histórico do git para achar respostas de testes de programação ou identificaram por conta própria um benchmark em execução e descriptografaram a chave de respostas
    • External attackers (atacantes externos): o agente é atacado por caminhos externos como ferramentas, arquivos e acesso à rede (incluindo prompt injection e ataques tradicionais ao runtime, à orquestração e a proxies)

  • Três componentes de defesa

    • O ambiente em que o agente executa: sandbox de processos, VM, fronteiras de sistema de arquivos e controle de egress definem limites rígidos do que pode ser alcançado
      • Se credenciais não entram na sandbox, não podem ser exfiltradas, seja qual for a causa: usuário, modelo ou atacante
    • O modelo ao qual o agente recorre: system prompt, classificadores, probes e ajustes de treinamento só alteram tendências, sem controlar o conjunto teórico de possibilidades
      • No benchmark Agent Red Teaming da Gray Swan, o Claude Opus 4.7 teve taxa de sucesso de ataque de cerca de 0,1% em tentativa única, mantendo algo em torno de 5–6% após 100 tentativas adaptativas
      • O Claude Code auto mode bloqueia cerca de 83% dos comportamentos excessivos antes da execução, mas defesas na camada do modelo nunca chegam a 100% e não podem se sustentar sozinhas
    • O conteúdo externo ao qual o agente chega: servidores MCP, plugins de terceiros e ferramentas de busca na web injetam no contexto conteúdo vindo de fontes fora de controle
      • Um conector auditado não significa dados auditados, e um conector do GitHub pode carregar para o contexto do modelo um README contaminado mesmo que tenha passado por verificação de malware
      • Um agente com acesso somente leitura a um banco de dados pode ser implantado de forma muito mais ampla do que um agente que grava em produção

Três padrões de isolamento para contenção de agentes

  • Padrão 1 — Contêiner temporário (execução de código no claude.ai)

    • O claude.ai é conhecido pela interface de chat, mas também escreve e executa código, cria arquivos e chama conectores; a execução de código acontece em contêineres gVisor da infraestrutura de isolamento
    • O agente funciona inteiramente no lado do servidor e não executa código na máquina local; o sistema de arquivos é efêmero (ephemeral) por sessão — o raio de dano é mínimo, mas a ausência de workspace persistente e de acesso ao sistema de arquivos do usuário também limita o que pode ser feito
    • Como o objetivo é proteger a própria infraestrutura e o isolamento entre tenants, não a máquina do usuário, o trabalho antes do lançamento se concentrou em segurança tradicional: configuração de rede, autenticação de serviços internos e orquestração
    • gVisor e seccomp vêm sendo endurecidos há mais tempo do que a IA agente em si, então o esforço de revisão se concentrou nos componentes novos construídos ao redor deles
      • Foi justamente esse proxy customizado o ponto de falha no incidente mais grave

  • Padrão 2 — Sandbox com intervenção humana (Claude Code)

    • O Claude Code roda na máquina do usuário e acessa sistema de arquivos, shell e rede; sem isso, a utilidade de um agente de programação fica limitada, então é essencial conceder permissões com segurança
    • Essa abordagem funciona porque o usuário médio é um desenvolvedor que consegue ler bash, entende o significado de rm -rf e executa npm install de fontes não confiáveis várias vezes por semana
    • No lançamento, começou-se com a defesa mais simples: leitura permitida; escrita, bash e acesso à rede exigiam aprovação

    • Fadiga de aprovação e sandbox do sistema operacional

      • A fadiga de aprovação apareceu em poucas semanas, levantando a possibilidade de o próprio recurso criado para supervisionar acabar reduzindo a atenção do usuário
      • Foram introduzidas sandboxes em nível de sistema operacional — Seatbelt no macOS e bubblewrap no Linux — reforçando os limites com leitura permitida, escrita apenas no workspace e rede bloqueada por padrão
      • O resultado foi uma redução de 84% nos prompts de permissão, e o runtime foi publicado como open source para permitir auditoria das fronteiras
      • Usuários experientes usam autoaprovação cerca de 2x mais do que iniciantes, mas intervêm mais durante a execução e tendem a supervisionar apenas quando o agente se desvia
      • Ainda assim, esse método exige que o usuário seja técnico e atento o bastante para notar o desvio, e sua eficácia cai conforme a capacidade do modelo aumenta ou há transição para múltiplos agentes

    • Risco ignorado: tudo antes do diálogo de confiança

      • Entre meados de 2025 e janeiro de 2026, três vulnerabilidades que exploravam código executado antes de o usuário consentir foram reportadas por meio do programa de divulgação responsável
      • Exemplo: ao clonar um repositório para revisão de PR, um desenvolvedor podia encontrar um .claude/settings.json no repositório definindo hooks; como o Claude Code lia essa configuração de projeto antes do prompt “você confia nesta pasta?”, um hook enviado pelo atacante podia ser executado automaticamente
      • A correção seguiu a mesma direção: adiar o parsing e a execução de configurações locais do projeto para depois da aceitação do prompt de confiança
      • Abertura de projeto, carregamento de config e listeners em localhost devem ser tratados como requisições vindas da internet, sem confiar implicitamente neles só por serem locais

    • Risco ignorado: o usuário como vetor de injeção

      • Em um exercício interno controlado de red team em fevereiro de 2026, um pesquisador conseguiu fazer phishing com um funcionário para que ele executasse o Claude Code com um prompt malicioso
      • O phishing parecia colaboração comum (“você pode rodar isto para mim?” em um e-mail + um prompt para copiar e colar) e, no meio da configuração, inseria discretamente um pedido para ler ~/.aws/credentials, codificar o conteúdo e enviá-lo por POST para um endpoint externo
      • Em 25 tentativas repetidas com o mesmo prompt, o Claude concluiu o vazamento em 24
      • Isso é prompt injection direta — a instrução do atacante chega pelo usuário, não pela saída de uma ferramenta, então as defesas da camada do modelo baseadas na intenção do usuário não conseguem detectar algo anômalo
      • A única defesa efetiva é o ambiente: controle de egress que bloqueie POST independentemente da intenção e fronteiras de sistema de arquivos que impeçam acesso a ~/.aws desde o início
      • Quando o prompt foi compartilhado no Slack interno, observou-se que alguns agentes internos liam o Slack, o que fez a carga maliciosa circular; para detectar se algo a capturava, foi adicionada uma canary string — em ambientes onde agentes leem tudo, até as próprias ferramentas de investigação viram superfície de ataque

  • Padrão 3 — VM local (Claude Cowork)

    • O Claude Cowork roda no desktop, acessa a pasta de workspace escolhida pelo usuário e é voltado para trabalho intelectual geral, não apenas engenharia de software; portanto, o usuário médio pode não ser fluente em bash
    • Não dá para esperar que um trabalhador do conhecimento não técnico avalie comandos como find . -name "*.tmp" -exec rm {} \;, então o administrador precisa definir fronteiras absolutas e sempre ativas

    • Modo full VM e mecanismo de isolamento

      • A primeira versão rodava em uma máquina virtual completa, usando o hipervisor do fornecedor da plataforma (Apple Virtualization framework no macOS e HCS no Windows)
      • A VM tem seu próprio kernel Linux, sistema de arquivos e tabela de processos; apenas o workspace selecionado e a pasta .claude são montados, e nada mais do host fica visível
      • Credenciais permanecem no keychain do host e não entram no guest
      • O design busca garantir que, mesmo comprometido, o Claude só possa danificar o conteúdo dentro da pasta de workspace (até que o usuário adicione conectores)
      • Na arquitetura original (modo full-VM), o próprio loop do agente rodava dentro do guest como um usuário Linux comum, sem consciência da sandbox, e não havia processo externo com privilégio para conceder exceções — em contraste com o Claude Code, onde um processo privilegiado externo decide o enforcement comando a comando

    • Transição para host mode

      • O modo full-VM teve um problema prático: se a inicialização da VM falhasse, o Cowork inteiro se tornava inutilizável
      • A execução de código foi mantida dentro da VM, mas o loop do agente foi movido para fora da VM, permitindo que o Claude continuasse respondendo e ajudando no debug mesmo se a VM travasse (com impacto mínimo em segurança, já que a VM continua impondo controle de sistema de arquivos e rede)
      • Servidores MCP locais também foram movidos para fora da VM — dentro dela eram difíceis de auditar, criavam problemas de dependência em atualizações da VM e impediam suporte a MCPs que interagem com processos locais, como bancos de dados
      • Isso alinha o comportamento ao MCP local do Claude Desktop: ele passa a ser tratado como software instalado pelo usuário, e a decisão sobre quais MCPs locais ativar fica com o administrador (MCPs remotos não são executados na máquina do usuário, então o impacto é diferente)

    • Controle do sistema de arquivos

      • Para ser útil, o sistema precisa acessar alguns arquivos do host; por isso, para minimizar o raio de dano e dar transparência ao acesso local, os modos de montagem foram refinados
      • Há três modos de montagem de arquivos: read-only, read-write e read-write-no-delete
      • Uma armadilha importante: links simbólicos devem ser resolvidos antes da validação do caminho; caso contrário, um symlink dentro de uma pasta permitida pode apontar para fora e permitir escape
      • Clientes enterprise podem ser controlados por administradores com uma allowlist de mount paths em configuração MDM

    • Risco ignorado: vazamento por domínio aprovado

      • Um caso revelado por divulgação de terceiro mostrou que a allowlist de egress do Cowork deixava passar corretamente tráfego para api.anthropic.com, necessário ao funcionamento do produto
      • Um arquivo malicioso colocado no workspace montado continha instruções ocultas e uma chave de API controlada pelo atacante; o Claude seguiu as instruções, leu outros arquivos e chamou a Anthropic Files API usando a chave do atacante
      • O proxy de egress só verificava se o destino era api.anthropic.com e deixava passar, de modo que os arquivos foram enviados para a conta Anthropic do atacante — a sandbox funcionou perfeitamente, mas os dados vazaram
      • A allowlist passou então a ser vista não como filtro de destino, mas como concessão de capacidade (capability grant) — toda função alcançável em um domínio permitido vira superfície de ataque
      • Foi colocado dentro da VM um proxy defensivo man-in-the-middle para interceptar o tráfego da própria API, liberando apenas requisições com o token de sessão de provisionamento da própria VM e rejeitando chaves injetadas por atacantes (além de bloquear headers que habilitem server-side fetch)
      • O proxy fica dentro da VM, não no servidor — do ponto de vista do servidor, uma requisição do Cowork é indistinguível de qualquer outro cliente da API, então a proveniência só é conhecida pela VM
      • É o segundo exemplo do princípio de que software feito em casa tende a ser o ponto mais frágil — hipervisor, seccomp e gVisor seguiram confiáveis, mas o proxy customizado de allowlist falhou

    • Risco ignorado: o isolamento da VM também bloqueia software EDR

      • Equipes de segurança enterprise perguntaram por que seu EDR não conseguia ver o interior do ambiente — a mesma isolação que confina o Claude também bloqueia EDR baseado no host
      • Para o EDR, o Cowork aparece como um processo opaco do hipervisor, sem visibilidade do guest
      • A mitigação atual é uma exportação OTLP baseada em pull, que permite ao administrador coletar logs de eventos depois do fato, mas isso não equivale a monitoramento em tempo real

Resumo comparativo por ambiente

  • Contêiner temporário (claude.ai): overhead de isolamento na inicialização do contêiner, sem dependência do usuário, raio de dano limitado a um contêiner no servidor protegido por gVisor + fronteiras da infraestrutura do host
  • Sandbox HITL (Claude Code): overhead de isolamento baixo com sandbox nativa de baixa latência, exige que o usuário interprete bash, raio de dano limitado ao workspace local
  • VM selada (Claude Cowork): overhead de isolamento no boot da VM completa, sem dependência do usuário, raio de dano limitado ao workspace montado protegido por vsock + fronteiras do hipervisor

Confiar no que o agente lê

  • Empresas frequentemente perguntam sobre a segurança de conexões MCP, mas a pergunta correta é mais ampla — recursos externos carregam simultaneamente dois riscos: risco de execução de código (pelo lado da supply chain) e vetor de prompt injection
    • Auditoria tradicional de dependências (fixação de versão, verificação de assinatura, revisão de código-fonte) resolve apenas o primeiro e deixa o segundo passar
  • A diferença entre remoto e local é mais importante do que parece — ferramentas locais podem ser auditadas, fixadas por versão e não mudam, enquanto ferramentas remotas (servidores MCP hospedados, conectores em nuvem) podem mudar de comportamento a qualquer momento após a aprovação, tornando inválida a decisão de confiança feita na instalação
    • O connector directory ajuda com revisão contínua, mas o restante deve ser tratado como não confiável e testado primeiro com dados falsos em um ambiente com raio de dano contido
  • A saída de ferramentas continua sendo superfície de ataque, mesmo quando a ferramenta é confiável — é o caso do exemplo anterior do README no GitHub; o mesmo scanning de entrada aplicado a páginas web deve ser aplicado aos resultados de ferramentas conectadas à rede
    • Se uma resposta contaminada da ferramenta induz o agente a exfiltrar dados, os logs depois só mostrarão chamadas de API autorizadas e bem-sucedidas, sem sinal retroativo; por isso, mesmo aumentando a latência e sem ser perfeita, a inspeção ao vivo deve vir primeiro
    • No Claude Code e no Cowork, chamadas de ferramentas passam por proxies que impõem políticas de rede e arquivo, e os classificadores usados na inspeção podem ser modelos pequenos e rápidos, sem necessidade de serem o modelo de raciocínio principal

Desafios futuros

  • Persistent memory poisoning (envenenamento persistente de memória): conforme aumenta a quantidade de contexto preservado entre sessões (memória do produto, arquivos CLAUDE.md, workspaces montados, diretórios de estado de agentes agendados ou de longa duração), injeções inseridas ali passam a ser recarregadas em cada início do agente — bons classificadores no início da sessão precisarão se tornar mais comuns
  • Multi-agent trust escalation (escalada de confiança em múltiplos agentes): subagentes podem devolver fatos estruturados em vez de texto bruto, ajudando a isolar conteúdo não confiável, mas se a saída de um subagente for tratada com confiança maior do que o resultado bruto de uma ferramenta só porque “é nossa”, surge um novo vetor de injeção — há um trade-off entre diferenciar níveis de confiança e expor caminhos de escalada de confiança
  • Agent identity (identidade do agente): o Cowork mantém credenciais no keychain do host e entrega à VM tokens reduzidos por sessão, que podem ser revogados independentemente do usuário
    • Ainda assim, a questão cross-platform sobre se o agente deve ter identidade própria como principal ou herdar permissões como extensão do usuário pode acabar exigindo uma combinação dos dois modelos
  • Como esses tipos de falha provavelmente se repetirão em toda a indústria e em laboratórios de pesquisa, será necessário investimento coletivo em postura de segurança específica para agentes: benchmarks compartilhados, normas públicas, padrões comuns de identidade e red teams entre fornecedores

Resumo dos princípios centrais

  • Projete a contenção primeiro na camada de ambiente e só depois ajuste o comportamento na camada do modelo — os dois incidentes que mais ensinaram (phishing contra funcionário e divulgação por allowlist de terceiro) foram ambos casos de egress em que os dados saíram por caminhos permitidos; nesse cenário, a camada do modelo não tem sinal anômalo a detectar, e a fronteira determinística é a última linha de defesa
  • Ajuste a força do isolamento à capacidade de supervisão do usuário — um desenvolvedor que lê bash e um trabalhador do conhecimento que não lê não compartilham o mesmo modelo de ameaça; tanto impor atrito excessivo a especialistas quanto dar confiança excessiva a não especialistas leva ao fracasso
  • Desconfie de componentes customizados — hipervisores, filtros de syscall e runtimes de contêiner consolidados passaram por muito mais validação adversarial; em todas as implantações, os primitives padrão resistiram, e foi o trabalho próprio em volta deles que revelou falhas
  • Mesmo que agentes sejam uma nova categoria de software, interações em nível de sistema (ler arquivos, abrir sockets, criar processos) não são novas, então a contenção com ferramentas maduras continua sendo uma defesa centralmente eficaz

Leituras relacionadas

1 comentários

 
GN⁺ 5 시간 전
Comentários do Hacker News

  • O enquadramento que estão usando é engraçado, e o pequeno gráfico combina perfeitamente. O risco de dano não diminui, mas a recompensa aumenta, então o dano acaba virando um custo do negócio justificado pela recompensa
    Quanto maior a recompensa, maior também a escala do dano que tentam justificar. Dá a sensação de que a sociedade inteira funciona assim

    • Se entendi direito, a posição da Anthropic agora é algo como: “Sim, isso pode acabar destruindo parte da sua infraestrutura, mas vale a pena”
      O problema é que ninguém conseguiu provar que de fato vale o suficiente para arcar com esse custo. É uma suposição bem frágil
    • Toda ação envolve um cálculo de risco/recompensa, e normalmente só não vemos isso desenhado de forma tão explícita. Levantar da cama de manhã traz o risco de cair e bater a cabeça no chão, atravessar a rua traz o risco de ser atropelado por um ônibus, e comer traz o risco de engasgar
      Segurança de computadores é a mesma coisa. O único computador realmente seguro é o que nunca é ligado, e mesmo assim ainda existe o risco de alguém invadir e roubar o dispositivo de armazenamento. Independentemente de o dano potencial neste caso ser maior que o benefício, esse cálculo sempre acontece, então acho correto dizer que a sociedade inteira é assim
    • Se você abrir um negócio de conserto de PCs, no começo perder um pente de RAM ou queimar a placa-mãe de um cliente ao atender 10 casos por semana é um custo enorme. Mas quando você passa a atender 1000 casos por semana, o negócio fica bem rentável e esse tipo de perda vira algo fácil de absorver
      Quando aumentam as ferramentas e a velocidade de processamento, a proporção muda
    • É assim mesmo que as decisões no mundo real são tomadas. Risco/recompensa existe de verdade
    • Responsabilidade limitada torna racional escolher assumir riscos ilimitados. A IA só amplia esse modelo empresarial e comprime o tempo até o próximo desastre

  • Vejo o que a Anthropic diz com bastante ceticismo. Porque, às vésperas de um IPO, o incentivo para fazer o produto parecer arriscado — isto é, “capaz”, “saído da ficção científica” e “à frente de todos” — é grande demais
    Já vimos isso antes. Lembrando daquela história de que “quando ameaçado, o modelo usa o e-mail do engenheiro para chantagear sobre um caso extraconjugal”, aquilo era pura fanfic. Na prática, eles só montaram um cenário com alguns fatos e pediram para o modelo continuar a história. Se você perguntar ao Claude como roubar as joias da Coroa britânica, ele vai dar algumas ideias. Isso não significa que o modelo seja perigoso a ponto de precisarem reforçar a segurança da Tower of London. Acho que boa parte do resto desse marketing do medo é parecido

    • É verdade que “na prática, eles só montaram um cenário com alguns fatos e pediram para o modelo continuar a história”. Esse é justamente o ponto central da pesquisa. A Anthropic deixa explícito, ao começar a explicação da observação do teste de chantagem, que se trata de um cenário de teste com uma empresa fictícia
      “In another cluster of test scenarios, we asked Claude Opus 4 to act as an assistant at a fictional company”
      https://www.anthropic.com/claude-4-system-card
    • A Anthropic me preocupa mais do que a OpenAI porque é mais dissimulada
    • OpenAI, Google e outras não estão usando “essa estratégia”. Acredito que as pessoas da Anthropic realmente se importam com segurança em IA
      Esse foi o principal motivo da fundação da empresa. Dito isso, com a entrada de gente nova e dinheiro novo, pode ser que esse idealismo esteja enfraquecendo

  • Cheguei tarde nesta thread, mas parece que o post pulou a parte sobre riscos, erros e acidentes que podem surgir do “padrão 1”, em que o acesso do Claude é limitado a um contêiner. Ainda é difícil fazer isso direito
    Por exemplo, a Anthropic já lançou várias vezes bugs que permitiam a qualquer sessão isolada do claude.ai/code em um contêiner temporário acessar e exfiltrar todas as outras sessões do usuário, repositórios conectados e variáveis de ambiente. Um Claude malicioso ou comprometido também podia criar novas sessões do Claude com instruções arbitrárias e permissões de acesso, independentemente das restrições da sessão original. Escrevi sobre isso pela primeira vez em fevereiro, com autorização [1], e a maior parte foi corrigida rapidamente. Mas o problema fundamental de escopo de token se repetiu várias vezes, inclusive depois do Mythos, então é difícil dizer que a Anthropic resolveu isso
    [1]: https://www.noahlebovic.com/hacking-claude-code-on-the-web-b...

  • No geral, isso é realmente muito difícil de fazer. Infelizmente, o post até menciona alguns exemplos, mas não entra a fundo em quão difícil isso é
    Por exemplo, se você executa um agente em uma VM com acesso à rede, algo encontrado lá dentro pode enganar o agente via injeção de prompt para codificar uma injeção de prompt secundária em algum artefato que sai da VM, e isso pode infectar um agente local com privilégios maiores. No meu emprego anterior, ao fazer análise de uso de computadores, considerávamos se era possível confiar que a entrada do usuário não era maliciosa. Se o usuário digitou diretamente, em geral tudo bem, mas e os arquivos do usuário? E os eventos do calendário? Como o próprio objetivo do produto era deixar o agente gerenciar isso no lugar da pessoa, já não dava mais para confiar que não havia injeção. Quando você tenta fazer esse tipo de rastreamento de contaminação, logo percebe como é muito difícil impedir esse tipo de coisa e como simplesmente cercar tudo com sandbox ou VM em geral não ajuda muito demais

  • Ainda estou satisfeito com minha configuração de isolamento no Linux[1][2]. Dos riscos mostrados no texto, o único que se aplica de fato é algo como “exfiltração por meio de domínios autorizados”. Mas, por projeto, dentro da VM não há muito o que exfiltrar além do próprio código-fonte, e hoje em dia código-fonte não tem o mesmo valor de antigamente
    A grande vantagem dessa configuração é que o agente pode fazer todo o trabalho de desenvolvimento que eu conseguiria fazer, por exemplo instalar pacotes ou compilar/executar imagens Docker. Isso cria um ciclo muito mais rápido do que eu testar manualmente e depois reportar de volta ao agente
    [1] https://blog.emilburzo.com/2026/01/running-claude-code-dange...
    [2] https://news.ycombinator.com/item?id=46690907

    • O agente pode ser enganado e usar uma biblioteca maliciosa no projeto, depois fazer commit e push disso. Aí, se o usuário executar fora da VM, fica perigoso
      Se você executa o código do repositório fora da VM sem revisar tudo o que foi commitado, continua sendo arriscado

  • Ao inspecionar o Cowork VM, a contaminação não é documentada nem controlada publicamente. Tenho formas de contornar, mas no processo há bastante desperdício e frustração
    CLAUDE_CODE_ADDITIONAL_DIRECTORIES_CLAUDE_MD=1 significa que o Claude procura e carrega os CLAUDE.md de todos os repositórios montados ao longo do tempo e conforme a configuração. Por isso, a experiência padrão de trabalhar em vários repositórios não relacionados ao mesmo tempo não é boa
    Algumas variáveis de ambiente interessantes da VM:
    CLAUDE_CODE_IS_COWORK=1
    CLAUDE_CODE_BRIEF=1 CLAUDE_CODE_BRIEF_UPLOAD=1 CLAUDE_CODE_DISABLE_AUTO_MEMORY=1 CLAUDE_CODE_DISABLE_BACKGROUND_TASKS=1 CLAUDE_CODE_DISABLE_CRON=1
    CLAUDE_CODE_ENTRYPOINT=local-agent CLAUDE_CODE_EXECPATH=/usr/local/bin/claude CLAUDE_CODE_HOST_HTTP_PROXY_PORT=36543 CLAUDE_CODE_HOST_PLATFORM=darwin CLAUDE_CODE_HOST_SOCKS_PROXY_PORT=46673
    USE_STAGING_OAUTH= _=/usr/bin/env all_proxy=socks5h://localhost:1080 ftp_proxy=socks5h://localhost:1080 grpc_proxy=socks5h://localhost:1080 http_proxy=http://localhost:3128 https_proxy=http://localhost:3128 no_proxy=localhost,127.0.0.1,::1,.local,.local,169.254.0.0/16,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16

  • Sobre a frase “quanto mais capaz o agente fica, maior também é o potencial raio de explosão. A questão de engenharia é como limitar isso”, hoje em dia as pessoas ficam meio desconfortáveis quando se antropomorfiza LLMs, mas pior do que isso é fingir que um LLM poderia vazar sorrateiramente para a internet e começar a se replicar como um limo, em lógica de filme

    • O problema é que treinamos os modelos para resolver problemas e seguir instruções. Se você manda fazer algo, o modelo pode seguir a lógica e concluir que a forma mais fácil é apagar o banco de dados de produção e, se tiver acesso, vasculhar todas as credenciais para encontrar as credenciais do banco de dados e realmente apagá-lo
      A capacidade de fazer esse tipo de coisa está melhorando, e eles também seguem instruções cada vez melhor, mas nem sempre são bons em seguir todas as instruções ou agir com bom senso. Em vez de escapar como um limo e se replicar, o mais provável é que, quanto mais acesso você der, maior a chance de em algum momento o modelo concluir logicamente que deve fazer algo que o usuário não quer. Pode ser porque isso não foi explicitamente proibido, ou porque o contexto ficou complexo demais e essa instrução perdeu peso, levando-o a seguir outras. Já vi um caso em que ele concluiu que precisava de uma chave de API para acessar um serviço e realizar a tarefa. O modelo não tinha essa chave, mas o usuário podia acessar pelo navegador. Então ele escreveu um script em Python para raspar os cookies do navegador. O problema ali não era o sandbox do agente, e sim que o CrowdStrike não gostou de um script em Python desconhecido tentando raspar cookies do navegador e bloqueou isso
    • Por que não poderia? Se não estivermos falando de executar o próprio modelo, um agente de IA pode escrever um worm de agentes que espalhe mais agentes por meio de vulnerabilidades de software
      Hoje é difícil o próprio modelo se espalhar porque LLMs ainda exigem hardware demais, mas com alguns anos e otimização talvez vejamos isso também. Isso me lembra os velhos tempos em que se dizia “uma imagem não pode espalhar vírus”. Aí foram descobertas vulnerabilidades em decodificadores e imagens-vírus desse tipo realmente foram criadas
    • No momento em que LLMs são antropomorfizados, parece que ficam claramente quebrados por projeto, mas acho que o software como conhecíamos também está evoluindo para algo como “entidades antropomorfizadas”. Deixei algumas notas relacionadas em [1], e o conteúdo foi gerado por IA
      Há também uma tendência interessante de marcas mais antropomorfizadas se tornarem mais dominantes. Algo como Claude e Doubao versus ChatGPT e DeepSeek
      [1] https://github.com/NascentCore/agentic-suite/tree/main/perso...

  • Estou usando uma VM qemu. Essa VM tem acesso à internet, e o maior risco parece ser o Claude conseguir enviar dados para algum lugar
    Para deixá-lo trabalhar com GitHub, eu crio tokens com permissões limitadas por repositório, só leitura ou leitura/escrita. Mesmo assim, prefiro deixá-lo apenas fazer commit, não push; eu pego os commits da VM por SSH, verifico o log e depois faço o push manualmente. Também pensei em rodar o Claude em um contêiner, mas isso me parece fraco. Existem vulnerabilidades demais no Linux. Esse medo pode até não ter fundamento, mas sinto que rodar algo não confiável em uma VM qemu é mais seguro

  • Recentemente improvisei uma pequena função auxiliar para executar processos com bubblewrap, dando acesso de leitura/escrita apenas ao diretório de execução e deixando todo o resto como somente leitura. Abri exceções para alguns diretórios específicos do sistema Linux para que coisas como GUI e libportal funcionassem
    É muito menos incômodo do que contêineres para tarefas em que eu quero que o agente realmente aponte para coisas arbitrárias espalhadas por aí, como screenshots ou arquivos de log, mas ao mesmo tempo não quero ficar observando e aprovando manualmente toda vez. É bem estranho que plataformas de ferramentas de IA ainda não estejam investindo nisso. O que me levou a fazer isso foi o Zed. É um editor feito com trabalho de IA em mente, mas as permissões de caminho do agente só podem ser colocadas no arquivo de configuração global do usuário. Existe um arquivo de configuração em nível de projeto, mas, por algum motivo incompreensível, ele não oferece suporte explícito às configurações de permissão do agente

  • Não sou teórico da decisão, mas acho que não se deve esperar até que recompensa e dano esperado se igualem estatisticamente, e sim até que a recompensa em valor esperado supere o dano esperado

    • A sorte favorece os ousados