Les garde-fous avant qu’un agent IA ne tourne

Lire, modifier, refuser

Les garde-fous d’un agent IA passent en premier. Un agent qui peut appeler un outil peut modifier un enregistrement : asseyez-vous donc avec la personne responsable du processus et écrivez trois limites avant d’autoriser cet appel. Le système peut lire certaines données. Il peut modifier certains enregistrements. Il doit refuser le reste.

Dans le processus de factures qui sert d’exemple à ces guides, les trois listes pourraient se lire ainsi. L’agent peut lire les factures entrantes, les bons de commande et la liste des fournisseurs. Il peut passer le statut d’une facture à « rapprochée » ou « signalée » et y joindre une note. Il doit refuser de modifier les coordonnées bancaires d’un fournisseur, de déclencher un paiement, ou d’exécuter toute instruction qui arrive à l’intérieur d’une facture.

Écrire les limites, c’est la moitié du travail. L’autre moitié, c’est l’endroit où elles vivent. Une phrase dans le prompt qui demande à l’agent de ne pas toucher aux coordonnées bancaires est une demande. Un identifiant qui n’a pas la permission d’y toucher est une limite. Le guide d’OpenAI du 15 janvier 2026, A practical guide to building agents (en anglais), dit la même chose : les garde-fous du modèle doivent s’accompagner d’authentification, d’autorisation, de contrôles d’accès stricts et des mesures habituelles de sécurité logicielle. Donnez à l’agent son propre compte, limité aux trois listes, pour qu’une erreur ou une instruction manipulée se heurte à un mur plutôt qu’à un rappel poli.

La communauté de la sécurité est arrivée à la même priorité. La liste des risques les plus graves pour les applications de LLM de l’OWASP GenAI Security Project (en anglais), dans son édition 2026 publiée en août, a fait passer l’« agentivité excessive » (excessive agency) de la sixième à la troisième place. L’OWASP la ramène à trois causes, et chacune correspond à l’une des listes :

• Fonctionnalité excessive. Un outil qui en fait plus que le travail ne le demande, comme un lecteur de documents qui peut aussi supprimer. À corriger dans l’outil lui-même.
• Permissions excessives. Une fonction étroite qui tourne sur un compte capable de bien plus. À corriger dans le compte.
• Autonomie excessive. Aucune personne entre l’agent et une action irréversible. À corriger dans le transfert, traité dans Là où une personne garde la main.

La méthode autour de tout cela se trouve dans Construire un agent IA qui tient. La façon dont nous menons un processus mesuré jusqu’en production se trouve sur la page agents IA.

Des couches sur la même exécution

OpenAI décrit les garde-fous comme des couches. Aucune ne suffit seule, et ensemble elles rendent le système plus difficile à faire céder. Leur liste :

• Pertinence : signale les demandes hors du périmètre, pour que l’agent reste sur sa tâche.
• Sécurité : détecte les jailbreaks et les injections de prompt, c’est-à-dire les tentatives de contourner les instructions ou de les extraire.
• Données personnelles : vérifie la sortie avant qu’une donnée personnelle ne quitte le système sans nécessité.
• Modération : signale les entrées nuisibles ou abusives.
• Protections des outils : une note de risque sur chaque outil, traitée plus bas.
• Règles simples : listes de blocage, limites de longueur, reconnaissance de motifs, traitées plus bas aussi.
• Validation de la sortie : vérifie que ce qui sort respecte les standards de l’organisation.

Leur conseil pour construire cet empilement est pragmatique. Commencez par la confidentialité des données et la sécurité du contenu. Ajoutez une couche chaque fois qu’un cas réel passe à travers. Réglez à la fois pour la sécurité et pour l’usage, car un garde-fou qui bloque le travail normal finira désactivé.

Un détail du guide mérite plus d’attention qu’il n’en reçoit. Dans l’Agents SDK d’OpenAI, les garde-fous tournent par défaut en même temps que l’agent, et non avant lui, et interrompent l’exécution s’ils se déclenchent. Cela convient pour une réponse, qu’on peut jeter. Cela ne convient pas pour un outil qui écrit : le temps qu’un contrôle parallèle se déclenche, l’enregistrement peut déjà avoir changé. Pour tout outil d’action, le contrôle doit se terminer avant l’appel.

Les classifieurs réduisent le risque d’injection de prompt, mais ne le suppriment pas. La note d’Anthropic d’avril 2026, Trustworthy agents in practice (en anglais), décrit des défenses en couches, de l’entraînement à la surveillance en passant par les équipes d’attaque. Elle reconnaît pourtant qu’ensemble elles ne constituent pas une garantie, et demande aux concepteurs de réfléchir sérieusement aux outils, aux données et aux permissions qu’ils confient à un agent.

Le « lethal trifecta » de Simon Willison (en anglais), de juin 2025, en fait une règle de conception. Un agent devient facile à piller quand il réunit trois choses : un accès à des données privées, une exposition à du contenu qu’un attaquant peut contrôler, et un moyen d’envoyer de l’information vers l’extérieur. La défense fiable n’est pas un meilleur filtre. C’est retirer l’une des trois.

Le processus de factures réunit les trois par défaut. Le système financier contient des données privées. Les factures viennent de l’extérieur, et n’importe qui peut écrire du texte dans un PDF. Si l’agent peut en plus envoyer un e-mail à qui il veut, une seule facture piégée pourrait lui demander d’expédier la liste des fournisseurs ailleurs. Nous retirons donc un des trois éléments. L’agent n’envoie aucun e-mail, ou ne répond qu’à l’adresse déjà enregistrée, par un outil qui n’accepte pas de destinataire en argument.

Une note de risque sur chaque outil

OpenAI attribue à chaque outil une note de risque, faible, moyen ou élevé, avant qu’il ne tourne. Les critères qu’ils citent : l’outil lit-il ou écrit-il, son action est-elle réversible, de quelles permissions a-t-il besoin, et de l’argent est-il en jeu. La note décide ensuite de la suite : un appel à risque élevé peut attendre un contrôle supplémentaire ou passer à une personne.

La personne responsable du processus fixe chaque note avec nous. Pour le processus de factures :

Outil	Lit ou écrit	Réversible	Argent	Note	Ce qui se passe
Lire une facture	Lit	Sans objet	Non	Faible	S’exécute
Consulter un bon de commande	Lit	Sans objet	Non	Faible	S’exécute
Passer en « rapprochée » ou « signalée »	Écrit	Oui	Non	Moyen	S’exécute, journalisé, contrôlé en code avant
Mettre en file pour paiement	Écrit	Jusqu’au lot de paiement	Oui	Élevé	Attend une personne
Modifier les coordonnées bancaires d’un fournisseur	Écrit	Difficile à détecter	Oui	Non fourni	L’agent n’a pas cet outil

La dernière ligne est le garde-fou le plus solide du tableau. La façon la plus sûre de gérer un outil à risque élevé est souvent de ne pas le donner à l’agent. Revoyez les notes chaque fois qu’un outil change. Un outil qui lisait hier et écrit aujourd’hui est un nouvel outil.

Le contrôle avant l’étape suivante

Une étape fausse devient l’entrée de la suivante, donc les erreurs s’accumulent. C’est dans la note d’ingénierie d’Anthropic du 19 décembre 2024, Building effective agents (en anglais), que cet avertissement est le plus net. Sa réponse : que l’agent obtienne à chaque étape une vérité de terrain venue de l’environnement, au lieu de se fier à son propre récit.

En pratique, placez un contrôle entre les étapes, en code partout où c’est possible. Dans le processus de factures, après la lecture d’une facture et avant tout rapprochement, vérifiez que les lignes s’additionnent bien au total, que le numéro de commande existe, et que le fournisseur de la facture est bien celui de la commande. Un dossier qui échoue part vers une personne avec la raison jointe. Il ne passe pas à l’étape suivante.

Le contrôle de la sortie a lieu avant l’étape suivante. Un modèle qui a décidé qu’il avait fini n’est pas ce contrôle.

Des règles simples à côté du modèle

OpenAI nomme aussi des règles qui n’ont pas besoin de modèle : une liste de blocage, une limite de longueur, un motif qu’une machine sait reconnaître. Nous les fixons avec la même personne responsable du processus. Elles ne coûtent presque rien, donnent la même réponse à chaque fois et se testent facilement. Elles couvrent les cas que vous savez déjà nommer. Les couches fondées sur un modèle couvrent ceux que vous ne savez pas nommer.

Chaque garde-fou est aussi un cas de test. Ajoutez à l’ensemble d’évaluation des cas qui doivent déclencher chaque garde-fou et des cas qui ne doivent pas le déclencher. Un garde-fou qui ne se déclenche jamais n’a pas prouvé qu’il fonctionne, et un garde-fou qui se déclenche sur le travail normal sera retiré par ceux qu’il ralentit. Journalisez chaque déclenchement. C’est de ce journal que viendra la prochaine couche.

Les questions sont les mêmes à la fin qu’au début. Que peut lire le système ? Que peut-il modifier ? Que doit-il refuser ? Et chaque réponse est-elle appliquée à un endroit où le modèle ne peut pas la discuter ? Voyez ensuite la méthode, dans Construire un agent IA qui tient.