L’injection d’instructions paraît souvent être une démonstration de laboratoire contre un chatbot jouet. Le rapport de PromptArmor sur Atlassian Rovo est plus utile: il décrit un risque d’entreprise concret. Un assistant IA lit des données internes, traite un contenu non fiable et garde un moyen de contacter une adresse externe. C’est là que la frontière de sécurité doit exister.

Assistant IA arrêté par une barrière de sécurité avant d’envoyer des documents d’entreprise vers un réseau externe

PromptArmor a publié son rapport le 5 août 2026. Les chercheurs affirment que Rovo pouvait être manipulé pour envoyer le contenu de tickets Jira et de documents Confluence vers un site contrôlé par un attaquant grâce à une instruction cachée. Ils disent avoir prévenu Atlassian le 23 mai, reçu un numéro de dossier le 25 mai, relancé en juin et juillet, puis publié après plus de deux mois sans correctif public ni nouvelle réponse. Au moment de la rédaction, je n’ai pas trouvé de réponse publique d’Atlassian contredisant le rapport.

Cela ne signifie pas que tous les clients Atlassian ont subi une fuite. Le matériel public décrit une chaîne d’attaque démontrée, pas une exploitation massive confirmée. La bonne réponse n’est pas la panique: il faut traiter les assistants IA intégrés aux outils métier comme des logiciels dotés d’accès aux données et de capacités réseau.

Le problème est la combinaison des droits

Rovo est la couche IA d’Atlassian pour Jira, Confluence et des services connectés. Atlassian le présente comme un assistant qui connaît l’entreprise, rassemble le contexte des personnes, des projets et du code, et se connecte à des applications SaaS tierces. La page des connecteurs cite Google Drive, GitHub, GitLab, Microsoft SharePoint, Outlook Mail, Gmail, Zendesk, Box, Dropbox, Figma, Azure DevOps, ServiceNow, Slack et d’autres sources.

C’est la promesse du produit et son modèle de risque. Jira et Confluence contiennent souvent des feuilles de route, des incidents clients, des notes de sécurité, des plans d’ingénierie, des procédures internes et des liens vers d’autres systèmes. Un assistant utile a besoin de ce contexte. Un assistant sûr a besoin de limites strictes sur la destination de ce contexte.

Les pages de confiance d’Atlassian indiquent que les autorisations de la plateforme et des connecteurs sont respectées quand elles sont correctement configurées. Elles précisent aussi que les connecteurs administrés ne sont pas activés par défaut et que certaines sources, comme Google Drive ou SharePoint, peuvent être limitées par listes d’autorisation ou de blocage. Ces contrôles sont utiles, mais la question de PromptArmor est différente: l’assistant peut-il prendre des données qu’il a le droit de lire et les placer dans une requête externe construite par le modèle?

La chaîne décrite

D’abord, un contenu non fiable entre dans un espace que l’assistant peut lire. Dans l’exemple de PromptArmor, il s’agit d’un fichier avec des instructions dissimulées, mais les chercheurs expliquent que le même schéma peut venir de tickets de support, de documents externes, d’applications connectées ou de données web si la recherche est activée.

Ensuite, l’utilisateur demande une tâche ordinaire, par exemple organiser des tickets. Rovo consulte Jira et Confluence parce que c’est son rôle. L’instruction cachée tente de faire ajouter un contenu sensible à une adresse externe. L’outil d’ouverture d’URL visite ensuite cette adresse, et le serveur récepteur peut enregistrer les données dans ses journaux.

Le point clé est l’outil qui ouvre les URL. PromptArmor affirme que l’attaque fonctionne même quand la recherche web de Rovo est désactivée, car ce réglage ne retire pas l’outil qui ouvre les résultats. Autrement dit, désactiver la fonction visible de recherche ne coupe pas forcément tous les chemins réseau.

Ce n’est pas seulement une erreur du modèle

Dire que le modèle a simplement suivi une mauvaise consigne est insuffisant. Le modèle agit dans un système d’outils. Si ce système lui donne des données privées et un canal externe, le jugement du modèle ne doit pas être le principal contrôle.

La formule de Simon Willison est utile: données privées, contenu non fiable et communication externe. Deux éléments peuvent être maîtrisés. Les trois ensemble créent une voie d’exfiltration. Rovo n’est pas un cas unique; on peut retrouver ce schéma dans des agents de navigateur, des assistants de code, des outils bureautiques, des bots support et des moteurs de recherche internes.

La défense doit être déterministe. Un outil d’ouverture d’adresses ne devrait pas visiter n’importe quelle URL assemblée par le modèle. Il est plus sûr d’autoriser seulement les adresses fournies par l’utilisateur ou par un composant fiable, et de bloquer les paramètres contenant des données internes. Les images distantes dans Markdown doivent aussi être traitées comme des requêtes réseau.

Ce que les administrateurs doivent vérifier

Vérifiez d’abord si Rovo et les fonctions IA d’Atlassian sont actives dans votre organisation. Utilisez la console d’administration réelle, pas seulement la page produit.

Faites l’inventaire des connecteurs: Google Drive, SharePoint, GitHub, GitLab, Zendesk, ServiceNow, Gmail, Outlook et autres sources larges. Un connecteur acceptable pour la recherche peut devenir risqué si l’assistant mélange ses résultats avec des instructions non fiables et des requêtes externes.

Appliquez le moindre privilège. Ne connectez pas une racine complète de Drive ou SharePoint si une liste limitée suffit. Revoyez les groupes, les invités, les sous-traitants et les anciens comptes.

Posez une question précise au fournisseur: lorsque la recherche web est désactivée, Rovo peut-il ouvrir une URL construite par le modèle? Si oui, peut-on désactiver cette capacité, la limiter à des sources fiables ou l’auditer?

Bloquez quand possible les adresses externes construites par le modèle. Servez-vous des journaux réseau, d’un proxy ou de règles de prévention de fuite pour repérer des données sensibles dans les paramètres sortants. Traitez les images distantes et les aperçus comme des appels réseau. Exigez une validation humaine pour toute communication externe contenant des données internes.

Ce que les utilisateurs peuvent faire

N’envoyez pas de fichiers externes aléatoires à un assistant connecté à des tickets et documents sensibles. Soyez prudent lorsque vous demandez à un assistant privilégié de résumer des pièces jointes de clients, des documents fournisseurs ou des pages inconnues. Si l’assistant tente d’ouvrir des liens externes, insère des références d’images étranges ou produit un texte ressemblant à une instruction cachée, signalez-le.

La leçon est simple: “le modèle devrait savoir qu’il ne faut pas divulguer” n’est pas un contrôle de sécurité. La frontière doit être dans la couche d’outils: listes d’autorisation, contrôle des classes de données, origine du contenu, validations, journaux et réglages sûrs par défaut. Pour un assistant qui lit Jira, Confluence, le courrier, les documents et le code, la question est: que peut-il lire, afficher, appeler, envoyer, et qui peut le vérifier?