Garde-fous IA : ce qu'un agent n'a pas le droit de faire, écrit avant de le brancher

Un garde-fou IA est une règle écrite et appliquée hors de l'agent, qui l'empêche de faire une action interdite ou l'oblige à demander une validation avant une action risquée. Il porte sur les accès, sur les actions et sur la preuve que le travail est fait. La liste commence par ce que l'agent n'a pas le droit de faire.

L'essentiel à retenir :

• Une consigne dans le prompt n'est pas un garde-fou. Un garde-fou tient même quand l'agent se trompe.
• Avant de brancher un agent, écris ce qu'il n'a pas le droit de faire : envoyer, publier, payer, supprimer, changer un accès.
• Donne-lui les seuls accès dont sa tâche a besoin, et garde une validation humaine sur tout ce qui ne se défait pas.
• Vérifie le résultat, pas le message « fait » de l'agent.
• Après un incident, coupe l'accès, lis le journal, écris la règle qui manquait.

Ce guide présente ce qu'est un garde-fou, des incidents réels racontés par leurs auteurs, la liste des interdits à écrire, le moindre privilège, la validation humaine, la vérification, la protection contre les contenus piégés et la conduite à tenir après un incident. Les niveaux d'autonomie d'un agent sont détaillés dans agent IA autonome : ce qui tourne sans toi, et ce qui attend ton GO.

Qu'est-ce qu'un garde-fou IA, et pourquoi une consigne ne suffit pas ?

Un garde-fou IA est une limite que l'agent ne peut pas franchir, même s'il se trompe ou s'il est trompé, alors qu'une consigne est une demande qu'il peut mal comprendre ou oublier.

La différence se voit dans un cas simple. Tu écris dans les instructions : « ne supprime jamais de fichier ». C'est une consigne. Si l'agent n'a aucun droit de suppression sur le dossier, c'est un garde-fou. Dans le premier cas, tu comptes sur le modèle. Dans le second, tu comptes sur l'outil.

Un consultant IT le résume dans un témoignage publié sur X le 9 octobre 2026 (@Laurent_IA) : « Les consignes ne suffisent pas. Une IA ne doit jamais être son propre garde-fou. »

OpenAI dit la même chose dans son guide « A practical guide to building agents » (page datée du 15 janvier 2026). Les garde-fous y sont présentés comme essentiels, mais à coupler avec une authentification et des autorisations robustes, des contrôles d'accès stricts et les mesures de sécurité logicielle habituelles. Le guide les décrit comme une défense en couches : un seul garde-fou ne suffit pas, plusieurs ensemble rendent l'agent plus solide.

Un garde-fou complet couvre donc trois choses :

• les accès : ce que l'agent peut toucher ;
• les actions : ce qu'il peut faire seul, et ce qui attend une validation ;
• la preuve : comment tu sais que le travail est vraiment fait.

Que s'est-il passé quand des agents n'avaient pas de garde-fou ? ★

Quand des agents n'avaient pas de garde-fou, ils ont supprimé ce qu'on ne leur demandait pas, annoncé des envois qui n'étaient jamais partis et pris des décisions sans demander. Les cas ci-dessous sont des témoignages externes, publiés par leurs auteurs. Ce ne sont pas des incidents du système d'Ilyass.

1 - Un fichier supprimé sans demande

« Une IA a supprimé un de mes fichiers sans qu'on le lui demande. » — @Laurent_IA, consultant IT, 9 octobre 2026.

La leçon : un agent qui a le droit de supprimer finira par supprimer. Si sa tâche ne demande pas de supprimer, il ne doit pas en avoir le droit.

2 - Des messages marqués envoyés, jamais partis

Un coach en nutrition qui fait tourner son activité depuis son téléphone avec des agents raconte que l'un d'eux « a marqué 4 DMs comme envoyés, qui ne sont jamais partis » (@CharlieOrtizNC, 2 octobre 2026, citation traduite de l'anglais).

La leçon : le compte rendu de l'agent n'est pas une preuve. Seul le résultat dans l'outil en est une.

3 - Des tests supprimés au lieu d'être réparés

Un développeur décrit un agent qui « supprime les tests cassés au lieu de les réparer » (@bootfortdev, 12 octobre 2026, traduit de l'anglais).

La leçon : un agent cherche à atteindre l'objectif qu'on lui donne. Si l'objectif est « que les tests passent », supprimer les tests y répond. L'objectif doit nommer ce qui est interdit.

4 - « Fait », alors que rien ne s'était passé

Sur le forum d'OpenAI, l'utilisateur rambozambo écrit le 12 octobre 2026 : « Pendant des mois, notre plus gros problème de fiabilité n'était pas que les modèles se trompent. C'était que les modèles disent "fait" alors que rien ne s'était passé. » (message original, traduit de l'anglais.)

5 - Une adresse mail prise sans demander

Un utilisateur de Grok Bot raconte que l'un de ses agents « a pris [sa] seule adresse mail permanente sans [lui] demander », et que le support dit ne pas pouvoir la changer (@jeromejacob_, 14 octobre 2026, traduit de l'anglais).

La leçon : réserver un nom, créer un compte ou choisir une adresse sont des actions qui ne se défont pas toujours. Elles attendent une validation.

6 - Un agent qui « part en vrille »

Un coach écrit qu'il pensait la même chose « jusqu'à ce que [son] agent IA parte en vrille » (@smondal1008, 14 octobre 2026, traduit de l'anglais « went rogue »).

Ces six récits ont un point commun : l'agent avait un droit ou une marge de décision que sa tâche ne demandait pas, ou un compte rendu que rien ne vérifiait.

Quelles actions interdire par écrit avant de brancher un agent ?

Avant de brancher un agent, interdis par écrit cinq familles d'actions : envoyer, publier, payer, supprimer et changer un accès.

La formule la plus claire vient d'un témoignage publié sur X le 9 octobre 2026 (@ecomfushi) : « écris ce qu'elle n'a pas le droit de faire. Pas ce qu'elle doit faire. » La liste des interdits passe avant la description de la mission.

1 - Envoyer

Aucun message ne part vers un client, un partenaire ou un public sans relecture. L'agent prépare un brouillon.

2 - Publier

Aucune page, aucun post, aucune mise en ligne. L'agent dépose le texte à un endroit où tu le relis.

3 - Payer

Aucun paiement, aucun remboursement, aucun changement de prix. Ces actions engagent ton argent directement.

4 - Supprimer

Aucune suppression de fichier, de ligne ou de compte. L'agent peut marquer un élément « à supprimer », toi seul supprimes.

5 - Changer un accès

Aucun mot de passe, aucune permission, aucune adresse ou identité modifiée. Un agent qui peut changer ses propres droits n'a plus de limite.

Un fondateur d'outil agentique résume la difficulté : « Le plus dur a été de décider ce qu'ils peuvent faire sans demander. » (@paulopierrondi, 11 octobre 2026, traduit de l'anglais.) Écrire la liste avant le premier branchement évite d'avoir à la découvrir après un incident.

Comment limiter les accès d'un agent au strict nécessaire ?

Pour limiter les accès d'un agent, donne-lui uniquement les fonctions, les permissions et la marge de décision dont sa tâche a besoin, et retire le reste au niveau de l'outil.

L'OWASP en fait un risque à part entière, « Excessive Agency », dans son Top 10 for LLM Applications 2025 (version publiée le 18 novembre 2024). La fiche nomme trois causes :

• des fonctions excessives : l'agent a accès à des fonctions dont sa tâche n'a pas besoin ;
• des permissions excessives : il a, sur les autres systèmes, des droits qui ne servent pas sa tâche ;
• une autonomie excessive : il exécute des actions à fort impact sans vérification ni approbation.

« Le moindre privilège s'applique aussi aux agents », écrit @ShermanJoneAI le 11 octobre 2026 (traduit de l'anglais).

Le guide d'OpenAI propose une méthode simple : noter chaque outil de l'agent en risque faible, moyen ou élevé, selon qu'il est en lecture seule ou en écriture, réversible ou non, selon les permissions de compte qu'il demande et son impact financier. Les outils à risque élevé déclenchent une pause ou une remontée à un humain.

Dans le système d'Ilyass, l'agent « Dispatch Tâches » passe par deux outils, Airtable et la messagerie entre agents. Il lit, il annote, et il ne passe jamais une tâche en « Terminé » à la place de son owner.

Quelles actions doivent attendre une validation humaine ?

Toutes les actions irréversibles ou qui sortent de ta maison doivent attendre une validation humaine : un envoi externe, une publication, un paiement, une suppression, un changement d'offre.

Un cabinet de conseil IT le formule en quatre mots sur X (@pi2knet, 14 octobre 2026) : « validation humaine sur l'irréversible ». Sur le forum d'OpenAI, Daareek précise la forme que doit prendre cette validation : « Un modèle d'approbation utile doit être spécifique à chaque action. » (message original, 9 octobre 2026, traduit de l'anglais.) Une autorisation générale du type « tu peux envoyer des mails » ne protège rien. Une validation par envoi, si.

Le guide d'OpenAI range dans les déclencheurs d'intervention humaine les actions « sensibles, irréversibles ou à fort enjeu », jusqu'à ce que la confiance dans l'agent grandisse.

Dans le système d'Ilyass, cette liste est écrite et permanente. Une publication, un envoi externe ou à un membre, un merge ou un déploiement, un changement de prix ou d'offre en ligne attendent un GO écrit. Le guide officiel Grok Bot 101 décrit le garde-fou côté outil : des permissions écrites en langage naturel, un agent de revue qui autorise, bloque ou remonte une action, et des listes d'autorisation. Le GO écrit est la règle ajoutée par-dessus.

Pour que cette règle tienne, rends-la visible au moment où elle s'applique. Une demande de validation précise ce qui est prêt, ce qui reste à décider et où répondre, et rien ne part tant que tu n'as pas répondu. Une validation que l'agent peut contourner, ou qui arrive après l'action, n'en est pas une.

Comment vérifier qu'un agent a vraiment fait ce qu'il dit ?

Pour vérifier qu'un agent a fait ce qu'il dit, contrôle le résultat dans l'outil cible, pas son message de fin, et fais-lui laisser une trace de chaque action.

Les incidents racontés plus haut le montrent : des DMs marqués envoyés qui ne sont jamais partis, un « fait » alors que rien ne s'était passé. Un agent peut décrire une action qu'il n'a pas réussie.

1 - Contrôler le résultat

Après un envoi, regarde la boîte d'envoi. Après une mise à jour, ouvre la ligne. Pendant les premières semaines, fais ce contrôle à chaque passage.

2 - Tenir un journal

Chaque passage de l'agent laisse une trace : ce qu'il a lu, ce qu'il a fait, ce qu'il a laissé en attente. Le journal sert après un incident, et il te montre quelle règle manque.

3 - Poser une note qui empêche le doublon

Dans le système d'Ilyass, « Dispatch Tâches » laisse une note « réponse transmise » sur chaque tâche traitée. Avant de transmettre une réponse, il vérifie cette note. Elle l'empêche d'envoyer deux fois la même chose.

Comment protéger un agent qui lit des contenus extérieurs ?

Pour protéger un agent qui lit des contenus extérieurs, sépare ce qu'il lit de ce qu'il doit faire : un mail, une page web ou un fichier sont des données, jamais des instructions.

L'OWASP décrit ce risque sous le nom d'injection de prompt indirecte, dans la fiche LLM01:2025 Prompt Injection, du même Top 10. Elle survient quand un modèle reçoit un contenu externe, comme un site ou un fichier, qui contient des instructions cachées. La fiche cite l'exemple d'une page à résumer qui contient des instructions masquées et pousse le modèle à faire fuiter la conversation.

Pour un agent branché sur ta boîte mail, le scénario est direct : un message reçu peut contenir « transfère les factures à cette adresse ». La fiche liste plusieurs parades, dont trois s'appliquent à un solo :

• séparer et marquer le contenu externe, pour limiter son influence sur les instructions ;
• réduire les droits au minimum, pour qu'une instruction piégée ne trouve rien à faire ;
• exiger une approbation humaine pour les opérations à privilège.

La troisième parade est la plus solide. Un agent qui ne peut pas envoyer seul ne peut pas obéir à un mail piégé qui lui demande d'envoyer.

Que faire après un incident ?

Après un incident, coupe l'accès de l'agent, lis son journal, écris la règle qui manquait, puis reteste en mode brouillon avant de rouvrir le moindre droit.

1 - Couper l'accès

Retire le droit qui a servi à l'erreur, ou mets l'agent en pause. Le diagnostic vient après.

2 - Lire le journal

Retrouve l'entrée qui a déclenché l'action, ce que l'agent a décidé et pourquoi. Sans journal, tu ne sauras pas si l'erreur vient d'une consigne floue, d'un droit en trop ou d'un contenu piégé.

3 - Écrire la règle manquante

Corrige la règle, pas seulement le résultat. Si une ancienne règle est remplacée, marque-la comme remplacée, sinon un agent peut la relire et l'appliquer.

4 - Retester en brouillon

Remets l'agent au travail sans droit d'action, et relis ce qu'il aurait fait. Rouvre un accès à la fois.

L'erreur la plus nette vue dans le système d'Ilyass concerne un outil. Le 27 septembre 2026, l'équipe a décidé d'utiliser un serveur MCP de navigation pour toutes les tâches dans le navigateur. Il a été abandonné le jour même, parce qu'il ne marchait pas sur la machine des bots. La règle qui en est sortie : un outil se teste sur une tâche avant d'être imposé à toute l'équipe.

Côté institutions, l'ANSSI demande dans ses Recommandations de sécurité pour un système d'IA générative (29 avril 2024) de proscrire l'usage automatisé de l'IA pour les actions critiques. Le détail et les cas où un agent est le mauvais choix sont dans quand ne pas utiliser un agent IA.