Sécuriser un agent IA qui a accès à vos outils

La sécurité d'un agent IA devient un sujet dès l'instant où l'agent cesse de produire du texte pour commencer à agir. Tant qu'un modèle rédige un brouillon, le pire scénario est une bêtise que quelqu'un relit. Dès qu'il peut interroger une base, envoyer un message ou modifier une fiche, le pire scénario change de nature.

La difficulté tient à une confusion de vocabulaire. On parle d'un agent comme d'un collaborateur : on lui « donne accès », on lui « fait confiance ». C'est trompeur. Un agent est un compte de service dont les décisions sont dictées par du texte, y compris du texte qu'il lit dans les données qu'il traite.

Cet article applique aux agents le principe du moindre privilège : délimiter un périmètre d'outils, interdire certaines actions, placer la validation humaine au bon endroit, et journaliser assez pour reconstituer ce qui s'est passé. Avec, pour finir, une check-list de mise en production.

Sécurité agent IA : raisonner en compte de service

Le bon modèle mental est celui d'un compte technique : périmètre écrit, droits minimaux, rotation de secret, journalisation. Personne ne lui « fait confiance », on vérifie ce qu'il peut faire.

Une différence essentielle sépare toutefois l'agent du compte de service classique, et c'est elle qui rend le sujet particulier. Un script exécute une suite d'instructions décidée à l'avance. Un agent décide de ses actions à l'exécution, à partir d'un texte, et ce texte peut provenir d'une source qu'il ne contrôle pas : un courriel entrant, une page consultée, un ticket, un document déposé par un tiers. Comme nous l'avions posé en définissant ce qu'est un agent IA, c'est précisément la boucle de décision qui fait sa valeur et son risque.

Trois conséquences pratiques en découlent :

• Toute donnée lue est une instruction potentielle. Un contenu externe peut contenir des consignes destinées à l'agent. Il faut concevoir en supposant que cela arrivera.
• Les droits de l'agent sont les droits de l'attaquant. Si un contenu malveillant réussit à orienter l'agent, il agit avec tout ce que l'agent peut faire. Réduire le périmètre est donc la mesure la plus efficace, avant toute technique de détection.
• La sortie de l'agent n'est pas fiable par construction. Elle ne doit jamais être exécutée directement, ni injectée telle quelle dans une requête, une commande ou une page.

Le classement de référence des risques des applications à base de modèles de langage, publié par l'OWASP, nomme explicitement ce problème sous l'appellation d'autonomie excessive : donner à un système plus de capacités, de permissions ou d'indépendance que ce que sa fonction exige.

Délimiter le périmètre d'outils

C'est la décision la plus structurante, et elle se prend avant la première ligne de code. La règle est celle de la liste blanche : l'agent n'a accès qu'à des outils explicitement déclarés, jamais à une capacité générique.

Quatre principes de conception rendent ce périmètre défendable.

1. Un outil, une capacité, un verbe. Préférez dix outils précis (« lire une fiche client », « créer un brouillon de réponse », « ajouter une note ») à un outil général (« exécuter une requête SQL », « appeler cette adresse »). Un outil générique annule toute délimitation, puisqu'il permet tout ce que permet le système sous-jacent.
2. Séparez la lecture de l'écriture. Deux identifiants distincts, deux jeux de droits. Beaucoup d'agents utiles n'ont besoin que de lire, et le découvrir tôt évite des débats inutiles.
3. Filtrez au niveau de la source, pas du prompt. Une consigne du type « ne consulte jamais les dossiers du service paie » n'est pas un contrôle d'accès : c'est une suggestion. Le filtrage doit être appliqué par le système qui détient la donnée, avec l'identité effective de l'utilisateur quand c'est possible.
4. Bornez les paramètres. Un outil d'envoi de message n'accepte que des destinataires figurant dans l'annuaire. Un outil de remboursement plafonne le montant. Un outil de recherche limite le nombre de résultats. Ces bornes sont dans le code de l'outil, pas dans la consigne.

Ce raisonnement vaut quel que soit le mécanisme de connexion, y compris lorsque les outils sont exposés par un protocole standardisé comme le protocole MCP. Un standard facilite le branchement, il ne décide pas des droits à votre place : un serveur d'outils tiers s'évalue comme n'importe quelle dépendance.

Les actions à ne jamais laisser en autonomie

Le critère de tri est la réversibilité, pas la sensibilité perçue. Une action réversible peut être corrigée après coup ; une action irréversible ne se rattrape pas, et un taux d'erreur de 1 % devient alors inacceptable.

La dernière ligne est la plus souvent oubliée, et c'est pourtant elle qui produit les incidents les plus spectaculaires : une action inoffensive répétée quatre mille fois en dix minutes devient un incident majeur. Un plafond par exécution et un plafond par heure, appliqués côté outil, coûtent une demi-journée.

Placer la validation humaine sans tuer l'intérêt

Une validation systématique supprime le bénéfice de l'agent et se dégrade d'elle-même : au bout de deux semaines, la personne valide sans lire. Une validation bien placée repose sur des règles.

Quatre déclencheurs couvrent l'essentiel des situations :

• Le seuil de montant. En dessous, l'agent agit ; au-dessus, il propose. Le seuil se fixe sur le coût d'une erreur, pas sur le confort.
• Le destinataire hors périmètre. Toute action visant une entité absente de vos référentiels passe en validation.
• La volumétrie inhabituelle. Un écart significatif par rapport au comportement observé déclenche une pause, même si chaque action est autorisée.
• La faible confiance. Quand l'agent n'a pas trouvé l'information demandée ou a dû faire une hypothèse, il escalade au lieu de trancher. Cela suppose de prévoir explicitement un chemin « je ne sais pas », faute de quoi il inventera.

Trois conditions rendent la validation utile : elle contient l'action exacte proposée et non un résumé, elle arrive là où la personne travaille déjà, et elle expire au bout de vingt-quatre heures sans réponse plutôt que de s'exécuter par défaut.

Journaliser pour pouvoir reconstituer

Le jour où quelque chose se passe mal, la question sera : qu'a fait l'agent, sur ordre de qui, avec quelles données. Sans journal complet, il n'y a pas de réponse, donc pas de correction possible et pas de retour en production.

Le minimum à enregistrer pour chaque étape :

• L'identifiant de corrélation de la session, qui relie toutes les actions d'une même tâche.
• La demande initiale et son origine (utilisateur, déclencheur automatique, message entrant).
• Chaque outil appelé, avec ses paramètres complets et le résultat renvoyé.
• L'identité effective utilisée pour l'appel, qui n'est pas toujours celle du demandeur.
• Les décisions de garde-fou : blocage, escalade, validation accordée et par qui.
• La version du modèle et de la consigne système en vigueur au moment de l'exécution.

Ce dernier point est régulièrement omis et se paie cher. Une consigne système modifiée sans versionnement rend tout incident inanalysable, puisque le comportement observé n'est plus reproductible. Traitez vos consignes comme du code : versionnées, revues, déployées.

Attention enfin à ne pas transformer le journal en fuite de données : les paramètres d'appel contiennent souvent des données personnelles. Le journal suit les mêmes règles de conservation et d'accès que la donnée d'origine, secrets masqués.

Les modes de défaillance propres aux agents

Cinq schémas reviennent, et mieux vaut les connaître avant de les rencontrer.

1. L'autonomie excessive. L'agent dispose de droits dont sa tâche n'a pas besoin. C'est la cause première, celle qui transforme un incident mineur en incident majeur.
2. L'instruction cachée dans les données. Un contenu traité par l'agent contient une consigne qui détourne son comportement. La parade n'est pas un filtre parfait, qui n'existe pas, mais la limitation des droits et la validation des actions sensibles.
3. Le mandataire trompé. L'agent dispose de droits plus étendus que l'utilisateur qui le sollicite, et devient un moyen de contourner les habilitations. Propager l'identité de l'utilisateur jusqu'à la source de données est la seule vraie réponse.
4. La boucle. L'agent répète une action qui échoue, ou déclenche un traitement qui le rappelle. Un plafond d'itérations, un plafond de coût et un délai maximal par tâche sont indispensables.
5. L'exfiltration par un outil de sortie. L'agent lit une donnée sensible puis l'envoie ailleurs par un outil légitime (message, appel externe, écriture dans un document partagé). Restreindre les destinations autorisées est plus efficace que tenter de détecter le contenu.

Ces schémas ne sont pas propres à l'IA : ce sont des problèmes classiques de contrôle d'accès appliqués à un composant non déterministe. Les principes qui valent pour sécuriser des workflows d'automatisation restent valables, avec une exigence de bornage en plus.

Check-list de mise en production

À passer avant toute exposition à des données ou des utilisateurs réels.

• Le périmètre d'outils est écrit, limité, et chaque outil a des paramètres bornés.
• Aucun outil générique d'exécution (requête libre, commande système, appel arbitraire) n'est exposé.
• Lecture et écriture utilisent des identités distinctes, avec des droits minimaux.
• Les actions irréversibles sont interdites ou passent par une validation nominative.
• Des plafonds sont en place : itérations, coût, volume par exécution, volume par heure.
• Un interrupteur d'arrêt existe et a été testé, pas seulement documenté.
• La journalisation permet de reconstituer une session complète, avec version de consigne.
• Les secrets sont hors des consignes et hors des journaux, avec rotation prévue.
• Un jeu de cas de test inclut des tentatives de détournement par le contenu traité.
• Un responsable est nommé, avec une revue périodique des droits accordés.

Deux références permettent d'ancrer la démarche dans un cadre reconnu : les recommandations de sécurité de l'ANSSI pour les systèmes d'IA générative, et le cadre de gestion des risques du NIST.

Ce qu'il faut retenir

La sécurité d'un agent IA ne se joue pas sur la qualité du modèle mais sur l'étendue de ce qu'il peut faire. Un agent restreint à cinq outils précis, sans action irréversible, avec des plafonds et un journal complet, reste maîtrisable même s'il se trompe. Un agent disposant d'un accès large à vos systèmes reste dangereux même s'il se trompe rarement.

Le réflexe à installer est celui de la revue de droits : listez ce que votre agent peut faire, retirez tout ce dont sa tâche n'a pas strictement besoin, et vérifiez qu'il fonctionne encore. Dans la grande majorité des cas, il fonctionne, et vous venez de supprimer l'essentiel du risque sans rien perdre en utilité.