Sécurité des compétences d’agents IA : pourquoi les permissions sur mobile doivent être vérifiées au moment de l’action

Un scanner propre ne suffit pas à faire confiance

La question que beaucoup d’utilisateurs se posent est simple : si une compétence, un plugin ou un module d’agent IA passe un scanner de sécurité, peut-on lui faire confiance ? La réponse prudente est non. Un contrôle avant installation est utile, mais il n’observe qu’une partie du problème. Il peut lire le code visible, repérer des appels suspects, vérifier des dépendances ou signaler des schémas connus. Il ne garantit pas que le comportement réel restera acceptable une fois la compétence chargée, configurée et appelée par un agent.

Le signal récent autour de SkillCloak illustre bien cette limite. The Hacker News a rapporté le 6 juillet 2026 des travaux décrivant des compétences d’agents IA capables d’échapper à des scanners statiques grâce à des techniques de masquage et d’auto-extraction. Le point important n’est pas de conclure que tous les plugins IA sont dangereux. Le point est que l’apparence au repos ne suffit pas à prédire ce qu’un module fera au moment où l’agent lui donne un contexte, un objectif et des autorisations.

La sécurité des compétences d’agents IA doit donc passer d’une logique de confiance à l’installation vers une logique de contrôle continu. Un module peut sembler limité, puis tenter d’accéder à un fichier, de modifier une requête, de transmettre une donnée ou d’élargir son rôle pendant une tâche. La règle de décision est simple : un scanner est un filtre d’entrée, pas une preuve de sécurité. Plus l’agent peut agir sur des données personnelles ou des outils réels, plus le comportement au moment de l’action devient décisif.

Ce qu’il faut vérifier pendant l’usage

Vérifier pendant l’usage signifie observer ce que la compétence tente réellement de faire quand elle reçoit des instructions, des données et des autorisations. Un bon contrôle ne se limite pas à demander « ce code contient-il une chaîne suspecte ? ». Il demande : quelle donnée entre dans le module, quelle sortie est produite, quel outil est appelé, quelle permission est sollicitée, et l’action correspond-elle à la demande de l’utilisateur ? Ce type de raisonnement est plus proche d’un suivi de comportement que d’une simple lecture statique.

La prépublication Cloak and Detonate, associée à la discussion SkillCloak et SkillDetonate, présente justement une approche où les comportements sont déclenchés et analysés dans un environnement contrôlé. Les chiffres de détection ou de contournement rapportés doivent être lus comme des résultats de recherche, pas comme des garanties industrielles définitives. Une prépublication peut éclairer une tendance sans fixer à elle seule la norme de sécurité de tout l’écosystème.

Pour les agents, le point pratique est très utile : il faut traiter les compétences comme des composants qui peuvent changer de comportement selon le contexte. Une compétence de résumé ne devrait pas soudainement envoyer des données ailleurs. Une compétence de calendrier ne devrait pas lire des messages privés sans raison. Une compétence de fichier ne devrait pas demander un accès plus large que la tâche demandée. Quand les journaux, les validations et l’historique sont consultables, les journaux de permissions des agents IA deviennent une forme de mémoire de sécurité : ils aident à comprendre qui a demandé quoi, quand, et pour quelle action.

Pourquoi le téléphone rend le risque plus personnel

Un plugin mal conçu dans un environnement de test peut produire un mauvais résultat. Une compétence malveillante d’agent IA sur téléphone peut toucher à des éléments beaucoup plus personnels : messages, contacts, notifications, réglages, photos, fichiers, comptes, localisations ou applications bancaires. Même quand l’agent ne finalise pas l’action, la préparation d’une action peut exposer des données. Lire une notification pour rédiger une réponse, par exemple, n’est pas neutre.

Les catégories de risque décrites par le projet OWASP Top 10 pour les applications LLM aident à cadrer ce problème : injection de prompt, vulnérabilités de dépendances, conception fragile de plugins, pouvoir excessif donné à l’agent et divulgation d’informations sensibles. Sur mobile, ces catégories deviennent concrètes. Une instruction cachée dans un contenu peut essayer d’influencer l’agent. Une compétence trop permissive peut accéder à plus de données que nécessaire. Une action automatique peut avoir un effet visible sur la vie de l’utilisateur.

Le lieu de traitement compte aussi. Certains contrôles peuvent se faire sur l’appareil, d’autres dans le cloud, et certains systèmes combinent les deux. Quand un agent doit lire un contexte téléphonique ou préparer une action, le choix entre agent IA dans le cloud ou sur l’appareil influence les données déplacées, la latence, les risques et les explications à fournir. Local ne veut pas dire sans risque ; cloud ne veut pas dire automatiquement dangereux. La bonne question est : quelles données sont utilisées, quelle permission est demandée, et quelle action peut réellement être exécutée ?

Android rappelle une règle importante : les permissions sont des capacités contrôlées par le système et accordées par l’utilisateur selon différents niveaux de sensibilité. La documentation Android Developers sur les permissions montre qu’un accès à une donnée ou à une fonctionnalité n’est pas un détail technique. Pour un agent mobile, une permission n’est pas la même chose qu’une confirmation d’action. Autoriser l’accès à une catégorie de données ne signifie pas accepter chaque usage futur de cette donnée.

Le bon modèle : moins d’accès, plus de confirmation

Un modèle de permission sérieux commence par le moindre accès utile. Une compétence météo n’a pas besoin de lire les contacts. Une compétence de rappel n’a pas besoin d’accéder à tous les fichiers. Une compétence de messagerie peut avoir besoin de préparer un brouillon, mais pas d’envoyer sans validation. Cette logique réduit les dégâts possibles si un module se comporte mal ou si une instruction hostile tente de l’exploiter.

Le deuxième principe est la demande au bon moment. Plutôt que d’accorder un accès large dès l’installation, l’agent devrait demander l’autorisation quand la tâche l’exige. L’utilisateur comprend mieux une demande si elle est liée à une action précise : « lire cette notification pour préparer une réponse », « ouvrir le calendrier pour créer cet événement », « accéder à ce fichier pour le joindre ». Les contrôles de permission à l’exécution donnent du contexte à la décision, alors qu’un écran d’installation trop large favorise l’acceptation automatique.

La confirmation doit être séparée de la permission. Une permission peut autoriser l’agent à préparer une action ; la confirmation autorise l’effet final. Envoyer un message, modifier un réglage, partager une localisation, supprimer un fichier, passer une commande ou publier un contenu devrait exiger une validation claire. Cette séparation évite le piège du « vous avez déjà accepté ». L’utilisateur doit pouvoir approuver l’accès à une information sans approuver tous les usages possibles de cette information.

Les entreprises utilisent des contrôles beaucoup plus larges : politiques d’accès, segmentation, supervision, journaux centralisés, revues et règles de conformité. Ces pratiques dépassent les simples demandes de permission sur un téléphone grand public, mais elles inspirent la même discipline. Le sujet de la sécurité des agents IA en entreprise montre pourquoi les journaux, les limites de rôle et l’analyse des actions deviennent essentiels dès qu’un agent manipule des données sensibles. Pour le mobile, la version utile doit rester lisible par l’utilisateur, pas réservée aux équipes sécurité.

Checklist pratique avant d’installer une compétence d’agent

Avant d’ajouter une compétence d’agent IA, commencez par sa fonction réelle. Peut-elle seulement lire et résumer ? Peut-elle appeler un outil ? Peut-elle modifier des données ? Peut-elle envoyer, supprimer, publier ou déclencher une opération ? Plus la compétence a d’effets sur le monde réel, plus elle doit fournir des limites visibles. Une compétence qui promet beaucoup mais n’explique pas ses permissions mérite une attention particulière.

Regardez ensuite l’origine et la maintenance. Le développeur est-il identifiable ? Les mises à jour sont-elles documentées ? Les dépendances semblent-elles raisonnables ? Le module demande-t-il des accès cohérents avec son usage ? Un plugin de conversion de fichiers qui demande l’accès aux contacts ou aux notifications doit déclencher une alerte. Il ne faut pas supposer la malveillance, mais il faut demander une justification. Les risques des plugins IA commencent souvent par une permission trop large ou une dépendance mal comprise.

La troisième vérification porte sur le comportement pendant la tâche. L’agent affiche-t-il ce qu’il est en train de faire ? Demande-t-il une permission au moment utile ? Présente-t-il le contenu avant envoi ? Permet-il d’annuler ? Explique-t-il pourquoi une action échoue ? Un système qui ne montre pas l’état de la tâche oblige l’utilisateur à faire confiance à l’aveugle. À l’inverse, un état visible, une confirmation claire et un historique consultable transforment une automatisation opaque en outil vérifiable.

Enfin, prévoyez le retrait. Pouvez-vous désactiver la compétence ? Révoquer ses permissions ? Effacer son historique local ? Voir quelles actions elle a tentées ? Restaurer un réglage modifié ? Une compétence acceptable n’est pas seulement celle qui s’installe proprement. C’est celle qui peut être contrôlée, limitée et retirée sans casser tout le système. La meilleure règle pour l’utilisateur reste sobre : n’accordez pas à un agent plus de pouvoir que ce que vous seriez prêt à vérifier après coup.

Ce que cela implique pour FoneClaw

FoneClaw doit être positionné avec des limites nettes. Il est indépendant de The Hacker News, des auteurs arXiv, d’OWASP, d’Android, de Google, de Claude Code, d’OpenAI Codex, d’OpenClaw et des fournisseurs de sécurité. Cet article ne dit pas que FoneClaw a été touché par SkillCloak, qu’il scanne des compétences tierces ou qu’il garantit une sécurité totale. Le bon angle est plus concret : un agent IA Android devrait rendre les actions prises en charge visibles, limitées par permission et confirmées avant effet sensible.

Pour un agent de téléphone, la confiance ne vient pas d’une phrase marketing. Elle vient de détails répétables : montrer la tâche en cours, expliquer la permission demandée, séparer la préparation de l’action finale, afficher le résultat, garder un historique et permettre le retrait d’un accès. Si l’agent prépare une réponse, l’utilisateur doit voir le texte avant envoi. S’il ouvre un réglage, l’utilisateur doit comprendre ce qui changera. S’il accède à une notification, il doit y avoir une raison liée à la tâche.

La sécurité des compétences d’agents IA devient donc une leçon de conception produit. Les contrôles statiques gardent une place, mais ils ne suffisent pas. Les contrôles pendant l’usage, les permissions contextualisées et les confirmations lisibles sont plus proches de ce dont un téléphone a besoin. FoneClaw peut être utile s’il reste dans ce cadre : aider l’utilisateur à opérer son téléphone, coopérer avec les limites Android, refuser les actions non prises en charge et garder le contrôle humain au centre.