autonomous-offensive-llm-handbook

Un harness deterministico e un manuale per agenti LLM offensivi autonomi, che impone controlli di autorizzazione, ambito e prove per garantire test di penetrazione riproducibili e onesti.

Questa release è verificata su CPython 3.14. Le versioni precedenti di Python non fanno parte delle prove di release; se ne usi una, esegui l'intera sequenza di gate qui sotto prima di fare affidamento sul risultato.

Costruisci in fasi: Delimita il confine degli effetti collaterali e l'ordine delle fasi; Descrivi il target attraverso fatti misurati e cataloghi; Prova le affermazioni tramite catture e predicati di policy indipendenti; Controlla e rendi conto di autorizzazione, gate, completamento e lavoro omesso. L'ordine di sviluppo non è l'ordine di esecuzione: autorizzazione e gate precedono il dispatch.

Il lab pubblico non effettua alcuna richiesta di rete e non chiama alcun modello. Il suo predicato di prova è sintetico, il suo host e i suoi adattatori sono considerati affidabili, e ogni risultato è marcato come bisognoso di revisione umana. Il lab non implementa il flusso di accettazione o firma del report di una persona. Una citazione testuale stabilisce l'integrità della citazione, non l'exploitability. Meno chiamate al modello e meno rilavorazione sono obiettivi di progettazione, non risparmi misurati dal corpus.

Caso di studio storico

I capitoli seguenti descrivono la precedente implementazione core/ e walkthrough/ e i suoi difetti pubblicati. Il suo verificatore assente che chiama il modello rimane assente da quel percorso storico. Il nuovo pacchetto harness/ è un riferimento di controllo offline separato; non ripara retroattivamente il corpus o i moduli storici. Leggi il confine e le correzioni del capitolo 07 prima di copiare un componente storico.

Punta un modello capace verso un host, consegnagli una cassetta degli attrezzi e digli di eseguire un penetration test, e farà qualcosa di sensato. Eseguilo di nuovo domani e farà qualcos'altro di sensato, e nessuna delle due esecuzioni può dirti perché ha saltato ciò che l'altra ha catturato. Questo manuale sostiene un compito più piccolo per il modello: affida ogni decisione al livello più economico che può prenderla correttamente, e spendi capacità del modello solo dove la risposta non è davvero derivabile da ciò che già possiedi. Quell'ordinamento, dalle decisioni che una tabella può prendere a quelle poche che richiedono un modello, è il gradiente nel titolo del capitolo 00. I capitoli seguono un agente di sicurezza offensiva funzionante e i controlli che i suoi fallimenti hanno richiesto.

Il sistema storico ha due percorsi di orchestrazione. Sul percorso guidato dal server, un orchestratore mantiene la propria lista di fasi e offre al modello solo gli strumenti che quella fase consente. Sul percorso guidato dall'agente, un modello orchestratore pianifica l'esecuzione e chiama gli strumenti da solo, con i livelli sottostanti costruiti ma non sempre consultati. Un percorso di scrittura condiviso rende revisionabili le azioni registrate e i risultati, ma una shell disponibile può bypassarlo. Un endpoint inventato ottiene una risposta catturata, non un verdetto automatico di vulnerabilità. Il governatore di severità non può alzare; il gate di innalzamento storico del verificatore separato controlla una citazione ma non stabilisce l'exploitability. L'autorizzazione è richiesta al confine dello strumento piuttosto che a ogni richiesta in uscita. I capitoli di reporting distinguono una scansione che non ha trovato nulla da una scansione rifiutata alla porta. Quelle differenze tra intento e applicazione fanno parte del caso di studio, non proprietà da copiare in un nuovo harness.

Ogni capitolo dopo il primo termina ammettendo ciò che il suo controllo sbaglia ancora, e le sezioni di onestà portano le misurazioni che lo dimostrano. Leggi prima le sezioni di onestà se stai decidendo se fidarti del resto: il corpus è la storia operativa di un sistema, l'esecuzione selezionata su target pubblico è un aggregato registrato dall'autore con due esecuzioni escluse pubblicate accanto ad esso, e lo studio di ablazione che mostrerebbe quanto contribuiscono realmente i livelli deterministici non è stato eseguito. Il repository non include i risultati grezzi dell'esecuzione selezionata, la ground truth o il matcher, quindi la precisione registrata non è riproducibile in modo indipendente qui. L'argomento di progettazione è argomentato, non misurato, e il capitolo 05 lo dice con queste parole.

Le cinque leggi

Canoniche nel capitolo 00, copiate qui. Ciascuna è intento di progettazione, e il capitolo nominato alla fine di una legge è dove questo sistema viene valutato contro di essa: quali parti valgono per costruzione, quali valgono solo su uno dei due percorsi di orchestrazione, quali valgono sul buon comportamento dell'orchestratore, e quali non valgono ancora.

1. Il modello propone; il codice deterministico dispone. Dai al modello un'interfaccia di proposta, non accesso diretto al target, storage grezzo o l'ultima parola sulla severità. Il codice deterministico valida, esegue e registra il lavoro ammesso. Il sistema storico non applica quel confine ovunque: entrambi gli orchestratori possono raggiungere una shell, e il suo percorso di scrittura porta un sottocomando che memorizza un risultato senza un'esecuzione. Un endpoint inventato potrebbe restituire 404, una pagina di login o una shell applicativa; registra la risposta e giudica l'affermazione separatamente. Uno scrittore condiviso non è una sandbox. Capitoli 01 e 02.

2. Le affermazioni sul passato devono citare. Le proposte sul futuro devono eseguire. Sono tipi diversi di dichiarazioni e richiedono gate diversi. Un'affermazione su qualcosa già osservato deve citare la propria cattura; una citazione corrispondente stabilisce l'integrità della citazione, non che la conclusione sia vera. Il gate storico perde: mantiene un elemento per batch anche se nessuno passa, e su un percorso di orchestrazione una confidenza fornita dal chiamante può sostituire il controllo. Un test proposto non può essere validato citando un'osservazione che non ha fatto. Può essere eseguito solo dopo che autorizzazione, scope, gate e controlli di budget lo consentono, e il suo esito richiede comunque interpretazione. La legge non è il permesso di eseguire ogni proposta. Capitolo 02.

3. La severità scende per default e sale solo contro prove. Il governatore deterministico può abbassare una severità o marcare un risultato come falso positivo, e non può alzarla. Questo limita la sua autorità; non rende corrette le sue conclusioni. La sotto-segnalazione può nascondere una vulnerabilità reale, quindi ogni regola di abbassamento richiede test di corrispondenza e controesempi e una ragione revisionabile. L'endpoint di innalzamento storico controlla una citazione testuale ma non applica il punteggio autoriale che il suo contratto richiede. Una citazione da sola non è prova di exploitability. Collega la cattura al risultato, applica una policy di prova di dominio revisionata e mantieni un processo separato di revisione e firma umana. Capitolo 03.

4. Lo scope è una funzione, non una frase. L'autorizzazione scritta in un prompt compete con ogni altra istruzione nella finestra di contesto. Codifica il permesso dell'operatore come una policy revisionabile e applicala prima di ogni azione in uscita, con una registrazione dei rifiuti. La guardia storica è carente: viene richiesta al confine dello strumento piuttosto che a ogni richiesta, amplia alcuni confini dell'host, e fallisce aperta sotto un kill switch o quando costruita senza un target. Il lab rifiuta le origini non elencate prima del suo callback affidabile, ma il contenimento del trasporto appartiene ancora all'adattatore. Una decisione di policy è corretta solo quanto l'autorizzazione e la destinazione che valuta. Capitolo 04.

5. Riporta ciò che non hai fatto. Una scansione che non ha trovato nulla e una scansione che non ha potuto raggiungere nulla sono scansioni diverse, e un report che le rende identiche mente per omissione. Copertura, stato del gate e un registro di ogni host saltato con la sua ragione appartengono al deliverable, accanto ai risultati. Questo è un requisito che il report storico non ha soddisfatto: è arrivata solo la copertura, calcolata contro il suo denominatore più debole e sotto un'etichetta che ne nominava uno diverso. Il lab rende conto delle azioni pianificate strumento-e-URL, del lavoro eseguito, degli errori e dei salti; quel denominatore non misura la copertura delle vulnerabilità. Capitolo 05.

I capitoli

L'implementazione di riferimento

Il codice storico sotto core/ è qui per essere letto, eseguito e contestato. È clean-room e deliberatamente non funzionale come tester live: la profilazione, il punteggio di rilevanza, la pianificazione e la validazione delle tool-call sono reali ed eseguibili, e tutto ciò che metterebbe un pacchetto sul filo è trattenuto. Esegui ls core/*.py per vedere cosa viene fornito piuttosto che fidarti di una cifra scritta qui, che è il tipo di affermazione che diventa stantia nel momento in cui viene aggiunto un modulo. I controlli su cui i capitoli successivi fanno affidamento sono tra questi: il percorso di scrittura è core/store_protocol.py, il governatore di severità core/severity_governor.py, la guardia di scope core/scope_guard.py, il gate check core/gate_check.py e la macchina a fasi walkthrough/run.py. Il verificatore storico che chiama il modello è trattenuto. Il capitolo 06 lo specifica; il capitolo 07 fornisce una guardia di prove deterministica separata, non quel verificatore e non un flusso di accettazione umana. Tieni separati i loro compiti: il critico di grounding controlla il contenimento delle citazioni, il governatore limita la severità, e un percorso di innalzamento deve soddisfare una policy di prova revisionata in modo indipendente. Nessuno di essi sostituisce la revisione e la firma umana.

walkthrough/ guida quella macchina a fasi su fixture committate e scrive gli artefatti che i capitoli citano in walkthrough/artifacts/. Rigenerali con python3 -m walkthrough.run, che accetta una directory --out se preferisci non toccare le copie committate, e tests/test_walkthrough_is_in_sync.py confronta un'esecuzione fresca in memoria con quelle copie byte per byte, quindi una fixture modificata senza una riesecuzione diventa rossa invece di essere pubblicata. Ciò che quel gate non cattura è un artefatto che è sbagliato in entrambi i punti, e il suo stesso docstring lo dice.

I numeri

Ogni cifra in ogni capitolo risolve a una chiave in data/stats.json, o porta un'annotazione che nomina cosa sia la cifra e perché non sia una misurazione presa da un target. Attraverso i capitoli da 00 a 05 e questo README, tredici annotazioni nominano una costante o una proprietà del codice, trentacinque coprono una quantità scritta in lettere che il controllo delle cifre non può leggere, cinque nominano un codice di stato HTTP e una nomina un confronto tra due snapshot pubblicati di questo stesso repository. Il file delle statistiche è uno snapshot congelato con una finestra pubblicata, non una query live, e il capitolo 05 spiega perché rieseguire la pipeline non lo riprodurrebbe.

Il capitolo 05 riporta l'F1 del sistema contro un'applicazione pubblica deliberatamente vulnerabile e lo colloca accanto a un punteggio di scansione passiva OWASP ZAP. Questo repository prova l'aritmetica e mantiene i quattro file di punteggi aggregati sincronizzati con data/stats.json; non contiene i risultati grezzi, le voci di ground truth, il matcher, gli identificatori del target o gli identificatori dell'esecuzione necessari per provare che i due strumenti siano stati valutati in un confronto diretto controllato. Tratta la coppia come punti dati storici registrati dall'autore, non come un benchmark equo. La dimensione del campione, la dispersione che quindi non riporta e le esecuzioni escluse con la ragione di ciascuna esclusione sono tutte in quel capitolo.

Una copia generata dei capitoli, con ogni cifra risolta al suo valore in posizione e ogni citazione di codice trasformata in un link in core/, vive in l'albero renderizzato per la lettura su GitHub; è prodotta da scripts/render.py e mantenuta in passo con la fonte da tests/test_rendered_is_in_sync.py.

Se stai pubblicando il repository, segui PUBLICATION.md. Pubblica uno snapshot senza storia in un nuovo repository pubblico; non cambiare la visibilità del repository di sviluppo e non presumere che un albero di lavoro pulito abbia cancellato la sua storia Git raggiungibile. Il pre-commit obbligatorio scripts/publication_gate.sh rifiuta la pubblicazione a meno che la denylist privata non sia stata effettivamente unita, l'identità dell'autore Git pubblico corrisponda al valore approvato e il repository di staging non abbia refs, oggetti o reflog precedenti.

scripts/audit.sh spazza il repository per identificatori, scripts/prose_check.sh e scripts/verify_claims.sh spazzano la prosa, tests/test_gates.sh pianta violazioni contro di essi per provare che scattino ancora, e la suite di test tiene l'implementazione di riferimento contro ciò che i capitoli dicono di essa. Un capitolo non è finito finché ciascuno di questi non passa:

tests/test_chapter_claims.py, dentro quella suite, è quello che vale la pena rubare. Contiene asserzioni contro l'implementazione di riferimento e le statistiche pubblicate, e ciascuna è ancorata alla frase testuale che sostiene, quindi una modifica che cambia un fatto fa fallire un test invece di essere pubblicata silenziosamente.

Theodoros Moutesidis.