Les équipes de sécurité font appel à des agents IA pour trouver des vulnérabilités, générer des correctifs et réduire l’arriéré de failles à analyser. Mais une analyse plus rapide peut aussi accélérer l’exposition de données, l’escalade de privilèges ou l’introduction d’une modification de code dangereuse. Un article de Google Cloud et Mandiant publié le 16 juillet 2026 propose un modèle opérationnel utile : combiner les capacités de l’IA avec des contrôles déterministes, une exécution isolée et le jugement humain.
L’urgence est claire. L’article cite les renseignements sur les menaces de Mandiant pour 2026, selon lesquels des vulnérabilités peuvent être exploitées avant qu’un correctif soit disponible. Cela ne signifie pas que chaque équipe de sécurité devrait donner à un agent un accès étendu à ses dépôts. Cela signifie que le flux de travail doit être conçu pour appliquer la vitesse à des tâches contrôlées et vérifiables.
1. Commencer par un contrôle des données et du modèle de menace
Avant qu’un agent ne voie une instruction ou un fichier source, définissez précisément les données qu’il peut traiter. Testez le flux de travail dans un environnement hors production contenant des données synthétiques. Supprimez les secrets, les informations personnelles et tout autre élément sensible avant qu’ils n’atteignent le modèle. Les déploiements en production nécessitent une conception en couches : un moteur de politiques déterministe doit servir de première barrière, tandis qu’un modèle de garde distinct ou un contrôle équivalent peut inspecter les instructions et les sorties afin de détecter les tentatives d’injection ou les contenus sensibles.
Traitez le code comme une entrée non fiable, même lorsque le dépôt est interne. Des instructions malveillantes peuvent être dissimulées dans des commentaires, de la documentation ou des dépendances tierces. Un agent qui suivrait ces instructions pourrait ignorer une faille ou tenter d’exposer des variables d’environnement. L’ingestion du dépôt doit donc inclure l’assainissement des entrées, l’examen des dépendances et un relevé précis des fichiers fournis à l’agent.
2. Isoler chaque charge de travail d’agent
Exécutez l’analyse dans un environnement strictement isolé et sans privilèges, avec des permissions limitées dynamiquement. L’agent ne doit partager ni identifiants, ni volumes accessibles en écriture, ni accès réseau étendu avec les services de production. Utilisez des environnements éphémères pouvant être détruits après chaque revue et limitez les connexions aux systèmes nécessaires au test approuvé.
Cette mesure de confinement limite les dégâts si un agent hallucine une commande destructive, entre dans une boucle récursive ou est manipulé par une injection d’instructions. Elle facilite aussi l’audit du flux de travail : chaque exécution possède un périmètre défini, un état initial connu et un point de terminaison clair.
3. Donner à l’agent une identité restreinte
Les agents IA peuvent avoir besoin d’ouvrir une pull request ou de créer un commit proposant un correctif, mais ils ne doivent pas opérer avec le compte personnel d’un développeur. Créez une identité machine distincte pour chaque flux de travail et rattachez-la à un responsable humain identifié. Utilisez des jetons éphémères, délivrés juste à temps, limités à un seul dépôt et, si possible, à une seule branche en cours d’examen.
Examinez la chaîne d’approvisionnement autour de l’agent avec autant d’attention que l’agent lui-même. Les compétences tierces, les plug-ins et les serveurs Model Context Protocol peuvent introduire des dépendances compromises ou des mises à jour dangereuses. Verrouillez les versions approuvées, hachez ou vérifiez autrement les outils entrants et exigez une revue avant toute modification d’une intégration. Le framework d’orchestration doit également être évalué, car l’empoisonnement de la mémoire de session et les faiblesses liées aux boucles récursives peuvent affecter l’ensemble du flux de travail.
4. Rendre les actions observables et testables
Enregistrer la réponse finale ne suffit pas. Conservez les entrées de l’agent, ses appels d’outils, ses sorties, son identité, la version du modèle et les points de terminaison de destination. Surveillez les mouvements de données à l’exécution afin que le contexte interne ne puisse pas circuler silencieusement vers un service externe non approuvé. Des journaux centralisés et résistants aux altérations doivent permettre à un responsable de reconstituer ce que l’agent a vu, tenté et modifié.
Utilisez autant que possible une validation déterministe. Si un agent affirme avoir trouvé une vulnérabilité, exigez un banc de test reproductible pouvant s’exécuter dans l’environnement isolé. Définissez des délais d’exécution et des limites d’itérations afin qu’une tentative de preuve échouée ne puisse pas consommer une quantité illimitée de calcul ou de budget API. Une exécution réussie prouve qu’une condition technique s’est produite, mais ne démontre pas automatiquement que le problème est exploitable ou prioritaire.
5. Orienter le bon travail vers le bon outil
Conservez les contrôles SAST et DAST conventionnels pour assurer une couverture de référence. Les agents IA sont particulièrement utiles lorsque leurs points forts correspondent à la cible. Les recommandations de Google Cloud identifient le code vulnérable aux problèmes de mémoire, comme le C et le C++, comme un bon candidat pour des audits assistés par agent, car la corruption mémoire peut produire un crash observable ou un autre résultat binaire. En revanche, les contournements d’autorisation et les failles de logique métier nécessitent souvent une connaissance des frontières de confiance et de l’intention métier que l’agent ne peut pas déduire de manière fiable du seul code source.
Ne dirigez pas un scanner autonome vers tous les dépôts en même temps. Commencez par un périmètre réduit et à fort impact, définissez l’oracle attendu pour la réussite et mesurez la charge de revue. Les agents peuvent réduire l’effort nécessaire pour trouver des problèmes candidats, mais ils n’offrent pas une couverture exhaustive et peuvent manquer des vulnérabilités inédites.
6. Garder la remédiation derrière une pull request
Pour les problèmes localisés de niveau syntaxique, un assistant intégré à l’IDE peut proposer une modification ciblée qu’un développeur examine avant de la valider. Les changements plus larges doivent être pris en charge par un exécuteur CI/CD qui crée une pull request au lieu de modifier directement la branche principale.
Exécutez la suite normale de régression ainsi que le banc de test déterministe d’origine sur le correctif proposé. Si la preuve de concept fonctionne toujours, le correctif n’a pas fermé la condition démontrée. Si le patch passe, un ingénieur doit malgré tout examiner la possibilité d’atteinte, l’architecture et l’impact métier avant la fusion. C’est particulièrement important lorsqu’un correctif techniquement valide pourrait affaiblir la logique d’autorisation ou introduire une nouvelle régression.
7. Ajouter des contrôles après le déploiement
Le code généré par l’IA mérite la même discipline de restauration que toute autre modification importante. Maintenez un chemin automatisé vers une version connue comme fiable, verrouillez les versions des API de modèles lorsque le flux de travail dépend d’un comportement reproductible et prévoyez des migrations contrôlées lorsqu’une version verrouillée arrive en fin de vie. Conservez des journaux d’audit immuables indiquant la version du modèle, les résultats de validation et l’ingénieur ayant approuvé le changement.
La règle pratique est simple : laissez l’IA accélérer la découverte et la préparation, mais maintenez l’accès, l’exécution, la fusion et le confinement dans des limites déterministes. Cette combinaison offre aux équipes de sécurité un flux de gestion des vulnérabilités plus rapide sans transformer l’agent de gestion des vulnérabilités en opérateur de production privilégié.
Source : Google Cloud et Mandiant, « Demystifying AI Exploits: A Blueprint for AI-Assisted Vulnerability Management », publié le 16 juillet 2026.