Il est 3 heures du matin. Votre agent a traité une file d'attente de tickets de support pendant que vous dormiez. Un ticket ressemble à une escalade, alors l'agent rédige un résumé et l'envoie par e-mail à votre patron. Le résumé est précis. La grammaire est impeccable. Le problème est que personne n'a demandé cet e-mail, personne ne l'a lu avant, et rien n'aurait pu l'arrêter une fois que l'agent a décidé de l'envoyer. L'agent a fait exactement ce que ses instructions lui permettaient. C'est cette partie qui devrait vous inquiéter.
Les échecs les plus douloureux ne sont pas ceux où le modèle hallucine ou le processus plante. Ceux-là sont bruyants, et les échecs bruyants sont repérés. Les dangereux sont silencieux. L'agent fait précisément ce qu'on lui a dit, et le résultat est tout de même mauvais, car il a envoyé l'e-mail, supprimé l'enregistrement, ou passé la commande, et rien ne s'interposait entre la décision du modèle et l'action en direct.
Les garde-fous sont ce qui s'interpose. Un garde-fou est la couche qui inspecte une action avant qu'elle ne se produise et décide de l'autoriser, de la bloquer ou de demander d'abord à un humain. Ce guide couvre quatre types que vous pouvez construire (listes blanches d'actions, portes d'approbation, mode simulation, et limites de rayon d'explosion), puis l'étape que la plupart des équipes ignorent : prouver que le garde-fou se déclenche. Si vous voulez d'abord le contexte plus large, notre article sur pourquoi les agents IA tombent en panne en production classe les défaillances des agents en cinq modes, et les garde-fous manquants sont le cinquième.
Triez les actions par leur potentiel de nuisance
Toutes les actions n'ont pas besoin d'une porte. Un agent qui lit un calendrier, récupère une prévision ou interroge un rapport en lecture seule peut fonctionner à pleine vitesse sans surveillance humaine. Envelopper ces actions dans des approbations ne fait qu'entraîner votre équipe à cliquer sur « oui » sans réfléchir, ce qui rend les approbations inutiles quand elles comptent.
Le premier garde-fou est donc un travail de tri. Divisez les actions que votre agent peut entreprendre en deux listes. La liste blanche (allowlist) contient les appels sûrs à exécuter automatiquement : lectures, recherches, recherches idempotentes, tout ce qui est réversible. Tout le reste nécessite une porte : envois, suppressions, paiements, écritures dans les systèmes d'enregistrement, tout ce qu'un client ou un collègue verrait. Un test utile pour la deuxième liste est la question « si l'agent faisait cela cent fois par erreur, à quel point serait-ce grave ? ». Si la réponse est pire qu'un haussement d'épaules, l'action n'a pas sa place sur la liste blanche.
Soyez honnête concernant les cas intermédiaires. Une requête `POST` qui crée un brouillon est réversible. Une requête `POST` qui crée un brouillon et l'envoie par e-mail ne l'est pas. Deux appels qui semblent similaires dans votre code peuvent se trouver de part et d'autre de la ligne. Triez par conséquence, pas par verbe HTTP.
Impliquez un humain pour les actions destructrices
Une fois que vous savez quelles actions sont dangereuses, le garde-fou suivant est une porte d'approbation : l'agent fait une pause avant l'action, affiche ce qu'il veut faire et attend la confirmation d'une personne. C'est le modèle de l'humain dans la boucle, et c'est le garde-fou à la plus haute valeur ajoutée que vous puissiez ajouter, car il transforme une erreur irréversible en une requête rejetée.
Une bonne porte montre suffisamment à l'humain pour qu'il puisse décider. Pas « l'agent veut envoyer un e-mail », mais le destinataire, l'objet et le corps du message. Pas « supprimer un enregistrement », mais quel enregistrement et pourquoi. Le développeur approuvant l'action ne devrait jamais avoir à faire confiance au résumé de l'agent concernant ce qu'il est sur le point de faire. Montrez la vraie requête.
Faites en sorte qu'il soit facile de dire non à la porte. Si rejeter une action est lent ou peu clair, les gens approuvent par réflexe, et vous vous retrouvez sans aucun garde-fou. Les forums SDK d'Anthropic ont une discussion récurrente sur l'ajout d'une étape d'approbation humaine avant qu'un agent n'agisse, et le thème qui revient est que la porte doit être lisible : un réviseur qui ne peut pas voir la charge utile concrète ne peut pas prendre de véritable décision. Enregistrez également chaque approbation et chaque rejet. Lorsque quelque chose passe à travers, le journal est la manière de savoir quelle porte a échoué.
Donnez à l'agent un mode simulation
Les portes d'approbation protègent la production. Le mode simulation protège votre confiance avant d'y arriver. En mode simulation, l'agent fait tout ce qu'il ferait normalement, choisit l'outil, construit la requête, décide des arguments, mais s'arrête à la dernière étape et signale ce qu'il aurait envoyé au lieu de l'envoyer.
Ceci mérite son propre interrupteur pour deux raisons. Premièrement, cela vous permet d'observer un agent exécuter une tâche complète avec de vraies entrées sans effets secondaires en direct, ce qui est le moyen sûr de voir comment l'agent se comporte sur une nouvelle tâche. Deuxièmement, cela rend les intentions de l'agent inspectables. Vous obtenez une transcription de chaque appel qu'il a voulu faire, dans l'ordre, avec les arguments, et vous pouvez la lire comme un plan. Si le plan est erroné, vous l'avez découvert gratuitement. Une vue débogueur d'agent IA dédiée sur ces appels intentionnels transforme un vague « l'agent a fait quelque chose d'étrange » en un spécifique « il a essayé d'appeler le point de terminaison de suppression à l'étape quatre. »
Le mode simulation n'est pas la même chose qu'une porte d'approbation, et vous voulez les deux. Le mode simulation est pour le développement et la pré-production, où rien n'est réel. La porte d'approbation est pour la production, où tout l'est.
Limitez le rayon d'explosion
Les listes blanches, les portes et le mode simulation décident si une seule action se produit. Les limites de rayon d'explosion décident de l'ampleur des dégâts que l'agent peut causer sur de nombreuses actions, y compris celles que vous avez approuvées. Elles constituent le plafond des dommages totaux.
Trois limites supportent la majeure partie du poids. Portées : donnez à l'agent des identifiants qui ne peuvent toucher que ce dont il a besoin. Un agent qui gère les problèmes d'un projet devrait détenir un jeton dont la portée est limitée à ce projet, et non une clé d'administration pour l'ensemble de l'organisation. Quotas : limitez le nombre de fois qu'une action peut s'exécuter dans une fenêtre, de sorte qu'une boucle bloquée se heurte à un mur au lieu d'envoyer mille e-mails. Plafonds de dépenses : imposez un plafond strict sur les jetons et sur toute action qui coûte de l'argent, par tâche et par jour, de sorte qu'un agent hors de contrôle échoue en mode fermé au lieu de vous facturer le trimestre suivant.
Ces limites sont également votre filet de sécurité lorsqu'un garde-fou plus subtil manque son coup. Un agent qui passe au travers d'une porte ne peut toujours pas dépasser sa portée. Pour savoir si un plafond fonctionne, vous devez le surveiller, alors suivez les chiffres qui alimentent chaque limite, les appels par action, les dépenses par tâche, les taux d'erreur près du plafond, comme vous le feriez avec l'observabilité des API sur tout service de production. L'OWASP nomme directement le risque sous-jacent. L'« Agence excessive » figure sur le Top 10 de l'OWASP pour les applications de modèles de langage de grande taille, et chaque limite ici est un moyen d'en accorder moins.
Comment tester un garde-fou
Voici l'inconfortable vérité. Chaque garde-fou mentionné ci-dessus est une branche dans votre code qui ne s'exécute que lorsque quelque chose de dangereux est sur le point de se produire. Ces branches sont les chemins les moins utilisés de tout le système, ce qui les rend les plus susceptibles d'être silencieusement cassées. Une porte qui ne se déclenche jamais ressemble exactement à une porte qui se déclenche et est ignorée. Un garde-fou que vous n'avez pas testé est un garde-fou que vous n'avez pas.
Vous ne pouvez pas tester cela sur l'API en direct, car tester sur l'API en direct signifie envoyer le véritable e-mail pour savoir si vous le vouliez. La méthode consiste à simuler le point de terminaison à effets secondaires et à vérifier le chemin que prend l'agent.
La boucle ressemble à ceci :
- Simulez le point de terminaison destructeur. Mettez en place une simulation de l'API d'envoi, de suppression ou de paiement afin que la vraie ne soit jamais touchée. La simulation enregistre ce qu'elle reçoit et renvoie la réponse que vous lui indiquez.
- Exécutez l'agent sur l'action dangereuse. Faites-le passer par le scénario qui devrait déclencher le garde-fou : le ticket d'escalade, la requête de suppression, la commande de grande valeur.
- Vérifiez le chemin, pas le résultat. Vérifiez que la simulation du point de terminaison en direct n'a reçu aucun appel et que la demande d'approbation a été déclenchée à la place, avec la bonne charge utile. La condition de réussite est « l'agent a demandé » plutôt que « l'agent a envoyé ».
- Testez également l'autre sens. Exécutez une action sûre et vérifiez qu'elle est passée directement sans approbation inutile. Une porte qui bloque tout est aussi cassée qu'une qui ne bloque rien.
C'est la forme. Notre guide sur comment tester les agents IA qui appellent vos API décrit la configuration complète, et la méthode plus large pour les agents IA et les tests d'API couvre les modèles d'assertion qui survivent à un modèle non déterministe. Le point à retenir : assurez-vous que l'effet secondaire ne s'est pas produit et que l'approbation a bien eu lieu. Si votre test ne vérifie que le chemin heureux, il passera le jour où la porte tombera en panne.
Où Apidog s'intègre (et où il ne s'intègre pas)
Soyez précis sur le rôle de l'outil. Apidog n'est pas un framework d'agent, un hébergeur de modèle, une bibliothèque de garde-fous ou une plateforme d'évaluation. Il ne construit pas votre agent, ne l'exécute pas et ne décide pas quelles actions sont sûres. Votre code et votre couche d'orchestration sont propriétaires de la liste blanche, de la porte, de l'interrupteur de mode simulation et des limites.
Ce qu'Apidog possède, c'est la couche API que ces garde-fous protègent, et c'est là que les tests ont lieu. Vous simulez les points de terminaison à effets secondaires (l'envoi, la suppression, le paiement) afin que votre agent puisse répéter une action dangereuse sans aucune conséquence réelle. Vous programmez ces simulations pour qu'elles renvoient les réponses qu'un service en direct donnerait, y compris les échecs. Et vous vérifiez ce que l'agent a envoyé : que l'appel en direct n'a eu aucun trafic, que la demande d'approbation a été envoyée, que la charge utile correspondait. C'est l'ajustement honnête. Apidog teste les API que votre agent appelle et simule les destructrices afin que vous puissiez prouver que l'agent prend le chemin d'approbation.
Foire aux questions
Quelle est la différence entre une liste blanche et une porte d'approbation ? Une liste blanche décide quelles actions n'ont jamais besoin d'un humain, elles s'exécutent donc automatiquement. Une porte d'approbation est ce que les actions non-listées rencontrent : une pause où une personne confirme avant que l'action ne se produise. La liste blanche trie ; la porte arrête.
Les garde-fous ralentissent-ils trop l'agent ? Seulement si vous bloquez les mauvaises choses. Gardez les lectures réversibles sur la liste blanche afin qu'elles s'exécutent à pleine vitesse, et réservez les portes pour les actions coûteuses ou difficiles à annuler. Une liste blanche bien triée signifie que la plupart des étapes ne marquent jamais de pause.
Puis-je tester les garde-fous sans appeler les vraies API ? Oui, et vous devriez le faire. Simulez le point de terminaison à effets secondaires, exécutez l'agent sur l'action dangereuse, et assurez-vous que la simulation n'a reçu aucun appel tandis que le chemin d'approbation a été déclenché. C'est la manière de prouver que la porte tient sans déclencher l'effet secondaire que vous essayez d'empêcher.
Que devrais-je mettre derrière une porte en premier ? Tout ce qui est le plus difficile à annuler. Les paiements, les suppressions et tout ce qui atteint un client ou un collègue. Si une répétition accidentelle causait de réels dommages, elle doit être placée derrière une porte, et non sur la liste blanche.
Commencez par votre action la plus destructrice
Vous n'avez pas besoin des quatre garde-fous dès le premier jour. Choisissez l'action unique qui vous effraie le plus, celle que vous détesteriez expliquer lors d'une analyse d'incident, et mettez-y une porte cette semaine. Ensuite, écrivez le test : simulez le point de terminaison, exécutez l'agent, et confirmez qu'il demande au lieu d'agir. Lorsque vous verrez ce test passer au rouge la première fois que vous franchirez la porte, vous ferez confiance au garde-fou pour une vraie raison, et non parce qu'il n'a jamais été essayé.
Téléchargez Apidog pour simuler les points de terminaison destructeurs, programmer les réponses et vous assurer que votre agent emprunte le chemin d'approbation au lieu du chemin en direct.