Exfiltration côté serveur via les agents de recherche approfondie

De quoi s’agit-il ?

L’exfiltration côté serveur est une classe d’injection de prompt indirecte où un agent connecté fait fuiter vos données depuis le cloud du fournisseur plutôt que depuis votre navigateur. Le cas de référence est ShadowLeak, divulgué par Radware le 18 septembre 2025 (signalé à OpenAI le 18 juin 2025, corrigé début août 2025). Radware a montré qu’un seul e-mail piégé, traité par l’agent Deep Research de ChatGPT connecté à Gmail, pouvait amener l’agent à lire le contenu sensible de la boîte de réception et à l’envoyer vers une URL contrôlée par l’attaquant — sans clic, sans interface visible et sans approbation de l’utilisateur.

Ce qui distingue cette classe, c’est l’endroit où la fuite se produit. Les travaux antérieurs — EchoLeak (Aim Security) et AgentFlayer (Zenity) — reposaient sur un rendu côté client : l’exfiltration se déclenchait quand le navigateur de l’utilisateur chargeait une image contrôlée par l’attaquant. ShadowLeak déplace la fuite dans le backend d’OpenAI : c’est l’outil de navigation de l’agent qui émet directement la requête sortante.

Comment ça fonctionne

L’attaque exploite la triade létale — données privées, contenu non fiable et canal sortant — toutes présentes dans un même agent connecté. Le contenu non fiable est un e-mail d’apparence anodine dont les instructions sont dissimulées dans le HTML (polices minuscules, texte blanc sur blanc, astuces de mise en page) : l’humain ne les voit jamais, mais l’agent les lit et les exécute lorsqu’il traite la boîte de réception.

Radware rapporte que les instructions directes du type « envoie ces données vers mon URL » étaient refusées de manière fiable ; l’approche efficace est passée de la persuasion du modèle à l’abus de la couche d’exécution des outils. Les techniques de contournement signalées sont comportementales, pas un exploit de code : fausse affirmation d’autorisation, déguisement du point de collecte en service de « conformité », instruction de réessayer pour vaincre des contrôles de sûreté non déterministes, et consigne d’encoder en Base64 les champs volés avant de les ajouter à l’URL — afin que la couche d’exécution ne voie qu’une chaîne opaque au lieu des données brutes. (Nous omettons le payload verbatim ; ce qui compte est le motif, pas une recette réutilisable.)

Document non fiable (e-mail/fichier/issue/invitation)
   → instructions cachées dans le HTML/les métadonnées   [REDACTED]
   → l'outil de navigation de l'agent émet la requête depuis le cloud du fournisseur
   → les données encodées partent via une URL attaquant  ← aucun rendu client, aucune trace sur votre réseau

Pourquoi c’est important

Les fuites côté serveur sont plus difficiles à voir et à arrêter que celles côté client. L’exfiltration part de l’intérieur du réseau du fournisseur : une passerelle web sécurisée, un agent endpoint ou une politique de navigateur de votre côté ne voit jamais la requête. Rien n’est rendu, donc l’utilisateur n’a aucun indice visuel. Et là où les fuites d’images côté client sont souvent restreintes à une liste blanche de domaines (le mécanisme url_safe d’OpenAI), Radware n’a observé aucune restriction comparable sur les URL que l’agent pouvait atteindre directement — un éventail bien plus large de points d’exfiltration.

La leçon plus large est la généralité : tout connecteur qui alimente un agent en texte est un vecteur d’injection. Radware note que le même schéma s’étend à Drive, SharePoint, aux invitations Outlook et Google Agenda, aux messages Teams, aux README et issues GitHub, aux enregistrements Notion et Linear. L’agent devient un proxy de confiance qui fait sortir les données sous couvert d’un usage normal des outils.

Défenses

L’assainissement du contenu avant ingestion aide mais ne suffit pas : normalisez et retirez le CSS invisible, les caractères obscurcis et le HTML suspect des documents avant que l’agent ne les lise. Cela n’arrêtera pas une instruction bien conçue qui survit à la normalisation.

Les mitigations durables s’attaquent à la troisième jambe de la triade et au comportement de l’agent :

• Couper le canal sortant. Le 4 juin 2026, OpenAI a étendu le Lockdown Mode aux comptes ChatGPT personnels et Business en libre-service (introduit le 13 février 2026). Il désactive de manière déterministe Deep Research, le mode Agent, la navigation web en direct (cache uniquement), la récupération d’images web, le réseau de Canvas, les connecteurs en direct et les téléchargements de fichiers — précisément pour supprimer les chemins qu’une injection réussie utilise pour exfiltrer. Voir notre note sur le Lockdown Mode d’OpenAI.
• Liste blanche de sortie. Limitez les domaines que la couche de navigation/outils d’un agent peut atteindre à un petit ensemble approuvé, et traitez tout outil de fetch direct comme à haut risque.
• Surveillance d’intention. Le contrôle recommandé par Radware est une surveillance comportementale continue : comparer les actions et l’intention inférée de l’agent à l’objectif initial de l’utilisateur, et bloquer les écarts en temps réel.
• Hygiène des connecteurs. Accordez les portées les plus étroites, isolez les connecteurs sensibles et journalisez les lectures de connecteurs afin qu’une tentative d’exfiltration laisse une trace que vous contrôlez.

C’est le versant offensif d’une défense déjà couverte ; les deux se complètent directement avec le cadre de la triade létale.

Statut

Élément	État	Date
ShadowLeak (ChatGPT Deep Research, Gmail)	Corrigé par OpenAI	Début août 2025
Classe d’exfiltration côté serveur	En cours, tous connecteurs	2025–2026
Lockdown Mode OpenAI (coupe le canal sortant)	Déployé personnel/Business	4 juin 2026
Fuites côté client (EchoLeak, AgentFlayer)	Antérieures, corrigées	2025

L’exfiltration côté serveur n’est pas un bug unique à corriger une fois ; c’est une propriété structurelle des agents connectés et autonomes. Tant que la surveillance au niveau de l’intention et le contrôle strict des sorties ne seront pas standard, la posture la plus sûre pour les données sensibles est de priver l’agent d’un canal sortant dont il n’a pas strictement besoin.