autonomous-offensive-llm-handbook

Un harnais et manuel déterministe pour les agents LLM offensifs autonomes, imposant des contrôles d’autorisation, de périmètre et de preuve afin de garantir des tests d’intrusion reproductibles et honnêtes.

Cette version est vérifiée sur CPython 3.14. Les versions antérieures de Python ne font pas partie des preuves de version ; si vous en utilisez une, exécutez la séquence complète de portes ci-dessous avant de vous fier au résultat.

Construire par phases : Borner la frontière des effets de bord et l'ordre des étapes ; Décrire la cible à travers des faits mesurés et des catalogues ; Prouver les affirmations par des captures et des prédicats de politique indépendants ; Contrôler et rendre compte de l'autorisation, des portes, de l'achèvement et du travail omis. L'ordre de développement n'est pas l'ordre d'exécution : l'autorisation et la porte précèdent le lancement.

Le laboratoire public n'effectue aucune requête réseau et n'appelle aucun modèle. Son prédicat de preuve est synthétique, son hôte et ses adaptateurs sont de confiance, et chaque constat est marqué comme nécessitant une revue humaine. Le laboratoire n'implémente pas le flux d'acceptation ou de signature de rapport d'une personne. Une citation verbatim établit l'intégrité de la citation, pas l'exploitabilité. Moins d'appels de modèle et moins de retravail sont des objectifs de conception, pas des économies mesurées par le corpus.

Étude de cas historique

Les chapitres ci-dessous décrivent l'implémentation antérieure core/ et walkthrough/ ainsi que ses défauts publiés. Son vérificateur d'appel de modèle absent reste absent de ce chemin historique. Le nouveau paquet harness/ est une référence de contrôle hors ligne distincte ; il ne répare pas rétroactivement le corpus ni les modules historiques. Lisez la frontière et les corrections du chapitre 07 avant de copier un composant historique.

Pointez un modèle capable vers un hôte, donnez-lui une boîte à outils et dites-lui d'exécuter un test d'intrusion, et il fera quelque chose de sensé. Relancez-le demain et il fera autre chose de sensé, et aucune des deux exécutions ne peut vous dire pourquoi il a ignoré ce que l'autre a détecté. Ce manuel plaide pour une tâche plus réduite pour le modèle : confiez chaque décision à la couche la moins coûteuse qui peut la prendre correctement, et dépensez la capacité du modèle uniquement là où la réponse n'est véritablement pas dérivable de ce que vous possédez déjà. Cet ordre, des décisions qu'une table peut prendre à celles qui nécessitent un modèle, est le gradient du titre du chapitre 00. Les chapitres suivent un agent offensif de sécurité en activité et les contrôles que ses échecs ont exigés.

Le système historique a deux chemins d'orchestration. Sur le chemin piloté par serveur, un orchestrateur conserve sa propre liste de phases et n'offre au modèle que les outils que cette phase autorise. Sur le chemin piloté par agent, un modèle orchestrateur planifie l'exécution et appelle lui-même les outils, les couches sous-jacentes étant construites mais pas toujours consultées. Un chemin d'écriture partagé rend les actions enregistrées et les constats révisables, mais un shell disponible peut le contourner. Un point de terminaison inventé produit une réponse capturée, pas un verdict automatique de vulnérabilité. Le gouverneur de sévérité ne peut pas augmenter ; la porte d'augmentation historique du vérificateur séparé vérifie une citation mais n'établit pas l'exploitabilité. L'autorisation est demandée à la frontière de l'outil plutôt qu'à chaque requête sortante. Les chapitres de rapport distinguent un scan qui n'a rien trouvé d'un scan refusé à la porte. Ces différences entre intention et application font partie de l'étude de cas, pas des propriétés à copier dans un nouveau harnais.

Chaque chapitre après le premier se termine en admettant ce que son contrôle rate encore, et les sections d'honnêteté portent les mesures qui le montrent. Lisez les sections d'honnêteté en premier si vous décidez de faire confiance au reste : le corpus est l'historique opérationnel d'un système, l'exécution sélectionnée sur cible publique est un agrégat enregistré par l'auteur avec deux exécutions exclues publiées à côté, et l'étude d'ablation qui montrerait combien les couches déterministes contribuent réellement n'a pas été menée. Le dépôt n'inclut pas les constats bruts de l'exécution sélectionnée, la vérité terrain ni le matcher, donc la précision enregistrée n'est pas indépendamment reproductible ici. L'argument de conception est argumenté, pas mesuré, et le chapitre 05 le dit en ces termes.

Les cinq lois

Canoniques dans le chapitre 00, copiées ici. Chacune est une intention de conception, et le chapitre nommé à la fin d'une loi est celui où ce système est jugé contre elle : quelles parties tiennent par construction, lesquelles tiennent sur un seul des deux chemins d'orchestration, lesquelles tiennent sur le bon comportement de l'orchestrateur, et lesquelles ne tiennent pas encore.

1. Le modèle propose ; le code déterministe dispose. Donnez au modèle une interface de proposition, pas un accès direct à la cible, au stockage brut ni le dernier mot sur la sévérité. Le code déterministe valide, exécute et enregistre le travail admis. Le système historique n'applique pas cette frontière partout : les deux orchestrateurs peuvent atteindre un shell, et son chemin d'écriture porte une sous-commande qui stocke un constat sans exécution. Un point de terminaison inventé peut renvoyer 404, une page de connexion ou un shell applicatif ; enregistrez la réponse et jugez l'affirmation séparément. Un écrivain partagé n'est pas un bac à sable. Chapitres 01 et 02.

2. Les affirmations sur le passé doivent citer. Les propositions sur le futur doivent s'exécuter. Ce sont des types d'énoncés différents et ils nécessitent des portes différentes. Une affirmation sur quelque chose déjà observé doit citer sa propre capture ; une citation correspondante établit l'intégrité de la citation, pas que la conclusion est vraie. La porte historique fuit : elle conserve un élément par lot même si aucun ne passe, et sur un chemin d'orchestration, une confiance fournie par l'appelant peut se substituer à la vérification. Un test proposé ne peut pas être validé en citant une observation qu'il n'a pas faite. Il ne peut s'exécuter qu'après que les vérifications d'autorisation, de portée, de porte et de budget le permettent, et son résultat nécessite encore une interprétation. La loi n'est pas une permission d'exécuter chaque proposition. Chapitre 02.

3. La sévérité diminue par défaut et n'augmente que contre une preuve. Le gouverneur déterministe peut abaisser une sévérité ou marquer un constat comme faux positif, et ne peut pas en augmenter une. Cela limite son autorité ; cela ne rend pas ses conclusions correctes. La sous-déclaration peut cacher une vulnérabilité réelle, donc chaque règle d'abaissement nécessite des tests de correspondance et de contre-exemple ainsi qu'une raison révisable. Le point de terminaison d'augmentation historique vérifie une citation verbatim mais n'applique pas le score rédigé que son contrat demande. Une citation seule n'est pas une preuve d'exploitabilité. Liez la capture au constat, appliquez une politique de preuve de domaine révisée, et conservez un processus séparé de revue et de signature humaine. Chapitre 03.

4. La portée est une fonction, pas une phrase. L'autorisation écrite dans un prompt entre en compétition avec chaque autre instruction dans la fenêtre de contexte. Encodez la permission de l'opérateur comme une politique révisable et appliquez-la avant chaque action sortante, avec un enregistrement des refus. Le garde historique est insuffisant : il est demandé à la frontière de l'outil plutôt qu'à chaque requête, élargit certaines frontières d'hôtes, et échoue en mode ouvert sous un kill switch ou lorsqu'il est construit sans cible. Le laboratoire rejette les origines non listées avant son rappel de confiance, mais le confinement du transport appartient toujours à l'adaptateur. Une décision de politique n'est aussi correcte que l'autorisation et la destination qu'elle évalue. Chapitre 04.

5. Rapportez ce que vous n'avez pas fait. Un scan qui n'a rien trouvé et un scan qui n'a pas pu atteindre quoi que ce soit sont des scans différents, et un rapport qui les rend identiques ment par omission. La couverture, le statut des portes et un registre de chaque hôte ignoré avec sa raison appartiennent au livrable, à côté des constats. C'est une exigence que le rapport historique n'a pas satisfaite : seule la couverture est arrivée, calculée contre son dénominateur le plus faible et sous une étiquette en nommant un autre. Le laboratoire rend compte des actions planifiées outil-et-URL, du travail exécuté, des erreurs et des sauts ; ce dénominateur ne mesure pas la couverture des vulnérabilités. Chapitre 05.

Les chapitres

L'implémentation de référence

Le code historique sous core/ est ici pour être lu, exécuté et contesté. Il est en chambre blanche et délibérément non fonctionnel comme testeur en direct : le profilage, la notation de pertinence, l'ordonnancement et la validation des appels d'outils sont réels et exécutables, et tout ce qui mettrait un paquet sur le fil est retenu. Exécutez ls core/*.py pour voir ce qui est livré plutôt que de vous fier à un chiffre écrit ici, ce qui est le genre d'affirmation qui devient obsolète dès qu'un module est ajouté. Les contrôles sur lesquels s'appuient les chapitres ultérieurs en font partie : le chemin d'écriture est core/store_protocol.py, le gouverneur de sévérité core/severity_governor.py, le garde de portée core/scope_guard.py, la vérification de porte core/gate_check.py, et la machine à étapes walkthrough/run.py. Le vérificateur d'appel de modèle historique est retenu. Le chapitre 06 le spécifie ; le chapitre 07 livre un garde de preuve déterministe séparé, pas ce vérificateur ni un flux d'acceptation humaine. Gardez leurs rôles séparés : le critique d'ancrage vérifie le confinement des citations, le gouverneur limite la sévérité, et un chemin d'augmentation doit satisfaire une politique de preuve révisée indépendamment. Aucun d'eux ne remplace la revue et la signature humaines.

walkthrough/ pilote cette machine à étapes sur des fixtures validées et écrit les artefacts que les chapitres citent dans walkthrough/artifacts/. Régénérez-les avec python3 -m walkthrough.run, qui prend un répertoire --out si vous préférez ne pas toucher aux copies validées, et tests/test_walkthrough_is_in_sync.py compare une exécution fraîche en mémoire à ces copies octet par octet, donc une fixture modifiée sans ré-exécution rougit au lieu d'être livrée. Ce que cette porte ne détecte pas, c'est un artefact qui est faux aux deux endroits, et son propre docstring le dit.

Les chiffres

Chaque chiffre de chaque chapitre se résout en une clé dans data/stats.json, ou porte une annotation nommant ce que le chiffre est et pourquoi ce n'est pas une mesure prise sur une cible. À travers les chapitres 00 à 05 et ce README, treize annotations nomment une constante ou une propriété du code, trente-cinq couvrent une quantité épelée que la vérification de chiffres ne peut pas lire, cinq nomment un code de statut HTTP, et une nomme une comparaison entre deux des propres instantanés publiés de ce dépôt. Le fichier de statistiques est un instantané figé avec une fenêtre publiée, pas une requête en direct, et le chapitre 05 explique pourquoi ré-exécuter le pipeline ne le reproduirait pas.

Le chapitre 05 rapporte le F1 du système contre une application publique délibérément vulnérable et le place à côté d'un score de scan passif OWASP ZAP. Ce dépôt prouve l'arithmétique et maintient les quatre fichiers de scores agrégés synchronisés avec data/stats.json ; il ne contient pas les constats bruts, les entrées de vérité terrain, le matcher, les identifiants de cible ni les identifiants d'exécution nécessaires pour prouver que les deux outils ont été évalués dans un face-à-face contrôlé. Traitez la paire comme des points de données historiques enregistrés par l'auteur, pas comme un benchmark équitable. La taille de l'échantillon, la dispersion qu'elle ne rapporte donc pas, et les exécutions exclues avec la raison de chaque exclusion sont toutes dans ce chapitre.

Une copie générée des chapitres, avec chaque chiffre résolu à sa valeur en place et chaque citation de code transformée en lien vers core/, vit dans l'arbre rendu pour la lecture sur GitHub ; elle est produite par scripts/render.py et maintenue en phase avec la source par tests/test_rendered_is_in_sync.py.

Si vous publiez le dépôt, suivez PUBLICATION.md. Publiez un instantané sans historique dans un nouveau dépôt public ; ne changez pas la visibilité du dépôt de développement et ne supposez pas qu'un arbre de travail propre a effacé son historique Git accessible. Le pré-commit obligatoire scripts/publication_gate.sh refuse la publication à moins que la denylist privée n'ait été réellement fusionnée, que l'identité d'auteur Git publique ne corresponde à la valeur approuvée, et que le dépôt de préparation n'ait aucune réf antérieure, aucun objet ni aucun reflog.

scripts/audit.sh balaie le dépôt pour les identifiants, scripts/prose_check.sh et scripts/verify_claims.sh balaient la prose, tests/test_gates.sh plante des violations contre eux pour prouver qu'ils se déclenchent toujours, et la suite de tests maintient l'implémentation de référence contre ce que les chapitres disent d'elle. Un chapitre n'est pas terminé tant que chacune de ces étapes ne passe pas :

tests/test_chapter_claims.py, dans cette suite, est celui qui vaut la peine d'être volé. Il contient des assertions contre l'implémentation de référence et les statistiques publiées, et chacune est ancrée à la phrase verbatim qu'elle soutient, donc une modification qui change un fait échoue à un test au lieu d'être livrée silencieusement.

Theodoros Moutesidis.