Sécuriser les appels d'outils des chatbots IA : droits, confirmation et stratégie de rollback

Un chatbot de site web change fondamentalement de nature dès lors qu'il ne se contente plus de répondre, mais qu'il peut déclencher des actions. Une simple consultation de rendez-vous reste facile à gérer. En revanche, une annulation de rendez-vous, un changement d'adresse ou un remboursement modifie l'état réel de votre activité. Le modèle de langage peut suggérer l'appel d'outil approprié. Cependant, la décision d'autoriser ou non cette action doit impérativement revenir à une couche applicative distincte et déterministe. La sécurité des appels d'outils d'un chatbot IA ne repose donc pas sur un prompt système particulièrement strict, but sur des fonctions restreintes, un contrôle des droits côté serveur, une confirmation claire et un parcours d'exécution maîtrisé.

Pourquoi un bon modèle de langage ne remplace pas l'autorisation

Un modèle fonctionne sur la base de probabilités. Il peut mal interpréter une intention, ajouter un paramètre non désiré ou réagir à des contenus manipulés. La description des risques de l'OWASP concernant l'Excessive Agency identifie trois causes principales : des fonctionnalités trop étendues, des autorisations trop larges et une autonomie excessive. Le problème ne provient donc pas uniquement d'une saisie malveillante. Une demande ambiguë ou une erreur plausible du modèle peut également préparer une action non souhaitée.

La règle d'architecture essentielle est donc la suivante : le modèle formule une proposition, mais l'application autorise et exécute. Un appel d'outil comme cancelAppointment n'est d'abord qu'une intention structurée. C'est le contrôle de politique (policy check) qui vérifie l'utilisateur, l'organisation (tenant), l'objet, l'action autorisée, l'état actuel et la confirmation requise. Cette séparation complète la protection contre les injections de prompts dans les chatbots de sites web ; elle reste indispensable même lorsqu'aucune attaque n'est détectée.

Classer chaque outil selon son impact plutôt que selon son nom

Les équipes ne doivent pas classifier l'ensemble du chatbot de manière globale comme « sûr » ou « critique ». Ce qui compte, c'est l'impact de chaque outil individuel. Une matrice de risques simple permet d'y voir plus clair :

• Lecture seule et peu sensible : consulter les horaires d'ouverture ou des informations produits publiques.
• Lecture seule et données personnelles : afficher le statut d'une commande ou les données d'un client ; cela nécessite de vérifier l'identité, l'organisation et le lien avec l'objet.
• Écriture, mais facilement réversible : créer une demande de rappel interne ou ajouter une note informative.
• Impact important ou difficilement réversible : annuler une réservation, modifier des coordonnées, publier du contenu, envoyer des messages ou initier des paiements.

De cette classification découlent les droits, le niveau de confirmation, les limites et la journalisation. Une autorisation globale telle que « Le chatbot peut utiliser le CRM » est trop vague. Il est préférable d'établir une liste de capacités concrètes avec des paramètres définis et des transitions d'état autorisées.

Le moindre privilège commence par le découpage des fonctionnalités

L'OWASP Authorization Cheat Sheet recommande d'appliquer le principe du moindre privilège (Least Privilege) et le refus par défaut (Deny by Default). Pour les appels d'outils, cela signifie qu'un chatbot ne reçoit que la fonction et l'extrait de données strictement nécessaires à l'étape en cours.

Des outils ciblés plutôt que des interfaces universelles

Un outil tel que getOrderStatus(orderId) est beaucoup plus facile à sécuriser qu'un accès ouvert à la base de données. Un outil requestCallback(topic, timeWindow) est plus contrôlable qu'une fonction générale permettant d'envoyer n'importe quel message. Les fonctions libres SQL, Shell, URL ou e-mail élargissent inutilement l'impact potentiel. De même, les outils de test qui ne sont plus nécessaires doivent disparaître du catalogue de production.

Exécuter dans le contexte de l'utilisateur connecté

Le backend ne doit pas se fier uniquement au modèle pour transmettre le bon ID client. Il doit déduire l'utilisateur actuel et l'organisation à partir d'une session de confiance et vérifier à nouveau, pour chaque objet, si l'accès est autorisé. La différence pratique entre un chat public et un espace sécurisé est expliquée en détail dans l'article sur l'identité et l'accès aux données dans le portail client. Utiliser un compte de service générique avec un accès complet est généralement une mauvaise solution pour les actions liées aux utilisateurs.

Valider les paramètres de manière déterministe

Les paramètres des outils nécessitent un schéma strict : champs autorisés, types, longueurs, plages de valeurs et règles d'état. Un ID de rendez-vous doit appartenir à l'utilisateur, une date doit s'inscrire dans une plage valide et une action doit correspondre au statut actuel. Les champs inconnus doivent être rejetés. L'application doit également s'assurer que le nom de l'outil provient d'une liste d'autorisations (allowlist) fixe et n'est pas exécuté à partir d'un texte généré librement.

La confirmation doit afficher l'action réelle

Pour des modifications à fort impact, la question « Êtes-vous sûr ? » ne suffit pas. Le guide OWASP sur l'autorisation de transactions décrit le principe « What You See Is What You Sign » (Ce que vous voyez est ce que vous signez) : les utilisateurs doivent pouvoir visualiser et confirmer les données essentielles de l'action concrète. Pour un chatbot de site web, cela se traduit par exemple par :

• « Annuler le rendez-vous du 18 août à 14h30 » au lieu de « Confirmer la modification »
• « Modifier l'adresse de livraison pour la commande ...84 vers Paris » au lieu de « Enregistrer les données »
• « Créer une demande de rappel pour le sujet Facturation » au lieu de « Envoyer la demande »

La confirmation est liée côté serveur à ce projet d'action précis. Si la cible, le montant, la date, le destinataire ou d'autres paramètres essentiels changent, la confirmation devient caduque. Elle dispose d'une durée de validité courte et ne peut pas être réutilisée pour une seconde action. Pour les opérations particulièrement critiques, une nouvelle authentification ou une validation par un opérateur humain peut être requise. Le modèle ne doit ni sauter cette étape, ni la remplacer par une réponse à la formulation rassurante.

Prévoir l'idempotence, les limites et la stratégie de rollback

Même un appel d'outil correctement autorisé peut parvenir en double pour des raisons techniques : le navigateur réitère une requête, un délai d'attente (timeout) déclenche une nouvelle tentative ou l'utilisateur renvoie le même message. Les outils d'écriture doivent donc utiliser un ID d'idempotence côté serveur. Pour un même ID, la même action est exécutée au maximum une seule fois ; une tentative répétée reçoit le résultat déjà connu.

De plus, chaque outil a besoin de limites adaptées : nombre maximal d'appels par session, timeouts courts, retries limités et interruption en cas de chaînage inhabituel. Avant l'exécution, le backend vérifie une nouvelle fois l'état. Ainsi, une réservation déjà annulée ne sera pas traitée une seconde fois. Dans la mesure du possible, une action doit d'abord être créée sous forme de brouillon ou de commande en attente. Pour les modifications directes inévitables, la procédure de compensation, d'annulation ou de transfert à une équipe de support doit être claire. Un mode dégradé et un plan de rollback préparés évitent d'avoir à improviser en cas d'incident.

Journaliser sans collecter de secrets

Un journal de sécurité (log) doit pouvoir répondre aux questions : qui a validé quelle action, sur quelle base et avec quel résultat. Il est pertinent d'inclure un ID d'acteur pseudonymisé, l'outil et sa version, la référence de l'objet, la version de la politique, la décision d'autorisation, l'ID de confirmation, l'ID d'idempotence, l'horodatage et le résultat. Les mots de passe, jetons, historiques de chat complets et données personnelles inutiles n'ont pas leur place dans ce journal.

L'OWASP AI Agent Security Cheat Sheet recommande de structurer les données de décision pour les actions à risque et de séparer la décision de l'exécution. Cela diffère du tracing technique complet : pour l'audit de sécurité, ce qui compte est une preuve concisa et fiable de la chaîne de validation. La conservation et l'accès doivent être alignés sur les besoins réels de contrôle.

Une architecture solide en cinq couches

1. Dialogue et proposition : le modèle identifie l'intention et génère un projet d'action structuré, mais n'exécute rien directement.
2. Décision de politique (Policy) : un composant déterministe vérifie l'allowlist de l'outil, l'utilisateur, l'organisation, l'objet, les paramètres, la classe de risque et les limites.
3. Confirmation : l'interface affiche les données clés de l'action. La validation est éphémère et strictement liée au projet inchangé.
4. Exécution : un exécuteur strictement restreint vérifie à nouveau l'autorisation juste avant l'appel et utilise un ID d'idempotence.
5. Traçabilité et réaction : le résultat, les erreurs et la chaîne de validation sont journalisés dans le respect de la sobriété des données ; l'alerte, la compensation et le transfert humain sont définis.

Le NIST AI RMF Core classe ces tâches selon les piliers Gouverner, Cartographier, Mesurer et Gérer (Govern, Map, Measure, Manage). En pratique, cela signifie : définir les responsabilités et les limites de risque, comprendre le contexte d'utilisation, tester les contrôles et réagir aux écarts observés.

Matrice de test avant le passage en production

Les tests positifs ne suffisent pas. Un outil doit également échouer de manière sécurisée dans des conditions défavorables. Au minimum, ces cas doivent figurer dans une matrice de test répétable :

• Un utilisateur non connecté ou non autorisé demande l'action.
• Une session valide fait référence à un objet appartenant à une autre organisation.
• Des paramètres essentiels changent après la confirmation.
• La même requête est répétée en raison d'un timeout ou d'un double-clic.
• Un outil renvoie des instructions manipulées ou des champs supplémentaires inattendus.
• Un appel dépasse les limites de temps, de volume ou de coût.
• Le système cible tombe en panne entre la vérification et l'exécution.
• Une autorisation est révoquée juste avant l'exécution.

On n'attend pas seulement le succès des actions, mais des refus clairs, des données intactes et des événements de sécurité exploitables. Avant d'activer les accès en écriture pour les utilisateurs réels, le processus peut être testé en Shadow Mode avec des requêtes réelles, sans exécuter les actions proposées.

Check-list pour les équipes web

• Chaque outil est-il ciblé, limité à un usage précis et issu d'une allowlist fixe ?
• L'utilisateur, l'organisation, l'objet et l'action sont-ils contrôlés côté serveur ?
• Le principe du refus par défaut et les autorisations techniques minimales sont-ils appliqués ?
• Les utilisateurs voient-ils toutes les données essentielles avant une action critique ?
• La confirmation expire-t-elle en cas de modification et après un court délai ?
• Un ID d'idempotence empêche-t-il les exécutions en double ?
• Des limites, timeouts, interruptions, procédures de compensation et handoffs humains sont-ils en place ?
• Les jetons, secrets et données personnelles inutiles sont-ils exclus des logs ?
• La matrice de test couvre-t-elle les erreurs de droits, les manipulations, les retries et les pannes ?

Conclusion : le modèle propose, l'application décide

Un chatbot de site web capable d'agir n'a pas besoin de démarrer avec un accès complet. Commencez par une action très ciblée et réversible, puis construisez la chaîne de validation de manière transparente autour d'elle. Lorsque le découpage des outils, l'autorisation côté serveur, la confirmation concrète, l'idempotence et la stratégie de rollback sont conçus ensemble, le chat reste utile sans attribuer au modèle le rôle d'un système de sécurité. Pour passer à l'étape suivante, organisez un atelier regroupant produit, développement, support et protection des données : choisissez une action réelle, évaluez son risque et définissez le cas de refus sécurisé avant le premier déploiement en production.