Les agents d’IA ont besoin d’une identité avant d’avoir besoin d’une passerelle

Hush Security a fait son entrée dans Google News avec une affirmation claire : les entreprises doivent identifier chaque agent d’IA avant de placer une passerelle autour de son trafic. L’enjeu est important, car de nombreux agents empruntent encore des autorisations humaines ou partagent des identifiants. Une passerelle peut inspecter les connexions, mais elle ne peut pas établir de responsabilité lorsque tous les appelants paraissent identiques.

L’argument a suivi l’annonce de financement de Hush Security en juillet 2026 et l’expansion de sa plateforme d’identités non humaines. L’entreprise a levé 30 millions de dollars et présenté une Identity Gateway conçue pour découvrir les agents, leur attribuer des identités, négocier un accès limité et enregistrer leurs actions. Son idée centrale est simple : les contrôles de sécurité ne peuvent pas gouverner un agent de manière fiable tant qu’ils ne savent pas quel agent agit.

Cette position remet en cause une approche « passerelle d’abord » qui émerge dans l’IA d’entreprise. Cisco, Palo Alto Networks, Microsoft et d’autres fournisseurs de sécurité placent désormais des contrôles entre les agents et les outils. Pourtant, une passerelle voit les requêtes, pas nécessairement l’identité complète, le propriétaire, l’autorité déléguée ou l’historique d’exécution qui les sous-tendent. Il en résulte une frontière de sécurité familière, mais un problème d’attribution inédit.

Il ne s’agit pas de débattre de l’utilité des passerelles. Elles restent des points d’application utiles pour l’authentification, les vérifications de politiques, l’inspection du trafic et les restrictions sur les outils. La question est de savoir si les entreprises installent le point de contrôle avant d’attribuer des identifiants distincts à tous ceux qui le traversent.

Le titre de Google News révèle une évolution plus profonde de l’identité

Hush Security redéfinit la sécurité des agents d’IA comme un problème d’identité que les passerelles seules ne peuvent pas résoudre.

L’entreprise est sortie de l’ombre en 2025 en se concentrant sur les identités non humaines. Elles comprennent les comptes de service, les clés API, les jetons d’accès et d’autres identifiants utilisés par des logiciels plutôt que par des employés. Hush s’est d’abord attaquée à un problème ancien en entreprise : les organisations accumulent souvent des identifiants machines difficiles à inventorier, à renouveler et à révoquer.

Les agents autonomes font monter les enjeux. Ils peuvent interpréter des instructions, sélectionner des outils, récupérer des données et agir dans plusieurs systèmes au cours d’une même tâche. Une automatisation classique suit une séquence prédéterminée. Un agent peut modifier sa trajectoire après avoir reçu de nouvelles informations, ce qui rend ses autorisations effectives plus difficiles à prévoir.

Dans son rapport du 30 juillet, VentureBeat a décrit comment Hush étendait ce travail initial à une passerelle d’identité pour agents. La plateforme proposée se place entre les agents et les ressources de l’entreprise. Hush affirme pouvoir découvrir les agents, les relier à des propriétaires humains, délivrer des accès spécifiques à une tâche, consigner l’activité et révoquer centralement un agent.

Hush appelle son modèle d’accès « least agency ». Le terme adapte le principe de sécurité du moindre privilège, qui n’accorde à un utilisateur ou à une charge de travail que l’accès nécessaire à une tâche. Le principe de « least agency » ajoute à cette décision l’objectif de l’agent, le contexte d’exécution et l’autorité déléguée.

Prenons un agent de programmation chargé de diagnostiquer une erreur de production. Il peut avoir besoin d’un accès en lecture aux journaux, au code source et aux métadonnées de déploiement. Il ne devrait pas recevoir automatiquement l’autorisation de modifier des dossiers de facturation, de télécharger des bases de données clients ou de réécrire sa propre politique de sécurité.

La même distinction s’applique aux agents de productivité. Un assistant qui prépare une note de réunion peut rechercher dans les calendriers, les notes et les documents approuvés. Il n’a pas besoin d’un accès illimité à chaque boîte mail, espace de stockage cloud ou console d’administration accessible à l’employé qui l’a lancé.

Une passerelle peut bloquer des destinations interdites ou des requêtes malformées. Toutefois, ses politiques deviennent imprécises lorsque plusieurs agents utilisent le même jeton OAuth ou compte de service. Elle peut savoir qu’un identifiant approuvé a demandé un fichier. Elle peut ne pas savoir quel agent a effectué la demande, pourquoi il a agi ou si cette action restait dans le cadre de la délégation initiale.

C’est pourquoi le titre de Google News a plus de poids qu’une histoire de financement habituelle. Hush ne se contente pas d’ajouter une couche d’inspection. L’entreprise soutient que l’identité doit devenir l’enregistrement central du propriétaire, de l’objectif, des autorisations, des sessions et des actions d’un agent.

Ce modèle modifie également la réponse aux incidents. Les équipes de sécurité commencent généralement une enquête en demandant qui a accédé à une ressource. Les identifiants partagés peuvent réduire la réponse à une application, un employé ou un compte de service. Une identité d’agent distincte offre un point de départ plus précis, surtout lorsque plusieurs processus autonomes opèrent sous l’autorité d’une même personne.

Les identifiants partagés obligent les passerelles à deviner

Une passerelle ne peut appliquer une politique qu’avec la précision de l’identité et du contexte associés à chaque requête.

De nombreux premiers agents d’entreprise ont été déployés comme des scripts. Les développeurs ont stocké une clé API, attribué un compte de service ou transmis le jeton OAuth de l’utilisateur humain. Cette approche permet de faire fonctionner rapidement un prototype, mais elle regroupe plusieurs acteurs sous une seule identité de sécurité.

L’employé, l’hôte de l’agent, le modèle, l’agent individuel et la session d’outil peuvent tous apparaître sous la même autorisation. Si l’agent crée des sous-agents, la chaîne devient encore plus difficile à reconstruire. Un service en aval peut recevoir un jeton valide sans savoir quel composant a initié l’action.

L’enquête de VentureBeat menée en juin 2026 auprès de 107 répondants d’entreprises a révélé que 69 % utilisaient des clés API partagées dans leurs déploiements d’agents. Ses recherches sur la sécurité des agents ont également montré que 82 % s’appuyaient principalement sur les contrôles fournis par les fournisseurs de modèles ou les hyperscalers.

Ces contrôles offrent des protections utiles. Les filtres de prompts peuvent détecter des schémas d’injection connus, les systèmes de prévention de perte de données peuvent signaler du contenu sensible et les politiques cloud peuvent restreindre l’accès aux ressources gérées. Aucune de ces fonctionnalités ne crée automatiquement une identité distincte pour chaque instance d’agent.

L’enquête a relevé une adoption de Microsoft Entra Agent ID de 13 % parmi les répondants. D’autres produits spécifiquement dédiés à l’identité apparaissaient à des taux à un chiffre. Cet écart suggère que les entreprises ont déployé des protections générales pour l’IA plus rapidement que des mécanismes de responsabilité propres aux agents.

Le déséquilibre devient plus grave lorsqu’un agent reçoit une autorité excessive. Un identifiant d’administrateur partagé ne devient pas sûr parce qu’une passerelle le surveille. Si la politique autorise cet identifiant à effectuer une action, la passerelle peut approuver une requête dangereuse qui reste techniquement valide.

L’injection de prompt illustre le problème. Un agent peut lire un texte non fiable lui demandant de récupérer du matériel confidentiel ou de modifier une configuration. L’instruction peut arriver par un document, un site web, un e-mail, la réponse d’un outil ou un enregistrement de base de données. Un filtre linguistique doit alors relever la difficile tâche de distinguer une intention légitime d’une intention manipulée.

Les contrôles d’identité répondent à une autre couche du problème. Ils n’ont pas besoin de déterminer si chaque phrase est malveillante. Ils peuvent limiter l’autorité maximale disponible pour l’agent, quelle que soit la décision du modèle.

Par exemple, un agent de recherche doté d’un accès en lecture seule ne peut pas supprimer un dépôt de code source après avoir rencontré une instruction hostile. Un agent d’assistance temporaire ne peut pas conserver son accès aux données clients une fois son ticket clôturé. Un agent financier autorisé à préparer un paiement ne peut pas également approuver ce paiement, sauf si la politique accorde les deux actions.

Les identifiants de courte durée réduisent davantage l’exposition. Au lieu de placer un secret réutilisable dans l’environnement d’un agent, un système d’identité peut délivrer un jeton pour une seule tâche, une seule ressource et une seule fenêtre temporelle. Le jeton expire automatiquement et peut être révoqué à la fin de la session.

Ce modèle favorise également de meilleurs journaux. Un enregistrement d’audit devrait identifier l’agent, son sponsor humain, la tâche, la décision de politique, l’identifiant utilisé et l’action qui en a résulté. Ne consigner que la requête passant par la passerelle oblige les enquêteurs à déduire trop d’éléments après un incident.

Les entreprises préservent déjà le contexte lorsqu’elles gèrent une activité humaine importante. Elles enregistrent l’utilisateur, l’appareil, l’application, la session, la méthode d’authentification et la ressource. Les logiciels autonomes ont besoin d’au moins autant de détails, car ils peuvent exécuter de nombreuses actions sans s’arrêter pour une revue humaine.

Le défi est le volume. Une organisation peut créer, copier ou mettre fin à des agents plus rapidement qu’elle n’embauche des employés. Le provisionnement des identités doit donc devenir automatique. Un enregistrement manuel créerait des retards, encouragerait les contournements et laisserait des agents fantômes hors de la gouvernance.

Cette pression rend la gestion du cycle de vie essentielle. Chaque identité d’agent a besoin d’un événement de création, d’un propriétaire, d’un objectif approuvé, d’un ensemble de politiques, d’une règle d’expiration et d’un mécanisme de révocation. Si un seul de ces éléments reste indéfini, la passerelle reçoit du trafic provenant d’un acteur que l’organisation ne peut pas expliquer entièrement.

Une passerelle contrôle le trafic, mais l’identité établit l’autorité

L’architecture la plus robuste traite l’identité comme la source de l’autorité et la passerelle comme l’un des endroits où cette autorité est appliquée.

Une passerelle d’IA assure généralement la médiation des communications entre les modèles, les agents, les outils et les services de données. Elle peut authentifier les connexions, inspecter les requêtes, appliquer des limites de débit, filtrer le contenu et générer des journaux. Une passerelle MCP réalise un travail similaire pour les connexions Model Context Protocol.

MCP est un protocole ouvert qui permet aux applications d’IA de découvrir et d’appeler des outils externes via une interface commune. Il réduit le besoin de code d’intégration personnalisé, mais des connexions standardisées peuvent également étendre la surface accessible à un agent.

Une passerelle devient utile parce qu’elle fournit un point de contrôle central des politiques. Les équipes de sécurité peuvent placer des règles devant de nombreux outils au lieu de modifier chaque système backend. Cette commodité architecturale ne répond pas à la question de savoir qui est l’agent ni d’où provient son autorité.

L’identité apporte cette fondation. Une identité distincte peut lier l’agent à son code, son hôte, son propriétaire, sa tâche et ses capacités approuvées. L’autorisation peut ensuite déterminer ce que cette identité peut faire dans les conditions présentes.

La distinction ressemble à un contrôle aéroportuaire. Contrôler chaque voyageur est utile, mais le processus dépend de la connaissance de l’identité du voyageur qui présente chaque document. Inspecter les bagages sans établir l’identité produit un dossier de sécurité incomplet.

Le National Institute of Standards and Technology américain a placé les mêmes composants dans un cadre plus large en 2026. Son projet sur l’identité des agents a identifié l’identification des agents, l’autorisation, la délégation, la journalisation, la transparence et la provenance des données comme des domaines de travail liés.

NIST a également renvoyé vers des technologies établies plutôt que de proposer une réponse propriétaire unique. OAuth peut porter une autorisation déléguée, OpenID Connect peut exprimer des informations d’authentification et SCIM peut prendre en charge le provisionnement des identités. SPIFFE et SPIRE peuvent délivrer des identités cryptographiquement vérifiables aux charges de travail logicielles.

Ces technologies résolvent différentes parties du problème. OAuth indique quel accès un jeton confère. OpenID Connect aide à décrire une partie authentifiée. SCIM peut créer ou désactiver des enregistrements d’identité. SPIFFE peut attester qu’une charge de travail exécutée dans une infrastructure contrôlée est bien celle qu’elle prétend être.

Aucune ne capture indépendamment toute la vie d’un agent autonome. Une entreprise doit encore relier une identité de charge de travail à la délégation humaine, à la politique, au périmètre de la tâche et à l’historique des actions.

Ce lien manquant explique pourquoi il ne suffit pas d’attribuer un nom à un agent. Un identifiant auto-déclaré au sein d’une requête peut être modifié ou copié. Une identité digne de confiance doit être émise ou vérifiée par un système accepté par le service destinataire.

L’identité doit également survivre à ses déplacements dans l’infrastructure. Les agents peuvent s’exécuter dans des applications de bureau, des conteneurs cloud, des environnements de développement, des plateformes gérées et des services tiers. Une information d’identification ancrée dans un seul cluster peut perdre sa signification lorsqu’un agent franchit une frontière organisationnelle.

Un document de l’OpenID Foundation consacré à la gestion des identités des agents décrit ce défi de portabilité. Il relève qu’un identifiant client MCP ne constitue pas nécessairement une identité fiable de charge de travail ou d’agent. Il explique également pourquoi l’attestation fondée sur l’infrastructure devient plus difficile lorsque les agents traversent des domaines de confiance.

Cette question distingue l’authentification de la capacité d’action. L’authentification établit qu’un composant logiciel contrôle une information d’identification. La capacité d’action décrit pourquoi ce composant agit, pour le compte de qui il agit et quelle délégation il détient actuellement.

Une passerelle a besoin de ces deux types d’informations. Elle devrait rejeter un appelant non vérifié, mais aussi un agent vérifié qui dépasse la tâche qui lui a été déléguée. Réussir l’authentification ne peut pas devenir une autorisation d’effectuer toutes les actions accessibles à l’utilisateur qui le parraine.

L’approche de Hush place un courtage d’identité piloté par des politiques avant l’accès aux ressources. La passerelle devient alors un mécanisme d’application de cette autorité négociée. Cette séquence permet des autorisations plus restreintes et une attribution plus claire qu’une passerelle qui découvre d’abord l’identité à partir du trafic.

L’architecture reste toutefois dépendante de l’intégration. Les applications et les serveurs d’outils doivent respecter les revendications d’identité, les périmètres ou les jetons de capacité qu’ils reçoivent. Si les systèmes en aval ramènent chaque requête à un unique compte backend privilégié, le registre d’identité perd sa valeur d’application.

Les fournisseurs de sécurité convergent vers le même point de contrôle

Le marché s’oriente vers l’identité des agents, mais les fournisseurs divergent quant à savoir si l’identité, le trafic réseau ou le comportement des terminaux doit guider l’application des contrôles.

Hush n’est pas le seul à considérer les agents comme une nouvelle catégorie d’acteurs non humains. Microsoft, Cisco, Palo Alto Networks, 1Password, Okta, Ping Identity et plusieurs startups ont lancé des fonctionnalités d’identité ou de gouvernance axées sur les agents.

Duo Agentic Identity de Cisco enregistre les agents comme des objets distincts associés à des propriétaires humains. Son architecture de sécurité plus large peut acheminer les appels d’outils via une passerelle MCP. Palo Alto Networks a présenté un registre d’agents, un fournisseur d’identité pour les agents et des contrôles de passerelle au sein de Prisma AIRS.

Microsoft répartit la gouvernance des agents entre Entra, Purview, Defender et Sentinel. Entra Agent ID se concentre sur la création et la gouvernance des identités des agents. Les autres services Microsoft traitent des contrôles de données, de la détection des menaces et de la surveillance.

CrowdStrike met l’accent sur l’activité des terminaux. Cette approche suit ce que font les processus logiciels sur un appareil, plutôt que de s’appuyer uniquement sur l’intention exprimée par un modèle. Elle peut aider à détecter les modifications de fichiers, les lancements de processus et d’autres actions concrètes après une authentification réussie.

Ces différentes approches sont complémentaires, mais elles se disputent le rôle de principal plan de contrôle. Les fournisseurs d’identité soutiennent que chaque action devrait commencer par un acteur digne de confiance et une autorité délimitée. Les fournisseurs de réseau considèrent les passerelles comme des points d’inspection centraux. Les fournisseurs de terminaux se concentrent sur l’exécution observable.

RSAC 2026 a montré à quelle vitesse ces catégories convergeaient. L’analyse de VentureBeat des cadres de sécurité pour agents a constaté que les principaux fournisseurs avaient lancé des registres, des passerelles, des objets d’identité et une surveillance à l’exécution.

Les lacunes restantes révèlent pourquoi aucun contrôle unique ne suffit. Un agent peut passer toutes les vérifications d’identification tout en modifiant la politique qui régit son propre comportement. Une passerelle peut voir chaque appel d’outil sans reconstituer une chaîne de délégation. Un capteur de terminal peut observer une action sans savoir si l’agent disposait d’une autorité métier valide.

La délégation multi-agents crée le cas le plus complexe. Supposons qu’un agent d’approvisionnement demande à un agent de recherche de comparer des fournisseurs. L’agent de recherche crée ensuite un agent de navigation, qui sollicite des documents auprès d’un service tiers.

Chaque transfert devrait restreindre ou préserver l’autorité, sans jamais l’étendre silencieusement. Le service final a besoin de suffisamment d’éléments pour déterminer qui a initié la tâche, quels agents y ont participé et si l’action demandée correspond à l’objectif initial.

L’usurpation d’identité utilisateur traditionnelle fonctionne mal dans ce contexte. Si chaque agent enfant hérite de l’identité de l’employé, les systèmes en aval ne peuvent pas distinguer l’utilisateur d’origine des délégués autonomes. La révocation d’un enfant compromis peut exiger la fin de toute la session utilisateur.

Un meilleur modèle attribue à chaque agent une identité distincte tout en conservant une chaîne de délégation signée. L’enfant ne reçoit que le sous-ensemble d’autorisations nécessaire à sa mission. Les journaux préservent la relation entre le propriétaire humain, l’agent parent, l’agent enfant et l’action qui en résulte.

Cette structure ressemble à la manière dont les charges de travail cloud sécurisées échangent des informations d’identification de courte durée. Les agents introduisent toutefois des comportements incertains et des objectifs formulés en langage naturel. Les politiques doivent tenir compte à la fois de l’identité technique et de l’évolution du contexte de la tâche.

Il existe également un problème d’intégration concret. Les entreprises exploitent déjà des fournisseurs d’identité, des systèmes de gestion des accès privilégiés, des passerelles API, des maillages de services, des agents de terminal et des plateformes de surveillance de la sécurité. L’ajout d’une couche distincte d’identité des agents peut créer une console et une source de vérité supplémentaires.

Les approches gagnantes devront se connecter à l’infrastructure d’identité existante. Les équipes de sécurité résisteront aux systèmes qui exigent que chaque application adopte un protocole propriétaire ou maintienne un annuaire d’employés en double.

Cette pression favorise les revendications fondées sur des standards, les jetons de courte durée et les registres d’audit portables. Elle favorise aussi les produits capables de découvrir les agents fantômes avant que ceux-ci ne demandent une inscription formelle.

La découverte compte, car les employés peuvent installer des assistants de codage ou connecter des agents locaux sans approbation de la sécurité. Une politique d’identité parfaite ne sert à rien pour un agent dont l’organisation ignore l’existence. La télémétrie réseau, terminal, cloud et d’identité contribue toutes à détecter ces déploiements.

La convergence du marché soutient donc la prémisse de Hush sans valider chaque affirmation produit. L’identité devient nécessaire, mais elle opérera aux côtés des passerelles, des sandboxs, de la surveillance des terminaux et des contrôles de données. La véritable concurrence porte sur la couche qui définira le registre faisant autorité.

L’identité ne rend pas un agent sûr

Une identité vérifiée améliore le contrôle et la responsabilité, mais elle ne prouve pas que le comportement d’un agent est digne de confiance.

Cette limite constitue le principal défi à une approche centrée sur l’identité. Un agent authentifié peut toujours prendre une mauvaise décision, suivre une instruction malveillante, exposer des données ou utiliser un outil dangereux. L’identité indique aux défenseurs qui a agi. Elle ne garantit pas que l’action était judicieuse.

La sécurité traditionnelle offre un avertissement. Des comptes légitimes sont à l’origine de nombreux incidents dommageables, parce que les attaquants volent des informations d’identification, que les employés reçoivent des accès excessifs ou que des logiciels approuvés se comportent de manière inattendue. Une identité valide ne constitue que le début d’une décision de politique.

Les systèmes d’agents ajoutent de l’incertitude, car leurs plans peuvent évoluer pendant l’exécution. Un modèle peut choisir un autre outil après avoir lu de nouvelles informations. Il peut mal comprendre une contrainte ou traiter un contenu non fiable comme une instruction.

C’est pourquoi le sandboxing reste important. Un sandbox isole l’exécution afin qu’un agent compromis ou erroné ne puisse pas affecter librement le système hôte. L’identité peut limiter les ressources autorisées, tandis que l’isolation limite techniquement ce que le processus peut atteindre.

Les contrôles des prompts et des sorties conservent également leur rôle. Ils peuvent détecter des schémas d’attaque connus, des données sensibles ou des contenus interdits avant qu’une requête n’atteigne un autre système. Leur faiblesse tient au fait qu’ils traitent l’interprétation sémantique comme l’unique défense.

Une architecture complète exige une défense en profondeur. La couche d’identité établit l’acteur et l’autorité déléguée. La passerelle applique les politiques de connexion. Le sandbox limite l’exécution. La surveillance des terminaux et du cloud consigne le comportement réel. Les contrôles de données restreignent les informations sensibles.

Le moteur de politiques doit rester hors du contrôle de l’agent. Si un agent peut modifier les règles qui définissent ses propres autorisations, une identité valide peut aider les enquêteurs à attribuer les dommages sans les empêcher.

La protection des informations d’identification présente un autre risque. Donner à chaque agent un secret unique et durable améliorerait l’attribution tout en multipliant le nombre de secrets que les attaquants peuvent voler. Les systèmes d’identité devraient délivrer des informations d’identification de courte durée et conserver les secrets réutilisables hors de l’environnement de l’agent.

Les organisations doivent également éviter la prolifération permanente d’agents. Créer automatiquement des identités est utile, mais les identités inactives doivent expirer automatiquement. Sinon, l’entreprise remplace des clés API non gérées par des comptes d’agents non gérés.

La propriété humaine peut également devenir trompeuse. Associer un agent à un employé ne signifie pas que cet employé a examiné chaque action. Les registres de responsabilité devraient distinguer le parrainage, l’approbation, l’exploitation et l’exécution.

Un responsable peut approuver un flux de travail, tandis qu’un développeur déploie l’agent et qu’un autre employé lance une tâche. Réduire ces trois rôles à un seul champ « propriétaire » peut créer une fausse certitude.

La provenance des données nécessite une attention similaire. Un agent peut combiner des documents, du texte généré, des réponses d’outils et du contexte mémorisé. Les journaux de sécurité devraient préserver quelles informations ont influencé les actions importantes, sans collecter plus de contenu sensible que nécessaire.

Pour les travailleurs du savoir, cette question dépasse la cybersécurité. Les agents agissent de plus en plus sur des notes personnelles, des documents de projet, des transcriptions et des décisions antérieures. Une base de connaissances personnelle bien organisée peut améliorer le contexte, mais l’accès nécessite toujours des limites claires.

Un agent préparant une mise à jour hebdomadaire peut avoir besoin d’une sélection de dossiers de projet. Il ne devrait pas hériter d’un accès sans restriction à chaque note privée simplement parce que toutes les informations appartiennent à un même utilisateur. L’identité et le périmètre de la tâche contribuent à séparer le contexte utile de l’exposition inutile.

Les affirmations de Hush nécessitent donc une validation indépendante dans des environnements de production. Les acheteurs devraient se demander si son système identifie cryptographiquement les instances d’agents, s’intègre aux fournisseurs d’identité existants et propage l’identité aux outils en aval.

Ils devraient également tester la rapidité de révocation, le comportement en cas d’échec des politiques, le suivi des délégations et l’exhaustivité des journaux. Un plan de contrôle qui perd le contexte lors d’un appel d’outil ou accorde par défaut un accès large pendant une panne peut recréer le risque qu’il promet de réduire.

Le financement et l’annonce du produit de l’entreprise établissent une intention de marché, et non des résultats de sécurité mesurés. Les éléments publics ne montrent pas encore comment la plateforme se comporte dans chaque environnement d’agent de bureau, cloud et géré.

Cette incertitude n’invalide pas une architecture centrée sur l’identité. Elle définit la norme à l’aune de laquelle les produits devraient être évalués. La question utile n’est pas de savoir si un tableau de bord répertorie un agent. Il s’agit de savoir si l’identité limite, attribue et met fin de manière cohérente à l’autorité de cet agent.

Ce que les lecteurs de Google News devraient surveiller ensuite

Trois signaux montreront si l’identité des agents devient une véritable infrastructure ou reste une catégorie de marketing de la sécurité.

Le premier signal est l’adoption d’identités distinctes en production. Les équipes de sécurité devraient regarder au-delà du nombre d’agents découverts ou enregistrés. La mesure significative est le nombre d’agents actifs qui ont cessé d’utiliser des informations d’identification partagées ou des jetons humains sans restriction.

Les preuves de ce changement incluraient des identifiants de courte durée, des accès limités à une tâche, une expiration automatique et des services en aval qui conservent l’identifiant de l’agent. Si les clés partagées restent courantes, l’adoption d’une passerelle ne suffira pas à combler le déficit de responsabilité.

Ce signal renforcera l’argument en faveur d’une approche centrée sur l’identité lorsque les entreprises signaleront moins de comptes de service partagés et davantage de sessions d’agent révocables. Il l’affaiblira si les produits d’identité restent limités à des tableaux de bord d’inventaire tandis que les accès à l’exécution ne changent pas.

Le deuxième signal concerne la prise en charge des chaînes de délégation. Les agents d’entreprise créeront de plus en plus de sous-tâches, feront appel à des agents spécialisés et franchiront des frontières organisationnelles. Les produits doivent préserver l’autorité tout au long de ces transferts.

Une mise en œuvre crédible devrait indiquer le sponsor humain d’origine, chaque agent participant, les autorisations transférées et les actions qui en résultent. Chaque identité enfant ne devrait recevoir pas plus d’autorité que son parent ne peut en déléguer.

Surveillez les organismes de normalisation et les fournisseurs pour repérer des moyens interopérables d’exprimer ces relations. Des enregistrements de délégation propriétaires peuvent fonctionner au sein d’une seule plateforme, mais les entreprises utilisent des agents de plusieurs fournisseurs. La vérification interplateforme déterminera si l’identité reste intacte en dehors de l’environnement d’un fournisseur.

Ce signal renforce la thèse si les outils MCP, les plateformes d’agents et les fournisseurs d’identité peuvent échanger des preuves de délégation vérifiables. Il l’affaiblit si chaque plateforme reconvertit les agents en jetons utilisateur ordinaires à la frontière.

Le troisième signal est le confinement des incidents. L’identité compte surtout lorsqu’un agent se comporte de manière incorrecte ou est compromis. Les fournisseurs doivent démontrer que les défenseurs peuvent isoler un seul agent sans désactiver un employé, une application ou un flux de travail entier.

Parmi les tests utiles figurent la révocation immédiate, le refus des sessions existantes, le blocage des agents enfants et la reconstitution de la chaîne d’actions. Les organisations doivent également vérifier que l’application des politiques échoue de manière sûre lorsque l’infrastructure d’identité devient indisponible.

Les équipes de sécurité doivent comparer les journaux des systèmes d’identité, des passerelles, des terminaux et des applications en aval. Si ces enregistrements ne peuvent pas être corrélés, l’entreprise ne dispose toujours pas d’un compte rendu fiable et unifié de l’incident.

Le succès renforcerait la position de Hush en montrant que l’identité des agents change les résultats, et pas seulement la visibilité. Des incidents répétés impliquant des agents authentifiés mais non confinés montreraient que le marché a surestimé l’identité comme défense autonome.

Le cadrage de Google News présente globalement le bon ordre. Les entreprises devraient établir qui est un agent, de quelle autorité il est investi et combien de temps cette autorité dure avant de considérer qu’une passerelle constitue une gouvernance suffisante.

La prochaine étape est concrète : auditez un agent de production depuis sa création jusqu’à son dernier appel d’outil. Votre équipe peut-elle identifier son propriétaire, sa tâche, ses identifiants, ses autorisations, ses sous-agents, ses accès aux données et son chemin de révocation ? Si une réponse dépend d’un jeton partagé ou d’une déduction à partir du trafic, la passerelle est arrivée avant que les fondations de l’identité ne soient prêtes.