La sécurité des agents IA commence par l’identité, mais les entreprises ont besoin de plus que des identifiants

Google News a relayé le 2 septembre un avertissement concernant les agents IA, mais le problème dépasse largement une simple liste de contrôle de sécurité. L’article soutient que les entreprises doivent répondre à trois questions avant que les agents ne se multiplient : où se trouvent-ils, à quoi peuvent-ils se connecter et que peuvent-ils faire ?

Ce cadre a été présenté dans un article invité de GuidePoint Security, signé par Ariel Zommer, spécialiste du marketing produit sécurité chez Okta. Son idée centrale est simple : un agent devient un problème d’identité dès lors qu’il peut s’authentifier, accéder à des systèmes d’entreprise ou agir sans supervision humaine constante.

Le calendrier est important. Le NIST a publié un avertissement distinct sur l’identité le 27 août, moins d’une semaine avant la parution de l’article de GuidePoint. Microsoft, Okta et d’autres fournisseurs d’identité transforment également les identités d’agents en objets produits formels.

Cette convergence modifie le débat en entreprise. La question centrale n’est plus de savoir si un modèle peut produire une réponse exacte. Elle consiste à vérifier que chaque action qui en découle dispose d’un acteur visible, d’une autorité limitée, d’un responsable identifié et d’une connexion révocable.

L’argument paraît familier, car la gestion des identités encadre déjà les employés, les applications et les charges de travail traditionnelles. Les agents compliquent ce modèle, car leurs actions sont probabilistes, leurs connexions évoluent et une seule requête peut déclencher de nombreuses opérations en aval.

L’identité est donc nécessaire, mais elle ne suffit pas. Un identifiant peut identifier un agent sans démontrer que son action actuelle est sûre. Le véritable enjeu oppose une autonomie responsable à un accès pratique que les organisations ne peuvent pas entièrement retracer.

Ce que Google News a réellement mis en avant

L’information ne concerne pas la divulgation d’une nouvelle vulnérabilité. Il s’agit d’un avertissement coordonné selon lequel l’adoption des agents dépasse les contrôles d’identité des entreprises.

L’argument original sur l’identité a été publié par GuidePoint Security le 2 septembre 2026. Il a été rédigé par un employé d’Okta et présenté comme le point de vue d’un partenaire.

Cette distinction est importante. Les lecteurs doivent considérer l’article comme une analyse soutenue par un fournisseur, et non comme une preuve indépendante qu’une plateforme commerciale résout tous les problèmes de sécurité liés aux agents. Ses trois questions restent utiles, car elles décrivent des lacunes de contrôle mesurables.

La première question consiste à savoir où se trouvent les agents d’une organisation. Un inventaire doit inclure les agents développés en interne, les fonctionnalités intégrées aux produits SaaS, les agents hébergés dans le cloud, les outils autorisés par les employés et les systèmes expérimentaux.

Les inventaires d’actifs traditionnels passent souvent à côté de ces catégories. Un développeur peut créer un agent dans un compte cloud approuvé sans l’enregistrer comme application métier distincte. Un employé peut aussi autoriser un outil externe via OAuth.

OAuth est une norme d’autorisation qui permet à une application d’obtenir un accès limité à un autre service. Sa simplicité peut masquer des relations de confiance persistantes aux équipes qui n’ont jamais approuvé l’agent sous-jacent.

La découverte exige donc davantage qu’une analyse des dépôts de code. Les équipes de sécurité ont également besoin d’inventaires cloud, d’enregistrements d’applications, d’autorisations OAuth, de comptes de service, de signaux de navigateur, de journaux de passerelles API et de connexions Model Context Protocol.

Model Context Protocol, ou MCP, permet aux applications IA de se connecter à des outils et à des données via une interface commune. Il peut simplifier l’intégration tout en élargissant l’ensemble des systèmes accessibles.

La deuxième question porte sur les connexions possibles de chaque agent découvert. Cette cartographie doit couvrir les applications métier, les API internes, les bases de données, les systèmes de collaboration, les secrets, les comptes de service et les autres agents.

Une connexion ne révèle pas à elle seule le risque complet. Les équipes de sécurité ont également besoin de connaître sa méthode d’autorisation, l’étendue des permissions, la durée de vie des identifiants, le responsable métier, l’historique des approbations et la procédure de révocation.

La troisième question consiste à déterminer ce qu’un agent peut faire après s’être connecté. L’accès en lecture, la modification de dossiers, l’exécution de code, les mouvements de fonds et l’usurpation d’identité d’utilisateurs entraînent des conséquences très différentes.

Ces permissions peuvent aussi se combiner. Un agent qui lit les e-mails et crée des tickets de support paraît limité lorsque chaque connexion est examinée séparément. Il devient plus conséquent lorsqu’il peut extraire des instructions et déclencher des actions externes.

Google News a contribué à placer cet avertissement devant un public plus large. Toutefois, l’événement important s’est produit sous la couche d’agrégation. Les fournisseurs d’identité et les organismes publics de normalisation convergent autour des agents en tant qu’acteurs de premier plan dans l’entreprise.

Ce changement offre aux responsables de la sécurité un point de départ plus clair. Il crée aussi une pression pour distinguer l’identité d’un agent de celle de l’utilisateur, de l’application ou du compte de service qui l’a lancé.

Un jeton d’employé emprunté ne permet pas de faire cette distinction proprement. Une clé API partagée utilisée par plusieurs agents non plus. Ces deux configurations affaiblissent l’attribution lors des audits et des enquêtes sur incident.

Le changement immédiat est conceptuel, mais opérationnel. Les entreprises ont désormais besoin de dossiers de cycle de vie distincts pour les agents, couvrant leur création, leur propriété, leur autorisation, leur révision, leur suspension et leur retrait.

L’identité est devenue le plan de contrôle de l’IA

Un agent a besoin d’une identité distincte, car une autorité sans attribution transforme l’automatisation courante en problème d’enquête sans limites.

La gestion des identités et des accès, ou IAM, détermine qui peut accéder à une ressource et dans quelles conditions. Les systèmes IAM existants fournissent déjà des annuaires, des moteurs de politiques, des revues d’accès, des services de jetons et des journaux d’audit.

Ces composants offrent aux entreprises une base pratique. Elles peuvent enregistrer un agent, l’associer à un responsable, lui accorder des permissions précises et révoquer ces permissions lorsque l’agent évolue ou est retiré.

Le NIST a renforcé cette position dans sa récente analyse sur les fondations de l’identité. L’agence a averti que les premiers déploiements privilégient les fonctionnalités et la valeur immédiate au détriment des pratiques établies en matière d’identité.

Le NIST a également identifié le partage d’identifiants comme un problème central. Les identifiants partagés compromettent la responsabilité, car les enquêteurs ne peuvent pas déterminer de manière fiable quelle personne, quel service ou quel agent a effectué une transaction.

Le problème devient plus aigu lorsque les agents délèguent des tâches. Un utilisateur peut demander à un agent de préparer une présentation commerciale. Cet agent pourrait faire appel à un autre système pour obtenir des données clients et à un troisième service pour mener une recherche concurrentielle.

Chaque transfert crée une décision d’autorisation. L’entreprise doit préserver l’utilisateur à l’origine de la demande, l’agent qui agit, la ressource sollicitée et l’objectif de la requête.

Sans cette chaîne, les journaux peuvent indiquer qu’un compte de service a accédé à une base de données. Ils ne peuvent pas expliquer quel agent a initié l’action, quel utilisateur l’a demandée ni si l’action correspondait à un flux de travail approuvé.

Une identité de premier plan peut rétablir une partie de ce contexte. Chaque agent reçoit un identifiant unique au lieu d’emprunter un compte à usage général. Les politiques peuvent alors cibler l’agent concerné.

Ce modèle prend en charge le principe du moindre privilège, qui limite une identité à l’accès minimal nécessaire à sa tâche attribuée. Il permet également la révocation sans perturber les applications ou employés non concernés.

Les jetons de courte durée renforcent cette architecture. Un jeton est un identifiant signé qui représente une autorité accordée pour une portée et une durée limitées. De courtes expirations réduisent la valeur des identifiants volés.

Les identifiants fédérés apportent une autre amélioration. Ils permettent à une charge de travail de confiance de demander un jeton sans stocker de secret réutilisable dans le code, les fichiers de configuration ou la mémoire d’un agent.

La propriété complète l’enregistrement de base. Chaque agent en production doit avoir une personne nommée ou une équipe responsable, chargée de son objectif, de ses permissions, de ses révisions et de son retrait.

Le responsable ne peut pas être simplement le développeur ayant créé le premier prototype. La responsabilité métier compte, car quelqu’un doit déterminer si l’accès de l’agent reste nécessaire.

Le statut du cycle de vie compte également. Un agent expérimental ne devrait pas conserver des permissions de production après la fin d’un test. Un agent remplacé ne devrait pas rester actif parce que sa clé API fonctionne encore.

Cette structure ressemble à la gouvernance des employés et des applications. Pourtant, les agents exigent une évaluation plus fréquente, car leurs outils, leurs instructions, leurs modèles et leurs tâches déléguées peuvent évoluer indépendamment.

Les entreprises devraient donc considérer l’annuaire d’identités comme un plan de contrôle, et non comme un carnet d’adresses statique. L’enregistrement lance la gouvernance, mais l’application continue des politiques lui donne un sens.

Cette distinction protège aussi l’expérimentation légitime. Les développeurs peuvent bénéficier d’un chemin défini pour enregistrer un agent au lieu d’attendre une vaste revue de sécurité après son déploiement.

Un processus d’enregistrement utilisable doit recueillir l’objectif, le responsable, l’environnement, les outils, les catégories de données, les permissions et les limites opérationnelles attendues. Il doit également attribuer une date d’expiration ou de révision.

Si la voie approuvée est plus lente que la création d’un agent non enregistré, les équipes la contourneront. Le programme d’identité doit donc rendre l’intégration sécurisée plus facile que le déploiement dissimulé.

C’est là que les pratiques de gestion des connaissances peuvent soutenir la gouvernance. Les équipes ont besoin de dossiers consultables reliant les décisions, les responsables, les exigences, les approbations et les changements ultérieurs.

Un inventaire répond uniquement à la question de savoir où un agent a été enregistré. Les connaissances opérationnelles connectées expliquent pourquoi il existe et si son comportement actuel correspond toujours à cet objectif.

Les trois questions révèlent trois défaillances différentes

La découverte, le contrôle des connexions et la gouvernance des actions sont des disciplines distinctes, et réussir l’une ne compense pas l’échec d’une autre.

« Où sont mes agents ? » teste la visibilité. Les équipes de sécurité ne peuvent pas gouverner un agent qui n’apparaît que dans le compte d’un développeur, le navigateur d’un employé ou la configuration d’un administrateur SaaS.

Un inventaire utile doit inclure les déploiements autorisés et non autorisés. Il doit également distinguer les agents actifs des modèles, des expérimentations abandonnées, des instances désactivées et des applications ordinaires utilisant des fonctionnalités d’IA.

L’inventaire doit identifier l’environnement et l’état opérationnel de chaque agent. Les agents de développement, de test et de production ne devraient pas relever des mêmes hypothèses d’approbation.

Les équipes de sécurité doivent aussi décider de ce qui constitue un agent. Un chatbot qui ne renvoie que du texte présente un profil d’autorité différent d’un système qui appelle des outils ou modifie des enregistrements.

La définition doit se concentrer sur le comportement. Si un logiciel sélectionne des actions, appelle des outils connectés ou délègue du travail avec une supervision humaine limitée, il doit appartenir à la population gouvernée.

« À quoi peuvent-ils se connecter ? » teste le graphe de confiance de l’organisation. Un graphe de confiance enregistre les relations entre les identités, les identifiants, les applications, les ressources et les services délégués.

Ce graphe doit montrer les accès directs et indirects. Un agent peut ne pas avoir accès à une base de données, tout en ayant l’autorisation d’appeler un service capable d’interroger cette même base.

Les connexions d’agent à agent compliquent la cartographie. Un agent peut transmettre du contexte ou de l’autorité à un autre, créant une chaîne qui traverse les plateformes et les frontières administratives.

Les entreprises doivent consigner si chaque connexion utilise un accès permanent ou une autorisation spécifique à une tâche. L’accès permanent reste disponible entre les tâches, ce qui accroît l’exposition si l’agent est compromis.

Les tests « Que peuvent-ils faire ? » évaluent le contrôle à l’exécution. La réponse ne peut pas se résumer à une liste de portées d’API copiée depuis l’enregistrement d’une application.

Une portée peut autoriser la modification de fichiers, mais la politique doit tout de même distinguer l’édition courante de la suppression d’un dépôt. La même autorisation technique peut couvrir des actions aux conséquences métier différentes.

L’autorisation à l’exécution évalue une action proposée au moment où elle survient. Elle peut prendre en compte l’agent qui agit, l’utilisateur à l’origine de la demande, la sensibilité de la ressource, l’opération demandée, l’emplacement et les signaux de risque actuels.

Certaines décisions doivent rester automatiques. Exiger une approbation humaine pour chaque consultation à faible risque supprimerait le gain de productivité promis par les agents.

Les actions à fort impact méritent davantage de garde-fous. Les modifications de systèmes de production, les transferts d’argent, la divulgation d’informations réglementées et les suppressions irréversibles nécessitent des protections explicites.

L’approbation avec intervention humaine est une option. Elle place une personne à un point de décision défini avant que l’agent n’exécute une action sensible.

L’approbation doit fournir un contexte utile. Une invite qui indique « autoriser l’action » sans nommer la ressource, les données, l’objectif et l’effet attendu devient une simple case à cocher cérémonielle.

Les organisations ont également besoin d’une désactivation fiable. Un kill switch doit révoquer l’accès actif de l’agent dans l’ensemble des systèmes connectés, plutôt que de désactiver uniquement son interface visible.

Cette capacité dépend de l’architecture des identifiants. La révocation centralisée fonctionne mal lorsque les agents utilisent des clés API dispersées, des jetons mis en cache ou des identifiants copiés dans des services externes.

Les trois questions forment donc une séquence. La découverte établit le sujet, la cartographie des connexions définit la portée potentielle, et la gouvernance des actions contrôle l’autorité effectivement exercée.

Sauter cette séquence crée une fausse confiance. Une organisation peut maintenir un répertoire complet des agents tout en laissant chaque agent répertorié disposer de privilèges excessifs.

Elle peut aussi émettre des jetons à portée étroite tout en ignorant les agents créés par les employés. À l’inverse, elle peut journaliser les actions des agents sans conserver suffisamment de contexte d’identité pour les attribuer.

La valeur de ce cadre réside dans ces limites d’échec. Chaque question donne aux auditeurs et aux responsables de la sécurité une affirmation précise à vérifier, plutôt qu’une assurance générale sur une « IA responsable ».

Les contrôles d’identité ne peuvent pas déterminer si une action est judicieuse

Une identité valide répond à la question de savoir qui agit, mais ne garantit pas que l’agent a compris la demande ou choisi une action sûre.

Cette limite définit le compromis central de l’article. Les entreprises ont besoin de contrôles fondés sur l’identité, mais les agents restent moins prévisibles que les applications traditionnelles utilisant les mêmes identifiants.

Un service conventionnel exécute du code écrit pour un flux de travail connu. Un agent peut interpréter des instructions, sélectionner des outils, générer des paramètres et ajuster son parcours en fonction des informations renvoyées.

Cette flexibilité crée de la valeur. Elle signifie aussi que la réussite de l’authentification ne peut pas servir de preuve que la décision suivante correspond à l’intention de l’utilisateur.

L’injection de prompt illustre cet écart. Un agent peut rencontrer des instructions malveillantes dans un document, un e-mail, une page web ou un enregistrement récupéré, et les traiter comme faisant partie de sa tâche.

L’attaquant n’a pas besoin de voler l’identité de l’agent. Il peut tenter de manipuler un agent correctement authentifié afin qu’il abuse de ses autorisations légitimes.

OWASP répertorie les abus d’identité et de privilèges parmi ses risques de sécurité agentiques. Cette catégorie couvre la manipulation des chaînes de délégation, des rôles hérités, des identifiants mis en cache et du contexte de l’agent.

Le mauvais usage des outils pose un autre problème. Un agent peut appeler un outil approuvé avec des arguments dangereux ou au mauvais stade d’un flux de travail.

Les contrôles d’identité peuvent refuser l’accès à un outil non approuvé. Ils ne peuvent pas déterminer indépendamment si chaque appel autorisé sert l’objectif réel de l’utilisateur.

L’architecture de sécurité doit donc traiter le modèle comme un composant de décision non fiable. Des contrôles déterministes doivent rester en dehors du modèle partout où les conséquences sont importantes.

Un contrôle déterministe suit des règles explicites au lieu de générer une réponse probabiliste. Les exemples comprennent les vérifications d’autorisation, la validation de schéma, les limites de transaction et les étapes d’approbation obligatoires.

Le moteur de politiques doit évaluer ce que propose l’agent, sans compter sur l’agent pour se contrôler lui-même. L’agent ne doit pas pouvoir réécrire les règles qui contrôlent son autorité.

La validation des entrées et des sorties reste importante. Les paramètres des outils doivent respecter les schémas attendus, les limites de ressources, les classifications de données et les destinations approuvées.

Les contrôles réseau peuvent réduire davantage la portée. Un agent qui n’a jamais besoin d’un accès à l’internet public ne devrait pas l’obtenir par défaut.

Les contrôles des données sont importants, car l’identité n’empêche pas une divulgation inappropriée à un destinataire approuvé. Les politiques doivent également prendre en compte la sensibilité des données, leur finalité et leur conservation.

La surveillance doit porter sur le comportement autant que sur les connexions. Une authentification réussie suivie d’une énumération inhabituelle, de téléchargements massifs ou d’actions répétitivement refusées mérite une enquête.

C’est ici que l’affirmation de la primauté de l’identité doit être formulée avec prudence. L’identité fournit l’ancrage nécessaire à la responsabilisation, à la révocation et aux politiques. Elle ne constitue pas un système complet de sécurité des agents.

Une plateforme commerciale d’identité peut centraliser l’enregistrement et les jetons. Elle ne peut pas garantir que chaque modèle connecté résiste à la manipulation ou interprète correctement des objectifs ambigus.

La neutralité vis-à-vis des fournisseurs reste également incertaine. Les agents couvriront Microsoft, Google Cloud, Amazon Web Services, Salesforce, ServiceNow, les frameworks internes et des produits SaaS spécialisés.

Chaque plateforme peut représenter les agents différemment. Une identité interplateforme nécessite des jetons interopérables, des revendications cohérentes, des émetteurs de confiance et des politiques qui résistent aux transferts.

MCP ajoute une autre frontière. Une entreprise peut gouverner l’agent tout en dépendant d’un serveur externe pour exposer précisément les outils et protéger ses propres identifiants.

Une couche d’identité doit aussi être protégée contre toute compromission. Les annuaires centralisés et les services de jetons deviennent des cibles précieuses, car ils peuvent affecter de nombreux agents à la fois.

Les entreprises doivent séparer les responsabilités administratives, protéger les changements à privilèges élevés et surveiller les modifications inhabituelles de politiques. La gouvernance des agents ne peut pas reposer sur un seul compte de console doté de privilèges étendus.

Les journaux d’audit méritent le même scepticisme. Un grand volume d’événements ne produit pas automatiquement des preuves utiles.

Les enquêteurs ont besoin de registres reliant la demande de l’utilisateur, l’identité de l’agent, les agents délégués, l’outil sélectionné, la décision d’autorisation, la ressource affectée et le résultat final.

Les politiques de conservation doivent préserver cette chaîne suffisamment longtemps pour les enquêtes et les examens réglementaires. Les prompts et sorties sensibles peuvent nécessiter une minimisation ou un accès restreint.

La conclusion correcte est plus limitée que le message des fournisseurs. L’identité est le point de départ de la sécurité des agents, car le contrôle a besoin d’un sujet connu.

La sécurité exige toujours des défenses en couches autour de ce sujet. Ces couches comprennent des outils contraints, des politiques externes, des identifiants protégés, des contrôles des données, de la surveillance et une revue humaine.

Microsoft et Okta transforment le modèle en produits

L’idée de la primauté de l’identité passe du langage des conférences aux annuaires, aux flux de jetons, aux systèmes de découverte et aux contrôles de révocation.

Microsoft Entra Agent ID illustre la manière dont une grande plateforme représente désormais directement les agents. Microsoft décrit une identité d’agent comme un principal de service spécialisé doté d’un identifiant unique.

Un principal de service représente une application ou une charge de travail au sein d’un tenant d’identité. La version destinée aux agents permet aux politiques et aux journaux de distinguer l’agent de son modèle sous-jacent.

Le flux d’authentification autonome de Microsoft sépare une identité d’agent des secrets de production réutilisables. La documentation recommande les identités managées ou les certificats plutôt que les secrets client.

Les agents autonomes peuvent demander des jetons d’application pour leur propre identité. Les agents interactifs peuvent utiliser des flux délégués lorsqu’ils agissent pour un utilisateur authentifié.

Cette différence est essentielle. Un agent autonome de reporting nocturne ne devrait pas paraître identique à un assistant réalisant une action pour un employé connecté.

L’autorisation on-behalf-of préserve la relation avec l’utilisateur pendant la délégation. Le jeton résultant peut identifier l’utilisateur comme sujet et l’agent comme acteur.

Cette conception donne aux serveurs de ressources davantage de contexte pour l’autorisation. Un système peut demander si cet utilisateur, agissant par l’intermédiaire de cet agent, peut effectuer l’opération demandée.

Microsoft documente également des comptes utilisateur d’agent spéciaux pour les ressources nécessitant des objets de type utilisateur. Ces comptes peuvent prendre en charge des boîtes aux lettres ou des fonctionnalités collaboratives sans utiliser d’identifiants humains normaux.

Ces comptes incluent des restrictions. Microsoft indique qu’ils ne peuvent pas recevoir de rôles d’administrateur privilégié, créant ainsi une limite contre certaines formes d’escalade.

Okta poursuit le même marché depuis une position d’identité indépendante des plateformes. Son lancement d’identité d’agent d’avril décrivait la découverte, l’enregistrement, les connexions gérées, la gouvernance et la désactivation.

L’entreprise affirme que son annuaire peut importer des agents depuis des plateformes externes et enregistrer des agents personnalisés. Elle décrit également la détection des agents fantômes à partir des signaux de consentement OAuth.

Okta présente son produit autour des trois mêmes questions reprises dans l’article invité de GuidePoint. Ce chevauchement confirme le contexte commercial de l’article.

Le message produit mérite un examen attentif, mais les catégories d’implémentation sont concrètes. Les entreprises ont besoin d’annuaires pour les agents, de jetons à portée étroite pour les connexions et d’une application des politiques pour les actions.

La concurrence devrait bénéficier aux acheteurs si les plateformes exposent des contrôles interopérables. Le modèle de Microsoft peut convenir aux organisations centrées sur Entra et Microsoft Graph.

Okta met l’accent sur la gouvernance à travers plusieurs clouds, applications et frameworks d’agents. Les fournisseurs de cloud intégreront naturellement leurs services d’agents à leurs systèmes existants d’identité des charges de travail.

Le danger est la fragmentation. Une entreprise pourrait se retrouver avec un inventaire d’agents par cloud, un autre dans son fournisseur d’identité, et plusieurs autres dans des portails d’administration SaaS.

Ces inventaires divergeront à moins que l’organisation ne définisse un processus canonique de propriété et de cycle de vie. Les outils de découverte doivent alimenter ce processus plutôt que de créer des sources de vérité parallèles.

La compatibilité des jetons constitue un autre enjeu. OAuth peut standardiser les mécanismes d’autorisation, mais les fournisseurs peuvent différer sur les revendications d’identité, les preuves de délégation et les contrôles de politique à l’exécution.

La communication d’agent à agent augmente les enjeux. Le premier agent peut porter l’autorité déléguée d’un utilisateur, tandis qu’un agent en aval fonctionne de manière autonome avec des autorisations d’application.

La chaîne d’autorisation doit montrer où l’autorité a changé. Sinon, une demande utilisateur approuvée peut devenir une action machine étendue sans escalade visible.

Les équipes achats doivent tester les produits sur des flux de travail réels. Une interface d’annuaire soignée importe moins que la capacité de la plateforme à révoquer l’accès sur chaque connecteur affecté.

Elles doivent également tester l’exportabilité. Les données d’audit doivent rester accessibles pour la réponse aux incidents, la conformité et la migration, sans dépendre d’une vue d’enquête propriétaire.

Les équipes de sécurité doivent éviter d’accorder à une nouvelle plateforme d’agents un accès illimité simplement pour améliorer la visibilité. L’architecture de découverte nécessite son propre examen de moindre privilège.

Le marché évolue donc vers l’identité comme infrastructure partagée. Les gagnants ne se contenteront pas d’enregistrer les agents.

Ils préserveront l’attribution entre les plateformes, réduiront les identifiants permanents, permettront une révocation granulaire et rendront les décisions de politique visibles dans des enregistrements que des outils externes pourront évaluer.

Ce que les entreprises doivent vérifier avant de déployer les agents à grande échelle

La prochaine étape se mesurera aux preuves de déploiement, et non au nombre de fournisseurs qui répètent l’expression « identité de premier ordre ».

Le premier signal sera de savoir si les entreprises établissent des inventaires complets incluant les agents fantômes. Un annuaire alimenté uniquement par l’intégration formelle ne détectera pas les déploiements les plus risqués.

Les organisations devraient comparer les enregistrements d’identité avec les autorisations OAuth, les ressources cloud, la télémétrie des navigateurs, l’utilisation des API et les configurations SaaS. Des écarts importants affaibliraient la promesse d’une approche centrée sur l’identité.

Le deuxième signal sera de savoir si des autorisations temporaires et limitées remplacent les secrets statiques. Le nombre de migrations compte davantage que la capacité d’une plateforme à émettre des jetons modernes pour de nouveaux agents.

Les équipes devraient identifier les agents existants qui utilisent des clés API intégrées, des comptes de service partagés et des jetons d’actualisation à longue durée de vie. Elles devraient ensuite mesurer la rapidité avec laquelle ces identifiants disparaissent.

La documentation de Microsoft fournit aux entreprises un point de référence technique. Ses recommandations pour la production privilégient les identifiants fédérés et les identités gérées plutôt que les secrets client stockés.

Le troisième signal sera de savoir si les contrôles d’exécution résistent à la délégation entre plateformes. Cela déterminera si l’identité des agents devient une véritable infrastructure ou une nouvelle catégorie de produit isolée.

Un test utile commence par une demande humaine déclenchant plusieurs agents et outils. Les enquêteurs devraient pouvoir reconstituer toute la chaîne sans corréler manuellement des journaux sans rapport entre eux.

L’enregistrement devrait identifier la personne à l’origine de la demande, chaque agent participant, chaque échange de jetons, la politique appliquée et chaque ressource affectée.

La révocation devrait fonctionner sur l’ensemble de cette chaîne. La désactivation de l’agent initiateur ne doit pas laisser actifs des identifiants délégués ou des sessions en aval.

Les entreprises devraient également mener des tests adversariaux. Une équipe rouge peut insérer des instructions malveillantes dans un contenu qu’un agent autorisé est censé récupérer.

Le test devrait révéler si une politique externe bloque les actions dangereuses après que le modèle a accepté les instructions. L’identité seule ne permettra pas d’obtenir ce résultat.

Les dirigeants ont besoin d’un cadre décisionnel pour déterminer le niveau d’autonomie acceptable. Tous les agents ne nécessitent pas le même niveau d’examen, car les conséquences varient considérablement.

Un assistant de recherche qui lit des documents publics présente des risques différents de ceux d’un agent qui modifie du code de production. Un agent chargé des comptes fournisseurs introduit une tout autre catégorie de risque.

Les examens des accès devraient refléter ces différences. Les agents à fort impact nécessitent des cycles de certification plus courts, des limites plus strictes, une surveillance renforcée et des points d’approbation humaine définis.

Les plans de réponse aux incidents doivent inclure les agents comme acteurs. Les équipes devraient savoir comment suspendre une identité, invalider des jetons, isoler des connecteurs, préserver les journaux et identifier les données affectées.

Le plan devrait également couvrir les agents tiers compromis. Une confiance OAuth accordée à l’avance peut rester dangereuse même lorsque le code interne de l’entreprise n’a jamais été compromis.

Les équipes de sécurité devraient demander aux fournisseurs à quelle vitesse ils divulguent les compromissions de connecteurs et révoquent les accès émis. Les clauses contractuelles devraient traiter des journaux, des notifications et du soutien aux enquêtes.

Les développeurs ont besoin de normes plus claires dès la phase de conception. Chaque nouvel agent devrait déclarer son propriétaire, ses outils, ses catégories de données, son modèle d’autorisation et sa conséquence maximale autorisée.

Ces informations peuvent devenir partie intégrante d’un enregistrement interne de workflow IA. Les équipes produit, sécurité et ingénierie peuvent alors examiner les changements au regard de l’objectif initial.

L’article de Google News offre un point de contrôle utile, mais la répétition ne doit pas être confondue avec une résolution. Les fournisseurs d’identité ont défini le problème plus clairement que les entreprises n’ont mis en œuvre la réponse.

Ces trois questions constituent un premier examen pratique. Votre organisation peut-elle nommer chaque agent ? Peut-elle cartographier chaque système accessible ? Peut-elle contraindre et reconstituer chaque action importante ?

Un « oui » exige des preuves issues des annuaires, des jetons, des politiques et des journaux. Une feuille de calcul tenue à jour pour un audit ne prouve pas l’existence d’un contrôle en temps réel.

Commencez par un workflow de production et suivez-le de l’intention humaine jusqu’à l’effet final. Éliminez les identifiants partagés, restreignez chaque connexion et définissez où l’action automatique doit s’arrêter.

Testez ensuite la révocation et la reconstitution sous pression. Si l’une ou l’autre échoue, l’agent dispose de plus d’autonomie que l’organisation ne peut l’expliquer en toute sécurité.

Google News passera à un autre titre. La faille d’identité subsistera tant que les entreprises ne pourront pas relier chaque action d’un agent à une autorité limitée, une responsabilité claire et une politique applicable.