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 de requêtes ou d'autres techniques de manipulation pour inciter le LLM à utiliser l'autonomie qui lui est 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 : si le système de fichiers et les ressources de stockage de l'appareil, ou la possibilité d'effectuer des appels réseau, sont exposés au modèle par le biais de l'appel de fonction, un pirate informatique peut utiliser l'injection d'invite pour accéder aux fichiers de l'appareil (par exemple, les documents utilisateur, les données d'application) ou aux ressources réseau connectées, ou pour les modifier ou les supprimer.
- Exfiltration de données : si une application utilise un appel de fonction pour donner à un LLM l'accès à des données locales (par exemple, des bases de données Room, des SharedPreferences ou des API internes). Une requête malveillante peut inciter le modèle à récupérer des informations sensibles et à les transmettre à un outil externe, tel qu'une fonction de requête par e-mail ou réseau.
- 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 : si un LLM est intégré à l'appel de fonction qui expose les requêtes de base de données ou les requêtes réseau, une requête malveillante peut déclencher ces actions à plusieurs reprises. Cela peut entraîner une dégradation de l'état du système, comme une décharge excessive de la batterie, un dépassement de forfait de données ou l'épuisement des ressources locales.
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 d'e-mails, ne lui donnez pas accès à ces fonctionnalités.
- Utilisez des outils simples à usage unique : concevez des outils avec un champ d'application limité et spécifique. Par exemple, fournissez un outil qui ne lit qu'un type spécifique de paramètre utilisateur plutôt qu'un outil générique qui accepte des paramètres ouverts pour accéder à plusieurs sources de données. Évitez d'exposer des API puissantes au niveau du système, telles que
Runtime.getRuntime().exec(), à un LLM en permettant au modèle de définir la commande ou les arguments.
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 pour le compte de l'utilisateur, il doit le faire avec les autorisations et le contexte spécifiques de cet utilisateur. Une action effectuée par un LLM doit être une réponse directe à une commande utilisateur spécifique.
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. C'est comme si vous aviez besoin qu'un responsable approuve 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.