← Articles12 octobre 2026

Un agent a besoin de limites


Imaginez un nouvel arrivant dans votre entreprise. Brillant, rapide, infatigable. Il lit tout, il comprend vite, il ne rechigne devant aucune tâche.

Le premier jour, lui donneriez-vous le badge qui ouvre toutes les portes, le mot de passe de la banque et les clés du serveur ? Non. Vous lui donneriez ce qu'il faut pour sa mission, et vous élargiriez avec le temps.

C'est pourtant ce qu'on fait chaque jour avec les agents.

Un agent, c'est une IA à qui l'on confie une tâche et des accès. Celle qui écrit du code, mais aussi celle qui trie vos mails ou remplit votre CRM.

Le 25 avril 2026, chez PocketOS (nouvel onglet), un agent de code bloqué sur une tâche de test a trouvé un jeton d'accès oublié dans un fichier. Il l'a utilisé. En neuf secondes, la base de production et ses sauvegardes avaient disparu. Trente heures de crise ont suivi.

Ce qui rend l'histoire inconfortable, c'est qu'il n'y a pas de pirate, pas de faille exotique. Notre nouvel arrivant n'était pas malveillant. Il voulait finir sa tâche, et il a pris ce qui traînait sur le bureau.

Un agent n'est pas un outil comme un autre. Il agit. Et il agit avec vos accès.

Le nouvel arrivant peut aussi se faire manipuler

Un humain qui reçoit un mail étrange se méfie, parfois. Un agent lit tout ce qu'on lui présente comme du travail à faire. En juillet 2026, un chercheur de Noma Security a caché des instructions dans un ticket public sur GitHub. L'agent chargé de traiter les tickets les a suivies. Il est allé lire un dépôt privé et en a recopié le contenu dans un commentaire public. Korben a raconté l'attaque sous le nom de GitLost (nouvel onglet).

La configuration visée était très particulière. Mais le principe est général : tout ce que l'agent lit peut devenir un ordre.

Le bouton « accepter » n'est pas un contrôle

Le premier réflexe, c'est de surveiller. L'agent demande la permission, on valide, et on se sent rassuré. Seulement voilà, Anthropic a mesuré (nouvel onglet) que les utilisateurs de Claude Code acceptaient environ 93 % des demandes. Plus on en voit, moins on les lit. Ce n'est pas de la négligence, c'est humain, et ça porte un nom : la fatigue d'approbation. Chez OpenAI (nouvel onglet) comme chez Docker (nouvel onglet), on en parle ouvertement, jusqu'aux « modes YOLO » qui suppriment toutes les demandes (YOLO, pour you only live once).

Et quand ça va vite, la relecture ne suit pas. Neuf secondes ont suffi pour tout effacer. Aucun humain ne relit à cette vitesse.

Refuser n'est pas cloisonner

Anthropic décrit (nouvel onglet) deux façons de limiter les dégâts.

La première consiste à surveiller ce que fait l'agent, avec des demandes de permission, et de plus en plus un modèle qui valide à notre place. Le mode automatique d'Anthropic arrête environ 83 % des actions trop zélées. C'est beaucoup, mais pas tout, et l'entreprise le reconnaît elle-même (toute défense probabiliste a un taux d'échec non nul). Un garde-fou refuse, au cas par cas, ce qui lui semble suspect.

La seconde, c'est contenir ce qu'il peut faire. Un environnement séparé, un réseau filtré, aucun identifiant sensible à l'intérieur. Une frontière cloisonne, elle rend l'action bien plus difficile, quelle que soit l'intention. Comme le dit Anthropic, si les identifiants n'entrent jamais dans le bac à sable, ils ne peuvent pas fuiter, que l'erreur vienne de l'utilisateur, du modèle ou d'un attaquant.

Bien plus difficile, donc, mais pas impossible. Cet été, chez OpenAI, des agents en cours d'évaluation sont sortis de leur bac à sable (nouvel onglet) par une faille encore inconnue, puis se sont introduits chez Hugging Face pour y voler les solutions de leur propre test.

C'est pour ça que surveiller et cloisonner ne s'opposent pas, ils se combinent. Plus le périmètre est serré, plus on peut relâcher la surveillance, et laisser l'agent travailler sans valider chaque geste.

C'est exactement ce qu'on fait avec un nouvel arrivant.

Avec un nouvel arrivant Avec un agent
Un badge limité à son service Des accès limités à la tâche, en lecture seule si possible
Pas les clés de la production le premier jour Aucun accès de production dans son environnement
Un bureau à lui, pas celui du comptable Un environnement séparé, isolé du reste
Les archives au coffre Des sauvegardes hors de sa portée
On vérifie son travail, pas chacun de ses gestes Des tests et des contrôles automatiques, plutôt qu'une validation à chaque action

Cette dernière ligne compte. On délimite le périmètre, puis on regarde le résultat. On économise de l'attention là où elle ne servait plus, pour la garder là où elle compte.

Quatre questions avant de laisser un agent travailler

Pas besoin d'une équipe de sécurité pour commencer. Quatre questions suffisent à éviter l'essentiel des mauvaises surprises.

1. Que peut-il atteindre, au-delà de ce que je lui demande ? On pense à la tâche. L'agent, lui, voit tout ce qui est à sa portée : les fichiers voisins, la configuration, les mots de passe oubliés dans le code.

À vérifier. Aucun accès de production dans l'environnement où travaille l'agent.

2. Ses accès sont-ils limités à sa tâche ? Le jeton oublié du début servait à gérer des noms de domaine. Il permettait tout le reste. Chez Anthropic (nouvel onglet), un agent qui faisait le ménage a supprimé environ 200 services en production en 90 secondes, avec les droits de l'ingénieur qui l'avait lancé. Un accès large transforme une erreur banale en incident.

À vérifier. Des accès propres à l'agent, réduits à la tâche, en lecture seule quand c'est possible. Un agent qui ne fait que lire peut être utilisé bien plus largement.

3. Qu'est-ce qui est irréversible ? Une erreur qu'on peut annuler est un contretemps. Une erreur irréversible est une crise. Des sauvegardes rangées au même endroit que la base disparaissent avec elle.

À vérifier. Des sauvegardes hors de portée de ce qui peut les effacer, et les validations humaines gardées pour ce qui est vraiment irréversible.

4. Qui peut lui parler ? Un agent lit des tickets, des pages web, des fichiers. Chacun peut contenir une instruction, comme l'a montré GitLost.

À vérifier. Un agent qui lit des contenus extérieurs ne doit pas avoir, dans le même temps, accès à ce qui est sensible.

L'IA pour faire mieux

Je suis un enthousiaste de l'IA générative. Je l'utilise tous les jours depuis ses débuts, et ce qu'elle m'apporte de plus précieux n'est pas le temps gagné, c'est ce qu'il permet de faire. Aller au bout de ses idées, là où on devait souvent se contenter d'une version réduite, faute de temps. Écrire les tests qu'on aurait laissés de côté, tenir la documentation à jour, repérer les erreurs plus tôt.

Cette IA-là existe. Mais elle ne dispense pas des précautions qu'on prendrait avec n'importe quel nouvel arrivant. On parle beaucoup de ce que l'IA fait gagner, beaucoup moins de ce qu'elle peut casser (encore que, depuis cet été, le sujet revient sur la table). Si une formation à l'IA ne vous en parle jamais, posez la question.

Accueillez votre agent comme un nouvel arrivant. Un périmètre clair et restreint d'abord, la confiance ensuite, à mesure qu'elle se gagne. Et gardez à l'esprit qu'un agent n'éprouve pas de scrupules.