Mémoire d’agent IA empoisonnée sur téléphone

Définir l’empoisonnement de mémoire d’un agent IA

L’empoisonnement de la mémoire d’un agent IA désigne l’entrée non souhaitée d’une préférence, d’un fait ou d’une instruction dans une mémoire persistante que l’assistant pourra réutiliser plus tard. Le risque principal n’est pas une mauvaise réponse isolée. Le risque est la persistance : une consigne ou une préférence introduite aujourd’hui peut influencer une recommandation dans une conversation future, lorsque l’utilisateur ne se souvient plus du contexte d’origine.

Microsoft emploie l’expression AI Recommendation Poisoning pour décrire des tentatives promotionnelles visant à biaiser de futures recommandations. Exemple côté utilisateur : vous cliquez sur un bouton Ask AI depuis une page commerciale, l’assistant reçoit une invite qui présente discrètement une marque comme préférence à retenir, puis une question ultérieure sur le meilleur service ou produit reçoit une réponse orientée. L’efficacité réelle dépend de la plateforme, des garde-fous, de la façon dont la mémoire est gérée et de ce que l’utilisateur confirme ou autorise.

Pour nous, en construisant FoneClaw, ce sujet est important parce qu’un téléphone concentre des signaux personnels : écran actuel, contacts, messages, comptes, applications, préférences et actions possibles. Un agent Android peut devenir très utile quand il comprend le contexte personnel ; Agent IA avec contexte personnel : le guide téléphone explique cette opportunité. La contrepartie de sécurité est claire : plus une mémoire influence les recommandations ou les actions, plus son origine, son périmètre et ses contrôles doivent rester inspectables.

Il faut donc traiter la mémoire comme un état gouverné, pas comme une simple note privée de l’assistant. Une préférence enregistrée doit avoir une provenance. Une instruction persistante doit pouvoir être revue. Une recommandation importante doit pouvoir être vérifiée par une source indépendante. Cette discipline réduit l’impact d’une manipulation des recommandations IA sans confondre le sujet avec l’empoisonnement des données d’entraînement d’un modèle.

Du bouton Ask AI à la mémoire persistante

Le chemin le plus parlant commence par une interface familière. Une page web, un document, un email ou une fiche produit affiche un bouton Ask AI, Summarize with AI ou Demander à l’IA. Le libellé semble pratique : résumer, comparer, expliquer, recommander. Derrière ce bouton, le lien peut ouvrir un assistant avec du texte déjà fourni. Ce texte peut contenir le contenu visible, mais aussi des instructions ajoutées par le créateur du lien.

Microsoft a observé des URL spécialement construites avec des paramètres d’invite. Dans les cas étudiés, l’objectif pouvait être de demander à l’assistant de se souvenir d’une entreprise, de la prioriser dans de futures recommandations ou de la traiter comme un choix privilégié. Le point de sécurité n’est pas le bouton en lui-même : les boutons Ask AI peuvent être utiles. Le problème apparaît quand le texte envoyé à l’assistant dépasse ce que l’utilisateur pense transmettre.

Sur téléphone, cette ambiguïté est plus forte. L’écran est petit, les URL longues sont masquées, les applications ouvrent parfois une feuille de partage ou une fenêtre d’assistant sans montrer tout le contenu prérempli. L’utilisateur voit une action douce, mais l’assistant reçoit peut-être une instruction persistante. Même sans réussite garantie, ce chemin mérite d’être inspecté parce qu’il relie trois zones sensibles : contenu externe, assistant personnel et mémoire future.

Voici le modèle non opérationnel à garder en tête : un bouton libellé utile dirige vers un assistant ; l’assistant reçoit une invite préremplie ; l’invite tente d’ajouter une préférence ou une priorité durable ; une recommandation future peut être influencée si la plateforme accepte la persistance et si les protections ne filtrent pas l’instruction. Cette chaîne montre pourquoi la sécurité des boutons Ask AI commence avant l’envoi du message, au moment où l’utilisateur décide quel contexte il laisse entrer dans l’assistant.

Mémoire, injection de prompt et données d’entraînement

Trois menaces se ressemblent dans les mots, mais elles ne se diagnostiquent pas de la même manière. L’injection de prompt vise souvent la tâche actuelle : un contenu externe demande à l’assistant d’ignorer les instructions, de suivre une consigne cachée ou de produire une action non prévue. Elle peut provoquer une mauvaise réponse dans la session en cours, même si rien n’est conservé après.

L’injection dans la mémoire d’un LLM, au sens de ce guide, vise un état durable : préférences, faits utilisateur, instructions de comportement, priorités de recommandation ou souvenirs que l’assistant consulte plus tard. La différence tient à la réutilisation. Si une consigne cachée disparaît à la fin de la conversation, nous parlons plutôt d’une attaque ponctuelle. Si elle modifie une mémoire enregistrée ou une préférence durable, le problème devient un empoisonnement de mémoire.

L’empoisonnement des données d’entraînement se situe encore ailleurs. Il touche les données utilisées pour entraîner ou ajuster un modèle en amont, avant l’usage quotidien. Ce guide ne traite pas cette couche. Pour un utilisateur Android, le cas pratique est plus proche : ce que je viens d’envoyer à mon assistant peut-il modifier ce qu’il retiendra de moi ou ce qu’il recommandera ensuite ?

Une recommandation étrange ne prouve pas seule le mécanisme. Elle peut venir d’une mémoire, d’un prompt, d’un classement web, d’un biais de données ou d’un simple manque de contexte. Le bon réflexe consiste à chercher la provenance avant de conclure.

Ce que Microsoft a observé

Dans son analyse AI Recommendation Poisoning, Microsoft indique avoir observé plus de 50 prompts uniques provenant de 31 entreprises dans 14 secteurs. Ces prompts tentaient d’orienter des recommandations futures, souvent au moyen de liens ou boutons IA contenant du texte prérempli. Le point important est la nature de la tentative : faire entrer une préférence promotionnelle dans un assistant qui pourrait la réutiliser plus tard.

Les chiffres donnent un signal de terrain, mais ils ne doivent pas être lus comme une preuve que chaque tentative a réussi. Microsoft précise que l’efficacité variait selon les assistants et a évolué avec les sauvegardes de mémoire, les changements de produit et les mitigations. Certaines observations antérieures ne se reproduisaient plus dans les mêmes conditions. C’est exactement le type de nuance qu’il faut garder dans un guide sécurité : une technique peut être réelle même lorsque son succès dépend fortement de la plateforme.

Microsoft recommande notamment d’inspecter les liens, de revoir les mémoires enregistrées, de supprimer les entrées suspectes et de vérifier indépendamment les recommandations importantes. Ces gestes sont utiles au-delà d’un seul fournisseur. Un assistant qui conserve des préférences doit donner à l’utilisateur une manière de les examiner. Un bouton qui ouvre une invite préremplie doit être traité comme une entrée de contexte externe.

Le cadre MITRE ATLAS Memory Poisoning aide à nommer la menace : il distingue la compromission de la mémoire d’un système IA d’une simple erreur de sortie. Pour un téléphone, cette distinction est pratique : si une mémoire influence les réponses futures, l’investigation doit porter sur ce qui a été stocké, d’où cela vient et comment l’utilisateur peut reprendre le contrôle.

Pourquoi la provenance de la mémoire compte

Une mémoire utile doit répondre à cinq questions : qui l’a créée, à partir de quel contexte, quand, pour quel périmètre et avec quelle possibilité de modification. Sans cette provenance, une préférence légitime et une préférence injectée se ressemblent trop. Une recommandation biaisée peut alors paraître personnalisée alors qu’elle vient d’un contenu externe manipulé.

L’architecture publiée par TencentDB Agent Memory donne un exemple intéressant de gouvernance mémoire, sans être un produit téléphone ni une défense universelle. Le projet modélise des actifs comme Chat Memory, Skills, Wiki et CodeGraph avec propriété, versions, statut, visibilité, usages et liaisons aux agents. Il décrit aussi des couches où les conversations brutes restent en L0, puis des atomes, scénarios et éléments de persona ou de noyau sont dérivés au-dessus.

Ce modèle illustre un principe que nous appliquons dans notre raisonnement produit : une mémoire dérivée doit rester reliée à sa source. Si une phrase d’un site web devient une préférence durable, l’utilisateur doit pouvoir retrouver l’origine. Si une préférence change de version, le système doit montrer ce qui a changé. Si une mémoire ne vaut que pour un contexte, elle ne doit pas se comporter comme une règle globale.

Sur Android, la provenance sert aussi à distinguer contexte personnel et contexte importé. Un message affiché, une page web, une capture d’écran et une note utilisateur n’ont pas la même autorité. Pour comparer mémoire hybride, serveur et mémoire locale côté agent, État du serveur Hy-Memory vs mémoire locale d’agent : ce que les utilisateurs Android doivent savoir approfondit cette architecture. Ici, la règle opérationnelle est courte : une mémoire sans origine inspectable mérite une vérification avant d’influencer une recommandation ou une action.

Checklist téléphone avant d’envoyer du contexte à l’IA

Sur téléphone, l’inspection doit rester rapide. Avant d’utiliser un bouton Ask AI, Summarize with AI ou une feuille de partage vers un assistant, commencez par vérifier ce qui sera envoyé. Le libellé visible ne suffit pas. Un bouton peut transmettre une URL, un extrait, un titre, une instruction préremplie ou un contenu plus long que ce que l’écran montre.

• Regardez la destination réelle du lien ou de la feuille de partage lorsque l’interface l’affiche.
• Lisez l’invite préremplie avant de l’envoyer, surtout si elle contient des phrases de priorité, de préférence ou de mémoire.
• Séparez le contenu à résumer des instructions à suivre. Un article peut être source ; il ne doit pas devenir autorité de comportement.
• Évitez d’envoyer des contenus sensibles quand le résumé ou la recommandation peut se faire avec moins de contexte.
• Pour une recommandation importante, ouvrez une source indépendante au lieu de laisser une seule mémoire décider.

Les écrans, emails, documents, liens et textes copiés peuvent tous porter des instructions non fiables. L’inspection visuelle ne détecte pas tout, notamment les encodages ou contenus cachés dans un lien long, mais elle réduit beaucoup les cas simples : texte prérempli suspect, demande de mémorisation étrange, préférence commerciale forcée, instruction qui dépasse la tâche de résumé.

Chez FoneClaw, nous concevons l’attachement de contexte comme un geste volontaire. Cette discipline rejoint une question plus large : quel contexte part vers un service en ligne, quel contexte reste contrôlé localement, et quelles informations l’utilisateur peut modifier ? Confiance dans un agent IA : contrôle local Android ou sécurité cloud ? aide à choisir selon le niveau de sensibilité et la destination du traitement.

Contenir et récupérer après une mémoire suspecte

La récupération commence par la retenue. Si vous soupçonnez qu’une mémoire ou une recommandation a été contaminée, évitez d’utiliser cette recommandation pour une décision importante tant que vous n’avez pas vérifié son origine. Notez le déclencheur possible : bouton Ask AI, page consultée, document résumé, email ouvert, lien partagé, capture d’écran ou conversation où une préférence a été ajoutée.

1. Stoppez les décisions sensibles liées au sujet suspect : achat, choix médical, fournisseur, outil professionnel, finance, sécurité ou compte personnel.
2. Ouvrez les contrôles de mémoire, personnalisation ou souvenirs de l’assistant lorsque la plateforme les propose.
3. Recherchez des entrées récentes qui ressemblent à une préférence commerciale, une priorité non demandée ou une instruction de recommandation.
4. Supprimez ou modifiez les entrées suspectes avec les contrôles fournis par l’assistant.
5. Démarrez une nouvelle session avec une question neutre, sans réutiliser le lien ou le document suspect.
6. Comparez la réponse avec des sources indépendantes, notamment pour les recommandations à conséquence.
7. Réduisez temporairement l’usage de mémoire persistante sur ce sujet si l’assistant permet de limiter la personnalisation.

Les contrôles varient selon l’assistant. Supprimer un historique de chat, une mémoire enregistrée, une préférence ou un fichier joint peut correspondre à des fonctions différentes. C’est pourquoi la récupération doit suivre l’interface officielle de la plateforme utilisée. Après suppression d’une entrée suspecte, un test propre est nécessaire : posez une question comparable sans contexte contaminé et regardez si la recommandation reste biaisée.

Cette séquence ne promet pas un retour arrière universel. Elle donne une méthode de confinement : isoler le déclencheur, examiner ce qui est enregistré, retirer ce qui paraît non voulu, vérifier le comportement après nettoyage et confirmer les décisions importantes par d’autres sources. Sur téléphone, cette prudence vaut aussi pour les compétences ou extensions installées : Sécurité des compétences d’agents IA : pourquoi les permissions sur mobile doivent être vérifiées au moment de l’action explique pourquoi l’autorité doit être contrôlée au moment où l’agent agit.

Frontières de contexte dans FoneClaw

FoneClaw sert ici d’exemple Android concret de frontières visibles, avec une limite claire : nous présentons ces contrôles comme des points d’inspection et de décision pour l’utilisateur, pas comme une détection automatique de l’empoisonnement de mémoire. FoneClaw est un runtime d’agent Android : un modèle configuré raisonne et planifie, tandis que FoneClaw fournit l’exécution Android prise en charge avec permissions, approbations, résultats visibles et récupération.

D’après les informations FoneClaw actuellement disponibles, FoneClaw ajoute un assistant flottant déplaçable et l’attachement volontaire de l’écran actuel, en excluant les surfaces de superposition FoneClaw de cette capture. Cette évolution compte pour la sécurité du contexte : l’utilisateur choisit quand l’écran courant entre dans la tâche, au lieu de supposer que tout l’environnement Android devient automatiquement mémoire ou instruction.

Cette frontière se combine avec les contrôles de compte et de confidentialité. Les informations de compte gérées localement disposent de contrôles utilisateur, tandis qu’un modèle ou service en ligne configuré peut recevoir le contexte pertinent nécessaire au raisonnement. La politique de confidentialité FoneClaw donne le cadre utilisateur à lire avant de connecter un modèle ou d’envoyer du contexte sensible. Les actions Android prises en charge gardent ensuite leurs propres limites : permission, approbation, résultat visible, arrêt et récupération.

Les fonctionnalités FoneClaw montrent cette surface d’action gouvernée sans la transformer en audit mémoire automatique. Notre direction produit est de rendre les limites inspectables : quel contexte a été attaché, quelle action est proposée, quelle permission est demandée, quel résultat sera visible. Pour un risque de mémoire contaminée, ces limites aident l’utilisateur à ne pas confondre contenu partagé, mémoire durable et action autorisée.

Checklist d’évaluation de sécurité mémoire

Pour évaluer la sécurité mémoire d’un agent téléphone, commencez avec des préférences sans conséquence. Par exemple : une préférence de format, de langue ou de style de résumé. Ajoutez-la volontairement, vérifiez où elle apparaît, modifiez-la, puis supprimez-la. Ce test révèle plus qu’un discours marketing : l’utilisateur voit si la mémoire est inspectable, éditable et limitée.

Notez ensuite cinq critères. La provenance est-elle visible ? Le périmètre est-il clair : session, application, sujet ou profil global ? L’utilisateur peut-il supprimer ou corriger une mémoire ? L’assistant distingue-t-il une source externe d’une préférence utilisateur ? Une nouvelle session neutre change-t-elle le comportement après suppression ? Ces questions forment un audit de mémoire enregistrée réaliste.

Ajoutez enfin un test de recommandation. Demandez une suggestion dans un domaine à faible risque, introduisez un contexte externe clairement marqué comme source à résumer, puis vérifiez si l’assistant le transforme en préférence durable. Une bonne évaluation ne cherche pas un classement général des fournisseurs. Elle mesure la visibilité, la portée, la reprise et la vérification indépendante. C’est le niveau de discipline dont un agent sur téléphone a besoin lorsque la mémoire influence des décisions futures.