La réponse courte
Les chercheurs de Zenity Labs ont révélé AgentForger, une faille de falsification de requête inter-sites (CSRF) dans l'Agent Builder de ChatGPT qui permettait à un seul lien de hameçonnage de construire, autoriser et déployer un agent IA autonome contrôlé par l'attaquant au sein de l'organisation d'une victime — sans le moindre clic de confirmation. Le Builder acceptait une partie de son état de départ via des paramètres d'URL, et la valeur de initial_assistant_prompt était exécutée plutôt qu'affichée. Un clic d'un utilisateur connecté disposant des Workspace Agents et d'au moins une application connectée suffisait pour que le Builder câble ses connecteurs, coupe les demandes d'approbation, publie un nouvel agent et le mette sur un planning. OpenAI a été prévenu via Bugcrowd le 4 juin 2026 et a colmaté la brèche en quelques jours en supprimant le paramètre vulnérable.
Le correctif est fait, ce n'est donc pas un exercice d'urgence. C'est une leçon de conception pour quiconque livre des agents IA : l'agent est une identité dotée d'un accès permanent, et un agent forgé est un initié. L'intéressant dans AgentForger n'est pas le bug précis — c'est à quel point la faille web était ordinaire et à quel point elle a hérité d'un large rayon d'impact parce qu'un agent repose sur des connecteurs d'entreprise pré-approuvés.
Ce que Zenity a révélé
L'équipe rouge IA de Zenity Labs a publié fin juillet 2026 une recherche décrivant AgentForger, une faille de l'Agent Builder livré avec les Workspace Agents de ChatGPT. L'attaque exigeait seulement que la cible soit connectée à ChatGPT, ait accès aux Workspace Agents et dispose d'au moins un connecteur déjà autorisé — Outlook, Gmail, Google Calendar, Slack ou Teams, par exemple. Dans ces conditions courantes, ouvrir un lien d'apparence normale suffisait à dresser un agent fonctionnel qui répondait à l'attaquant plutôt qu'à l'employé.
La chaîne, telle que Zenity la décrit, est brutale. Un clic, et le Builder « se mettait au travail pour le compte de l'attaquant, câblant les connecteurs existants de la victime, coupant les demandes d'approbation, publiant le nouvel agent et le lâchant selon un planning ». Plutôt que de rappeler une infrastructure classique de commande et de contrôle, l'agent forgé surveillait la boîte de réception de la victime à la recherche de messages portant un mot-clé défini dans l'objet et traitait chacun comme une nouvelle mission — un canal discret, à faible signal, qui ressemble à du trafic de courrier ordinaire.
La chronologie compte pour la lecture de l'actualité. Zenity a signalé le problème à OpenAI via Bugcrowd le 4 juin 2026 ; OpenAI l'a reconnu le 5 juin et l'a corrigé en quelques jours en supprimant le paramètre d'URL vulnérable, le chemin précis est donc fermé. Le compte rendu public est l'événement de juillet, pas une faille zero-day active. Par ailleurs, OpenAI a annoncé qu'il retirerait l'Agent Builder le 30 novembre 2026 pour orienter les développeurs vers son Agents SDK — un rappel que la surface elle-même est encore jeune et mouvante.
Comment un lien a forgé un agent
La mécanique est un bug web de manuel dans un décor inhabituel. L'Agent Builder laissait une partie de son état initial arriver via des paramètres d'URL, selon une forme comme /agents/studio/new?template_name=…&initial_assistant_prompt=…. Le problème, selon les mots de Zenity, était que « au chargement de la page, la valeur d'initial_assistant_prompt n'est pas seulement placée dans le champ de saisie — elle est automatiquement soumise et exécutée ». Une instruction glissée dans un lien devenait la première commande sur laquelle agissait le Builder, avec l'autorité de celui qui cliquait.
C'est de la falsification de requête inter-sites : une action modifiant l'état, déclenchée par une requête piégée qui chevauche la session existante de la victime. Le CSRF est l'une des plus anciennes catégories du livre de la sécurité web, et les défenses standard — jetons anti-falsification, exigence d'un geste utilisateur explicite pour les actions sensibles, ne pas traiter les paramètres GET comme des commandes — sont bien comprises. Ce qui rendait AgentForger dangereux n'était pas la nouveauté mais l'effet de levier. La requête forgée ne transférait pas d'argent et ne modifiait pas d'e-mail ; elle créait un acteur autonome boulonné à des connecteurs que l'utilisateur avait déjà approuvés, si bien qu'aucun nouvel écran de consentement n'apparaissait.
Voilà le schéma à intérioriser. Quand une surface de création d'agents accepte des instructions issues d'entrées non fiables et les exécute, le contenu du prompt devient du flux de contrôle. Le rayon d'impact est alors tout ce que l'agent peut atteindre, et les agents d'entreprise modernes sont délibérément reliés au courrier, à la messagerie, aux fichiers et aux agendas pour être utiles. Une faille qui serait un CSRF de gravité moyenne sur une page de réglages devient un point d'appui pour un initié autonome dès lors que l'objet qu'elle crée est un agent doté d'un accès permanent.
Pourquoi un « initié autonome » est différent
Retirez les spécificités de ChatGPT et un agent forgé se comporte comme un compte employé compromis — avec deux différences qui jouent contre le défenseur. D'abord, il est patient et automatisé : il tourne selon un planning, ne réclame aucune main sur un clavier et peut rechercher des fichiers, collecter des documents, envoyer des messages sous l'identité de la victime et cartographier l'organisation sans jamais déclencher une alerte d'anomalie de connexion, puisqu'il utilise une session déjà de confiance et des connecteurs déjà approuvés. Ensuite, il peut se reproduire. Le scénario de Zenity fait lancer par l'agent forgé du hameçonnage interne qui engendre d'autres agents compromis, transformant un clic en une population d'initiés qui se propage.
Cela brise quelques hypothèses confortables. Le consentement est censé être le point de contrôle de l'accès aux connecteurs, mais une seule approbation donnée des semaines plus tôt suffisait ici — l'agent en héritait. La surveillance est calibrée sur des schémas humains, mais un agent qui prend ses ordres dans des messages de boîte de réception à l'objet anodin ne ressemble pas à de l'exfiltration. Et la gouvernance des identités suit en général les utilisateurs et les comptes de service, tandis que les agents existent souvent dans un angle mort : personne ne détient l'inventaire des agents existants, de qui les a créés et de ce qu'ils peuvent toucher. AgentForger est un aperçu de la catégorie du problème, pas un cas isolé.
Ce que cela implique pour les équipes logicielles aux États-Unis & en France
Le premier basculement est conceptuel : un agent IA est une identité privilégiée, pas une fonctionnalité d'interface. Si vous déployez des agents — qu'il s'agisse d'agents tiers comme ceux-ci ou de systèmes que vous bâtissez — ils exigent le même cycle de vie qu'un compte de service : un propriétaire, une entrée d'inventaire, des permissions restreintes, une piste d'audit et un moyen de les révoquer vite. « Un agent peut faire X » doit se lire « un nouveau principal dans votre environnement peut faire X », et se provisionner avec le moindre privilège qui lui permet encore de travailler. Les octrois de connecteurs larges et permanents sont le multiplicateur qui a transformé un CSRF de routine en un problème à l'échelle du domaine.
Le second basculement est une règle architecturale ferme pour quiconque bâtit des surfaces d'agents : ne laissez jamais une entrée non fiable devenir une instruction exécutée, et ne laissez jamais un seul consentement autoriser une action future ouverte. Maintenez une étape d'approbation humaine sur tout agent capable d'agir sur des données ou des personnes, exigez une confirmation explicite de même origine avant qu'un agent ne soit publié ou qu'un connecteur ne lui soit octroyé, et traitez les prompts arrivant par liens, documents ou e-mails comme des données à isoler, non comme des commandes à exécuter. Ce sont les mêmes leçons que l'industrie réapprend sans cesse — validation des entrées, jetons CSRF, moindre privilège — désormais appliquées là où l'objet exécuté est un travailleur autonome.
Pour les produits réglementés, la couche de gouvernance n'est pas optionnelle. Dans la FinTech et la HealthTech, un agent relié à des messageries et à des espaces documentaires côtoie des données personnelles et financières, si bien qu'un agent forgé est un incident RGPD potentiel avec ses délais de notification, pas une curiosité de laboratoire. Pour les entités financières supervisées, DORA et les attentes de l'ACPR sur la gestion du risque informatique et des prestataires tiers s'ajoutent — un agent autonome bâti sur un service externe entre exactement dans ce champ. Et sous le Règlement européen sur l'IA, un système automatisé prenant des actions conséquentes sur des personnes porte des exigences de documentation, de supervision humaine et de journalisation — « un agent tiers l'a fait de façon autonome » n'est pas une réponse qu'un auditeur acceptera. Intégrez dès maintenant les identités, permissions et supervision des agents à votre SDLC sécurisé et à votre registre des risques fournisseurs, tant que le nombre d'agents reste assez petit pour être inventorié à la main.
Que faire cette semaine
Une séquence courte et pratique qui transforme la divulgation en action plutôt qu'en anxiété :
- Inventoriez vos agents. Recensez chaque agent IA opérant dans vos environnements — agents ChatGPT Workspace, agents Copilot et agents maison — avec un propriétaire, ses connecteurs et ce que chacun peut atteindre. On ne gouverne pas ce qu'on n'a pas compté.
- Limitez les connecteurs au moindre privilège. Élaguez les octrois permanents pour qu'un agent ne touche que les boîtes mail, canaux et disques dont il a réellement besoin, et ne tourne jamais avec l'accès complet d'un humain ni une identité de déploiement en production.
- Gardez un humain dans la boucle pour les actions. Exigez une approbation explicite avant qu'un agent n'envoie, ne modifie ou ne partage au nom d'une personne, et avant qu'un nouvel agent ne soit publié ou qu'un connecteur ne lui soit octroyé. Ne laissez pas un consentement passé tenir lieu d'actions futures.
- Instrumentez pour le comportement des agents. Alertez sur les agents nouvellement créés ou modifiés, sur les octrois de connecteurs et sur les rafales d'activité de connecteurs planifiées ou automatisées — les signaux que produit un agent forgé — plutôt que de vous fier aux seules anomalies de connexion humaines.
- Durcissez vos propres surfaces de création d'agents. Si vous livrez quoi que ce soit qui assemble ou configure des agents, n'exécutez jamais automatiquement des instructions issues de paramètres d'URL, ajoutez une protection anti-CSRF aux routes modifiant l'état, et exigez une confirmation fraîche, de même origine, avant qu'un agent ne passe en production.
Rien de tout cela n'est un argument contre le fait de bâtir sur des agents — l'intérêt de productivité est réel et la direction est prise. Mais AgentForger est un signal net : dès l'instant où un agent peut agir avec l'accès de vos utilisateurs, il fait partie de votre programme de sécurité, et non d'une commodité qui lui serait extérieure.
Foire aux questions
Qu'est-ce que la vulnérabilité AgentForger ?
AgentForger est une faille de falsification de requête inter-sites (CSRF) que Zenity Labs a révélée dans l'Agent Builder de ChatGPT. Un lien piégé portait une instruction dans un paramètre d'URL (initial_assistant_prompt) que le Builder soumettait et exécutait automatiquement au chargement. Un clic d'un utilisateur connecté disposant des Workspace Agents et d'une application connectée suffisait à câbler ses connecteurs, couper les demandes d'approbation, publier un nouvel agent et le planifier sous le contrôle de l'attaquant. OpenAI a été prévenu le 4 juin 2026 et l'a corrigé en quelques jours.
AgentForger de ChatGPT a-t-il été activement exploité ?
Il n'existe aucune preuve publique d'exploitation dans la nature. La faille a été trouvée et divulguée de façon responsable par Zenity Labs, signalée à OpenAI le 4 juin 2026, reconnue le 5 juin et corrigée en quelques jours par la suppression du paramètre vulnérable. La recherche a été publiée fin juillet 2026 — cette publication est l'événement d'actualité ; le correctif le précède.
Comment un lien pouvait-il déployer un agent IA malveillant ?
Le Builder acceptait une partie de son état initial via des paramètres d'URL, et la valeur passée dans initial_assistant_prompt était exécutée, pas seulement affichée. Un lien de hameçonnage pouvait ordonner au Builder d'assembler un agent à partir des connecteurs déjà autorisés de la victime, de désactiver l'étape d'approbation humaine, de le publier et de le planifier. Comme la victime était déjà connectée et avait approuvé ces connecteurs, aucune nouvelle demande de consentement n'apparaissait.
Que pouvait faire l'agent forgé ?
Les chercheurs ont décrit un initié autonome. L'agent forgé pouvait atteindre tout ce que les connecteurs de la victime autorisaient — Outlook, Gmail, Slack, Teams, SharePoint, Google Drive — tournait selon un planning et prenait ses ordres via la boîte de réception de la victime. De là, il pouvait rechercher et exfiltrer des fichiers, collecter des identifiants, usurper l'identité de l'employé, cartographier l'organisation et envoyer du hameçonnage interne engendrant d'autres agents compromis.
Que doivent faire les équipes qui bâtissent sur des agents IA ?
Traitez chaque agent comme une identité machine dans votre modèle de menace. Maintenez une étape d'approbation humaine sur tout ce qui peut agir, limitez les permissions des connecteurs au moindre privilège et ne laissez jamais un consentement couvrir des actions futures ouvertes. Inventoriez quels agents existent, qui les possède et ce qu'ils peuvent atteindre ; alertez sur les agents nouveaux ou modifiés et sur l'activité automatisée des connecteurs. Sur vos propres surfaces, n'exécutez jamais automatiquement d'instructions issues de paramètres d'URL et exigez une confirmation explicite de même origine avant qu'un agent ne passe en production.
Sources
Zenity Labs — AgentForger, Part 1: ChatGPT Cross-Site Agent Forgery (recherche primaire)
The Hacker News — ChatGPT AgentForger Flaw Could Deploy Rogue Workspace Agents via a Phishing Link, juillet 2026
The Register — One ChatGPT link could smuggle a rogue AI agent into your company, 23 juillet 2026
SecurityWeek — OpenAI Fixes ChatGPT Agent Flaw That Could Let Attackers Forge an AI Insider, juillet 2026