Sécurité des agents IA : la faille CSRF AgentForger

En juin 2026, les chercheurs de Zenity Labs ont trouvé un moyen de forger un agent IA entier à partir d'une seule URL malveillante, à l'intérieur du périmètre de confiance d'une organisation. La faille, baptisée AgentForger, ne forge pas une simple requête : elle forge un agent autonome contrôlé par l'attaquant.

Réponse directe : AgentForger est une attaque par Cross-Site Request Forgery (CSRF) exploitant le builder d'agents ChatGPT Workspace Agents. Une victime connectée qui clique sur un lien malveillant déclenche la création, sans interaction supplémentaire, d'un agent IA qui se connecte à ses comptes déjà autorisés (Outlook, Gmail, Slack), désactive les contrôles d'approbation et s'exécute en continu via un planning. Pour les entreprises traitant des données personnelles, c'est un rappel brutal des risques de sécurité posés par les agents IA.

Qu'est-ce qu'AgentForger ?

AgentForger est une attaque par Cross-Site Request Forgery (CSRF) découverte par Zenity Labs dans le builder d'agents de ChatGPT (Workspace Agents). Une URL malveillante pré-remplit et exécute automatiquement une instruction qui crée un agent autonome contrôlé par l'attaquant, désactive les garde-fous d'approbation et lui donne accès aux comptes déjà connectés de la victime, à l'intérieur du périmètre de confiance de l'organisation. OpenAI a corrigé la faille quatre jours après sa divulgation.

Comment fonctionne le builder Workspace Agents en temps normal ?

Les agents Workspace d'OpenAI se connectent à Outlook, Gmail, Slack, Google Drive, SharePoint et Teams, peuvent exécuter des actions sur ces services et tourner selon un planning. Ils se construisent via un builder conversationnel : l'utilisateur décrit son agent en langage naturel, choisit un modèle de départ, configure les outils, décide quelles actions exigent une approbation, teste en mode Preview puis publie.

Dans cette séquence, plusieurs moments supposent un contrôle humain : choisir le modèle, fournir les instructions, approuver les outils connectés, relire les réglages d'approbation et décider de la mise en production. C'est précisément ce contrôle que la faille AgentForger neutralise.

Comment l'attaque forge-t-elle l'agent ?

Le builder est accessible à l'adresse chatgpt.com/agents/studio/new. Les chercheurs ont constaté qu'il accepte un état d'initialisation par paramètres d'URL. Deux paramètres importent :

• template_name : sélectionne un modèle d'agent préconstruit, comme chief-of-staff.
• initial_assistant_prompt : contient les instructions données au builder. Au chargement de la page, cette valeur n'est pas seulement placée dans la zone de prompt : elle est automatiquement soumise et exécutée.

L'instruction embarquée dans l'URL devient donc la première commande que le builder exécute. L'attaquant n'a besoin d'aucune interaction avec le navigateur de la victime : il envoie un lien classique, de type phishing :

https://chatgpt.com/agents/studio/new?template_name=chief-of-staff&initial_assistant_prompt=[instruction de l'attaquant]

Quand une victime connectée clique, ChatGPT ouvre le builder dans sa session authentifiée et soumet automatiquement le prompt contenu dans l'URL.

Quelles sont les conditions de l'attaque ?

L'attaque requiert une victime connectée à ChatGPT, disposant d'un accès aux Workspace Agents et ayant déjà autorisé au moins un connecteur. Ce point est central : le connecteur étant déjà autorisé, l'attaque ne déclenche aucune nouvelle demande de consentement OAuth. Aucun écran de consentement ne s'affiche, ce qui rend le déroulement invisible pour l'utilisateur.

Quelle est la charge utile du payload ?

Dans sa preuve de concept, Zenity Labs a structuré une instruction qui parcourt la création complète : connecter tous les connecteurs déjà autorisés, exclure les MCP personnalisés, basculer chaque connecteur en mode "ne jamais demander" (aucune approbation en lecture comme en écriture), créer plusieurs plannings décalés de cinq minutes, puis traiter à chaque exécution les emails entrants et renvoyer les résultats à une boîte contrôlée par l'attaquant.

Concrètement, le builder a :

• Créé un agent nommé "TASK Mail Operator" à partir du modèle chief-of-staff.
• Attaché les connecteurs existants, notamment Outlook et les modèles par défaut (Gmail, Calendriers, Slack, Teams), sans nouvel écran de consentement.
• Désactivé la barrière d'approbation : les écritures passent par défaut en "toujours demander", mais l'instruction force Outlook en "ne jamais demander".
• Publié l'agent en production, avec plusieurs plannings horaires décalés créant un point de contact toutes les cinq minutes.
• Lancé le mode Preview pour exécution immédiate.

Le mode Preview, censé permettre un test avant publication, exécute ici réellement l'agent sur les comptes connectés de la victime, avec les réglages d'approbation fraîchement configurés. Comme le prompt a déjà basculé Outlook en "ne jamais demander", l'exécution ne déclenche aucune confirmation.

Comment l'attaquant garde-t-il le contrôle ?

Le planning des Workspace Agents, utile en temps normal pour automatiser une tâche récurrente, devient ici le mécanisme de persistance. Une fois l'agent publié, l'attaquant n'a plus besoin d'un nouveau clic ni d'une nouvelle visite : l'agent se réveille selon le planning, lit la boîte de la victime pour trouver les instructions qu'il doit exécuter, agit sur les services connectés et renvoie les résultats.

L'ellipse devient un opérateur persistant : le clic initial installe l'agent, le planning le maintient en vie, et les comptes connectés fournissent à la fois la source de commandes, l'accès aux données sensibles et la voie de rapatriement des résultats.

Quelles sont les causes racines ?

Les chercheurs identifient deux comportements qui se combinent :

1. Exécution automatique inter-sites, sans protection CSRF : le builder traite le paramètre initial_assistant_prompt comme une entrée exécutable, non comme du contenu à confirmer. Une URL contrôlée par l'attaquant déclenche donc des opérations modifiant l'état dans la session authentifiée de la victime, sans intention explicite de sa part.

2. Configuration sensible exposée au langage naturel : le même prompt peut modifier des paramètres de sécurité, notamment les politiques d'approbation et les plannings. Le mécanisme censé exiger une approbation humaine pour les actions sensibles peut être désactivé par l'instruction elle-même.

Ensemble, ils réunissent la "triade létale" : une entrée non fiable (l'URL), un accès à des données privées (les connecteurs) et un moyen d'exfiltration (l'envoi d'emails). Là où la plupart des exploits doivent contourner des garde-fous, celui-ci se voit fournir un outil de construction et l'ordre de construire un agent avec les garde-fous déjà éteints.

Selon Zenity Labs, la seconde partie de cette recherche décrit le rayon de blast de l'agent après sa mise en production : reconnaissance de l'organisation, extraction de données sensibles, récupération d'identifiants, impersonation de la victime, phishing interne et préparation d'une compromission d'email professionnel (business email compromise).

Quels risques pour la protection des données (RGPD) ?

Même si la faille est corrigée, elle illustre des risques que les entreprises doivent intégrer au déploiement de tout agent IA. Un agent qui accède à des comptes personnels sans validation suffit-il à rester conforme au RGPD ?

Plusieurs articles s'appliquent directement :

Sécurité du traitement (Article 32 du RGPD) : le responsable de traitement doit mettre en oeuvre des mesures techniques et organisationnelles appropriées pour assurer un niveau de sécurité adapté au risque. Une chaîne d'exploitation qui expose des données personnelles à un opérateur non identifié est l'échec type de cette exigence.

Intégrité et confidentialité (Article 5(1)(f)) : les données doivent être traitées de façon à garantir une protection appropriée contre l'accès ou l'utilisation non autorisés. Rappel utile de la CNIL : la sécurité des données est l'un des principes fondateurs du règlement.

Protection des données dès la conception (Article 25) : l'approche par minimisation des réglages d'approbation, l'impossibilité de désactiver les contrôles par une simple instruction et la limitation des connecteurs exposés relèvent de la protection des données dès la conception et par défaut.

Transferts hors UE (Article 44) : un agent qui traite des données personnelles via un modèle hébergé aux États-Unis effectue un transfert international soumis aux exigences de l'article 44. Le cadre reste aggravé par le Cloud Act (2018), qui permet aux autorités américaines d'exiger l'accès aux données détenues par des entreprises US, même sur infrastructure européenne.

Comment sécuriser ses agents IA en entreprise ?

Le cas AgentForger pousse à des réflexes concrets, à appliquer quel que soit le fournisseur d'agents :

• Limiter la surface des connecteurs : n'exposer que les outils strictement nécessaires à la tâche, jamais tous les comptes personnels.
• Ne jamais laisser un prompt désactiver les contrôles d'approbation : toute modification de la politique d'approbation doit passer par un canal humain.
• Auditer les agents publiés et les plannings : détecter les agents inconnus, les connecteurs attachés et les horaires de traitement inhabituels.
• Tracer chaque action de l'agent (Article 5(2)) pour pouvoir démontrer la conformité en cas d'incident.
• Privilégier des accès limités et des sessions qui expirent, comme je le détaille dans mon article sur la gouvernance des agents IA.
• Pour les données sensibles, préférer une infrastructure européenne : le sujet rejoint la discussion sur les fuites de données des agents RAG.

En tant que freelance IA spécialisé dans l'intégration d'IA et la conformité RGPD, je recommande de traiter ces points avant tout passage en production. Le cadre d'audit et les pratiques de permissions font partie de mes prestations d'intégration d'agents IA. L'enjeu n'est pas l'alarme : la faille prouve seulement que la sécurité des agents IA n'est pas acquise par défaut et doit être construite.

TL;DR

AgentForger est une CSRF qui ne forge aucun agent mauvais : une URL malveillante pré-remplit le builder de ChatGPT Workspace Agents, exécute une instruction qui crée un agent autonome contrôlé par l'attaquant, retire les contrôles d'approbation et use de son planning pour exécuter des commandes en continu. OpenAI a corrigé la faille en quatre jours. Pour les entreprises, l'incident illustre des obligations de sécurité déjà prévues par le RGPD (Article 32, Article 25) et plaide pour des agents aux permissions minimales, audités et si possible hébergés en Europe.

Vous évaluez la sécurité de vos agents IA ou préparez un déploiement en conformité RGPD ? Parlons-en.