IA en red team : périmètre, mémoire de travail et niveaux d’autonomie

« Trouve une faille ici » est souvent la pire première consigne à donner à un assistant. Le mot ici peut désigner une VM clonée, un réseau client vivant, une session administrateur ou un compte de test. Le modèle comble les blancs avec une histoire plausible, puis l’opérateur risque de suivre une piste qui répond à cette histoire plutôt qu’à la cible. La première règle est moins spectaculaire : lui laisser comprendre ce qui existe, ce que nous savons et ce qu’il lui manque. Ce travail ralentit les premières minutes ; il évite des heures à interpréter le mauvais résultat.

Ces règles parlent de jugement pendant une mission, pas de l’architecture d’un agent. Notre note sur les garde-fous de périmètre décrit déjà un proxy, des classes d’action, un journal et un arrêt d’urgence proposés. Elle reste une note de travail, pas le récit d’un dispositif déployé. Ici, la question est celle qui précède chaque commande : pourquoi ce test, avec quelle identité, et quel résultat nous ferait changer d’avis ?

Construire la cible avant de chercher la faille

Au début d’une mission, je donnerais à l’assistant une fiche courte : produits et versions observés avec leur source, hôtes et chemins autorisés, comptes et droits obtenus, fenêtre de test, services fragiles, puis objectif de l’exercice. J’ajouterais ce qui reste inconnu. « La console semble accessible depuis le VLAN de test » n’est pas « la console est exposée à Internet ». « Ce processus affiche SYSTEM dans un journal » n’est pas « notre code s’exécute avec un jeton SYSTEM ». Les mots que l’on choisit dans la fiche fixent la qualité du raisonnement qui suit.

Le cours SEC565 place le renseignement, le scénario, le périmètre et les règles d’engagement avant l’exécution. C’est aussi la logique des plans d’émulation de MITRE ATT&CK : relier des comportements en séquence à partir de rapports publics, tout en gardant les limites de ces rapports. L’IA peut aider à relier les observations à un scénario. Elle ne reçoit ni le pouvoir d’élargir le mandat ni celui d’inventer les faits manquants.

Avant de demander une piste, je lui demanderais : « reformule les identités et les frontières de confiance ; indique trois faits établis, trois inconnues et la source de chaque fait ». Si elle ne sait pas si une commande tourne dans la VM cible ou sur le poste opérateur, la prochaine action est une question de contexte, pas une tentative d’exploitation. Cela ressemble à une perte de temps seulement jusqu’au jour où une sortie whoami provenait du mauvais hôte.

Tester une hypothèse avec un contrôle négatif

Supposons qu’une application renvoie 200 à une requête envoyée avec un compte peu privilégié. Une lecture pressée dit « contrôle d’accès absent ». Une autre dit « réponse identique mais données filtrées ». Une troisième dit « la session navigateur a fourni un cookie administrateur ». L’assistant doit produire ces lectures concurrentes avant que nous choisissions celle qui nous plaît. Le test utile est une session propre, sans cookie, suivie d’une comparaison du contenu, de l’effet et du code HTTP. Cet exemple est hypothétique ; il illustre une méthode, pas une vulnérabilité découverte par rootzero.

Chaque piste doit inclure un contrôle capable de la réfuter : demander un objet inexistant, vérifier le jeton effectif ou inspecter le chemin réel de l’écriture. Les résultats de ce contrôle doivent être conservés avec ceux du test initial. La même vérification s’applique aux hypothèses de l’opérateur et à celles proposées par le modèle.

Tenir un journal des résultats de test

Le contexte de l’assistant contient des consignes, des résultats d’outils et des pages de la cible. La réduction de cet historique peut supprimer des détails nécessaires à la vérification d’un constat. Anthropic décrit le contexte comme une ressource finie à sélectionner et rafraîchir au fil des étapes. Nous proposons de conserver séparément le journal de décision suivant :

FAIT       Compte test A : GET /records/17 -> 200, corps sans champ owner.
SOURCE     Requête 0042 et réponse 0043 ; navigateur sans session admin.
HYPOTHÈSE Le filtre est appliqué au corps, mais pas à l’existence de l’objet.
ÉCARTÉ     « lecture complète d’un objet tiers » : champ sensible absent.
PROCHAIN   Comparer /records/17 et un identifiant absent avec le même compte.

Les références renvoient aux traces conservées hors du prompt. Le carnet empêche « nous avons prouvé l’accès » de survivre après un contrôle qui l’a réfuté. À chaque étape, l’assistant peut proposer une mise à jour ; l’opérateur confronte cette mise à jour aux sorties brutes. On relit les appels d’outil et leurs paramètres, pas uniquement le résumé final. Les pages et documents de la cible restent des données non fiables : ils peuvent contenir des instructions destinées au modèle, sans devenir des règles de mission.

Donner de l’autonomie selon le coût de l’erreur

Dans une VM possédée, isolée, restaurable et garnie de données factices, un agent peut enchaîner des lectures, modifier ses scripts de test et rejouer des contrôles négatifs sous un budget borné. L’intérêt de cette autonomie est de multiplier les expériences vérifiables. Elle n’autorise pas à transformer un artefact de labo en constat sur une version de production : il faut encore établir la version, les préconditions, la chaîne jusqu’à l’impact et le résultat contraire.

Sur un système client vivant, le coût change. Un appel qui envoie des courriels, modifie des droits, touche à la disponibilité ou sort du périmètre ne devient pas acceptable parce que le modèle le qualifie de « prochaine étape logique ». L’opérateur doit examiner l’action exacte, sa cible, son volume et son effet attendu avant de la lancer, dans le cadre des règles d’engagement. Les droits du compte et les contrôles de l’outil doivent limiter ce qui peut partir, même si le modèle ou l’humain se trompe. L’OWASP distingue justement les excès de fonctions, de permissions et d’autonomie.

Multiplier les boîtes « approuver » n’est pas une solution suffisante : on finit par cliquer sans lire. Anthropic a observé cette fatigue dans ses propres demandes d’autorisation Claude Code ; cette observation ne mesure pas les équipes red team. La leçon applicable est de réduire la portée des outils et d’isoler l’environnement, puis de réserver les validations humaines aux décisions qui le méritent. (Retour d’expérience d’Anthropic)

La recherche de vulnérabilités dans un laboratoire maîtrisé et l’émulation sur un réseau client n’appellent donc pas le même degré d’autonomie. Dans les deux cas, l’assistant peut être rapide et inventif. Il devient utile quand il sait dire « je ne sais pas », quand nous acceptons de retirer une conclusion séduisante, et quand la prochaine action a été choisie pour départager des hypothèses plutôt que pour entretenir une histoire.