ChatGPT AgentForger : un lien crée un agent rogue

Qu'est-ce qu'AgentForger ?

C'est le nom donné par Zenity Labs à une faille critique des ChatGPT Workspace Agents d'OpenAI. D'après The Hacker News, qui la classe comme une falsification de requête inter-sites (CSRF), l'Agent Builder acceptait un état initial transmis par les paramètres de l'URL, notamment un modèle d'agent et un prompt. Le prompt injecté était soumis et exécuté automatiquement au chargement de la page : une instruction placée dans une URL devenait la première commande de l'agent.

Zenity résume l'attaque en une phrase : un seul lien pouvait « détourner l'Agent Builder de ChatGPT » pour créer un agent contrôlé par l'attaquant.

Quelles conditions la victime devait-elle remplir ?

Trois conditions, d'après l'article : être connectée à ChatGPT, avoir accès aux Workspace Agents, et disposer d'au moins un connecteur autorisé, comme Outlook, Gmail, Google Calendar, Google Drive, Slack ou Teams. L'attaquant envoie un lien d'hameçonnage ; l'ouverture du lien suffit, sans autre interaction.

Que pouvait faire l'agent forgé ?

Selon Zenity, tel que rapporté par The Hacker News, l'agent pouvait :

• rattacher tous les connecteurs existants et les configurer pour s'exécuter sans approbation ;
• s'exécuter toutes les heures, ce qui sert de mécanisme de persistance ;
• chercher les e-mails d'une adresse de l'attaquant dont l'objet commence par « TASK », exécuter les tâches demandées et renvoyer les résultats ;
• faire de la reconnaissance, récolter des documents sensibles dans le stockage cloud et extraire des mots de passe partagés dans Slack ;
• se faire passer pour la victime sur Teams afin d'envoyer des liens d'hameçonnage, ce qui ouvre la voie au vol d'identifiants et à la compromission de messagerie professionnelle.

Mike Takahashi, de Zenity, parle d'un « échec de confiance de l'agent » : la plateforme supposait que l'utilisateur avait intentionnellement créé et approuvé l'agent.

Pourquoi l'impact dépasse-t-il celui d'un CSRF classique ?

Un CSRF traditionnel force une action ponctuelle. Ici, il crée un travailleur autonome qui agit dans la durée avec l'identité de la victime. Trois propriétés expliquent la gravité.

1. Persistance : l'agent continue de s'exécuter une fois la page d'hameçonnage fermée, et l'attaquant n'a pas à maintenir de session.
2. Confiance héritée : l'agent agit sous l'identité de l'employé, donc les systèmes en aval voient une activité légitime.
3. Approbations coupées : désactiver les validations humaines rend l'action silencieuse.

Quel est l'état du correctif ?

OpenAI a traité le problème au 8 juin 2026, à la suite d'une divulgation responsable de Zenity. L'entreprise a par ailleurs annoncé que l'Agent Builder sera retiré à compter du 30 novembre 2026 au profit du Agents SDK et des Workspace Agents. Si vous étiez une cible possible, relisez les agents créés autour de cette période.

Que peuvent faire les administrateurs d'une organisation qui utilise ces agents ?

Même après correction, quelques mesures réduisent l'exposition à ce type de scénario, que le produit soit celui d'OpenAI ou un autre.

• Inventorier les agents existants : qui les a créés, quand, avec quels connecteurs, avec ou sans approbation, et quelle planification.
• Limiter les connecteurs autorisés : ne laissez connectables que les services dont l'agent a réellement besoin, en lecture seule quand c'est possible.
• Exiger l'approbation humaine pour l'envoi de messages, le partage de documents et toute écriture, et empêcher les utilisateurs de la désactiver.
• Surveiller les créations d'agents et les e-mails ou messages automatiques qui sortent de l'organisation, en particulier ceux dont l'objet suit un motif répété.
• Sensibiliser : un lien vers un outil d'IA reste un lien. Les messages qui invitent à cliquer pour « configurer » ou « activer » un assistant sont à traiter comme de l'hameçonnage.
• Réviser régulièrement les accès accordés aux agents et révoquer ce qui n'est plus utilisé.

Ces points s'appliquent à tout assistant connecté à la messagerie, au stockage de documents et aux outils d'équipe.

Que faire si vous développez une fonction d'agent ?

La faille est un cas d'école de conception, applicable à tout produit qui permet de créer des agents depuis une interface web.

1. Aucune action à effet par simple chargement d'URL. Les paramètres d'URL peuvent pré-remplir un formulaire, jamais le soumettre ni l'exécuter sans geste explicite de l'utilisateur.
2. Protection CSRF sur chaque requête qui modifie un état : jetons anti-CSRF et cookies SameSite stricts, pas seulement des contrôles d'origine.
3. Séparer « créer » et « autoriser ». Construire un agent et lui accorder l'accès aux données de production sont deux actions distinctes, chacune demandant un consentement explicite.
4. Approbations imposées côté serveur pour les outils à haut risque (envoi externe, facturation, suppression). Le créateur de l'agent ne doit pas pouvoir les désactiver depuis l'interface.
5. Inventaire et détection : listez chaque agent actif dans l'organisation, son créateur, ses connecteurs et sa planification, et alertez sur les agents créés hors des schémas habituels (heure, source, absence d'interaction).
6. Avertissement visible : affichez ce qu'un agent peut faire avant de l'activer, avec la liste des connecteurs et des droits.

Comment tester un produit qui crée des agents ?

Avec un compte de test et une autorisation, essayez de provoquer la création d'un agent sans geste de l'utilisateur.

1. Paramètres d'URL : identifiez ceux qui préremplissent l'état de l'assistant (modèle, prompt, connecteurs). Un prompt présent dans l'URL est-il exécuté au chargement ?
2. Protection CSRF : forgez, depuis un autre domaine, une requête de création, d'autorisation et de désactivation d'approbation. Chaque requête doit échouer sans jeton valide.
3. Consentement séparé : vérifiez qu'un connecteur ne peut pas être rattaché à un nouvel agent sans consentement explicite.
4. Approbations : vérifiez qu'une action risquée exige toujours une validation, quel que soit le réglage de l'agent.
5. Planification : un agent peut-il se programmer seul pour s'exécuter à intervalle régulier ? Où l'utilisateur le voit-il ?
6. Détection : la création d'un agent génère-t-elle un message à l'utilisateur et une trace pour l'administrateur ?

La page red team d'agents IA et la page sécurité des agents IA décrivent cette approche.

Que retenir ?

Dès qu'un produit permet de créer des travailleurs autonomes qui agissent au nom des utilisateurs, chaque vieille vulnérabilité web (CSRF, IDOR, XSS, SSRF) voit son impact multiplié. La défense consiste à appliquer des contrôles anciens avec le sérieux que demande la nouvelle surface. Le Red Team Agent Express de CleanIssue (1 900 €, 5 jours) teste la création, l'autorisation et les droits des agents de votre produit : voir l'offre. Le rendez-vous découverte, 30 minutes et gratuit, sert à examiner quels liens un utilisateur peut cliquer pour créer un agent à son insu.

Pour aller plus loin

• sessions d'agent volées par infostealers