Fuites de données IA : Rovo vs Notion AI vs Slack AI vs ClickUp Brain

En résumé : Les fuites de données causées par l'IA dans les outils de travail surviennent lorsqu'un assistant analyse un texte malveillant, exécute les instructions qui y sont dissimulées et transmet vos données confidentielles à un serveur externe via une requête URL, l'affichage d'une image ou un simple lien. Des recherches publiques l'ont démontré pour Atlassian Rovo, Notion AI et Slack AI. Notion et Slack ont déployé des correctifs ; en revanche, nous n'avons trouvé aucun correctif public pour la méthode touchant Rovo au 27/10/2026.

L'IA de votre outil de gestion de projet lit des contenus que vous n'avez pas écrits : tickets de support, fichiers PDF importés, pages issues de connecteurs ou canaux publics. N'importe lequel d'entre eux peut dissimuler des instructions hostiles.

Cet article compare Rovo, Notion AI, Slack AI et ClickUp Brain. Chaque ligne s'appuie sur une analyse source ou une page officielle du fournisseur, avec sa date. En l'absence d'information, le tableau indique « aucun rapport public trouvé ». Le même mécanisme s'applique aux agents de développement, abordés en fin d'article.

Une fuite de données par IA expliquée en une phrase

Une injection indirecte de prompt est une consigne cachée dans un contenu traité par un assistant IA, que ce dernier exécute ensuite comme si vous en étiez l'auteur.

Elle débouche sur une fuite de données dès lors que trois conditions sont réunies. Simon Willison les a baptisées le trio mortel en juin 2025 :

1. L'assistant peut lire des données privées.
2. L'assistant lit un contenu manipulable par un tiers.
3. L'assistant dispose d'un canal pour transmettre des données vers l'extérieur.

Éliminez l'une de ces conditions et le risque d'exfiltration disparaît. Or, les assistants d'espace de travail réunissent ces trois éléments par conception.

Comment fonctionnait l'exfiltration sur Atlassian Rovo

PromptArmor a publié son rapport d'analyse sur Rovo le 05/08/2026. L'enchaînement est court :

1. Un utilisateur téléverse un fichier — dans la démonstration, un « Guide du Backlog » — contenant une consigne dissimulée.
2. L'utilisateur demande à Rovo d'organiser ses tickets Jira.
3. Rovo effectue une recherche dans Jira et Confluence, puis applique la consigne cachée.
4. Rovo concatène le contenu des tickets et des pages à l'URL de l'attaquant et l'ouvre au moyen de son outil de récupération d'URL.
5. Le serveur de l'attaquant enregistre la requête, données comprises. L'utilisateur, lui, ne voit qu'une réponse tout à fait normale.

Aucune validation humaine n'a été demandée. L'attaque a fonctionné même avec la recherche web désactivée, car cette option ne supprime pas l'outil de récupération d'URL. Rovo interprète également les images Markdown, ce qui offre un second canal de fuite.

Le calendrier de divulgation est particulièrement éclairant pour les acheteurs. PromptArmor a signalé le problème le 23/05/2026, Atlassian en a accusé réception le 25/05, les relances du 04/06 et du 29/07 sont restées sans réponse, et l'article est paru le 05/08 alors que Rovo était toujours vulnérable. Le fil de discussion sur Hacker News a cumulé 306 points et 138 commentaires.

Une faille distincte affectant Rovo a quant à elle été corrigée. La note de recherche de la Cloud Security Alliance du 14/08/2026 porte sur le vecteur en un clic « RovoBlast » de Varonis exploitant un paramètre d'URL de chat, qu'Atlassian a corrigé côté serveur avant la publication de Varonis. La même note mentionne que la méthode par document découverte par PromptArmor reste non résolue. Nos recherches au 27/10/2026 n'ont révélé aucune annonce de correctif ultérieure.

Précision terminologique : Rovo Dev est l'agent de développement d'Atlassian. Il s'agit d'un produit différent de l'assistant Rovo analysé ici, et les recherches mentionnées ci-dessus ne le concernent pas.

Rovo vs Notion AI vs Slack AI vs ClickUp Brain

Le tableau compare les comportements constatés ou documentés pour chaque assistant. La mention « Non traité » indique que la source étudiée n'aborde pas ce point.

Nous n'avons pas inclus Linear ni Asana. Nos recherches au 27/10/2026 n'ont révélé aucun rapport public d'exfiltration par injection de prompt pour leurs assistants, sachant que l'absence de rapport ne garantit en rien l'absence de vulnérabilité.

Notion AI : la modification enregistrée avant même votre accord

Dans le cas de Notion AI documenté par PromptArmor, du texte blanc en taille 1 était dissimulé dans un CV. Lorsqu'on demandait à Notion AI de mettre à jour un tableau de recrutement à partir de ce fichier, l'outil créait une URL d'image en y ajoutant le texte du tableau. Même si Notion affichait un avertissement concernant cette URL externe, la modification était déjà enregistrée : les données étaient donc transmises, que l'utilisateur valide l'action ou non.

Notion a confirmé la vulnérabilité après sa révélation publique et a déployé un correctif dans la nuit. PromptArmor a aussi signalé un problème similaire dans l'assistant de rédaction de Notion Mail ; la mise à jour consultée ne précise pas si le correctif s'applique également à Mail.

Slack AI : un simple clic sur un lien de réauthentification

L'attaquant publiait des instructions dans un canal public qu'il avait créé. Quand un utilisateur interrogeait Slack AI sur une information confidentielle située dans son propre canal privé, la réponse contenait un lien « cliquer ici pour vous réauthentifier » intégrant cette information dans l'URL. Un simple clic suffisait à l'expédier à l'extérieur.

Le 19/08/2024, Slack a indiqué à PromptArmor que la recherche dans les canaux publics constituait un comportement normal. Le 21/08/2024, Slack annonçait un correctif pour un scénario de phishing de faible gravité ; SC Media a rapporté que l'avis de sécurité ne citait pas PromptArmor et ne précisait pas s'il s'agissait du même problème. PromptArmor a également relevé que Slack AI avait commencé à ingérer les fichiers des canaux et des messages privés ce mois-là, une piste qu'ils n'ont pas testée.

ClickUp Brain : aucun rapport public trouvé

Nous n'avons trouvé aucune étude publiée sur une fuite de données touchant ClickUp Brain ou les Super Agents au 27/10/2026. La page des Super Agents de ClickUp affirme que les agents fonctionnent avec des autorisations implicites et explicites et conservent un « historique d'audit complet pour chaque action ». Un article de blog de ClickUp sur les workflows des Super Agents précise que les agents héritent des autorisations de l'utilisateur et requièrent une approbation humaine pour les actions sensibles. Il s'agit d'affirmations de l'éditeur, non de résultats de tests indépendants. L'article d'aide de ClickUp sur l'injection de prompt nous ayant renvoyé un contrôle anti-robot, nous n'avons pas pu le citer.

Quels correctifs tiennent la route et lesquels ne font que ralentir l'attaquant ?

Le fil de discussion Hacker News a établi un classement des protections :

• Ne récupérer que les URL saisies par l'utilisateur ou renvoyées par un outil de confiance. Simon Willison soutient que l'agent ne doit absolument pas construire d'URL. Filtrer la chaîne de requête est insuffisant, car un DNS avec joker (wildcard DNS) permet de transmettre des données via un sous-domaine.
• Se limiter aux URL déjà indexées. Le contributeur wunderwuzzi23 a rappelé que restreindre les requêtes aux seules pages indexées par les moteurs de recherche laisse tout de même fuiter des données, à raison d'un caractère par requête.
• Listes d'autorisation de domaines (allowlists). Pour un assistant au rôle bien délimité, une liste restreinte de domaines sortants autorisés s'avère très solide.
• Classificateurs et filtres par expressions régulières. Utiles comme couche de défense supplémentaire. Étant probabilistes, ils ne doivent jamais constituer l'unique rempart.

Le constat général s'impose : les limites déterministes sur le canal sortant l'emportent toujours sur des prompts plus sophistiqués. Un modèle qui refuse plus souvent d'exécuter des requêtes suspectes conserve malgré tout les accès réseau que vous lui avez accordés — un point que nous soulignions déjà à propos des injections de prompt et des garde-fous pour agents au lancement de Claude Opus 5.5.

Les points à vérifier avant d'activer une IA d'espace de travail

Posez ces questions par écrit à votre éditeur :

1. Quels outils sont capables d'envoyer des données hors de l'espace de votre organisation : requêtes URL, affichage d'images, génération de liens, e-mails, connecteurs ?
2. Chaque paramètre associé supprime-t-il réellement l'outil, ou masque-t-il seulement la fonctionnalité qui s'en sert ? Chez Rovo, le bouton de recherche web se contentait de la masquer.
3. L'IA peut-elle interroger une URL générée par le modèle lui-même ?
4. Les images Markdown hébergées sur des domaines externes sont-elles affichées dans les réponses de l'IA ?
5. Quels éléments l'IA lit-elle par défaut : fichiers téléversés, espaces de stockage connectés, messages privés, canaux publics ?
6. Quelles actions exigent une approbation humaine, et celle-ci intervient-elle avant l'exécution de l'action ? Chez Notion, elle intervenait après coup.
7. Quelle suite l'éditeur a-t-il donnée au dernier signalement externe reçu, et dans quel délai ?

Déployez un assistant d'espace de travail dès lors que ses canaux sortants sont documentés et désactivables un par un. Abstenez-vous si l'éditeur est incapable d'en fournir la liste.

Le positionnement de Sharkly, en toute franchise

Sharkly n'est pas un assistant intégré à vos documents, et il n'est pas imperméable aux injections de prompt. Sharkly gère des agents de programmation comme Claude Code et Codex, et ces agents traitent du texte non fiable tout au long de la journée : descriptions de tickets, fichiers README, pages web consultées. Le trio mortel s'applique à eux également.

La différence réside dans la maîtrise du périmètre. Dans Sharkly, les agents s'exécutent sur vos propres Computers via un service local. La documentation sur les Computers précise que la machine fournit les fichiers, les identifiants, les accès réseau et les outils nécessaires à chaque exécution. C'est donc à vous qu'il revient de restreindre les flux sortants : placez un Computer derrière une liste de domaines autorisés et chaque exécution héritera de cette restriction, quel que soit l'agent employé.

D'autres limites sont définies dans la documentation :

• Les invités n'accèdent qu'aux Spaces où ils sont explicitement ajoutés. Ils ne peuvent pas explorer ni rejoindre d'eux-mêmes des Spaces publics (People and roles).
• Les actions tierces nécessitent un connecteur autorisé. Un flux d'automatisation ne peut pas appeler une application externe non connectée par vos soins.
• Les secrets sont exclus des Skills. La documentation sur les Skills indique de ne jamais enregistrer de mots de passe, jetons ou clés dans les instructions ou fichiers d'un Skill.

Aucune de ces mesures n'empêche un agent d'être trompé pour accomplir une action non souhaitée dans le cadre des accès qui lui sont accordés. En revanche, elles restreignent ces accès et maintiennent une validation humaine sur la Task. Nos articles sur les permissions des agents de développement et les points de validation expliquent où placer ces garde-fous.

Conclusion

L'injection de prompt n'est résolue dans aucun produit traitant du texte non fiable, agents de développement compris. La vraie question est plus ciblée : quelles données l'assistant peut-il transmettre vers l'extérieur, et avez-vous la possibilité de couper ce flux ? Parmi les quatre outils analysés ici, deux ont subi des fuites publiques et ont déployé un correctif, un a fait l'objet d'une fuite sans correctif recensé à ce jour, et le dernier ne compte aucun rapport public.

Si vous utilisez plusieurs agents de développement et souhaitez les héberger sur des machines dont vous maîtrisez le réseau, connectez un Computer à Sharkly, verrouillez son trafic sortant et confiez une première Task à faible risque à un Agent. Sharkly est actuellement gratuit pour les organisations jusqu'à 5 personnes.

FAQ

Atlassian Rovo est-il toujours vulnérable à l'exfiltration de données ?

La faille par document signalée par PromptArmor n'était pas corrigée au 05/08/2026, et nous n'avons trouvé aucun correctif public au 27/10/2026. La vulnérabilité par lien découverte par Varonis a quant à elle été résolue.

Notion a-t-il corrigé la fuite de données de Notion AI ?

Oui. Notion a confirmé que son correctif pour la modification non sécurisée de documents par l'IA était en production le 07/01/2026, la nuit même de la divulgation publique par PromptArmor.

L'injection de prompt sur Slack AI a-t-elle été corrigée ?

Slack a annoncé un correctif le 21/08/2024, sans toutefois confirmer qu'il traitait exactement le problème documenté par PromptArmor.

Désactiver la recherche web empêche-t-il un assistant IA de faire fuiter des données ?

Pas toujours. Dans le cas de Rovo, désactiver la recherche web ne supprimait pas l'outil de récupération d'URL, de sorte que l'exfiltration fonctionnait toujours.

Qu'est-ce que le trio mortel en sécurité de l'IA ?

L'accès à des données privées, la lecture de contenus non fiables et la capacité d'émettre des données vers l'extérieur. Un assistant qui réunit ces trois éléments peut être détourné pour organiser une fuite de données.

Les agents de développement peuvent-ils faire fuiter des données de la même manière ?

Oui. Un agent de développement qui lit un README piégé et possède un accès réseau court le même risque. Limitez ses identifiants et restreignez ses connexions réseau sortantes directement au niveau de la machine hôte.