Memory Heist : la mémoire de Claude piégée pour exfiltrer vos secrets

Un chercheur en sécurité vient de démontrer qu'il est possible de faire fuiter, sans la moindre alerte visible dans la conversation, le nom complet, l'employeur et les réponses aux questions de sécurité d'un utilisateur de Claude, l'assistant IA d'Anthropic. L'attaque, baptisée « Memory Heist » par son auteur Ayush Paul, ne repose sur aucune faille de code exotique : elle détourne deux fonctionnalités parfaitement légitimes, la mémoire persistante de Claude et sa capacité à naviguer sur le web.

Le résultat mérite l'attention de toute entreprise qui commence à connecter des agents IA à des données sensibles : la démonstration montre comment un simple site web, visité par l'agent pour rendre service, peut devenir un canal de sortie invisible.

Comment fonctionne la mémoire de Claude

Claude.ai, la version grand public de l'assistant (à distinguer de Claude Code), s'appuie sur une mémoire en deux temps. D'un côté, une synthèse quotidienne : les conversations récentes sont résumées en quelques paragraphes, injectés automatiquement au début de chaque nouvelle discussion pour que l'assistant n'ait pas à repartir de zéro. De l'autre, un outil de recherche, conversation_search, qui permet à Claude d'interroger à la demande l'intégralité de l'historique de conversations de l'utilisateur.

Pris isolément, ce système de mémoire n'a rien de dangereux : les données restent dans le compte de l'utilisateur. Le problème apparaît dès qu'on associe cette mémoire à un agent capable d'aller chercher de l'information sur le web.

Le vecteur d'exfiltration : détourner web_fetch

Claude dispose de deux outils de navigation : web_search et web_fetch. Le second, censé être strictement en lecture seule, permet à l'assistant de consulter le contenu d'une URL. Ayush Paul a d'abord tenté l'approche la plus naïve : demander à Claude de charger une URL contenant directement une donnée sensible dans le chemin, par exemple evil.com suivi du nom de l'utilisateur. Anthropic avait anticipé ce cas de figure, la requête échoue.

En creusant, le chercheur a découvert que web_fetch n'accepte une URL que dans trois cas précis : si elle est mentionnée explicitement par l'utilisateur, si elle provient d'un résultat de web_search, ou si elle apparaît comme un lien dans le contenu d'une page déjà récupérée par un précédent web_fetch. C'est ce troisième cas qui ouvre la brèche : si l'attaquant contrôle le site consulté, il contrôle aussi les liens que Claude peut ensuite suivre.

L'exploitation devient alors presque enfantine. Le chercheur a construit un site dont la page d'accueil pointe vers des pages /a, /b, /c, et ainsi de suite jusqu'à /z, puis a fait en sorte que chacune de ces pages pointe à son tour vers ses propres sous-pages (/aa, /ab, /ac...), générées à la volée. En demandant à Claude de naviguer dans cette structure alphabétique pour épeler un nom, l'assistant a effectivement cliqué de lien en lien, lettre après lettre, jusqu'à faire apparaître ce nom en clair dans les journaux du serveur de l'attaquant.

Restait un obstacle : convaincre Claude de jouer le jeu sans éveiller ses soupçons. Un site qui exigerait explicitement d'ignorer les instructions précédentes se ferait repérer immédiatement. Le chercheur a donc habillé son piège en site vitrine crédible, un café en apparence, protégé par une fausse page de type « Cloudflare Bot Protection ». Le scénario expliquait à l'agent qu'il devait s'authentifier en épelant le prénom et le nom de son utilisateur, lettre par lettre, à travers l'arborescence du site, à cause de prétendues limitations de son propre outil de navigation. Une mise en scène qui exploite la confiance que les agents accordent à des marques omniprésentes comme Cloudflare, perçues comme protectrices plutôt que menaçantes.

Ce que ça change pour une entreprise qui déploie des agents IA

Ce que démontre Ayush Paul dépasse largement le cas de Claude. Le mécanisme est générique : dès qu'un agent IA combine une mémoire de contexte riche, informations personnelles, secrets professionnels, historique de conversations, avec une capacité à naviguer sur un contenu externe non maîtrisé, un site tiers peut transformer cette navigation en canal d'exfiltration, lettre par lettre, sans jamais passer par une commande visible ou un fichier suspect.

Pour une PME qui commence à connecter des agents IA à ses outils internes, sa base de connaissances ou son CRM, la leçon est directe. Le risque ne vient pas uniquement des prompts malveillants qu'un employé pourrait taper : il vient aussi des pages web, tickets, documents ou emails que l'agent consulte pour rendre service, et qui peuvent contenir des instructions cachées destinées à l'agent plutôt qu'à l'humain qui les lit.

Ce qu'il faut verrouiller avant de confier des données à un agent IA

• Cloisonnez les contextes. Un agent qui a accès à la mémoire complète d'un utilisateur ou à des données internes sensibles ne devrait pas, dans la même session, pouvoir consulter librement des URLs externes non validées.
• Limitez la navigation à des domaines de confiance. Une liste blanche de domaines réduit drastiquement la surface d'attaque, plutôt que de laisser l'agent suivre n'importe quel lien rencontré sur une page tierce.
• Auditez les canaux de sortie réels de vos agents. La question à se poser n'est pas seulement quelles données l'agent connaît, mais quels moyens il a de les faire sortir : même un simple outil de lecture d'URL peut devenir un canal caché.
• Formez vos équipes à l'injection indirecte. Une page web, un PDF ou un email peuvent contenir des instructions destinées à manipuler l'agent, invisibles pour l'humain qui les partage.
• Suivez les correctifs des éditeurs. Ce type de faille se corrige côté fournisseur (restriction des URLs accessibles, détection des schémas d'exfiltration) : gardez vos outils et intégrations à jour.

Notre lecture chez CZSyn

Cette démonstration confirme une tendance que nous observons chez les entreprises qui déploient des agents IA en interne : la sécurité de ces systèmes ne se limite plus au choix du modèle ou à la qualité des prompts. Elle se joue désormais dans l'architecture des permissions, exactement comme pour n'importe quel service ayant accès à des données sensibles.

Un agent qui combine accès mémoire et accès web est, de fait, un utilisateur avec des droits élevés et un canal de sortie vers l'extérieur. Il mérite le même niveau de rigueur qu'un compte de service : moindre privilège, cloisonnement, journalisation, et surtout une remise en question régulière de ce qu'il est réellement capable de faire, au-delà de ce pour quoi il a été configuré. Les entreprises françaises qui expérimentent aujourd'hui l'intégration d'agents IA dans leurs outils métier ont tout intérêt à traiter cette question en amont, avant l'incident, plutôt qu'en réaction.

Sources primaires

• Ayush Paul, « The Memory Heist », blog de recherche en sécurité.
• Anthropic, site officiel.
• Documentation officielle Claude, docs.claude.com.