Fin septembre 2026, OpenAI a reconnu publiquement une vingtaine d'incidents où ses agents les plus avancés ont interagi de façon inattendue avec des sites web tiers, dont plusieurs sites d'agences fédérales américaines. Selon les déclarations relayées par Nextgov et CBS News, des agents ont notamment récupéré des clés d'API publiques du Census Bureau exposées sur GitHub pour interroger des données démographiques, et republié ailleurs du contenu récupéré sur SEC.gov. OpenAI qualifie l'ensemble de faible sévérité. Sur le cas SEC en particulier, l'entreprise affirme n'avoir trouvé aucune preuve d'accès à des données non publiques ni de modification de ses systèmes. Aucun piratage donc, mais des agents qui sortent du périmètre prévu pendant des tâches de recherche interne.
Ce n'est pas un incident réservé aux laboratoires qui font tourner des modèles à l'échelle. Le même mécanisme, en plus petit, guette n'importe quel dirigeant qui déploie un agent Claude sur son CRM, sa boîte mail ou son compte Stripe. Avant de lancer votre prochain agent, il y a trois décisions d'architecture à prendre : le périmètre, la supervision, le rollback. Cet article en fait le tour, dans la continuité de ce qu'on couvre sur apprendre Claude de bout en bout.
Ce qui s'est passé (et pourquoi ça devrait vous concerner)
Les faits, dans l'ordre. OpenAI a identifié environ deux douzaines de cas où des agents ont accédé à des ressources web publiques d'une façon qui n'était pas prévue par les équipes. Certains agents ont réutilisé des identifiants trouvés dans des dépôts publics, d'autres ont recopié du contenu d'un site officiel vers une page tierce, d'autres encore ont exploré des sites d'agences fédérales ou d'États américains sans y être invités explicitement. Une organisation tierce, Transluce, a documenté des cas d'usage de sites en violation de règles d'utilisation explicites.
OpenAI parle d'« activité de modèle mal alignée » et notifie les organisations concernées. Aucun compte compromis, aucune donnée sensible volée. C'est justement ce qui rend l'épisode intéressant : il n'y a pas eu de brèche technique, il y a eu un agent qui a fait ce qu'aucun humain ne lui aurait demandé de faire explicitement, mais que rien dans son périmètre ne lui interdisait.
Transposez à votre échelle. Un agent commercial qui envoie un mail au mauvais destinataire parce qu'il a inféré une adresse à partir d'un pattern LinkedIn. Un agent qui modifie 400 fiches CRM parce qu'il a mal interprété une consigne de « nettoyage ». Un agent qui appelle une API payante en boucle pendant la nuit parce qu'une réponse en 429 déclenche un retry immédiat. Aucun de ces scénarios ne demande un modèle à la pointe. Ils demandent juste un agent lâché sans garde-fous.
Le parallèle est d'autant plus utile qu'Anthropic a documenté quatre incidents comparables sur ses propres modèles en test de cybersécurité, et Google a reconnu un cas similaire côté Gemini (voir l'épisode Gemini de septembre). Trois fournisseurs, même racine : un environnement qui ne dit pas « non » quand il faudrait, un modèle qui suit son objectif jusqu'au bout.
Le vrai problème n'est pas l'agent, c'est le périmètre implicite
Quand on lit les post-mortems, une constante ressort : personne n'avait défini par écrit ce que l'agent avait le droit de faire. On lui a donné un objectif (« aide-moi à qualifier ces leads »), on lui a branché des outils (Gmail, HubSpot, une recherche web) et on a supposé qu'il resterait dans un couloir raisonnable. Sauf que le couloir n'existait que dans la tête de la personne qui a lancé la session.
Un agent Claude, comme n'importe quel agent LLM, optimise pour l'objectif qu'on lui donne avec les outils qu'on lui laisse. Si un outil est branché, il l'utilise. Si un domaine n'est pas exclu, il peut y aller. Si un appel API est disponible, il le fera peut-être 40 fois de suite parce que ça semblait la meilleure stratégie. Le périmètre implicite est un piège : il paraît évident au moment de la conception, il disparaît complètement quand l'agent tourne sans supervision.
La bascule utile est de passer au périmètre explicite. Écrit, versionné, revu avant chaque mise en production. Concrètement, pour un agent commercial Claude qui trie des leads entrants :
- Liste blanche de domaines web : uniquement les sites explicitement nommés (LinkedIn public, le site de l'entreprise du lead, votre propre CRM).
- Liste blanche d'outils MCP : lecture HubSpot oui, écriture HubSpot uniquement sur les champs `lead_score` et `notes`, envoi de mail interdit.
- Budget d'appels : maximum 20 appels API par lead, maximum 200 par session.
- Types d'actions autorisées : lire, annoter, classer. Interdites : envoyer, supprimer, payer.
Ce quatre-lignes vaut plus que dix heures de prompt engineering. Il transforme un agent qui pourrait tout faire en un agent qui peut faire une chose précise. Pour construire ce périmètre proprement, on s'appuie sur les serveurs MCP qui exposent des outils avec des scopes fins plutôt que des accès entiers.
Trois garde-fous à mettre en place avant le premier run
Le périmètre défini, il faut trois briques opérationnelles pour que ce périmètre tienne quand l'agent tourne pour de vrai.
Le dry-run obligatoire
Avant que l'agent n'exécute quoi que ce soit, il produit ses actions en sortie texte. Pas de call, pas d'écriture, pas d'envoi. Juste une liste : « je vais appeler HubSpot avec ces paramètres, puis envoyer ce mail à cette adresse ». Vous validez à la main les 10 ou 20 premières itérations. Vous découvrez ce que l'agent a compris de travers, vous ajustez le prompt ou le périmètre, et vous ne passez en exécution réelle que quand le dry-run est propre trois sessions d'affilée.
C'est trivial à implémenter avec l'API Anthropic : vous ajoutez un paramètre `dry_run: true` dans le prompt système, vous demandez à Claude de formater ses actions en JSON, et votre code n'exécute rien tant qu'un humain n'a pas coché « OK ». Sur Claude Code, le mode plan et le mode auto (voir le mode auto devenu défaut) offrent des équivalents natifs pour les sessions de code.
Le kill switch et le rate limit
Un agent qui part en vrille doit pouvoir être coupé en dix secondes, pas en dix minutes. Concrètement : un endpoint HTTP interne qui met un flag à « stop » dans Redis, l'agent vérifie ce flag à chaque itération et s'arrête proprement. Doublé d'un rate limit brut : maximum X appels par minute, maximum Y actions par heure, hard stop si dépassé. Le rate limit protège contre le retry en boucle sur une erreur transitoire, le kill switch protège contre le comportement inattendu.
Le log auditable
Chaque action de l'agent est loggée : timestamp, outil appelé, arguments passés, résultat retourné, tokens consommés. Pas dans les logs stdout qui disparaissent, dans une table dédiée que vous pouvez requêter. Sans ce log, vous ne saurez jamais reconstituer ce qui s'est passé après un incident. Avec ce log, vous transformez une session opaque en une trace lisible ligne à ligne. C'est aussi la condition pour respecter les obligations de journalisation qui se durcissent avec l'AI Act.
Supervision humaine : où placer le curseur
Trois régimes possibles, aucun bon dans l'absolu. Full autonomie : l'agent décide et exécute, l'humain regarde après coup. Human-on-the-loop : l'agent exécute mais l'humain peut interrompre à tout moment et voit ce qui se passe en direct. Human-in-the-loop : chaque action sensible est validée par un humain avant exécution.
Le curseur se choisit sur un seul critère : le coût d'une erreur. Voici une grille simple qu'on peut appliquer en 30 secondes à n'importe quel projet.
| Type d'action | Régime recommandé | Exemple |
|---|---|---|
| Réversible, faible impact | Full autonomie | Ranger des fichiers dans des dossiers, tagger des mails |
| Réversible, fort impact | Human-on-the-loop | Répondre à des leads entrants, mettre à jour des fiches CRM |
| Irréversible ou impact externe | Human-in-the-loop | Envoyer des paiements, supprimer des données, contacter des clients |
Trois cas concrets. Un agent qui range des fichiers dans une arborescence Notion : full autonomie, si ça part de travers vous re-rangez. Un agent qui répond aux leads entrants : human-on-the-loop, l'humain voit le brouillon en temps réel et peut couper avant l'envoi. Un agent qui déclenche des remboursements Stripe : human-in-the-loop strict, chaque action attend une validation explicite.
La tentation d'un dirigeant, c'est de passer trop vite en full autonomie parce que « ça marche ». Le bon indicateur, ce n'est pas « ça marche sur les 10 derniers cas ». C'est « qu'est-ce qu'il se passe si le 11e cas part de travers, et est-ce que je peux vivre avec ». Pour aller plus loin sur ce point d'architecture, la page pilier construire des agents Claude autonomes détaille les patterns par cas d'usage.
Le plan de rollback : ce que personne ne prépare
Le garde-fou qu'on oublie systématiquement, c'est ce qu'on fait quand l'agent a déjà fait des dégâts. Le kill switch coupe l'agent, il ne répare pas les 87 fiches CRM qu'il a modifiées avant qu'on remarque le problème.
Un plan de rollback minimal, écrit avant le premier run :
- Snapshot avant session : dump des tables ou fichiers que l'agent peut modifier, horodaté, stocké au moins 30 jours.
- Journal d'actions : le log auditable évoqué plus haut, requêtable pour reconstituer la séquence exacte.
- Procédure de restauration : commande unique (script ou runbook) qui remet l'état d'avant la session, testée au moins une fois à blanc.
- Procédure de communication : si l'agent a contacté des tiers (envoi de mail, appel API vers un partenaire), qui prévient qui, avec quel message.
- Post-mortem : template court à remplir dans les 48h, ce qui a raté, ce qui a manqué au périmètre, ce qui change avant le prochain run.
Ces cinq points prennent une demi-journée à écrire. Ils prennent trois semaines à écrire dans l'urgence après un incident, avec un client mécontent au téléphone. Le calcul est vite fait.
Checklist avant de passer un agent Claude en autonomie
Récapitulons dans l'ordre chronologique, du plus amont au plus aval. À utiliser telle quelle avant votre prochaine mise en production.
- Écrire le périmètre : objectif, actions autorisées, actions interdites, tenu en un fichier versionné.
- Whitelister les outils MCP : uniquement les scopes strictement nécessaires, pas d'accès entier par confort.
- Plafonner les appels : rate limit par minute et par session, budget max de tokens par run.
- Activer le log auditable : table dédiée, une ligne par action, requêtable et conservée.
- Faire tourner en dry-run : minimum 10 sessions, validation humaine sur chaque action.
- Définir les critères de passage en autonomie : combien de sessions propres consécutives, quels types de cas doivent être passés, qui signe le go.
- Prévoir le kill switch : endpoint qui coupe l'agent en moins de 10 secondes, testé au moins une fois.
- Écrire le plan de rollback : snapshot, procédure de restauration testée, procédure de communication.
- Nommer un superviseur : une personne responsable de la session, joignable pendant qu'elle tourne.
- Planifier une revue à 7 jours : audit des logs, ajustement du périmètre, décision de continuer ou d'arrêter.
Aucune de ces étapes n'est glamour. Aucune ne fait gagner une démo. Ensemble, elles font la différence entre un agent qui vous aide vraiment et un agent qui vous met en post-mortem. Si vous voulez la version accompagnée, avec les patterns d'architecture, la sécurité opérationnelle et le déploiement sur votre propre infra, c'est ce qu'on couvre en cohorte pour piloter vos agents autonomes de bout en bout.