L'agence excessive est une faille qui se produit lorsqu'un grand modèle de langage (LLM) se voit accorder des capacités inutiles ou trop permissives pour interagir avec d'autres systèmes. Lorsqu'un LLM peut appeler des outils, des plug-ins ou des fonctions externes (son "agence"), cette faille lui permet d'effectuer des actions non prévues, non autorisées et potentiellement dangereuses. Un pirate informatique peut exploiter cette faille en utilisant l'injection d'invite ou d'autres techniques de manipulation pour inciter le LLM à utiliser l'autonomie qui lui a été accordée à des fins malveillantes. Le problème principal n'est pas seulement que le LLM peut effectuer des actions, mais que leur portée est trop large et mal contrôlée.
Pourquoi les développeurs Android devraient s'en soucier
Accorder une autonomie excessive à un LLM dans votre application Android peut entraîner de graves incidents de sécurité :
- Accès non autorisé au système : un pirate informatique peut ordonner au LLM d'accéder à des fichiers sur l'appareil Android local (par exemple, des documents utilisateur, des données d'application) ou à des ressources réseau connectées, de les modifier ou de les supprimer, si le modèle dispose de l'agence et des autorisations Android correspondantes pour le faire.
- Exfiltration de données : le LLM peut être amené à lire des données sensibles à partir de bases de données d'applications locales (comme Room), de SharedPreferences ou d'API internes, puis à exfiltrer ces informations vers une source externe (par exemple, en les envoyant à l'aide d'un appel d'API ou d'une fonction d'e-mail). Le modèle peut également divulguer des informations sensibles qu'il a absorbées lors de sa phase d'entraînement ou des informations sensibles que l'utilisateur fournit dans sa requête.
- Compromission d'autres fonctions/systèmes : si le LLM a le contrôle sur d'autres fonctions (par exemple, l'envoi de SMS, les appels, la publication sur les réseaux sociaux à l'aide d'intentions implicites, la modification des paramètres système, les achats via l'application), un pirate informatique pourrait détourner ces fonctions pour envoyer du spam, diffuser de la désinformation ou effectuer des transactions non autorisées, entraînant ainsi une perte financière directe ou un préjudice pour l'utilisateur.
- Déni de service : le LLM peut être invité à effectuer des actions gourmandes en ressources de manière répétée dans l'application ou sur les services de backend, comme exécuter des requêtes de base de données complexes ou appeler une API en boucle. Cela peut entraîner une perte de réactivité de l'application, une décharge de la batterie, une utilisation excessive des données, voire un déni de service pour les systèmes de backend.
Mesures d'atténuation pour les développeurs d'applications Android
Pour atténuer l'excès d'autonomie dans les applications Android, nous appliquons le principe du moindre privilège à chaque outil et fonction auxquels le LLM peut accéder ou qu'il peut déclencher.
Limitez la boîte à outils de l'IA (fonctions granulaires ou ouvertes) :
- Fournissez un minimum d'outils : le LLM ne doit avoir accès qu'aux outils spécifiques (fonctions, API, intentions) dont il a absolument besoin pour faire son travail dans votre application. S'il n'a pas besoin de pouvoir naviguer sur le Web ni d'envoyer un e-mail, ne lui exposez pas ces fonctionnalités.
- Utilisez des outils simples et à usage unique : il est préférable de fournir au LLM un outil qui ne peut effectuer qu'une seule action spécifique (par exemple, "lire un type spécifique de paramètre utilisateur") plutôt qu'un outil puissant et polyvalent qui pourrait tout faire (par exemple, "exécuter n'importe quelle commande shell").
Restreindre la puissance de l'IA
- Autorisations Android précises : lorsqu'une fonction déclenchée par un LLM interagit avec des ressources système Android ou d'autres applications, vérifiez que votre application ne demande et ne détient que le strict minimum d'autorisations Android requises.
- Autorisations par utilisateur : lorsque le LLM effectue une action au nom de l'utilisateur, il doit le faire avec les autorisations et le contexte spécifiques de cet utilisateur, et non avec un compte plus général, potentiellement au niveau de l'application. Cela permet de vérifier que le LLM ne peut pas faire ce que l'utilisateur ne serait pas autorisé à faire lui-même.
Garder un humain aux commandes (consentement de l'utilisateur pour les actions critiques)
- Exiger l'approbation de l'utilisateur : pour toute action importante ou risquée qu'un LLM pourrait suggérer ou tenter d'effectuer (par exemple, supprimer des données, effectuer des achats via l'application, envoyer des messages, modifier des paramètres critiques), exigez toujours une approbation humaine explicite à l'aide d'une boîte de dialogue de confirmation dans votre UI. Imaginez que vous ayez besoin de l'approbation d'un responsable pour prendre une décision importante.
La confiance n'exclut pas le contrôle (validation des entrées/sorties et backends robustes)
- Sécurité du backend : ne vous fiez pas uniquement au LLM pour déterminer si une action est autorisée. Tous les services ou API de backend auxquels les fonctions déclenchées par le LLM se connectent doivent disposer de leur propre système d'authentification, d'autorisation et de validation des entrées robuste pour vérifier chaque requête et s'assurer qu'elle est légitime et qu'elle respecte les paramètres attendus.
- Nettoyez les données : comme pour les autres failles de sécurité, il est essentiel de nettoyer et de valider à la fois les entrées du LLM et les paramètres générés par le LLM pour les appels de fonction. Cela permet de détecter les instructions malveillantes ou les sorties inattendues avant l'exécution d'une action.
Résumé
L'agence excessive est une vulnérabilité critique dans laquelle un LLM dispose d'autorisations trop larges pour interagir avec d'autres systèmes ou fonctions, ce qui lui permet d'être amené à effectuer des actions nuisibles. Cela peut entraîner un accès non autorisé aux données, une compromission du système, une perte financière ou un préjudice pour l'utilisateur dans les applications Android. L'atténuation repose fortement sur le principe du moindre privilège : limiter strictement les outils et les autorisations Android disponibles pour le LLM, vérifier que chaque outil dispose d'une fonctionnalité minimale et spécifique, et exiger une approbation humaine pour toutes les opérations à fort impact.