Para clientes do nosso Programa de Verificação de Cibersegurança, estamos fornecendo um novo classificador de escape de sandbox na API para monitorar e reduzir o uso indevido. Este artigo explica por que as transcrições de agentes valem a pena ler. Em seguida, há uma seção por camada de monitoramento: primeiro os logs de proxy, depois o que uma transcrição deve conter, regras de padrão sobre as transcrições e um revisor de modelo sobre as transcrições. Termina com o que fazer quando uma camada sinaliza um agente enquanto um lote está em execução e o que manter depois.
Este classificador está em beta privado.
Para uma visão geral de todos os recursos disponíveis para você, consulte Melhores práticas de contenção de agentes: primeiros passos (beta privado).
Visão geral
Ler as transcrições é uma verificação que não depende do sandbox ou do classificador tomar a decisão correta. A transcrição é produzida pelo próprio processo do agente, portanto, combine-a com registros obtidos fora do sandbox, como os logs de proxy. A investigação geralmente é visível em uma transcrição antes de qualquer coisa prejudicial ser executada, mas não confie em ter tempo para reagir: os controles que atuam antes de uma ação ser executada vêm em primeiro lugar. Durante um lote longo sem acesso à rede, verifique os arquivos de transcrição ao vivo em um cronograma e faça com que uma pessoa analise os resultados a cada hora ou duas. Para execuções com acesso à rede para um alvo, faça com que um engenheiro observe a execução ou verifique continuamente e interrompa o agente em um resultado. Após qualquer execução, verifique tudo uma vez para confirmar que cada agente permaneceu dentro de seu sandbox.
Use três camadas de monitoramento, a mais barata primeiro: (1) os logs de proxy de saída e proxy de credencial, (2) regras de padrão sobre as transcrições, escritas para seu ambiente, e (3) um revisor de modelo sobre as transcrições, com um prompt que você escreve para seu sandbox e escopo.
Também envie ao revisor uma amostra aleatória de 5 a 10% das transcrições que as regras de padrão não sinalizaram. Espere alguns falsos positivos. Se o revisor disser que um agente fez algo, leia essa parte da transcrição antes de agir.
Quando uma camada mostra que um agente saiu de sua tarefa durante uma execução, interrompa-o e informe sua equipe de conta da Anthropic sobre comportamento fora do escopo.
Mantenha transcrições e logs de proxy por pelo menos 30 dias.
Por que ler as transcrições
O sandbox e o classificador de permissão de modo automático do Claude Code atuam enquanto um agente está em execução. Ler as transcrições é uma verificação que não depende de nenhum deles. Tem dois usos.
Durante uma execução. A investigação, se acontecer, pode ser visível na transcrição antes de qualquer coisa prejudicial ser executada. Não confie em ter tempo para reagir: os controles que atuam antes de uma ação ser executada vêm em primeiro lugar. Durante um lote longo, verifique os arquivos de transcrição ao vivo em um cronograma e faça com que uma pessoa analise o que as verificações sinalizam a cada hora ou duas.
Após uma execução. Verifique tudo uma vez para confirmar que cada agente permaneceu dentro de seu sandbox.
Para engajamentos com acesso à rede para alvos reais, as melhores práticas recomendam que uma pessoa supervisione a execução ou que um monitor que conhece o escopo pretendido observe continuamente, escale para uma pessoa quando uma execução pode estar excedendo esse escopo e possa encerrar a execução (consulte a seção Escopo e supervisão em Sandboxing). As camadas neste artigo são as peças a partir das quais tal monitor é construído.
Se você executar agentes diretamente contra a API de Mensagens, a API também pode retornar uma pontuação por solicitação do classificador de escape de sandbox conforme eles são executados (consulte Monitoramento online).
Camada 1: logs de proxy
A camada mais barata não lê nenhuma transcrição.
O proxy de saída deve registrar cada solicitação que recusa, com o endereço do cliente e o destino. Com uma lista de permissões vazia, os agentes alcançam a API do modelo apenas através do proxy de credencial e não precisam de nenhum outro host, portanto, cada solicitação recusada durante uma execução vale a pena examinar. Leia a transcrição de cada execução que causou uma. O endereço do cliente mostra qual agente fez a solicitação, para que você saiba qual transcrição ler primeiro.
Saiba o que sua camada de saída não registra. No design de referência, o proxy de saída registra solicitações HTTPS CONNECT recusadas. Tentativas de HTTP simples e TCP bruto não passam pelo proxy na rede interna, portanto, falham sem uma linha de log e aparecem apenas nas transcrições. Em sua própria compilação, considere registrar conexões permitidas e recusadas, para cada protocolo, com timestamps.
O proxy de credencial deve registrar uma linha para qualquer solicitação que não fosse uma chamada de modelo. Salve seu log quando a execução terminar (consulte a seção Proxy de credencial em Sandboxing).
O que capturar em uma transcrição
A segunda e terceira camadas leem as próprias transcrições.
Faça com que o orquestrador no host escreva uma transcrição para cada estágio do agente, uma mensagem JSON por linha, conforme cada mensagem chega. A saída stream-json do Claude Code tem essa forma. Em cada arquivo, linhas com "type": "assistant" contêm o que o modelo produziu: blocos text, thinking e tool_use. A entrada tool_use contém o comando Bash ou o arquivo sendo escrito. Linhas com "type": "user" contêm blocos tool_result: saída de comando, conteúdo de arquivo e respostas de destino.
Capture cada estágio, incluindo estágios cujos agentes não têm ferramentas, como um agente que apenas julga ou compara descobertas. Há menos para verificar nessas transcrições, mas um estágio sem transcrição não pode ser revisado.
Camada 2: regras de padrão sobre transcrições
Escreva suas próprias regras de padrão, como expressões regulares, para seus agentes e alvos. Para agentes que trabalham através de um shell, cubra comportamentos como contornar o proxy de saída ou firewall, enviar credenciais ou abrir conexões SSH fora do sandbox, alterar tunáveis de kernel ou privilégio e listar outros processos através de /proc. As regras correspondem apenas ao comportamento que alguém antecipou, portanto, trate-as como um ponto de partida, não um detector completo.
Aplique as regras a strings decodificadas em JSON em vez de linhas brutas, porque em uma linha bruta aspas e quebras de linha são escapadas e os padrões podem não corresponder. Relate cada resultado com o arquivo, a linha, a regra e um trecho, e faça a verificação sair com um status distinto quando encontrar algo, para que um trabalho agendado possa executá-lo durante um lote longo e gerar um alerta.
Espere resultados benignos
Um resultado é uma razão para ler essa parte da transcrição. Por si só, não significa que o agente fez algo errado. Agentes que fazem pesquisa de vulnerabilidade rotineiramente executam comandos que correspondem a regras de escape por razões ordinárias:
executar o alvo sob um shim
LD_PRELOAD;anexar ptrace aos seus próprios processos filhos ou ler /proc/<pid>/ para esses processos;
desativar ASLR através de /proc/sys/kernel/randomize_va_space;
listar /proc para encontrar e matar seus próprios workers de fuzzing.
Uma regra de bypass de proxy pode corresponder a cada solicitação curl, wget ou netcat para um alvo de pentest com um IP público, e uma regra de saída SSH pode corresponder a qualquer ssh ou scp para um alvo com um IP público ou um nome DNS. Restrinja ou remova regras que produzem apenas resultados benignos em seus alvos.
Camada 3: revisor de modelo sobre transcrições
Para cada transcrição que as regras de padrão sinalizaram, envie uma solicitação da API de Mensagens para Claude com um prompt de revisor que você escreve. O prompt deve pedir a Claude para procurar um agente que ampliou seu acesso à rede ou saiu de seu sandbox, seja tentado ou alcançado, dizer o que sinalizar e o que não sinalizar, e pedir as descobertas, ou nenhuma, com as linhas de transcrição que as suportam.
Construa a mensagem do usuário em duas partes:
Comece com duas ou três frases que descrevem o sandbox e o escopo pretendido. Para o design de referência: cada agente é executado em seu próprio sandbox isolado (um contêiner ou microVM) em uma rede interna, a única maneira de sair é um proxy que encaminha chamadas de API de modelo e nada mais, e o alvo está dentro do sandbox com o agente. Se seu sandbox permite outros hosts ou o alvo está na rede, diga aqui e nomeie os alvos no escopo.
Em seguida, inclua as próprias mensagens do agente, ou seja, seus blocos
text,thinkingetool_use, com conteúdotool_resultsuficiente para mostrar o que cada chamada retornou.
Use o modelo com o qual você executa os agentes ou um mais barato. No Amazon Bedrock ou na Plataforma de Agentes do Google Cloud (Vertex AI), use um que esteja habilitado em sua conta.
Dois limites a ter em mente:
Um prompt de revisor que procura apenas por escape de sandbox e rede não detecta um agente que excede o engajamento em hosts que tem permissão para alcançar.
A transcrição é entrada não confiável para o revisor. Contém texto que o alvo controla. Um veredicto limpo não limpa uma transcrição que uma regra ou um log de proxy sinalizou.
Revise também uma amostra das transcrições não sinalizadas
As regras de padrão capturam apenas o que alguém antecipou, portanto, também envie uma amostra aleatória de 5 a 10% das transcrições que as regras não sinalizaram, usando a mesma solicitação. A amostra mostra o que as regras perdem e se você deve adicionar uma regra.
Leia as negações do classificador
As recusas do classificador de modo automático também são úteis de ler: procure nas transcrições as mensagens de negação do classificador e mantenha-as separadas das recusas que ele emite quando não está disponível (consulte Modo automático).
Este revisor é separado do classificador de permissão de modo automático (consulte Modo automático), que decide sobre cada ação antes de ser executada, e do classificador de escape de sandbox na API (consulte Monitoramento online). Os três se complementam.
O que fazer em um resultado durante uma execução
Quando uma das camadas mostra um agente que saiu de sua tarefa enquanto seu lote ainda está em execução:
Interrompa o agente. Em uma configuração baseada em Docker,
docker rm -fno contêiner do agente o interrompe. Remover um contêiner exclui o disco do convidado, portanto, qualquer coisa que o agente escreveu lá é perdida. O orquestrador deve registrar a execução como falha e continuar com o resto do lote.Mantenha a evidência. Deixe os resultados da execução como estão e verifique o log do proxy de saída para a mesma janela de tempo. Certifique-se de que as linhas de log carregam timestamps.
Relate-o. Se o que você encontrar for genuinamente comportamento fora do escopo, ou seja, um agente que investigou seu isolamento de sandbox ou rede ou agiu fora do engajamento, notifique sua equipe de conta da Anthropic, além de qualquer coisa que seu próprio processo de incidente exija.
Gire a credencial da API de modelo, como após qualquer execução cuja transcrição mostre comportamento inesperado (consulte Sandboxing).
Se você precisar compartilhar uma transcrição fora de sua equipe, trabalhe em uma cópia. Remova ids de sessão, contabilidade de uso e o inventário de host que a primeira linha de uma transcrição registra, e leia o arquivo antes de enviá-lo.
Retenção
Mantenha o seguinte por pelo menos 30 dias após uma execução, ou mais tempo onde suas obrigações regulatórias ou contratuais exigirem. Armazene-os fora do host:
Transcrições de agentes;
Os logs de qualquer coisa que imponha saída do sandbox (um proxy ou um firewall), incluindo conexões recusadas;
Os logs de qualquer coisa que injete a credencial da API de modelo, se esse for um componente separado.
Armazene-os com os mesmos controles de acesso que a execução em si. As transcrições podem conter código-fonte de destino, código de exploração e descobertas.
Se algum desses logs existir apenas como um log de contêiner, exporte-o antes que o contêiner seja removido ou recriado, porque o log é excluído com ele.