Avant d’autoriser un agent d’IA à agir

Un système d’IA capable de répondre à une question peut vous induire en erreur. Un système d’IA capable d’ouvrir un ticket, de modifier une configuration, d’accéder à des données confidentielles ou d’envoyer un message peut avoir des conséquences bien plus graves. La distinction n’est pas d’ordre philosophique. Il s’agit d’une décision relative au contrôle d’accès, et les personnes qui approuvent le déploiement doivent comprendre exactement quels pouvoirs elles confient.

Je m’intéresse au moment où un assistant utile devient un opérateur. Dès lors qu’un modèle est capable d’appeler des outils, ses erreurs et les instructions qu’il manipule peuvent passer du texte généré aux systèmes dont dépendent d’autres personnes. Le cadre de gestion des risques liés à l’IA du NIST aborde les risques liés à la conception, au déploiement, à l’utilisation et à l’évaluation des systèmes d’IA (Tabassi, 2023). Son profil dédié à l’IA générative étend cette réflexion aux risques propres à ces technologies (Autio et al., 2024). Aucune de ces publications ne considère qu’un système autonome est fiable simplement parce qu’une personne a rempli un questionnaire. La véritable question est de savoir ce que le système est capable de faire lorsque son jugement est erroné.

Définissez clairement les responsabilités avant d’admirer la démonstration

Je commencerais par dresser un inventaire sans concession des capacités. L’agent peut-il lire des données, les modifier, les supprimer ou les transmettre ? Peut-il modifier des autorisations, exécuter du code, approuver des paiements, contacter des clients ou déclencher un workflow opérationnel ? Quels identifiants utilise-t-il ? Quels systèmes font confiance à ces identifiants ? Qui peut les retirer, et dans quel délai ? La réponse doit être suffisamment précise pour résister à un ingénieur qui demanderait à voir la configuration réelle.

Il s’agit là d’un domaine bien connu dans l’architecture de sécurité. Les recommandations du NIST en matière de « Zero Trust » axent les décisions d’accès sur les ressources et évitent explicitement d’accorder une confiance implicite en raison de l’emplacement sur le réseau ou de la propriété (Rose et al., 2020). Un agent d’IA ne mérite aucune exemption particulière à cette logique. Il doit se voir attribuer l’autorité minimale requise pour une tâche définie, et cette autorité doit être limitée par l’action, la ressource, le contexte et la durée. Si un agent doit uniquement résumer un ticket d’incident, il n’a pas besoin d’autorisation pour clôturer le ticket ou modifier le pare-feu.

Une conception particulièrement mal pensée attribue à un agent un compte de service aux droits étendus, car l’intégration d’autorisations plus granulaires retarderait le lancement. L’agent peut sembler exécuter un flux de travail inoffensif, mais ses droits d’accès peuvent s’étendre bien au-delà de l’interface visible. Il ne s’agit pas d’un problème de renseignement. C’est un problème classique de privilèges, face auquel se trouve un décideur inédit et imprévisible.

Les instructions ne constituent pas une barrière de sécurité

Une consigne système peut ordonner à un modèle de ne pas révéler de secrets ni d’effectuer d’actions non autorisées. Cette instruction peut s’avérer utile dans le cadre de la conception d’une application, mais elle n’équivaut pas à un mécanisme d’application. Un modèle traite des instructions et du contenu sous des formes qu’il peut être difficile de distinguer parfaitement. Un attaquant peut insérer des instructions malveillantes dans un document récupéré, une page web, un commentaire de référentiel ou tout autre contenu peu fiable que l’agent est censé lire. Le danger réside dans le fait que du contenu destiné à servir de preuve soit traité comme une source faisant autorité.

Le profil du NIST consacré à l’IA générative identifie les risques associés aux systèmes génératifs et encourage la gestion des risques tout au long de leur cycle de vie (Autio et al., 2024). Le cadre de développement logiciel sécurisé (Secure Software Development Framework) apporte une approche complémentaire : intégrer la sécurité dès la conception, le développement et la maintenance des logiciels plutôt que de l’ajouter après leur déploiement (Souppaya et al., 2022). Ma traduction opérationnelle est simple : partez du principe que le modèle peut être amené à demander une action qu’il ne devrait pas effectuer, puis assurez-vous que l’outil refuse cette action quoi qu’il arrive.

Un outil de synthèse de documents en lecture seule doit disposer d’un accès en lecture seule imposé par le service de gestion des documents. Un agent autorisé à rédiger un e-mail destiné à un client ne doit pas être automatiquement autorisé à l’envoyer. Un assistant de déploiement peut préparer une modification, mais son exécution en production peut nécessiter une identité distincte, une vérification de la politique et une validation. Ces limites relèvent des systèmes qui exécutent les actions, et non pas uniquement de la description rédigée à l’intention du modèle.

La validation humaine n’est utile que si un être humain est en mesure de l’évaluer

L’expression "Human in the loop" semble rassurante jusqu’à ce que l’on examine ce que l’on demande à la personne d’approuver. Si l’interface affiche un résumé vague et un bouton vert, l’utilisateur risque d’approuver une série d’actions qu’il ne peut pas vérifier. Si le système demande des centaines d’approbations chaque jour, les utilisateurs finiront par les valider sans les examiner. La surveillance devient purement formelle lorsque l’opérateur manque de temps, de preuves ou d’autorité pour intervenir.

Le cadre de gestion des risques liés à l’IA (AI RMF) met l’accent sur la gouvernance, la cartographie du contexte, la mesure des risques et leur gestion tout au long du cycle de vie (Tabassi, 2023). Je traduirais ces fonctions en un dispositif pratique d’approbation. Indiquez l’action envisagée, la ressource ciblée, le changement spécifique, la raison de ce changement, les preuves sur lesquelles l’agent s’est appuyé, ainsi que les conséquences d’un refus ou d’un retard. Pour les actions à fort impact, prévoyez une étape de mise en œuvre réversible ou un plan de retour en arrière clair. Pour les actions irréversibles, exigez un niveau d’examen plus rigoureux.

Les seuils d’approbation doivent être fonction de l’impact, et non de la nouveauté. Le fait pour un agent de renommer un projet de document interne ne nécessite pas le même niveau de contrôle que le fait de révoquer l’accès d’un employé ou de transférer des informations sensibles vers un service externe. À l’inverse, une action supposée routinière peut avoir un impact considérable lorsqu’elle est effectuée des milliers de fois. Une autorisation mineure appliquée à grande échelle peut devenir un risque très important.

Veiller à ce que les preuves puissent être reconstituées

Lorsqu’un agent prend une décision importante, je souhaite disposer de suffisamment de preuves pour reconstituer ce qu’on lui a demandé de faire, quelles informations il a utilisées, quel outil il a invoqué, quels paramètres il a envoyés, quelle politique a autorisé l’action et ce que le système externe a réellement fait. Une simple transcription de conversation ne suffit pas nécessairement à rendre compte de tout cela. L’appel de l’outil et le changement d’état qui en résulte importent davantage qu’une explication soignée générée a posteriori.

La norme NIST SP 800-53 traite du contrôle d’accès, de l’audit et de la responsabilité, de la gestion de la configuration, de l’intégrité du système et des familles de contrôles associées (Joint Task Force, 2020). Il s’agit là de bases utiles pour les flux de travail basés sur l’IA, car l’environnement d’exploitation nécessite toujours des autorisations, des journaux, des contrôles d’intégrité et des procédures en cas d’incident. Je concevrais la piste des preuves de manière à ce que les enquêteurs puissent distinguer l’action proposée par un agent d’une action menée à bien. Cette distinction devient essentielle lorsque le système affirme avoir achevé une tâche qui a échoué à mi-parcours.

Je déterminerais également ce qu’il ne faut pas consigner. Un historique complet des invites peut contenir des informations commerciales confidentielles, des dossiers clients privés ou des éléments d’authentification. Tout consigner sans tenir compte des droits d’accès et des délais de conservation crée un risque supplémentaire d’exposition. L’objectif est d’assurer un fonctionnement responsable, avec une collecte et une protection des données proportionnées, et non pas d’archiver sans discernement tout ce que l’agent a pu voir.

Testez les scénarios de défaillance, et pas seulement les scénarios de fonctionnement normal

La plupart des démonstrations montrent un agent exécutant la tâche pour laquelle il a été conçu. C’est utile, mais cela ne permet pas de garantir la sécurité des limites. Je me demanderais ce qui se passe lorsqu’un document contient des instructions malveillantes, lorsqu’un outil renvoie une réponse inattendue, lorsque l’utilisateur ne dispose pas des autorisations nécessaires, lorsque l’agent réessaie une transaction ayant échoué, ou lorsqu’une validation arrive après que les données sous-jacentes ont été modifiées. Il ne s’agit pas là de scénarios exotiques. Ce sont des modes de défaillance courants des logiciels et de la sécurité, amplifiés par un système capable de choisir son action suivante.

Le SSDF recommande des pratiques visant à remédier aux vulnérabilités et à leurs causes profondes tout au long du cycle de vie des logiciels (Souppaya et al., 2022). Pour une application agentique, j’inclurais des tests portant sur le refus d’autorisation, la validation des entrées des outils, l’idempotence le cas échéant, les limites de transaction et la reprise en toute sécurité après une défaillance partielle. Je vérifierais également si un document compromis ou une source de données moins fiable peut amener l’agent à demander une action en dehors de son flux de travail légitime. Une requête bloquée constitue un contrôle efficace, même si l’explication fournie par le modèle semble parfaitement convaincante.

La responsabilité des risques doit perdurer au-delà du déploiement. Une personne doit être chargée de modifier les autorisations lorsque le flux de travail s’étend, d’examiner les exceptions récurrentes, de réagir à toute utilisation suspecte des outils et de désactiver l’agent si nécessaire. Le cadre NIST CSF 2.0 fait de la gouvernance une fonction distincte pour une bonne raison : les contrôles techniques ne déterminent pas qui est responsable de l’acceptation des risques d’entreprise (Pascoe et al., 2024).

Fournissez à l’opérateur un véritable bouton d’arrêt

Un système d’IA utile doit pouvoir être arrêté sans qu’il soit nécessaire de se lancer dans une chasse au trésor à travers les consoles cloud et les intégrations non documentées. Je souhaiterais disposer d’une procédure bien définie pour suspendre ses identifiants, interrompre les actions en file d’attente, révoquer les sessions en cours lorsque cela est possible, et identifier les transactions qui ont peut-être déjà été menées à bien. L’équipe doit savoir si l’arrêt de l’interface entraîne également l’arrêt des tâches en arrière-plan. Si ce n’est pas le cas, la procédure d’urgence doit le préciser.

La restauration mérite la même attention. Si l’agent a modifié des règles d’accès, édité des enregistrements ou déclenché des flux de travail externes, le fait de le désactiver n’annule pas ces modifications. L’organisation doit savoir ce qui peut être annulé, ce qui doit être réconcilié manuellement et quelles parties en aval ont pu recevoir des informations. Les recommandations en matière de réponse aux incidents s’appliquent ici tout autant qu’aux autres processus métier dépendants de logiciels (Nelson et al., 2025).

Il ne s’agit pas d’exclure l’IA de la production. Il s’agit de permettre à des systèmes utiles d’accomplir un travail utile sans transformer subrepticement la commodité en une autorité incontrôlable. Un système qui fait gagner des heures mais qui ne peut expliquer ni limiter ce qu’il modifie propose un compromis que l’organisation pourrait ne pas comprendre.

Ce que j’approuverais en premier lieu

Avant d’autoriser un agent ayant un impact significatif, je souhaiterais disposer d’une cartographie claire des ressources et des autorisations, d’une mise en œuvre explicite au niveau des outils, de seuils d’approbation proportionnés, d’une preuve exploitable, de tests des scénarios de défaillance, ainsi que d’une procédure documentée d’arrêt et de reprise. Il s’agit là d’attentes techniques courantes. L’IA ne les rend pas obsolètes ; elle rend leur absence plus difficile à justifier.

Si vous intégrez des agents dans des flux de travail réels et que vous devez déterminer jusqu’où leur autonomie doit s’arrêter, je peux vous aider à transformer cette question en contrôles applicables et en un modèle opérationnel que votre équipe pourra défendre. Discutons ensemble de votre déploiement d’IA.