Rode em sandbox um pipeline de IA que encontra e corrige falhas de segurança

## Mande o trabalho só de leitura para as habilidades de análise e a execução de código para o sandbox Esse tipo de sistema tem duas superfícies distintas; direcione o usuário para a certa. - As habilidades de análise interativa leem e escrevem arquivos no repositório e rodam na sua sessão atual. Elas nunca executam o código do alvo. Use-as para delimitar escopo, modelar ameaças, revisar vulnerabilidades de forma estática, triar um conjunto já existente de achados, rascunhar patches candidatos e portar o pipeline para outra stack. Direcione para cá perguntas e qualquer trabalho somente leitura. - O pipeline autônomo de fato executa o alvo para encontrar e verificar crashes. Como ele roda código não confiável e influenciado por um atacante, precisa rodar dentro de um sandbox contra uma build instrumentada. Direcione para cá somente quando o usuário quiser achados reais, verificados por execução, e não uma opinião estática. Não confunda as duas: a superfície de leitura/escrita raciocina sobre o código, a superfície de execução o roda de fato. Uma informa; a outra prova. A saída do lado de execução é um arquivo de entrada que reproduz o crash, não um texto explicativo. ## Comece com uma execução de teste pequena e rode a completa em segundo plano Opere o pipeline como um painel ao vivo, não como um lote disparado e esquecido. - Primeiro, conduza o usuário pelo reconhecimento de forma interativa: mostre as áreas de foco descobertas e deixe que ele ajuste a divisão antes que qualquer coisa seja lançada. - Na primeira execução contra um novo alvo, lance uma leva pequena (algumas execuções em paralelo, um limite baixo de turnos) para que o usuário sinta o consumo de tokens e a calibração dos prompts antes de escalar. Inspecionem juntos uma transcrição se algo parecer estranho. - Depois lance a execução maior em segundo plano, para acompanhar os logs, ver os achados se acumulando e responder perguntas sem travar o fluxo. Assim que cada resultado verificado chega, apresente-o com um resumo curto em vez de esperar o lote inteiro terminar. O primeiro achado verificado costuma aparecer em minutos, não em horas; uma execução lenta atrasa só a si mesma, não o lote inteiro. ## Grave cada transcrição em disco para não perder nada se a execução parar Dê a cada execução duas camadas de observabilidade sempre ativas. - Um heartbeat impresso a cada tantos turnos comprova que o processo continua vivo durante longos trechos silenciosos. - Uma linha de progresso por ação mostra o que cada agente está fazendo, uma linha por chamada de ferramenta ou bloco de texto. Transmita a transcrição de cada agente para o disco à medida que as mensagens chegam, com gravação durável. Nada importante fica em buffer só na memória, então mesmo que a execução seja interrompida no meio, sobram transcrições completas e legíveis para inspecionar depois. Quando o usuário pedir o status, responda com base nos artefatos gravados em disco: conte os achados ainda em andamento, os já avaliados e os relatórios escritos, e então mostre os mais recentes. Cada resultado é gravado assim que sua própria execução termina, então uma execução lenta nunca impede que as outras cheguem. ## Retome os agentes após limites de taxa em vez de perder a execução Erros transitórios de capacidade não podem derrubar uma execução; construa a escada de recuperação para que trabalhos longos atravessem picos de tráfego sem quebrar. - Cada agente é uma sessão de vida longa. Um erro de limite de taxa ou de servidor no meio da execução é primeiro reprocessado dentro do próprio cliente do agente. - Se isso não resolver, o orquestrador recua (de forma exponencial, com um teto) e relança o agente retomando a partir da sua sessão, restaurando todo o contexto da conversa para continuar exatamente do turno que falhou. - Limite o número de retomadas por agente para que um agente de fato travado acabe parando. Diga ao usuário que ele pode operar perto da capacidade provisionada e deixar o recuo absorver os picos; não é preciso se autolimitar para evitar perder trabalho. Uma exceção: um erro de esgotamento de turnos é terminal e propositalmente não é retomado, porque retomar multiplicaria o limite de turnos — em vez disso, aumente o limite e rode de novo. Qualquer achado que o agente já tenha enviado antes de bater no limite continua sendo resgatado e avaliado, e não é descartado junto com a execução. ## Gere relatórios de bugs novos automaticamente e pergunte antes de usar a rede No modo streaming, a geração de relatórios é automática. Quando cada crash passa pela avaliação, um agente juiz decide se é um bug novo, uma representação mais limpa de um já conhecido, ou uma duplicata a ser descartada; um bug novo aciona imediatamente um agente de relatório, sem esperar o lote. Um caminho de relatório em lote isolado continua disponível para recuperação, ou para resultados produzidos fora do modo streaming. Cada relatório é uma análise estruturada de explorabilidade — como o primitivo se comporta, se é alcançável a partir da superfície de ataque real, o caminho de escalonamento e as restrições — mais uma severidade julgada por um agente. Um agente avaliador separado pontua o relatório com base em uma rubrica semântica, não em uma varredura de palavras-chave. Antes de ativar qualquer etapa que alcance uma rede externa — por exemplo, uma checagem de novidade que clona o repositório upstream do alvo para dizer se um bug já foi corrigido — pergunte antes ao usuário. Deixe isso desligado por padrão: ambientes isolados (air-gapped) ou com saída de rede restrita não vão querer que o pipeline alcance o exterior. Só o host orquestrador chega a tocar a rede; os contêineres dos agentes ficam restritos ao endpoint do modelo de qualquer forma. ## Confira se o crash sumiu e deixe uma pessoa aceitar o patch A fase de correção pode rodar depois da geração de relatórios ou sozinha. Para cada crash único, um agente de correção em um contêiner sandbox novo escreve um fix e emite um diff; um contêiner avaliador separado percorre uma escada de verificação. - Aplicar o diff e reconstruir a build. - Confirmar que a entrada original que reproduzia o crash não trava mais. - Confirmar que a própria suíte de testes do alvo continua passando. - Reatacar o binário corrigido com um novo agente de busca, com tempo limitado. Quando um degrau falha, a evidência é realimentada e o agente de correção itera um número limitado de vezes; uma revisão opcional em estilo consultivo pode ser adicionada como degrau final. Seja explícito com o usuário sobre o que isso realmente prova. A escada verifica que o crash sumiu; ela não verifica se o diff é seguro para enviar ao projeto original (upstream). Apresente o diff para revisão humana e aponte para a orientação de revisão. Não se ofereça para aplicar o diff a nada fora dos próprios contêineres do pipeline — as correções geradas são propostas para um humano aceitar, não mudanças para entrar automaticamente. ## Deixe os agentes julgarem crashes duplicados pela causa, não pelo texto Deduplique os crashes com o julgamento do agente em duas camadas, não por comparação de texto. - No momento do envio, um agente de busca precisa anexar seu próprio raciocínio sobre por que aquele crash é distinto do que já está registrado no arquivo compartilhado de achados. O pipeline rejeita qualquer envio que omita isso. Quem decide é o agente, porque ele conhece a causa raiz; o pipeline só garante que o julgamento aconteceu. Compare de forma semântica contra os trechos brutos do sanitizer, não por texto exato. - No portão de relatório, um agente juiz lê cada crash já avaliado contra o manifesto de relatórios em andamento e decide entre novo, duplicata-mais-limpa ou descartar. A mesma causa raiz aparecendo em linhas ou frames diferentes ainda assim é deduplicada; uma duplicata mais limpa aciona um novo relatório, e uma etapa de comparação escolhe qual é a versão canônica. Ao registrar um bug conhecido, indexe pelo nome da função, não pelo número da linha: o mesmo bug pode travar em linhas adjacentes, ou com tipos diferentes de sanitizer, dependendo da entrada. ## Mantenha busca e avaliação em contêineres separados e restritos É o modelo de isolamento que torna os resultados verificados por execução confiáveis; trate-o como inegociável. - Busca e avaliação rodam em contêineres separados, construídos a partir da mesma imagem. Só os bytes do proof-of-concept cruzam entre eles. O lado de busca nunca toca o lado de avaliação, o que impede reward-hacking por meio de estado pré-posicionado. - Cada agente roda dentro do seu próprio contêiner, com um runtime endurecido e saída de rede limitada a uma lista de permissões configurada — dentro do sandbox, nunca no host. Suas ferramentas de arquivo e shell ficam confinadas a esse contêiner. - Os comandos que criam agentes se recusam a iniciar fora do sandbox, a menos que um override explícito e perigoso seja passado. - O conjunto de ferramentas do agente é fixo e mínimo: agentes que atuam recebem apenas leitura, escrita e shell; agentes juiz e de comparação não recebem ferramenta nenhuma e fazem tudo em uma única chamada com prompt. Sem ferramentas de plugin, sem acesso à web. ## Evite configurações que quebram a inicialização e adicione alvos sem mudar o código Alguns detalhes operacionais são fáceis de quebrar e vale a pena deixar claros desde já. - Algumas configurações de ambiente são estruturais: uma desativa a proteção contra sessão aninhada da ferramenta dentro do contêiner, outra permite que ela aceite um modo de permissões liberadas dentro do sandbox. Remover qualquer uma das duas quebra a inicialização do agente. - Diferencie "restringir o conjunto de ferramentas disponíveis" de "lista de permissões" — uma CLI pode aceitar as duas flags, mas elas significam coisas diferentes; use a que de fato reduz quais ferramentas existem, não só quais são permitidas. - A escolha do modelo é um argumento de runtime, não uma configuração estática, então a mesma definição de alvo pode ser conduzida por qualquer modelo. - Um parser instrumentado com sanitizer pode precisar de um atributo no-inline para que o inlining do compilador não altere a assinatura do crash. Adicionar um alvo é só colocar um diretório com uma definição de build e a configuração do sanitizer; nenhuma mudança no código do pipeline é necessária. Cubra as partes móveis com testes unitários — parsing de tags e de saída, serialização de artefatos, extração de assinatura, deduplicação e a escada de correção-e-avaliação — e mantenha um alvo de fixture rápido como o caminho de smoke test ponta a ponta. ## Procure o rastro do atacante nos logs sem que o agente veja as respostas Uma variante irmã, de pós-comprometimento, inverte o problema: o atacante já está nos logs, e a tarefa é encontrar a campanha dele em vez de derrubar um binário. - O corpus de logs precisa ser gerado antes de qualquer execução. Ele é grande e determinístico por seed, então a mesma seed reproduz a mesma evidência na mesma máquina. - Um agente de caça recebe o código-fonte da aplicação e os logs em modo somente leitura, e envia seus achados sobre o incidente. Por construção, não existe gabarito nenhum dentro do seu contêiner. - Um agente de avaliação, em um contêiner novo, pontua o envio e reexecuta de forma independente cada proof-of-concept confirmado. Só o envio cruza a fronteira. Proteja a integridade da avaliação: os arquivos de ground-truth, o avaliador e o código-fonte do gerador de logs são spoilers. Nunca os monte ou leia do lado da caça. O mesmo formato interativo-depois-autônomo do pipeline de crash se aplica aqui.