Que devrait-on autoriser un assistant IA à faire ?
Un assistant capable d’envoyer des messages ou de réserver un voyage a besoin de limites claires, pas seulement de réponses convaincantes.
Demandez à une IA de trouver un hôtel : elle pourra vous proposer une sélection. Reliez-la à des outils de réservation et elle pourra peut-être réserver une chambre. La conversation semble similaire, mais la seconde action crée un engagement.
Un agent IA est un logiciel capable d’utiliser des outils et d’accomplir des étapes pour réaliser une tâche. Il peut lire un résultat, décider de la suite et appeler un autre outil. La question importante n’est pas seulement de savoir s’il donne des réponses sensées, mais ce qu’il peut modifier lorsqu’une réponse est fausse.
Commencer par les accès nécessaires
Lire, modifier, envoyer et supprimer correspondent à des autorisations différentes. Accéder à un document n’équivaut pas non plus à accéder à tout un compte. Un assistant qui vérifie une réunion n’a pas automatiquement besoin de tous les courriels que vous avez reçus.
Les spécialistes de la sécurité parlent de « moindre privilège » : ne donner au logiciel que les accès nécessaires à sa tâche. L’OWASP identifie les fonctions, les permissions et l’autonomie inutiles comme des causes de capacité d’action excessive : le système peut faire davantage que ce que la tâche justifie.
L’accès en lecture seule compte aussi, car il peut exposer des informations privées. Limiter les accès doit concerner ce que le système peut voir autant que ce qu’il peut modifier.
Une page web ne doit pas devenir celle qui donne les ordres
Supposons qu’un assistant lise une page d’hôtel contenant une instruction cachée lui demandant d’envoyer votre itinéraire ailleurs. La page est censée fournir des informations sur l’hôtel. Elle n’a aucune autorité pour modifier votre demande.
Cette attaque s’appelle une injection indirecte de prompt : des instructions sont placées dans des contenus que l’assistant rencontre pendant son travail. Il peut s’agir d’une page web, d’un courriel ou d’un document. Si le système prend ces instructions pour des commandes fiables, il risque d’agir contre la volonté de l’utilisateur.
Demander au modèle d’ignorer ces attaques peut aider, mais ne constitue pas une défense complète. L’application doit aussi limiter les outils disponibles et vérifier les opérations proposées. Si l’envoi de courriels est techniquement impossible, une page trompeuse ne pourra pas utiliser cet outil pour transmettre votre itinéraire.
Permettre de vérifier l’action concrète
Un point de contrôle utile montre ce qui va se passer : le destinataire, le message et la pièce jointe ; ou l’hôtel, les dates, le prix et les conditions d’annulation. Un vague « Dois-je continuer ? » ne fournit pas assez d’informations pour évaluer une décision importante.
Le logiciel sous-jacent doit imposer ce contrôle. Un bouton d’approbation ne sert à rien si une autre voie permet d’effectuer la même opération sans accord. Préparer un brouillon et l’envoyer doivent réellement être deux étapes distinctes lorsque cette distinction compte.
Toutes les actions n’exigent pas la même supervision. De petites modifications réversibles peuvent souvent être automatisées dans des limites convenues. Publier en public, dépenser de l’argent ou supprimer des documents importants mérite un contrôle plus étroit. C’est une recommandation éditoriale fondée sur les conséquences des erreurs, pas l’affirmation qu’une même règle d’approbation convient à toutes les tâches.
Conserver une trace et un moyen d’arrêter
Un historique des actions doit indiquer clairement ce qui a été tenté, ce qui a réussi et à quel moment. Des plafonds de dépenses ou de volume de messages peuvent limiter les dégâts d’une erreur. Des accès rapidement révocables donnent à l’utilisateur un moyen concret d’arrêter les opérations suivantes.
La récupération compte aussi. Peut-on restaurer un fichier modifié ? Annuler une réservation ? Certaines actions sont bien plus difficiles à défaire que d’autres ; les protections doivent refléter cette différence.
Enfin, vérifiez le résultat auprès du service concerné. Un assistant qui dit « C’est réservé » n’équivaut pas à une confirmation de réservation du prestataire. Un système utile distingue une action proposée, une action tentée et un résultat confirmé.
Avant de connecter un compte
Demandez ce que l’assistant peut lire, ce qu’il peut modifier, quelles actions doivent être vérifiées et comment retirer ses accès. Cherchez des réponses précises. « Il peut rédiger une réponse, mais pas l’envoyer » en dit davantage qu’une promesse générale de sécurité.
L’objectif est de laisser l’assistant accomplir un travail utile tout en gardant ses pouvoirs compréhensibles. Une démonstration impressionnante montre ce qu’un système peut faire une fois. Un service fiable précise aussi ce qu’il n’est pas autorisé à faire ensuite.
Sources et lectures complémentaires
- NIST, Lessons Learned from the Consortium: Tool Use in Agent Systems (2025) (https://www.nist.gov/news-events/news/2025/08/lessons-learned-consortium-tool-use-agent-systems)
- OWASP, LLM06:2025 Excessive Agency (https://genai.owasp.org/llmrisk/llm062025-excessive-agency/)
- NIST, Strengthening AI Agent Hijacking Evaluations (2025) (https://www.nist.gov/news-events/news/2025/01/technical-blog-strengthening-ai-agent-hijacking-evaluations)
- OWASP, LLM Prompt Injection Prevention Cheat Sheet (https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html)