La surveillance des agents IA doit intervenir pendant l’exécution

Le 15 mai 2026, Parand A. Alamdari, Toryn Q. Klassen et Sheila A. McIlraith ont publié un article défendant l’idée que la gouvernance de l’IA a besoin d’audits hors ligne, d’une surveillance en ligne pendant l’exécution et de dispositifs capables d’intervenir avant qu’une violation prédite ne se produise.¹

Ce dernier mot est essentiel.

Une surveillance qui se contente d’enregistrer un échec sert au post-mortem. Une surveillance capable de mettre en pause, de bloquer, de contenir ou de réorienter l’agent modifie l’exécution tant que le résultat reste encore ouvert.

La surveillance des agents IA doit intervenir pendant l’exécution. Les journaux, traces, tableaux de bord et registres d’approbation donnent des preuves aux équipes. L’intervention pendant l’exécution transforme ces preuves en décision au moment où l’agent peut encore éviter la mauvaise action.

TL;DR

La surveillance des agents IA échoue lorsqu’elle fonctionne comme une analyse après coup. Un environnement d’exécution sérieux pour agents doit observer la trajectoire active, détecter les violations de règles et les erreurs décisives, puis choisir une intervention bornée : continuer, avertir, mettre en pause, bloquer, contenir, réparer ou faire remonter.

Les travaux récents convergent vers cette idée sous plusieurs angles. Les travaux issus des méthodes formelles appliquent la logique temporelle à la surveillance pendant l’exécution et aux moniteurs intervenants.¹ AgentForesight présente la détection d’échec comme un audit en ligne avant la fin d’une trajectoire.² AgentTrust intercepte les appels d’outils risqués avant leur exécution et renvoie des verdicts structurés.³ AIR intègre la réponse à incident dans la boucle de l’agent, afin que le système puisse détecter, contenir, réparer et synthétiser de futurs garde-fous.⁴

La leçon pratique : ne vous arrêtez pas à l’observabilité. Construisez la partie de l’environnement d’exécution qui peut agir sur ce qui est observé.

Points clés

Pour les équipes de plateformes d’agents : - Traitez la surveillance comme une boucle de contrôle, pas seulement comme un tableau de bord. - Définissez les actions d’intervention avant que l’agent n’accède aux outils à haut risque.

Pour les équipes sécurité : - Passez de la revue après coup à la détection en ligne aux points d’engagement. - Journalisez chaque intervention avec la règle, les preuves, la décision et le résultat.

Pour les équipes produit : - Présentez les événements d’intervention comme des objets de revue structurés. - Montrez à l’utilisateur pourquoi l’exécution s’est interrompue, quelles preuves ont déclenché la pause et quelles options sûres restent disponibles.

Pour les opérateurs : - Accordez davantage de confiance aux traces capables de changer le comportement qu’aux traces qui expliquent seulement les dégâts plus tard. - Demandez-vous si un moniteur peut arrêter la prochaine mauvaise étape, et pas seulement reconstruire la précédente.

Pourquoi la surveillance des agents IA échoue-t-elle trop tard ?

La plupart des dispositifs de surveillance commencent après que l’agent a déjà agi.

Un journal peut montrer que l’agent a exécuté une commande shell. Une trace peut montrer qu’il a récupéré une page web, appelé un serveur MCP, écrit un fichier ou demandé une approbation. Un tableau de bord peut indiquer qu’une règle réseau a bloqué un domaine. Ces enregistrements comptent, mais ils ne changent pas automatiquement l’action suivante.

L’article d’OpenAI sur la sécurité de Codex décrit le bon socle de preuves : exécution bornée, configuration gérée, règles réseau, approbations et télémétrie native pour agents. Codex peut exporter des événements OpenTelemetry pour les prompts utilisateur, les décisions d’approbation d’outils, les résultats d’exécution d’outils, l’usage de serveurs MCP et les événements d’autorisation ou de refus du proxy réseau.⁵ OpenAI décrit aussi l’utilisation des journaux Codex avec un agent de triage sécurité, afin que les relecteurs puissent inspecter la demande initiale, l’activité des outils, les approbations, les résultats d’outils et les décisions de règles réseau autour d’alertes suspectes sur des points de terminaison.⁵

Cette visibilité compte. Le manque apparaît lorsqu’elle n’a aucun actionneur.

Si un moniteur détecte qu’un agent a lu du contenu non fiable puis tente d’envoyer des données vers un nouveau domaine externe, le système ne doit pas seulement journaliser la séquence. Il doit mettre l’exécution en pause ou bloquer la requête. Si un agent de code réessaie trois fois une migration en échec puis propose une commande destructrice plus large, l’environnement d’exécution ne doit pas attendre la revue finale. Il doit interrompre la trajectoire.

La surveillance des agents IA doit répondre à deux questions à la fois :

La deuxième question transforme la surveillance en intervention.

Qu’apportent les nouveaux articles sur l’exécution ?

Ce nouveau groupe de recherches donne au domaine un vocabulaire plus précis.

L’article sur les méthodes formelles porte sur les contraintes comportementales étendues dans le temps : des règles qui tiennent compte de l’ordre, de la distance et de la séquence, et pas seulement d’événements isolés. Les auteurs combinent méthodes formelles et apprentissage automatique pour l’audit hors ligne et la surveillance en ligne de systèmes d’IA boîte noire, notamment des LLM.¹ Ils introduisent aussi des moniteurs prédictifs et intervenants capables de prévenir ou d’atténuer des violations prédites pendant l’exécution.¹

AgentForesight nomme le mode de défaillance en termes d’agents. L’article explique que les systèmes multi-agents à horizon long peuvent accepter une erreur décisive, puis dériver vers un échec à l’échelle de toute la trajectoire.² Au lieu de diagnostiquer l’étape responsable une fois la trajectoire terminée, AgentForesight demande à un auditeur en ligne d’inspecter uniquement le préfixe courant et de continuer ou de déclencher une alarme dès la première erreur décisive.²

AgentTrust travaille à la frontière des appels d’outils. Il intercepte les appels d’outils de l’agent avant leur exécution et renvoie un verdict structuré : autoriser, avertir, bloquer ou demander une revue.³ Cette forme compte, car les opérations sur fichiers, les commandes shell, les requêtes HTTP et les requêtes de base de données produisent des effets réels.³

AIR ajoute la couche de réponse à incident. L’article soutient que les travaux sur la sécurité des agents se concentrent souvent sur la prévention en amont des échecs, tout en laissant peu de capacité pour répondre, contenir ou réparer lorsque des incidents surviennent.⁴ AIR intègre la réponse à incident dans la boucle d’exécution de l’agent : détecter les incidents, guider les actions de confinement et de réparation, puis synthétiser des règles de garde-fous pour les exécutions futures.⁴

Pris ensemble, ces articles déplacent le centre de gravité :

Ce déplacement correspond au travail réel des agents. Les effets de bord se produisent pendant l’exécution, pas au moment de la réponse finale.

Qu’est-ce qu’une intervention pendant l’exécution ?

Une intervention pendant l’exécution est une action bornée que le système prend parce que des preuves en direct ont franchi un seuil de règle, de sécurité, de qualité ou de risque.

L’intervention doit être plus étroite que la panique et plus forte que la journalisation.

Une bonne intervention ne sermonne pas le modèle. Elle change l’état de l’environnement d’exécution.

Une intervention doit produire un enregistrement structuré :

Le moniteur gagne la confiance lorsqu’un autre relecteur peut inspecter l’événement et comprendre pourquoi l’environnement d’exécution a changé de trajectoire.

Pourquoi les contraintes temporelles comptent-elles ?

Beaucoup d’échecs d’agents dépendent de l’ordre.

« Ne pas publier sans tests » n’est pas une propriété d’une seule commande. C’est une relation entre une action de publication et des preuves antérieures. « Ne pas envoyer de trafic réseau externe après avoir lu du contenu non fiable » dépend d’une séquence. « Ne pas écrire en production après une migration échouée » dépend de l’état d’échec précédent. « Ne pas approuver un déploiement après un échec de vérification des sources » dépend à la fois de l’événement d’approbation et de l’événement de vérification.

La Linear Temporal Logic donne aux chercheurs un moyen d’exprimer des contraintes dans le temps : avant, après, jusqu’à, éventuellement et jamais. L’article du 15 mai sur les méthodes formelles indique que les techniques d’audit et de surveillance fondées sur la LTL ont surpassé les méthodes de référence LLM pour détecter les violations de contraintes comportementales étendues dans le temps.¹ Les auteurs rapportent aussi que même des étiqueteurs fondés sur de petits modèles ont égalé ou dépassé des juges LLM de pointe avec leur approche, et que le raisonnement temporel des LLM se dégradait lorsque la distance entre événements, le nombre de contraintes et le nombre de propositions augmentaient.¹

La leçon pour la production n’oblige pas chaque équipe à livrer demain une pile complète de méthodes formelles.

La leçon immédiate est plus simple : écrivez des règles qui comprennent les séquences.

Ces contraintes demandent à l’environnement d’exécution de garder assez d’historique pour juger l’étape suivante. Un prompt sans état ne peut pas le faire de manière fiable.

Où placer la surveillance pendant l’exécution ?

La surveillance pendant l’exécution doit se trouver aux points d’engagement.

Un point d’engagement est tout moment où l’agent passe d’une analyse réversible à un effet externe : modification de fichier, écriture en base de données, sortie réseau, déploiement, envoi de message, changement d’autorisation, paiement, suppression ou publication publique.

La documentation cloud de Codex d’OpenAI donne une frontière concrète. Codex bloque par défaut l’accès à internet pendant la phase agent, tandis que les scripts de configuration peuvent encore utiliser internet pour les dépendances.⁶ Cette même documentation avertit que l’activation de l’accès internet pour l’agent augmente les risques, notamment l’injection de prompt depuis du contenu web non fiable, l’exfiltration de code ou de secrets, les logiciels malveillants ou dépendances vulnérables, et les contenus soumis à licence restrictive.⁶ Elle recommande aussi des limites par domaine et par méthode HTTP, avec une protection supplémentaire lorsque les requêtes sont restreintes à GET, HEAD et OPTIONS.⁶

Cette forme de règle doit s’étendre au-delà de l’accès réseau.

Surveiller chaque jeton gaspille l’attention. Surveiller les points d’engagement protège les parties de l’exécution où les erreurs sortent de la transcription.

Comment l’agent doit-il vivre l’intervention ?

L’agent doit recevoir une mise à jour d’état précise, pas un reproche vague.

Réponse faible :

Soyez prudent. Cela peut être dangereux.

Meilleure réponse :

Bloqué : POST externe après lecture de contenu non fiable. Actions suivantes autorisées : résumer le risque, demander l’approbation de l’opérateur avec le domaine cible et la classe de charge utile, ou continuer sans sortie réseau.

La seconde réponse donne à l’agent un espace de planification sûr. Elle dit ce qui s’est déclenché, pourquoi l’action ne peut pas s’exécuter et quelles alternatives restent disponibles. La forme des verdicts d’AgentTrust va dans ce sens : autoriser, avertir, bloquer ou demander une revue, avec des alternatives plus sûres pour les commandes risquées.³

L’intervention pendant l’exécution doit préserver l’autonomie sans préserver le danger.

L’agent peut encore réparer la tâche. Il peut demander une approbation. Il peut changer d’outils. Il peut diviser le travail en une passe en lecture seule. Il peut produire un dossier de preuves. L’environnement d’exécution retire seulement les actions qui violent l’état courant des règles.

Que doit voir l’humain ?

L’humain doit voir une carte d’intervention, pas une pause mystérieuse.

Cette carte appartient à la même famille produit que les files d’approbation, les chronologies de traces et les dossiers de revue. La différence tient au moment où elle intervient. L’approbation demande si une action planifiée peut continuer. L’intervention pendant l’exécution dit que le moniteur a observé un motif en direct qui a changé la prochaine étape autorisée.

Une bonne interface ne doit pas obliger l’utilisateur à lire toute la transcription pour comprendre la pause. La carte doit pointer vers le segment de trace pertinent.

Que doivent construire les équipes en premier ?

Commencez par des règles de surveillance simples aux points d’engagement à forte valeur.

1. Définissez les points d’engagement. Nommez les appels d’outils et les ressources où les erreurs quittent la session locale.
2. Créez un flux d’événements typés. Enregistrez l’outil, les arguments, la cible, le résultat, les événements antérieurs pertinents et l’état de l’exécution.
3. Écrivez des règles sensibles aux séquences. Commencez par les relations d’ordre qui comptent souvent : test avant déploiement, revue avant sortie réseau, approbation avant écriture.
4. Ajoutez des interventions étroites. Préférez la pause, le blocage ou le confinement à l’arrêt général.
5. Renvoyez des verdicts structurés. Dites à l’agent ce qui s’est déclenché et quelles actions restent autorisées.
6. Affichez des cartes d’intervention. Donnez aux humains la règle, les preuves, le risque et les options suivantes.
7. Passez les résultats en revue. Promouvez les vrais positifs, ajustez les faux positifs et retirez les règles bruyantes.

La première version peut rester sobre. Quelques règles déterministes à la frontière des outils valent souvent mieux qu’un juge général fondé sur un modèle observant chaque phrase.

La version plus approfondie peut ajouter de la surveillance prédictive, des contraintes LTL, des auditeurs appris et des boucles de réponse à incident. Construisez ces couches après avoir stabilisé le flux d’événements et la sémantique des interventions.

Le niveau d’exigence digne de ce nom

L’intervention pendant l’exécution peut devenir du théâtre si chaque pause paraît grave et si chaque avertissement a le même poids.

Le niveau d’exigence doit rester étroit :

• Intervenir seulement lorsque la prochaine action peut compter.
• Nommer la règle déclenchée.
• Montrer les preuves.
• Préserver un chemin suivant sûr.
• Enregistrer le résultat.
• Retirer les règles qui créent du bruit sans prévenir de dommage.

Une bonne surveillance protège le travail. Une mauvaise surveillance ne protège que le récit de responsabilité du fournisseur.

L’environnement d’exécution de l’agent ne doit pas maximiser le mouvement. Il doit maximiser le progrès responsable. Parfois, ce progrès responsable consiste à laisser l’agent continuer sans interruption. Parfois, il consiste à refuser l’étape suivante.

Le niveau de qualité se joue dans la capacité à distinguer les deux.

Résumé rapide

La surveillance des agents IA doit intervenir pendant l’exécution parce que les échecs d’agents surviennent à l’intérieur des trajectoires, pas seulement à la fin. Les journaux et les traces expliquent ce qui s’est passé. Les moniteurs intervenants peuvent changer ce qui se passe ensuite.

La direction actuelle de la recherche est claire : contraintes temporelles formelles, auditeurs en ligne, verdicts sur les appels d’outils et boucles de réponse à incident poussent tous la surveillance vers un contrôle actif. Les équipes doivent commencer par des flux d’événements typés, des règles aux points d’engagement, des verdicts structurés, des cartes d’intervention et une revue des résultats. L’objectif n’est pas d’avoir plus d’alertes. L’objectif est de réduire les erreurs irréversibles.

FAQ

Qu’est-ce que l’intervention pendant l’exécution pour les agents IA ?

L’intervention pendant l’exécution signifie que le système modifie une exécution active d’agent parce que des preuves en direct ont franchi un seuil de règle, de risque, de sécurité ou de qualité. L’intervention peut continuer, avertir, mettre en pause, bloquer, contenir, réparer ou faire remonter l’exécution.

En quoi l’intervention pendant l’exécution diffère-t-elle de l’observabilité ?

L’observabilité enregistre ce qui s’est passé. L’intervention pendant l’exécution agit pendant que l’exécution reste active. Une trace peut servir aux deux, mais l’intervention exige une décision de règle et une prochaine action autorisée.

Chaque action d’agent doit-elle passer par un moniteur ?

Chaque action d’outil significative doit produire un événement typé. Seuls les points d’engagement à forte valeur ont besoin de règles interruptives. Les événements en lecture seule peuvent généralement être journalisés discrètement. Les événements à effets de bord méritent une surveillance plus stricte.

Les équipes ont-elles besoin des méthodes formelles pour commencer ?

Non. Les équipes peuvent commencer par des règles de séquence déterministes : pas de déploiement avant les tests, pas d’écriture externe après récupération non fiable, pas de commande destructrice après des échecs répétés de réparation, et pas de clôture finale sans preuves requises. Les méthodes formelles deviennent utiles lorsque l’ensemble de règles grandit et que les relations temporelles deviennent difficiles à inspecter à la main.

Qu’est-ce qui rend une intervention pendant l’exécution fiable ?

Une intervention fiable nomme la règle, montre les preuves, limite la prochaine action, enregistre le résultat et donne à un humain autorisé un parcours de revue. Un avertissement vague ne suffit pas.

Références