Un rôle administrateur n'est pas une politique de sécurité pour un agent IA
Pourquoi l'IAG, le coffre de secrets et l'autorisation au runtime doivent fonctionner ensemble. Un agent IA autonome ne doit pas recevoir le pouvoir associé au rôle technique que l'application nous oblige à lui attribuer ; il doit recevoir uniquement la capacité d'exécuter l'action pour laquelle il a été créé.
Un export CRM, un agent, et un rôle qui déborde
Nous utilisons nous-mêmes des Autonomous AI Agents pour automatiser certaines opérations internes. Un collaborateur autorisé peut leur adresser une demande depuis une interface conversationnelle simple — Telegram, WhatsApp — sous la forme d'une phrase du type « prépare l'export quotidien du CRM et transmets-le à l'outil de pilotage ». Derrière cette phrase, l'agent doit comprendre la tâche, sélectionner les outils utiles, interroger le CRM, générer l'export, en contrôler le format, transmettre le résultat à l'outil destinataire et signaler la réussite ou l'erreur.
Les secrets nécessaires à ces connexions ne sont pas écrits dans les prompts ni dans les messages. Ils sont conservés dans un Secret Vault. Lorsque c'est possible, les agents utilisent des accès OAuth 2.0 limités aux OAuth Scopes strictement nécessaires. Les secrets ou jetons sont fournis au composant technique chargé de l'appel — un Credential Broker — sans être exposés au modèle ou à l'utilisateur de la messagerie. Cette architecture réduit fortement l'exposition. Elle ne règle pourtant pas tout.
L'export doit contenir uniquement les informations utiles au pilotage : identifiant de l'opportunité, statut, montant, date prévisionnelle, responsable commercial et quelques attributs de reporting. Il ne doit pas contenir les notes confidentielles, les coordonnées personnelles inutiles, les pièces jointes, les secrets techniques, les données d'autres objets du CRM ni l'intégralité de l'historique. Sur le papier, la tâche est simple. Le problème apparaît au moment d'intégrer le CRM. L'application ne propose pas nécessairement un droit intitulé « exporter uniquement ces six champs, une fois par jour, vers cette destination ». Elle propose des rôles beaucoup plus larges — utilisateur, gestionnaire, intégrateur, administrateur — et, dans le cas observé, l'accès à l'API d'export nécessite un rôle administrateur.
L'Identity Governance peut gouverner l'attribution de ce rôle administrateur. Elle ne peut pas inventer une granularité que l'application ne possède pas. Elle ne peut pas transformer un rôle applicatif grossier en droit d'export limité si l'application elle-même ne sait pas l'exprimer. C'est précisément là que la conversation change de nature, et que la Fine-Grained Authorization au runtime devient utile.
Un agent explore les outils, pas les intentions de l'entreprise
Un agent autonome ne se contente pas toujours de rejouer une séquence figée. Pour atteindre l'objectif qui lui a été donné, il peut comparer plusieurs méthodes, explorer les outils mis à sa disposition, lire la documentation accessible, tester un endpoint, adapter sa requête après une erreur, choisir un autre chemin, combiner plusieurs actions ou recommencer avec des paramètres différents. C'est précisément la faculté qui fait sa valeur : elle permet de trouver une manière efficace de réaliser la mission sans qu'un développeur décrive chaque étape.
Cette faculté modifie la manière de penser la sécurité. Avec un script classique, nous examinons le code écrit. Avec un agent autonome, nous devons surtout maîtriser l'espace des actions qu'il peut décider d'explorer. Le risque ne vient pas d'une intention hostile de sa part. Il vient de sa capacité à chercher une solution à l'intérieur du périmètre technique qui lui a été ouvert.
Nous ne sécurisons pas seulement le chemin que nous imaginons que l'agent empruntera. Nous sécurisons tous les chemins que ses outils lui permettent d'emprunter. Cette formulation gouverne la conception de l'architecture, la manière d'écrire les politiques et le choix du point d'application. Elle explique aussi pourquoi une consigne écrite dans un prompt ne joue pas le même rôle qu'un contrôle technique exécuté par un composant extérieur au modèle.
Six affirmations à confronter à la réalité
Nous entendons régulièrement les mêmes formulations, dans les projets d'automatisation à base d'agents autonomes. Chaque affirmation contient une part de vérité. Aucune ne suffit, prise seule, à protéger la mission.
- 01
« Notre IAG gère les agents IA »
Une plateforme d'Identity Governance peut créer l'Agent Identity, lui affecter un propriétaire, provisionner son compte, gérer son cycle de vie, lui attribuer un rôle, organiser sa recertification et supprimer son accès à la fin du besoin. C'est utile et nécessaire. Nous posons alors une autre question. Que se passe-t-il après que l'agent a reçu le rôle administrateur ? Peut-il appeler uniquement l'API d'export, ou peut-il aussi supprimer une opportunité, créer un nouvel administrateur, modifier les paramètres du CRM, consulter toutes les données, télécharger toutes les pièces jointes, modifier les règles d'automatisation ? Si la réponse dépend uniquement du rôle configuré dans le CRM, l'IAG couvre proprement l'attribution du droit sans en réduire l'usage. Gouverner proprement un rôle administrateur ne rend pas ce rôle moins administrateur.
- 02
« OAuth applique déjà le moindre privilège »
OAuth apporte une protection essentielle. L'agent n'a pas besoin de connaître le mot de passe d'un utilisateur : il reçoit un Access Token limité dans le temps, destiné à une API précise, associé à un Client Credentials identifié, restreint à certains scopes, révocable. Nous privilégions cette approche chaque fois que l'application la permet. La qualité du Least Privilege dépend toutefois de la granularité des scopes exposés par l'application cible. Une API peut proposer `crm.read`, `crm.write` et `crm.admin` sans jamais offrir `opportunities.read.selected-fields`, `export.once-per-day`, `send-only-to-reporting-platform`, `deny-attachments` ou `deny-user-administration`. Si l'export impose `crm.admin`, le jeton est correctement limité au scope le plus petit disponible, mais ce scope reste trop large pour la mission réelle. Le scope le plus petit proposé par l'éditeur n'est pas toujours le privilège minimal dont le processus a réellement besoin. Le protocole fait ce pour quoi il est conçu ; la limite se trouve dans le modèle d'autorisation exposé par l'application cible.
- 03
« Les secrets sont dans un vault, le risque est traité »
Keeper — ou un autre Secret Vault — protège des éléments essentiels : client secrets, Refresh Tokens, clés API, certificats, mots de passe techniques. Le secret n'est pas copié dans Telegram, WhatsApp, un prompt, un fichier de configuration ou un dépôt de code. Un composant de confiance, le Credential Broker, récupère le secret ou échange le refresh token contre un access token temporaire, et l'agent utilise ensuite la connexion sans manipuler le secret brut. Le coffre couvre le stockage, la distribution, la rotation, la révocation et la traçabilité de l'usage. Il ne contrôle pas automatiquement toutes les actions permises par le jeton une fois obtenu. Une fois qu'un jeton administrateur valide a été émis, le fait que son secret d'origine soit parfaitement protégé n'empêche pas son utilisation pour une action non souhaitée. Le coffre protège le moyen d'obtenir le pouvoir. Il ne définit pas, à lui seul, la manière dont ce pouvoir sera exercé.
- 04
« La consigne du prompt suffit »
Un prompt peut préciser « exporte uniquement les opportunités et ne modifie jamais le CRM ». L'instruction est utile ; elle décrit le comportement attendu. Elle ne constitue pas une frontière de sécurité. L'agent peut mal interpréter une instruction, sélectionner un outil trop puissant, appeler un endpoint différent après une erreur, recevoir une donnée externe contenant une instruction ambiguë, choisir une méthode techniquement valide mais non prévue, ou produire une requête avec un périmètre trop large. Le prompt exprime l'intention. La politique d'autorisation fixe la limite. Une consigne que l'agent peut interpréter n'est pas équivalente à une interdiction qu'il ne peut pas contourner.
- 05
« La solution fait du PBAC pour les agents »
Une plateforme peut effectivement évaluer une politique PBAC pour un agent. Nous demandons alors où se situe le Policy Enforcement Point et si l'agent peut le contourner. Si l'agent reçoit directement le client secret, le refresh token, l'access token administrateur et l'adresse de l'API du CRM, et peut appeler librement cette API, une politique évaluée ailleurs ne limite pas réellement son pouvoir. Toutes les actions sensibles doivent passer par un PEP — API Gateway, proxy d'outils, service intermédiaire, broker de capacités, composant intégré à l'orchestrateur de l'agent. Une politique que l'agent peut contourner n'est pas une politique d'autorisation. C'est une recommandation d'usage.
- 06
« L'agent est supervisé par un humain »
Cette phrase revient souvent. Nous demandons quelles actions nécessitent réellement une approbation, comment l'identité de l'approbateur est vérifiée, à quel moment la validation intervient, et ce que fait l'agent lorsque la validation n'arrive pas. Une commande envoyée depuis Telegram ou WhatsApp transporte une intention humaine ; elle ne remplace pas le contrôle d'autorisation. Pour une action sensible, la politique peut imposer un utilisateur appartenant à un groupe autorisé, une demande durant une plage définie, une confirmation, une double validation, une exécution limitée à un environnement précis, et une justification conservée dans le journal. La simplicité de l'interface ne doit jamais être confondue avec la simplicité de la décision de sécurité.
Une architecture d'agent IA ne se juge pas à la liste de contrôles annoncés. Elle se juge à l'action que l'agent peut encore exécuter lorsque chacun de ces contrôles est contourné ou mal interprété.
Une chaîne à cinq maillons, aucun ne suffit seul
Dans le scénario de l'export CRM, l'agent demande l'exécution de l'outil « Export CRM », le composant d'outillage identifie l'agent et le contexte, la politique autorise ou refuse l'action, le broker récupère le secret dans le vault, il obtient un jeton OAuth, il exécute uniquement l'appel autorisé, il filtre éventuellement les champs, il transmet le résultat vers la destination approuvée, il conserve une trace, et le jeton expire ou est détruit. L'agent ne reçoit pas un accès administrateur réutilisable en dehors de cette chaîne. Chaque composant y joue un rôle précis — et aucun n'y suffit seul.
- Netwrix Identity Manager
- Netwrix Identity Manager gouverne l'identité de l'agent au même titre que celle d'un collaborateur : nom explicite, finalité, propriétaire métier, propriétaire technique, application source, application cible, criticité, date de création, durée de vie, processus de modification et de suspension, date de revue, justification pour chaque habilitation. Il détermine que l'agent existe légitimement, qu'il appartient au processus d'export CRM, qu'il peut obtenir le rôle applicatif requis, qu'il doit être recertifié, qu'il doit être désactivé si le processus disparaît et qu'il ne doit pas utiliser ses droits pour une autre mission. Il gouverne le fait que l'agent puisse obtenir le droit. Il ne transforme pas automatiquement un droit applicatif grossier en permission métier précise.
- Keeper
- Keeper protège les secrets nécessaires aux connexions — client secrets, refresh tokens, clés API, certificats, mots de passe techniques. Le secret est conservé, distribué et renouvelé de manière contrôlée. Il n'est pas injecté dans un prompt ni transmis dans la messagerie. Le coffre ne décide toutefois pas si l'appel API réalisé avec le jeton est conforme à la finalité de l'agent : cette décision se prend ailleurs, sur le chemin obligatoire de l'appel.
- OAuth et l'Access Management
- OAuth permet de fournir à l'agent ou au broker un jeton temporaire sans partager un mot de passe. Les scopes sont limités autant que l'application le permet. Ping Identity, Microsoft Entra ID, Keycloak ou les mécanismes propres à l'application peuvent intervenir dans l'émission et la gestion de ces jetons selon l'architecture. La Delegated Authorization couvre proprement le Machine-to-Machine Access. La granularité effective reste néanmoins bornée par les capacités de l'API cible.
- Axiomatics
- Axiomatics porte la Runtime Authorization. La politique combine l'identité de l'agent, son propriétaire, sa finalité, l'action demandée, la ressource, la destination, l'horaire, le volume, la classification des données, le demandeur humain et l'environnement. Le moteur peut refuser les endpoints de suppression, les opérations d'écriture, l'administration des utilisateurs, la lecture des pièces jointes, les champs non nécessaires, une destination non approuvée, un export déclenché hors du contexte autorisé, un volume anormal ou une action sans propriétaire ou demandeur identifiable. Il ne protège réellement l'action que si sa décision est appliquée sur le chemin obligatoire de l'appel.
- Le proxy d'outils ou l'API Gateway
- C'est le Policy Enforcement Point. Il intercepte les actions, limite les endpoints, filtre les paramètres, injecte le jeton, retire les champs interdits, impose une destination, limite le volume, bloque les opérations d'écriture et journalise l'exécution. C'est lui qui transforme une décision de politique en contrôle effectif. Sans lui, la politique reste une intention. Le rôle applicatif définit ce que le compte pourrait faire ; la politique runtime, appliquée par ce point, définit ce que l'agent est autorisé à faire dans cette exécution.
Trois niveaux de moindre privilège
Le moindre privilège d'un agent ne se résume pas à choisir le plus petit rôle proposé par une application. Il se lit sur trois niveaux qui doivent tous être tenus en même temps. Premier niveau, l'identité : l'agent possède une Non-Human Identity dédiée, il ne réutilise pas le compte d'un collaborateur, son propriétaire et sa finalité sont connus. Deuxième niveau, le secret et le jeton : le secret est conservé dans un vault, le jeton est temporaire, les scopes sont réduits à ce que l'application permet. Troisième niveau, l'action : la politique runtime limite l'endpoint, la ressource, les champs, la destination, le moment, le volume et la finalité.
Prenons une scène précise. L'agent tente l'endpoint d'export prévu. L'API répond avec une erreur de pagination. L'agent lit la documentation disponible et découvre un endpoint d'administration permettant de générer un export complet plus facilement. Du point de vue de l'objectif, cette méthode semble efficace. Du point de vue de la gouvernance, elle est inacceptable, car elle inclut davantage de données que nécessaire. Un script figé aurait échoué ; l'agent, lui, trouve une autre solution. C'est précisément sa valeur. La politique runtime doit donc autoriser le résultat métier attendu sans ouvrir tous les chemins techniques susceptibles d'y parvenir. Le PEP refuse l'endpoint d'administration. L'agent reste dans le périmètre de l'outil autorisé, ou signale qu'il ne peut pas terminer la tâche. Une réponse claire indiquant que la tâche ne peut pas être réalisée dans le périmètre autorisé est préférable à une réussite obtenue par un chemin non maîtrisé.
Pour un agent autonome, « mission accomplie » n'est pas un critère de sécurité suffisant. Le chemin utilisé compte autant que le résultat. Le moindre privilège d'un agent ne se mesure pas uniquement au rôle de son compte. Il se mesure à l'action maximale qu'il peut réellement exécuter.
Revenir à l'export CRM, une dernière fois
L'identité de l'agent est gouvernée dans Netwrix Identity Manager. Son secret OAuth est protégé dans Keeper. Le jeton reçu possède les scopes les plus limités que le CRM sait proposer. Parce que ces scopes restent trop larges, l'agent ne reçoit pas directement le pouvoir correspondant : il passe par un point de contrôle. Axiomatics évalue la politique au moment de l'action. Le proxy n'autorise que l'endpoint d'export, les objets prévus, les champs nécessaires, la destination approuvée et le contexte autorisé. Toute autre action est refusée, même si le rôle administrateur du compte aurait techniquement permis de l'exécuter.
Nous n'ajoutons pas du PBAC parce que l'agent utilise de l'intelligence artificielle. Nous l'ajoutons lorsque le modèle de droits de l'application est incapable d'exprimer la limite dont le métier a besoin. Un script simple, une API correctement limitée et un jeton en lecture seule suffisent pour beaucoup d'usages. La Runtime Authorization devient nécessaire lorsque l'agent choisit lui-même son chemin d'exécution, lorsque ses outils sont puissants, lorsque l'application impose un rôle trop large, lorsque plusieurs sources de données sont accessibles, lorsque les informations manipulées sont sensibles, lorsque la destination des données doit être contrôlée et lorsque la finalité de chaque action doit être démontrable.
Pour sécuriser un agent autonome, nous ne cherchons pas seulement à savoir quel rôle possède son compte. Nous cherchons à déterminer l'action la plus puissante qu'il peut réellement accomplir lorsque personne ne regarde.