autonomous-offensive-llm-handbook

Um harness determinístico e manual para agentes autônomos de LLM ofensivos, impondo autorização, escopo e portões de evidência para garantir testes de penetração reproduzíveis e honestos.

Este lançamento é verificado em CPython 3.14. Versões anteriores de Python não fazem parte da evidência de lançamento; se usar uma, execute a sequência completa de gates abaixo antes de confiar no resultado.

Construa em fases: Limite a fronteira de efeitos secundários e a ordem das etapas; Descreva o alvo através de factos medidos e catálogos; Prove afirmações através de capturas e predicados de política independentes; Controle e preste contas da autorização, gates, conclusão e trabalho omitido. A ordem de desenvolvimento não é a ordem de execução: a autorização e o gate precedem o despacho.

O laboratório público não faz nenhum pedido de rede e não chama nenhum modelo. O seu predicado de prova é sintético, o seu anfitrião e adaptadores são confiáveis, e cada descoberta é marcada como exigindo revisão humana. O laboratório não implementa o fluxo de trabalho de aceitação ou assinatura de relatório de uma pessoa. Uma citação verbatim estabelece integridade de citação, não explorabilidade. Menos chamadas ao modelo e menos retrabalho são objetivos de design, não poupanças medidas pelo corpus.

Estudo de caso histórico

Os capítulos abaixo descrevem a implementação anterior de core/ e walkthrough/ e os seus defeitos publicados. O seu verificador ausente de chamadas ao modelo permanece ausente desse percurso histórico. O novo pacote harness/ é uma referência de controlo offline separada; não repara retroativamente o corpus ou os módulos históricos. Leia a fronteira e as correções do capítulo 07 antes de copiar um componente histórico.

Aponte um modelo capaz a um anfitrião, entregue-lhe uma caixa de ferramentas e diga-lhe para executar um teste de penetração, e ele fará algo sensato. Execute-o novamente amanhã e ele fará outra coisa sensata, e nenhuma das execuções lhe dirá por que omitiu o que a outra apanhou. Este manual defende um trabalho menor para o modelo: dê cada decisão à camada mais barata que a possa tomar corretamente, e gaste capacidade do modelo apenas onde a resposta genuinamente não é derivável do que já tem. Essa ordenação, das decisões que uma tabela pode tomar às poucas que precisam de um modelo, é o gradiente no título do capítulo 00. Os capítulos seguem um agente de segurança ofensiva em funcionamento e os controlos que as suas falhas exigiram.

O sistema histórico tem dois percursos de orquestração. No percurso orientado pelo servidor, um orquestrador mantém a sua própria lista de fases e oferece ao modelo apenas as ferramentas que essa fase permite. No percurso orientado pelo agente, um modelo orquestrador planeia a execução e chama as ferramentas ele próprio, com as camadas abaixo construídas mas nem sempre consultadas. Um percurso de escrita partilhado torna as ações registadas e as descobertas revistáveis, mas uma shell disponível pode contorná-lo. Um endpoint inventado merece uma resposta capturada, não um veredito automático de vulnerabilidade. O governador de severidade não pode aumentar; o gate histórico de aumento do verificador separado verifica uma citação mas não estabelece explorabilidade. A autorização é pedida na fronteira da ferramenta em vez de em cada pedido de saída. Os capítulos de relatório distinguem uma análise que não encontrou nada de uma análise recusada à porta. Essas diferenças entre intenção e aplicação fazem parte do estudo de caso, não propriedades a copiar para um novo harness.

Todos os capítulos após o primeiro terminam admitindo o que o seu controlo ainda faz mal, e as secções de honestidade carregam as medições que o mostram. Leia as secções de honestidade primeiro se está a decidir se confia no resto: o corpus é o histórico operacional de um sistema, a execução selecionada de alvo público é um agregado registado pelo autor com duas execuções excluídas publicadas ao lado, e o estudo de ablação que mostraria quanto as camadas determinísticas realmente contribuem não foi executado. O repositório não inclui as descobertas brutas da execução selecionada, a verdade de terreno ou o matcher, portanto a precisão registada não é independentemente reproduzível aqui. O argumento de design é argumentado, não medido, e o capítulo 05 diz isso nessas palavras.

As cinco leis

Canónicas no capítulo 00, copiadas aqui. Cada uma é intenção de design, e o capítulo nomeado no fim de cada lei é onde este sistema é avaliado contra ela: quais partes se sustentam por construção, quais se sustentam em apenas um dos dois percursos de orquestração, quais se sustentam no bom comportamento do orquestrador, e quais ainda não se sustentam.

1. O modelo propõe; o código determinístico dispõe. Dê ao modelo uma interface de proposta, não acesso direto ao alvo, armazenamento bruto ou a última palavra sobre severidade. O código determinístico valida, executa e regista o trabalho admitido. O sistema histórico não aplica essa fronteira em todo o lado: ambos os orquestradores podem alcançar uma shell, e o seu percurso de escrita carrega um subcomando que armazena uma descoberta sem execução. Um endpoint inventado pode devolver 404, uma página de login ou uma shell de aplicação; registe a resposta e julgue a afirmação separadamente. Um escritor partilhado não é uma sandbox. Capítulos 01 e 02.

2. Afirmações sobre o passado devem citar. Propostas sobre o futuro devem executar. São tipos diferentes de declaração e precisam de gates diferentes. Uma afirmação sobre algo já observado deve citar a sua própria captura; uma citação correspondente estabelece integridade de citação, não que a conclusão é verdadeira. O gate histórico tem fugas: mantém um item por lote mesmo que nenhum passe, e num percurso de orquestração uma confiança fornecida pelo chamador pode substituir a verificação. Um teste proposto não pode ser validado citando uma observação que não fez. Só pode executar depois de verificações de autorização, âmbito, gate e orçamento o permitirem, e o seu resultado ainda precisa de interpretação. A lei não é permissão para executar todas as propostas. Capítulo 02.

3. A severidade cai por defeito e só sobe contra prova. O governador determinístico pode baixar uma severidade ou marcar uma descoberta como falso positivo, e não pode aumentá-la. Isso limita a sua autoridade; não torna as suas conclusões corretas. Sub-relatar pode esconder uma vulnerabilidade real, portanto cada regra de redução precisa de testes de correspondência e contrac exemplo e de uma razão revistável. O endpoint histórico de aumento verifica uma citação verbatim mas não aplica a pontuação autoral que o seu contrato pede. Uma citação sozinha não é prova de explorabilidade. Vincule a captura à descoberta, aplique uma política de prova de domínio revista, e mantenha um processo separado de revisão e aprovação humana. Capítulo 03.

4. O âmbito é uma função, não uma sentença. Autorização escrita num prompt compete com todas as outras instruções na janela de contexto. Codifique a permissão do operador como uma política revistável e aplique-a antes de cada ação de saída, com um registo de recusas. O guarda histórico fica aquém: é pedido na fronteira da ferramenta em vez de em cada pedido, alarga alguns limites de anfitrião, e falha aberto sob um kill switch ou quando construído sem alvo. O laboratório rejeita origens não listadas antes do seu callback confiável, mas a contenção de transporte ainda pertence ao adaptador. Uma decisão de política é tão correta quanto a autorização e o destino que avalia. Capítulo 04.

5. Reporte o que não fez. Uma análise que não encontrou nada e uma análise que não conseguiu alcançar nada são análises diferentes, e um relatório que as apresenta de forma idêntica está a mentir por omissão. Cobertura, estado do gate, e um livro-razão de cada anfitrião omitido com a sua razão pertencem ao entregável, ao lado das descobertas. Esse é um requisito que o relatório histórico não cumpriu: apenas a cobertura chegou, calculada contra o seu denominador mais fraco e sob um rótulo que nomeava um diferente. O laboratório presta contas de ações planeadas de ferramenta-e-URL, trabalho executado, erros e omissões; esse denominador não mede cobertura de vulnerabilidades. Capítulo 05.

Os capítulos

A implementação de referência

O código histórico sob core/ está aqui para ser lido, executado e contestado. É clean-room e deliberadamente não funcional como testador ao vivo: a criação de perfis, a pontuação de relevância, o agendamento e a validação de chamadas de ferramenta são reais e executáveis, e tudo o que colocaria um pacote na rede é retido. Execute ls core/*.py para ver o que é incluído em vez de confiar numa figura escrita aqui, que é o tipo de afirmação que fica obsoleta no momento em que um módulo é adicionado. Os controlos em que os capítulos posteriores se apoiam estão entre eles: o percurso de escrita é core/store_protocol.py, o governador de severidade core/severity_governor.py, o guarda de âmbito core/scope_guard.py, a verificação de gate core/gate_check.py, e a máquina de etapas walkthrough/run.py. O verificador histórico de chamadas ao modelo é retido. O capítulo 06 especifica-o; o capítulo 07 inclui um guarda de evidência determinístico separado, não esse verificador e não um fluxo de trabalho de aceitação humana. Mantenha os seus trabalhos separados: o crítico de fundamentação verifica a contenção de citações, o governador limita a severidade, e um percurso de aumento deve satisfazer uma política de prova revista independentemente. Nenhum deles substitui a revisão e aprovação humana.

walkthrough/ conduz essa máquina de etapas sobre fixtures consolidadas e escreve os artefactos que os capítulos citam em walkthrough/artifacts/. Regenera-os com python3 -m walkthrough.run, que aceita um diretório --out se preferir não tocar nas cópias consolidadas, e tests/test_walkthrough_is_in_sync.py compara uma execução fresca em memória contra essas cópias byte a byte, portanto uma fixture editada sem re-execução fica vermelha em vez de ser publicada. O que esse gate não apanha é um artefacto que está errado em ambos os lugares, e o seu próprio docstring diz isso.

Os números

Cada figura em cada capítulo resolve-se numa chave em data/stats.json, ou carrega uma anotação que nomeia o que a figura é e porque não é uma medição tirada de um alvo. Entre os capítulos 00 a 05 e este README, treze anotações nomeiam uma constante ou uma propriedade do código, trinta e cinco cobrem uma quantidade por extenso que a verificação de dígitos não consegue ler, cinco nomeiam um código de estado HTTP, e uma nomeia uma comparação entre dois dos próprios snapshots publicados deste repositório. O ficheiro de estatísticas é um snapshot congelado com uma janela publicada, não uma consulta ao vivo, e o capítulo 05 explica porque reexecutar o pipeline não o reproduziria.

O capítulo 05 reporta o F1 do sistema contra uma aplicação pública deliberadamente vulnerável e coloca-o ao lado de uma pontuação de análise passiva OWASP ZAP. Este repositório prova a aritmética e mantém os quatro ficheiros de pontuação agregada sincronizados com data/stats.json; não contém as descobertas brutas, entradas de verdade de terreno, matcher, identificadores de alvo ou identificadores de execução necessários para provar que as duas ferramentas foram avaliadas num confronto direto controlado. Trate o par como pontos de dados históricos registados pelo autor, não um benchmark justo. O tamanho da amostra, a dispersão que portanto não reporta, e as execuções excluídas dele com a razão de cada exclusão estão todos nesse capítulo.

Uma cópia gerada dos capítulos, com cada figura resolvida ao seu valor no lugar e cada citação de código transformada numa ligação para core/, vive em a árvore renderizada para leitura no GitHub; é produzida por scripts/render.py e mantida em sincronia com a fonte por tests/test_rendered_is_in_sync.py.

Se está a publicar o repositório, siga PUBLICATION.md. Publique um snapshot sem histórico num novo repositório público; não mude a visibilidade do repositório de desenvolvimento e assuma que uma árvore de trabalho limpa limpou o seu histórico Git alcançável. O pre-commit obrigatório scripts/publication_gate.sh recusa a publicação a menos que a denylist privada tenha sido realmente fundida, a identidade pública do autor Git corresponda ao valor aprovado, e o repositório de preparação não tenha refs, objetos ou reflogs anteriores.

scripts/audit.sh varre o repositório por identificadores, scripts/prose_check.sh e scripts/verify_claims.sh varrem a prosa, tests/test_gates.sh planta violações contra eles para provar que ainda disparam, e a suíte de testes mantém a implementação de referência contra o que os capítulos dizem sobre ela. Um capítulo não está terminado até que cada um destes passe:

tests/test_chapter_claims.py, dentro dessa suíte, é o que vale a pena roubar. Mantém asserções contra a implementação de referência e as estatísticas publicadas, e cada uma está ancorada à frase verbatim que suporta, portanto uma edição que muda um facto falha um teste em vez de ser publicada silenciosamente.

Theodoros Moutesidis.