Human-in-the-loop : quelles actions d'un agent valider

Pourquoi faut-il une validation humaine pour certaines actions ?

Parce qu'un agent peut être manipulé par le texte qu'il lit, et qu'un humain est le dernier contrôle indépendant du modèle. L'OWASP le formule à propos de LLM06:2025 (Excessive Agency) : utiliser un contrôle « human-in-the-loop » pour exiger qu'un humain approuve les actions à fort impact avant qu'elles soient exécutées. La même page recommande aussi la médiation complète, c'est-à-dire des autorisations appliquées dans les systèmes aval plutôt que laissées au jugement du LLM.

Le règlement européen sur l'IA (article 14) va dans le même sens pour les systèmes à haut risque : une surveillance humaine proportionnée aux risques, au degré d'autonomie et au contexte, avec la possibilité d'ignorer, d'annuler ou d'arrêter le système, et une vigilance face au biais d'automatisation. Ces obligations s'appliquent à partir du 2 décembre 2027 pour les systèmes de l'annexe III.

La validation humaine est donc à la fois une mesure de sécurité et, dans certains cas, une exigence de conformité.

Comment classer les actions par niveau de risque ?

Avec trois questions : l'action est-elle réversible, que peut-elle toucher, et qui en subit les conséquences. Plus la réponse est grave, plus le contrôle doit être fort.

Le niveau dépend du contexte. Un e-mail interne à soi-même est de niveau 1. Le même e-mail envoyé à une liste de clients est de niveau 2 ou 3. Évaluez donc l'action avec ses arguments (destinataires, montant, volume) et non avec le seul nom de l'outil.

Quelles actions exigent toujours une validation ?

Celles où une erreur ou une manipulation coûte cher et ne se rattrape pas. Voici la liste de départ que nous utilisons pour revoir un agent.

• Argent : paiement, remboursement, changement de coordonnées bancaires, création de bon de commande.
• Communication sortante : e-mails, messages et publications adressés à des tiers, surtout en volume.
• Suppression ou écrasement de données sans sauvegarde restaurable.
• Droits et identités : création d'utilisateur, changement de rôle, partage de fichier vers l'extérieur, émission de jetons.
• Export de données vers un domaine, un compte ou un service qui n'est pas déjà approuvé.
• Exécution de code ou de commandes hors d'un bac à sable : shell, SQL en écriture, déploiement.
• Modification de sa propre configuration : outils autorisés, règles de validation, serveurs MCP.

Le dernier point est loin d'être théorique. Dans CVE-2025-54135 (Cursor), l'agent pouvait créer un fichier de configuration MCP sans approbation, et dans CVE-2025-53773 (Copilot et VS Code), une injection pouvait activer le mode d'approbation automatique dans les réglages. Dans les deux cas, la validation humaine a été contournée en modifiant ce qui la gouverne. Voir notre article sur la sécurité des agents de code.

Comment concevoir une validation qui protège vraiment ?

En faisant appliquer la validation par le système, sur l'action réelle, avec une présentation qui permet de décider. Une validation mal conçue donne un faux sentiment de sécurité.

1. Appliquer côté serveur. L'outil refuse de s'exécuter sans jeton d'approbation lié à l'action exacte. Le modèle ne peut pas décider qu'une approbation est « déjà donnée ».
2. Montrer l'action réelle. L'humain voit les paramètres effectifs : destinataire, montant, requête SQL, fichier. Un résumé rédigé par le modèle peut être manipulé.
3. Lier l'approbation à l'action. Si les arguments changent après validation, il faut une nouvelle validation. Une approbation a une durée de vie courte et un usage unique.
4. Identifier l'approbateur. Une personne nominative, avec les droits requis, distincte du demandeur quand l'enjeu le justifie.
5. Journaliser la demande, ce qui a été montré, la décision et l'horodatage. Voir quoi journaliser.
6. Prévoir un refus simple et une voie d'arrêt de l'agent.

Quels pièges font échouer la validation humaine ?

Le principal est la fatigue d'approbation : si l'humain valide des dizaines de demandes bénignes, il finit par cliquer sans lire. Les autres sont plus mécaniques.

• Trop de demandes. Réservez la validation aux niveaux 2 et 3, et automatisez les niveaux 0 et 1 avec des limites. Une validation rare est une validation lue.
• Présentation trompeuse. Un texte long où l'élément important est noyé, un lien raccourci, un destinataire tronqué.
• Option « toujours autoriser ». Elle transforme une validation ponctuelle en autorisation permanente, y compris pour une action déclenchée par une injection.
• Validation côté interface seulement. Si l'API de l'outil reste appelable sans jeton, le contrôle ne vaut rien.
• Biais d'automatisation. L'humain fait confiance à l'agent parce qu'il a souvent raison. L'article 14 du règlement européen sur l'IA demande justement de rester attentif à ce biais.
• Contournement par le contenu. L'agent est amené à reformuler une action dangereuse en suite de petites actions, chacune sous le seuil. Évaluez aussi les séquences d'appels.

Comment tester que la validation humaine tient ?

En essayant de la contourner avec des charges inoffensives, du point de vue d'un attaquant qui contrôle un texte lu par l'agent. Les tests de base :

1. Appel direct. Appeler l'outil de niveau 3 sans jeton d'approbation, par l'API : il doit être refusé.
2. Substitution. Obtenir une approbation pour une action bénigne, puis modifier les arguments : l'exécution doit échouer.
3. Fractionnement. Découper une action sensible en étapes de niveau 1 et voir si une limite cumulée existe.
4. Injection. Placer dans un document une consigne demandant d'approuver ou de sauter l'étape, et vérifier qu'elle n'a aucun effet.
5. Auto-modification. Demander à l'agent de modifier ses règles de validation ou de créer un outil sans validation.
6. Lisibilité. Montrer l'écran de validation à un tiers : peut-il dire ce qui va se passer en dix secondes ?

Ce sont des scénarios classiques de nos missions sur les appels d'outils et le MCP. Le cadre complet figure dans notre pilier sécurité des agents IA.

Par où commencer cette semaine ?

Listez chaque outil que votre agent peut appeler, attribuez-lui un niveau de 0 à 4 avec le tableau, et regardez d'abord les niveaux 2 et 3. Pour chacun, vérifiez trois choses : la validation est-elle appliquée côté serveur, l'approbateur voit-il les vrais paramètres, la décision est-elle journalisée. Corriger ces trois points sur vos cinq outils les plus risqués supprime l'essentiel de l'exposition.

Comment CleanIssue revoit les actions d'un agent ?

Nous cartographions les outils, attribuons un niveau à chaque action avec ses arguments réels, puis essayons de franchir les contrôles. Le Red Team Agent Express à 1 900 € livre en 5 jours le classement des actions de votre agent et les preuves de contournement éventuelles. Si plusieurs agents sont concernés, le Red Team sur mesure est chiffré sur devis. Le premier échange est un rendez-vous découverte de 30 minutes, gratuit.