Sécuriser un agent IA ne consiste plus seulement à sécuriser un modèle
La sécurité d’un agent IA dépend autant de ce qu’il est techniquement autorisé à faire que de la qualité du modèle qui le pilote.
Un assistant conversationnel produit du contenu. Un agent consulte des données, appelle des API, utilise des outils et déclenche des actions dans des systèmes réels. Le défaut ne se traduit donc plus par une réponse fausse que l’utilisateur peut ignorer, mais par une écriture, un envoi ou une suppression que quelqu’un devra corriger.
Le NISTa publié en mai 2026 la synthèse des réponses à sa consultation sur la sécurité des agents. Deux constats y font consensus : les agents introduisent des menaces réellement nouvelles, et ces préoccupations de sécurité constituent elles-mêmes un frein à l’adoption. Les répondants s’accordent sur une nuance importante : les principes fondamentaux de la cybersécurité restent pertinents, mais demandent à être adaptés pour traiter correctement le cas des agents. En parallèle, le centre CAISI de l’institut mène des travaux sur l’identité et l’autorisation des agents, et sur les évaluations de sécurité qui permettront de les mesurer.
Cette adaptation ne peut pas reposer sur la seule robustesse du modèle. Le NIST en avait donné une illustration nette dès janvier 2025 : en concevant, avec son homologue britannique, de nouvelles attaques de détournement adaptées au modèle évalué, ses équipes ont fait passer le taux de réussite de 11 % pour la meilleure attaque connue à 81 % pour la meilleure attaque nouvelle, sur un banc d’essai standardisé. L’exercice portait sur un modèle daté, mais sa leçon de méthode ne l’est pas : un modèle qui résiste aux attaques publiées ne résiste pas nécessairement à celles qui seront écrites contre lui.
La question opérationnelle n’est donc pas seulement de savoir si l’agent produira la bonne réponse, mais ce qu’il peut atteindre le jour où il se trompe ou se fait manipuler. C’est cette surface d’action que les sept contrôles suivants cherchent à réduire.
Pourquoi les permissions deviennent-elles critiques avec les agents IA ?
Un agent connecté à un CRM, à une messagerie ou à une base documentaire dispose d’une surface d’action qu’un modèle isolé ne possède pas. Pour la cartographier, il faut distinguer trois périmètres qui, en pratique, ne coïncident jamais. Le premier est ce que le prompt demande à l’agent de faire : une intention exprimée en langage naturel, que rien n’empêche de contredire. Le deuxième est ce que l’application prévoit qu’il puisse faire : les outils exposés, les workflows conçus, les garde-fous applicatifs. Le troisième est ce que ses identifiants l’autorisent techniquement à faire, indépendamment de toute intention.
Seul le troisième constitue une barrière de sécurité, parce qu’il est le seul évalué par le système cible au moment de l’appel. Les deux premiers décrivent un comportement attendu, le troisième décrit un pouvoir réel, et tout l’écart entre les deux est du risque non gouverné.
C’est précisément cet écart qu’exploite le prompt injection, ces instructions dissimulées dans un contenu que l’agent traite (une page web, une pièce jointe, un ticket, un email) et qui le détournent de sa tâche. OpenAIdécrit ces attaques comme un problème de long terme pour tout agent exposé à des données externes, et les rapproche de l’ingénierie sociale plutôt que du contournement technique. Sa recommandation principale découle de ce constat : concevoir le système pour que l’impact d’une manipulation reste borné, notamment en restreignant l’accès aux outils, plutôt que de miser sur le seul filtrage des entrées. Un prompt n’est pas un système d’autorisation.
1. Donner une identité propre à chaque agent
Un agent qui accède au système d’information doit être identifiable indépendamment de l’utilisateur qu’il sert et des autres agents. Microsoften a fait un prérequis explicite dans ses recommandations de juillet 2026 : une identité dédiée par agent, avec un propriétaire nommé, une finalité documentée, un périmètre d’accès défini et un journal d’actions. À l’inverse, les agents lancés sous un secret partagé ou un compte de service mutualisé rendent impossible de déterminer quel acteur répond d’une action.
Cette séparation sert d’abord l’enquête. En cas d’incident, il faut pouvoir répondre en quelques minutes à une question simple : cette action a-t-elle été effectuée par l’utilisateur, par l’agent pour le compte de l’utilisateur, ou par l’agent de sa propre initiative ? Sans identité distincte ni contexte de délégation journalisé, ces trois cas produisent la même trace, et la chaîne de responsabilité se dissout au moment précis où elle devient nécessaire.
2. Appliquer réellement le principe du moindre privilège
Le principe est ancien, mais son application aux agents bute sur une facilité de développement : il est plus rapide d’accorder un accès large que de modéliser un rôle. Un agent qui doit consulter une fiche client reçoit l’accès au CRM entier, un agent qui doit analyser un message reçoit la boîte mail complète, un agent qui utilise deux points d’entrée d’une API reçoit la clé qui les expose tous. Chacun de ces raccourcis est invisible tant que rien ne va mal, et déterminant le jour où quelque chose va mal.
La contre-mesure consiste à raisonner par tâche plutôt que par système. Microsoft recommande des rôles calibrés sur une unité de travail précise (récupérer des documents en lecture seule, créer un brouillon de ticket) et bornés à une ressource identifiée, en séparant explicitement le rôle de lecture du rôle d’écriture : un agent qui rassemble des éléments puis ouvre un ticket n’a aucune raison de pouvoir en supprimer. Les outils accessibles sont eux-mêmes déclarés par liste blanche, les intégrations non revues étant refusées par défaut.
Lorsqu’une tâche exige réellement un privilège élevé, mieux vaut le rendre temporaire que permanent. L’élévation à la demande, avec un jeton de courte durée ou une activation de rôle limitée dans le temps, ramène le privilège à zéro dès la fin du workflow. Le périmètre doit enfin être réexaminé chaque fois que les outils, les données ou l’environnement de l’agent changent : une permission justifiée au lancement ne l’est plus forcément six mois plus tard.
3. Auditer les permissions effectives, pas seulement celles documentées
C’est le contrôle le plus souvent négligé, parce qu’il oblige à confronter l’architecture décrite à celle qui s’exécute. Un schéma peut indiquer qu’un agent n’atteint que trois services alors que les identifiants qu’il utilise lui en ouvrent dix. Le décalage n’est presque jamais intentionnel : il vient d’un accès élargi pendant un pilote et jamais resserré, d’un rôle hérité d’un autre usage, d’un secret réutilisé pour aller vite.
Microsoft insiste sur un mécanisme moins visible encore : le risque naît souvent de l’agrégation. Plusieurs rôles individuellement raisonnables se combinent en une capacité qui ne l’est plus, et ouvrent un enchaînement d’actions à fort impact qu’aucun d’eux n’autorisait seul. Auditer les permissions consiste donc à mesurer ce que l’agent peut faire de bout en bout, à travers ses rôles, ses outils et les systèmes en aval, plutôt qu’à examiner des habilitations une à une.
| Contrôle | Question à poser |
|---|---|
| Identité | L’agent dispose-t-il d’une identité propre ? |
| Données | Quelles données peut-il réellement lire ? |
| Écriture | Que peut-il modifier ou supprimer ? |
| Outils | Quelles actions chaque outil expose-t-il ? |
| Secrets | À quels credentials peut-il accéder ? |
| Réseau | Quelles destinations peut-il joindre ? |
| Délégation | Peut-il agir avec les droits d’un utilisateur ? |
| Agrégation | Que permet la combinaison de tous ses rôles ? |
4. Isoler l’environnement d’exécution
Les trois premiers contrôles définissent ce que l’agent a le droit de faire. L’isolation définit ce qu’il peut atteindre lorsqu’il sort de ce cadre. Dès qu’un agent exécute du code, navigue sur Internet ou branche des outils externes, son environnement d’exécution devient la dernière frontière avant le reste du SI, et c’est elle qui décide si une injection réussie reste un incident contenu ou devient une compromission.
Le réseau est la frontière la plus déterminante, parce que c’est par lui que sortent les données : restreindre les destinations joignables à une liste explicite prive une attaque de son canal d’exfiltration, même lorsqu’elle a réussi à faire lire un document confidentiel à l’agent. Le système de fichiers vient ensuite : un espace de travail éphémère, recréé à chaque exécution, empêche qu’un artefact déposé pendant une session influence la suivante. Les processus doivent être cloisonnés à leur tour, afin que le code produit ou récupéré par l’agent s’exécute sans droits sur la machine hôte.
Restent les éléments que l’agent ne devrait jamais pouvoir lire. Les secrets n’ont pas leur place dans un contexte que le modèle peut restituer : ils sont détenus par la couche d’exécution, qui signe les appels pour son compte. Les données sensibles se filtrent avant d’entrer dans le contexte plutôt qu’après, et les services accessibles se limitent à ceux dont le workflow a besoin. La règle qui unifie ces frontières est celle du refus par défaut : ce qui n’est pas nécessaire au workflow n’est pas accessible, et chaque ouverture est une décision explicite, documentée et réversible.
5. Journaliser les actions, pas seulement les conversations
La plupart des dispositifs de traçabilité mis en place autour des agents enregistrent la conversation : le prompt, la réponse, parfois le contexte. Microsoft identifie là une faiblesse récurrente : les journaux capturent la réponse produite, mais pas les appels d’outils sous-jacents, les périmètres réellement utilisés ni les décisions d’autorisation prises en aval, c’est-à-dire exactement ce dont une investigation ou une demande de conformité a besoin.
Une trace exploitable doit permettre de reconstruire la chaîne complète, de l’agent jusqu’à la ressource : quelle identité, quel rôle, quel périmètre effectif, quelle action, sur quelle ressource, pour le compte de quel utilisateur, et avec quel identifiant de corrélation reliant l’appel de l’orchestrateur aux systèmes appelés. Cet identifiant de corrélation fait toute la différence entre un journal consultable et un journal reconstructible : sans lui, chaque système ne détient qu’un fragment, et personne ne détient la séquence.
Googleformule la même exigence sous l’angle de l’observabilité, qu’il définit comme la capacité à comprendre l’état interne et le comportement d’un agent : interactions avec le modèle, usage des outils, raisonnement et enchaînement des actions, performances et ressources consommées, sécurité (application des politiques, opérations risquées, schémas d’accès) et qualité des résultats. Sécurité et observabilité agentique reposent donc sur la même instrumentation ; elles n’en tirent simplement pas les mêmes conclusions.
6. Prévoir des actions nécessitant une validation humaine
L’autonomie n’a aucune raison d’être uniforme sur l’ensemble des actions d’un agent. Une recherche documentaire et un virement bancaire n’engagent pas les mêmes conséquences, et il est logique que le second passe par une approbation quand le premier s’exécute seul. Microsoft recommande de placer derrière une approbation explicite les opérations destructrices ou à fort impact, suppression, export, modification de privilèges, ainsi que les traitements en masse.
La condition de fond est que cette validation soit imposée par le système, et non demandée dans le prompt. La séquence doit être déterministe : l’agent propose, un humain valide, le système exécute, et l’exécution reste techniquement impossible sans le jeton d’approbation. Une consigne du type « demande confirmation avant toute suppression » relève du premier périmètre décrit plus haut, celui que rien n’oblige à respecter.
Ce contrôle a un coût qu’il vaut mieux assumer que subir : multiplier les demandes de validation produit une approbation réflexe qui ne vérifie plus rien. Le point de contrôle humain doit donc être réservé aux actions dont l’impact le justifie, ce qui suppose d’avoir classé ces actions par niveau de risque en amont, comme le propose notre matrice d’autonomie par impact.
7. Prévoir la révocation avant l’incident
Le dernier contrôle est celui que l’on découvre en général au pire moment. Un système sécurisé doit permettre de répondre immédiatement à une seule question : comment arrêtons-nous cet agent, maintenant ? La réponse ne tient pas en un geste. Il faut pouvoir désactiver l’identité, invalider les jetons déjà émis, faire tourner les secrets, retirer les permissions résiduelles et interrompre les workflows en cours. Sans quoi la coupure n’est que partielle : une identité désactivée laisse vivre les jetons émis avant elle, et un secret non renouvelé reste utilisable ailleurs.
Microsoft range d’ailleurs le test de ces chemins parmi les tâches d’hygiène opérationnelle, au même titre que la revue d’accès, et propose d’en suivre le délai moyen comme un indicateur à part entière. C’est la seule façon de transformer une procédure décrite en capacité vérifiée : un mécanisme de révocation qui n’a jamais été déclenché reste une hypothèse.
Ce que ces sept contrôles déplacent
Le passage de l’assistant à l’agent ne supprime pas les enjeux liés au modèle, il en ajoute un autre, de nature différente. Maîtriser ce que le modèle génère reste un travail de qualité ; borner ce que le système peut faire est un travail d’architecture, et c’est celui-là qui détermine la gravité d’un incident.
L’unité de sécurité pertinente n’est donc plus le modèle seul, mais l’ensemble formé par l’agent, son identité, ses outils, ses permissions effectives et son environnement d’exécution. C’est aussi ce qui rend le problème traitable : contrairement à la robustesse d’un modèle face à des attaques encore inconnues, ces cinq éléments se conçoivent, se testent et se vérifient.
