Faire tourner en bac à sable un pipeline d'IA qui trouve et corrige des failles de sécurité

## Confier le travail en lecture seule aux compétences d'analyse et l'exécution de code au bac à sable Ce type de système comporte deux surfaces distinctes ; orientez l'utilisateur vers la bonne. - Les compétences d'analyse interactive lisent et écrivent des fichiers dans le dépôt et s'exécutent dans votre session en cours. Elles n'exécutent jamais le code cible. Utilisez-les pour le cadrage, la modélisation des menaces, la revue statique des vulnérabilités, le tri d'un ensemble de découvertes existant, la rédaction de correctifs candidats et le portage du pipeline vers une autre pile technique. Orientez ici pour les questions et tout travail en lecture seule. - Le pipeline autonome exécute réellement la cible pour trouver et vérifier les plantages. Comme il fait tourner du code non fiable, influencé par un attaquant, il doit s'exécuter dans un bac à sable contre une version instrumentée. Orientez ici uniquement quand l'utilisateur veut des découvertes réelles, vérifiées par exécution, plutôt qu'un avis statique. Ne confondez pas les deux : la surface lecture/écriture raisonne sur le code, la surface d'exécution le fait tourner. L'une informe ; l'autre prouve. La sortie côté exécution est un fichier d'entrée reproduisant le plantage, pas du texte. ## Commencer par une petite exécution d'essai, puis lancer l'exécution complète en arrière-plan Pilotez le pipeline comme un tableau de bord en direct, pas comme un lot lancé puis oublié. - Guidez d'abord l'utilisateur à travers la reconnaissance de façon interactive : montrez les zones d'intérêt découvertes et laissez-le ajuster le découpage avant tout lancement. - Pour une première exécution sur une nouvelle cible, lancez une petite vague (quelques exécutions parallèles, un plafond de tours bas) pour que l'utilisateur se fasse une idée de la consommation de tokens et du calibrage des prompts avant de monter en puissance. Examinez une transcription ensemble si quelque chose semble anormal. - Lancez ensuite l'exécution plus large en arrière-plan afin de pouvoir suivre les journaux, regarder les découvertes s'accumuler et répondre aux questions sans bloquer. Dès qu'un résultat vérifié arrive, faites-le remonter avec un court résumé plutôt que d'attendre tout le lot. La première découverte vérifiée arrive généralement en quelques minutes, pas en heures ; une exécution traînante ne ralentit qu'elle-même, pas le lot. ## Écrire chaque transcription sur disque pour ne rien perdre si l'exécution s'arrête Dotez chaque exécution de deux couches d'observabilité toujours actives. - Un signal de vie imprimé tous les quelques tours prouve que le processus est toujours actif pendant les longues périodes de silence. - Une ligne de progression par action montre ce que fait chaque agent, une ligne par appel d'outil ou bloc de texte. Diffusez chaque transcription d'agent vers le disque au fur et à mesure de l'arrivée des messages, avec écriture durable. Rien d'important n'est mis en mémoire tampon uniquement en mémoire, si bien qu'un arrêt en cours d'exécution laisse quand même des transcriptions complètes et lisibles à examiner par la suite. Quand l'utilisateur demande le statut, répondez à partir des artefacts présents sur le disque : comptez les découvertes encore actives, celles déjà notées et les rapports rédigés, puis montrez les plus récents. Chaque résultat est écrit dès que sa propre exécution se termine, si bien que les traînards ne bloquent jamais l'arrivée des autres. ## Reprendre les agents après une limite de débit au lieu de perdre l'exécution Les erreurs de capacité transitoires ne doivent pas tuer une exécution ; construisez l'échelle de récupération pour que les tâches longues traversent les pics sans encombre. - Chaque agent est une session de longue durée. Une erreur de limite de débit ou une erreur serveur en cours d'exécution est d'abord retentée à l'intérieur du client propre de l'agent. - Si cela échoue, l'orchestrateur applique un temps d'attente croissant (exponentiel, plafonné) et relance l'agent en reprenant sa session, de sorte que tout le contexte de la conversation est restauré et qu'il repart exactement du tour qui avait échoué. - Plafonnez le nombre de reprises par agent pour qu'un agent réellement bloqué finisse par s'arrêter. Dites à l'utilisateur qu'il peut fonctionner près de sa capacité provisionnée et laisser le mécanisme de temporisation absorber les pics ; il n'a pas besoin de s'autolimiter pour éviter de perdre du travail. Une exception : une erreur de dépassement du nombre de tours est définitive et n'est délibérément pas reprise, car la reprendre multiplierait le plafond de tours — augmentez plutôt le plafond et relancez. Toute découverte déjà soumise par l'agent avant d'atteindre une limite est quand même récupérée et notée, pas jetée avec l'exécution. ## Rédiger automatiquement les rapports des nouveaux bugs et demander avant d'utiliser le réseau En mode flux continu, la rédaction des rapports est automatique. Quand un plantage franchit la notation, un agent juge décide s'il s'agit d'un nouveau bug, d'un représentant plus propre d'un bug connu, ou d'un doublon à ignorer ; un nouveau bug déclenche immédiatement un agent de rapport, sans attendre le lot. Un chemin de rapport par lot autonome reste disponible pour la récupération, ou pour des résultats produits sans flux continu. Chaque rapport est une analyse structurée de l'exploitabilité — comment se comporte la primitive, si elle est atteignable depuis la surface d'attaque réelle, le chemin d'escalade et les contraintes — plus une gravité jugée par un agent. Un agent noteur distinct évalue le rapport selon une grille sémantique, pas par une simple recherche de mots-clés. Avant d'activer une étape qui touche un réseau externe — par exemple une vérification de nouveauté qui clone le dépôt amont de la cible pour déterminer si un bug est déjà corrigé — demandez d'abord à l'utilisateur. Laissez-la désactivée par défaut : les environnements isolés du réseau ou à sortie restreinte ne voudront pas que le pipeline accède à l'extérieur. Seul l'hôte orchestrateur touche jamais le réseau ; les conteneurs d'agents restent de toute façon limités au point de terminaison du modèle. ## Vérifier que le plantage a disparu et laisser une personne accepter le correctif La phase de correction peut s'exécuter après la rédaction des rapports ou de manière autonome. Pour chaque plantage unique, un agent de correction dans un conteneur isolé neuf rédige un correctif et produit un diff ; un conteneur noteur distinct parcourt une échelle de vérification. - Appliquer le diff et reconstruire. - Confirmer que l'entrée d'origine qui reproduisait le plantage ne le provoque plus. - Confirmer que la suite de tests propre à la cible passe toujours. - Réattaquer le binaire corrigé avec un nouvel agent de recherche, limité dans le temps. En cas d'échec à un échelon, les éléments constatés sont renvoyés et l'agent de correction itère un nombre limité de fois ; une revue consultative optionnelle peut être ajoutée comme échelon final. Soyez explicite avec l'utilisateur sur ce que cela prouve. L'échelle vérifie que le plantage a disparu ; elle ne vérifie pas que le diff est sûr à intégrer en amont. Faites remonter le diff pour une revue humaine et indiquez les consignes de revue. Ne proposez jamais d'appliquer le diff à quoi que ce soit en dehors des propres conteneurs du pipeline — les correctifs générés sont des propositions à accepter par un humain, pas des changements à intégrer automatiquement. ## Laisser les agents juger les plantages en double selon leur cause, pas selon le texte Dédupliquez les plantages grâce au jugement de l'agent sur deux niveaux, pas par comparaison de chaînes. - Au moment de la soumission, un agent de recherche doit joindre son propre raisonnement expliquant pourquoi un plantage est distinct de ce qui est déjà enregistré dans le fichier partagé des découvertes. Le pipeline rejette toute soumission qui l'omet. C'est l'agent qui tranche, parce qu'il connaît la cause racine ; le pipeline se contente d'imposer que ce jugement ait eu lieu. Comparez sémantiquement les extraits bruts du désinfecteur, pas par correspondance de texte exacte. - Au niveau du portail de rapport, un juge lit chaque plantage noté en le comparant au manifeste des rapports en cours et décide : nouveau, doublon plus propre, ou à ignorer. Une même cause racine qui ressurgit à des lignes ou des cadres différents est quand même dédupliquée ; un doublon plus propre déclenche un nouveau rapport, puis une étape de comparaison choisit la version canonique. Quand vous enregistrez un bug connu, indexez-le sur le nom de la fonction, pas sur le numéro de ligne : le même bug plante à des lignes adjacentes, ou avec des types de désinfecteur différents, selon l'entrée. ## Garder la recherche et la notation dans des conteneurs séparés et verrouillés C'est le modèle d'isolation qui rend fiables les résultats vérifiés par exécution ; traitez-le comme non négociable. - La recherche et la notation s'exécutent dans des conteneurs distincts construits à partir de la même image. Seuls les octets de la preuve de concept passent de l'un à l'autre. Le côté recherche ne touche jamais le côté notation, ce qui déjoue tout détournement de récompense via un état pré-positionné. - Chaque agent s'exécute dans son propre conteneur, avec un environnement d'exécution durci et une sortie réseau limitée à une liste d'autorisation configurée — dans le bac à sable, pas sur l'hôte. Ses outils de fichiers et de shell sont confinés à ce conteneur. - Les commandes qui font démarrer des agents refusent de s'exécuter en dehors du bac à sable, sauf si une dérogation explicitement dangereuse est passée. - L'ensemble d'outils des agents est fixe et minimal : les agents actifs n'ont que la lecture, l'écriture et le shell ; les agents juges et comparateurs n'ont aucun outil et font tout en un seul appel promptisé. Aucun outil de plugin, aucun accès web. ## Éviter les réglages qui cassent le démarrage et ajouter des cibles sans changer le code Quelques détails opérationnels sont faciles à casser et méritent d'être posés d'emblée. - Certains réglages d'environnement sont des piliers : l'un désactive la protection contre les sessions imbriquées de l'outil embarqué dans le conteneur, l'autre lui permet d'accepter un mode de contournement des permissions à l'intérieur du bac à sable. Retirer l'un ou l'autre casse le démarrage de l'agent. - Distinguez « restreindre l'ensemble d'outils disponibles » de « liste d'autorisation des permissions » — une CLI peut accepter les deux options, mais elles signifient des choses différentes ; utilisez celle qui restreint réellement les outils existants, pas seulement ceux qui sont autorisés. - Le choix du modèle est un argument d'exécution, pas une configuration statique, si bien que la même définition de cible peut être pilotée par n'importe quel modèle. - Un analyseur instrumenté par un désinfecteur peut avoir besoin d'un attribut anti-inlining pour que l'inlining du compilateur ne change pas la signature du plantage. Ajouter une cible consiste à déposer un répertoire avec une définition de build et une configuration de désinfecteur ; aucune modification du code du pipeline. Couvrez les parties mobiles avec des tests unitaires — l'analyse des balises et des sorties, la sérialisation des artefacts, l'extraction de signature, la déduplication et l'échelle correction-notation — et gardez une cible de test rapide comme chemin de fumée de bout en bout. ## Chercher la trace d'un attaquant dans les journaux sans que l'agent voie les réponses Une variante post-compromission inverse le problème : l'attaquant est déjà présent dans les journaux, et le travail consiste à retrouver sa campagne plutôt qu'à faire planter un binaire. - Le corpus de journaux doit être généré avant toute exécution. Il est volumineux et déterministe par graine, si bien que la même graine reproduit les mêmes preuves sur la même machine. - Un agent de chasse reçoit le code source de l'application et des journaux en lecture seule, puis soumet ses découvertes d'incident. Par construction, aucune grille de réponse n'existe à l'intérieur de son conteneur. - Un agent de notation, dans un conteneur neuf, note la soumission et rejoue indépendamment chaque preuve de concept confirmée. Seule la soumission traverse la frontière. Protégez l'intégrité de l'évaluation : les fichiers de vérité terrain, le noteur et le code source du générateur de journaux sont des indices révélateurs. Ne les montez et ne les lisez jamais du côté chasse. La même structure interactive-puis-autonome que le pipeline de plantages s'applique ici.