Agent-guard 0.7 : sécuriser les tests des agents IA

Le faux positif a un coût opérationnel

Une règle qui bloque toute modification d'un fichier de test paraît simple. Sur le long terme, elle devient vite pénible : les développeurs doivent toucher aux tests pour faire évoluer le produit. Si chaque changement déclenche une alerte sans nuance, l'équipe finit par contourner la règle, la désactiver, ou ignorer ses avertissements.

Donc oui : trop bloquer, c'est créer de la friction ; trop laisser passer, c'est ne plus protéger grand-chose. Le vrai défi est de distinguer des motifs reconnaissables sans prétendre que l'outil saura toujours lire dans l'intention de la personne - ou de l'agent - qui a fait le changement.

C'est encore plus vrai quand des agents peuvent modifier plusieurs fichiers et exécuter les tests de manière autonome. La revue humaine ne disparaît pas, mais elle ne peut pas non plus dépendre d'un examen ligne par ligne « en temps réel ». Il faut donc un garde-fou qui stoppe les changements vraiment suspects, garde une trace claire des décisions, et évite de transformer les cas ambigus en blocages impossibles à gérer.

Pourquoi une règle binaire ne suffit pas

Avant la version 0.7, la logique du projet semblait plus « binaire » : soit on bloque, soit on laisse passer. Et la question qu'on se pose forcément - « comment savoir si c'est légitime ? » - met le doigt sur la limite : certains changements sont clairement dangereux, d'autres plausibles, et une partie ne peut pas être classée automatiquement sans doute raisonnable.

La version 0.7 rend cette nuance visible. Elle ne prétend pas deviner l'intention à coup sûr. Elle propose plutôt une décision exploitable : autoriser ce qui paraît légitime, bloquer ce qui paraît suspect, et faire remonter les cas incertains pour qu'une personne tranche.

Changements considérés comme légitimes

La catégorie legit regroupe des changements que le classificateur juge compatibles avec un travail normal sur les tests. La liste fournie comprend notamment :

• l'ajout de nouvelles fonctions de test ;
• l'ajout de fixtures ou de fonctions auxiliaires ;
• l'ajout de nouveaux imports ;
• le renommage de certains éléments ;
• des modifications limitées aux commentaires.

Dans ces cas, la session se termine normalement et l'événement est inscrit dans le journal d'audit. L'intérêt est simple : limiter les interruptions sur des changements qui ajoutent du contexte ou renforcent la couverture, sans donner l'impression qu'une vérification a été neutralisée.

Cela dit, il faut garder la tête froide sur ce que signifie le verdict : c'est une décision heuristique basée sur le diff, pas une preuve que le test « est correct ». Un test nouvellement ajouté peut être bancal. Un renommage peut aussi s'inscrire dans une modification plus large. Le verdict automatise un contrôle - il ne remplace pas la revue de code.

Changements bloqués comme suspects

La catégorie malicious vise des motifs associés à l'affaiblissement ou à la suppression des vérifications. Dans la description de la version 0.7, on retrouve par exemple :

• des assertions affaiblies, supprimées ou inversées ;
• de nouveaux tests ignorés ou désactivés ;
• un bloc try/except qui masque une assertion retirée ;
• la suppression complète d'un fichier de test.

Ces modifications restent bloquées, comme dans la version précédente, et le message de blocage affiche le verdict. Et honnêtement, le détail compte : un refus explicite avec un motif compréhensible aide plus qu'un blocage opaque que personne ne saura quoi contourner.

Changements ambigus : le cas des snapshots

La catégorie ambiguous couvre les changements que l'outil ne peut pas interpréter avec assez de confiance. L'exemple donné est la modification d'une valeur attendue sans changement évident du niveau de sévérité du test. Ça peut correspondre à une mise à jour légitime d'un snapshot après une évolution d'API... ou à une tentative de faire accepter un résultat incorrect.

Par défaut, la version 0.7 bloque ces cas. C'est un choix prudent : quand l'heuristique ne sait pas départager les deux intentions, elle ne transforme pas son incertitude en autorisation silencieuse. La conséquence, c'est qu'il faut une façon contrôlée de valider une mise à jour légitime. C'est précisément le rôle de la dérogation.

Variante pour les agents qui ne passent pas d'options

Si l'agent ne peut pas transmettre de paramètres à la commande, la documentation propose aussi une variable d'environnement :

export AGENT_GUARD_ALLOW_TEST_CHANGE=1

C'est pratique en automatisation, mais ça demande de la prudence : une variable d'environnement peut toucher un périmètre plus large que l'action précise qui l'a motivée, selon la façon dont le processus est lancé. Mieux vaut limiter sa durée et son contexte, puis vérifier que la décision est bien visible dans l'audit.

Ce qui est enregistré

Chaque utilisation de la dérogation est ajoutée au journal avec le motif, la session, les fichiers concernés et les verdicts associés. Dans agent-guard log, la décision apparaît sous la forme allowed-escape-hatch.

Cette trace répond à une question très concrète : qui a autorisé le passage, sur quels fichiers, et pourquoi ? Elle aide à relire un changement après exécution et permet de repérer les dérogations répétées. Si l'exception devient la norme, le problème n'est peut-être plus ponctuel : il faut peut-être réexaminer la règle, le classificateur, ou le processus de test.

La dérogation ne doit donc pas devenir un bouton « continuer quand même » sans conséquence. Sa valeur tient à deux choses : une décision explicitement prise au moment du changement, et une trace consultable ensuite. L'exception est facile à utiliser, mais elle n'est pas invisible.

Examiner un diff sans bloquer la session

La commande agent-guard test-review --session <id> sert à classer le diff courant sans bloquer. En pratique, c'est utile pour voir ce que le garde-fou détecte avant de décider quoi faire. Vous pouvez l'utiliser pour comprendre un cas ambigu, préparer une revue, ou vérifier si un changement « a priori légitime » risque quand même d'être stoppé.

Un déroulé réaliste peut ressembler à ça :

1. L'agent modifie le code et les tests dans le cadre de la session.
2. Le hook compare les fichiers de test avec leur état au démarrage.
3. Les changements classés legit sont consignés ; les changements malicious ou ambiguous sont bloqués.
4. Pour un cas ambigu jugé justifié, une personne examine le diff et lance la dérogation avec un motif précis.
5. L'équipe fait ensuite la revue normale du code et décide de valider ou non la modification.

Ce processus ne remplace ni la CI ni la revue humaine. Il ajoute un contrôle au moment où un agent a pu toucher aux tests. Le traiter comme une barrière autonome serait une erreur ; mieux vaut le voir comme un garde-fou complémentaire.

Quelques vérifications avant adoption

Dans un contexte pro, surtout si le code ou les journaux contiennent des données sensibles, il faut regarder au minimum :

• quels fichiers sont considérés comme des tests dans votre dépôt ;
• où les journaux sont conservés et qui peut les consulter ;
• comment les variables d'environnement sont propagées aux agents ;
• qui a le droit d'utiliser une dérogation ;
• comment les verdicts s'intègrent à votre revue de code et à votre CI.

Ces points ne sont pas des « fonctionnalités » d'agent-guard : ce sont des questions d'intégration qui dépendent de votre organisation. Ça compte particulièrement en Europe, où les règles internes de sécurité, de confidentialité et de traitement des données varient beaucoup selon le projet. L'outil ne remplace pas la vérification des obligations applicables, notamment pour les informations contenues dans les journaux.

Les limites à garder en tête

L'analyse est heuristique. Un diff ne dit pas toujours l'intention, et l'automatisation peut faire des faux positifs ou rater un cas subtil. La règle annoncée pour les cas incertains est volontairement conservatrice : ambiguous reste bloqué jusqu'à une décision explicite. C'est cohérent pour empêcher l'affaiblissement des tests, mais ça implique qu'une personne devra examiner le changement et autoriser les exceptions légitimes.

Le projet indique aussi fonctionner avec une politique « fail-open ». Attention : dans le même temps, le comportement décrit pour les changements ambiguous reste bien un blocage, sauf dérogation. Ce sont deux sujets différents : la manière dont l'outil gère certaines défaillances, et la politique de décision appliquée à un diff incertain. Pour savoir exactement ce qui se passe en cas d'erreur d'exécution ou selon votre configuration, le plus sûr reste de lire la documentation et de tester dans votre environnement plutôt que de déduire une garantie générale depuis une phrase.