En bref : IBM a annoncé le 27 octobre 2026 la disponibilité générale d'IBM Agent Identity, couplée à HashiCorp Vault 2.2. La solution attribue à chaque agent IA une identité d'entreprise vérifiable, des credentials à durée limitée et une capacité de révocation en temps réel. Seules 13 % des organisations estiment disposer d'une gouvernance adaptée à leurs agents (Gartner, 2026), alors que la majorité en a déjà en production. Voici ce que change concrètement cette annonce pour les équipes qui déploient des agents.
Lorsque vous déployez un agent IA dans votre entreprise, vous lui confiez des accès : bases de données, APIs internes, outils métiers. La question qui devrait se poser immédiatement est simple : savez-vous exactement ce que cet agent a fait, sur quelle autorité, et comment l'arrêter en cas de dérive ?
Dans la grande majorité des déploiements actuels, la réponse est non. Les accès sont accordés via des clés API permanentes partagées entre plusieurs agents, les pistes d'audit sont inexistantes ou fragmentées, et stopper un agent compromis implique souvent de couper une application entière. IBM a conçu Agent Identity pour combler ce vide, en s'appuyant sur son outil de gestion des identités (IBM Verify) et sur HashiCorp Vault, référence du marché pour les secrets d'infrastructure.
Le vide de gouvernance dans les déploiements d'agents
Les outils classiques de sécurité ont été conçus pour des identités humaines et des systèmes stables. Un agent IA introduit un nouveau type d'entité : il agit de manière autonome, peut lancer des sous-agents, accède à plusieurs systèmes en parallèle, et ses actions s'enchaînent sans validation humaine systématique. Ce profil ne rentre pas dans les modèles de gouvernance existants.
La situation standard dans une organisation qui déploie des agents sans gouvernance structurée ressemble généralement à ceci :
- Un agent de traitement de documents utilise une clé API permanente valable pour l'ensemble du périmètre applicatif — même si l'agent n'est censé toucher qu'un sous-ensemble limité.
- En cas de comportement inattendu ou de compromission, la révocation impose de changer la clé, de redeployer l'application, et parfois d'impacter d'autres agents qui partagent le même credential.
- L'audit trail ne distingue pas les actions de l'agent des actions humaines, rendant l'investigation d'incident lente et imprécise.
- La multiplication des orchestrateurs — Amazon Bedrock, Microsoft Foundry, Google Gemini, LangGraph — crée des îlots de gouvernance incompatibles entre eux.
Gartner chiffre l'écart : 67 % des organisations ont des agents IA en production ou en pilote en 2026, mais 87 % d'entre elles n'ont pas mis en place la gouvernance correspondante. IBM cite ce chiffre comme point de départ de sa solution, en formulant la question ainsi : comment gouverner des agents IA avec les mêmes standards que les identités humaines en entreprise ?
Cette problématique rejoint directement les enjeux de l'automatisation métier : plus les agents prennent en charge des processus critiques, plus la traçabilité et le contrôle d'accès deviennent des exigences non négociables.
Architecture IBM Verify + HashiCorp Vault 2.2
La solution s'articule autour de deux composants complémentaires, chacun avec un rôle distinct.
IBM Verify : le plan de contrôle d'identité centralisé
IBM Verify sert de couche de gouvernance centralisée pour les identités agents. Il maintient un Agent Registry — l'enregistrement autoritaire de chaque agent, comprenant son propriétaire, son statut dans le cycle de vie (actif, suspendu, révoqué) et l'autorité qui lui a été déléguée. Avant qu'un agent puisse exécuter la moindre action, il doit exister dans ce registre avec un profil clair.
IBM Verify prend en charge :
- L'autorisation : définition des ressources accessibles par l'agent, sous quelles conditions et pendant combien de temps.
- L'audit unifié : chaque action est liée à une identité agent, elle-même reliée à l'identité humaine qui l'a déléguée. La piste d'audit lie ainsi les trois niveaux : humain → agent → action.
- La gouvernance des tokens : échange de tokens entre agents et humains pour des délégations contrôlées, sans partage de credentials permanents.
- La révocation en temps réel : si un agent tente une action hors périmètre, IBM Verify peut révoquer ses droits immédiatement, sans attendre l'expiration naturelle du token.
HashiCorp Vault 2.2 : les credentials éphémères
Pour les systèmes qui ne consomment pas directement des tokens délégués — bases de données, APIs legacy, outils internes — HashiCorp Vault agit comme broker de credentials just-in-time. Vault émet des credentials à courte durée de vie, strictement limités aux permissions nécessaires pour la tâche en cours.
En pratique : un agent qui doit lire une table de base de données reçoit un credential valide 15 minutes, avec un droit en lecture seule sur cette table spécifique. À l'expiration, le credential est inerte. Si l'agent tente d'accéder à une autre ressource, le credential est refusé — et la tentative est enregistrée dans les logs d'audit.
La nouveauté de Vault 2.2 est la formalisation de l'Agent Registry au niveau de Vault lui-même : avant qu'un agent obtienne un credential, il doit être enregistré et mappé à une entité d'identité dans Vault. Les logs d'audit incluent non seulement la requête, mais l'identité de l'agent, la délégation accordée et la décision de politique appliquée.
Le principe de moindre privilège appliqué aux agents
La combinaison IBM Verify + Vault 2.2 applique mécaniquement le principe de moindre privilège : chaque agent reçoit exactement les droits dont il a besoin, pour la durée minimale nécessaire. Ce principe, recommandé depuis longtemps en sécurité informatique pour les humains, devient ainsi applicable aux agents IA de façon systématique.
Ce qui est GA et ce qui reste en preview
Il est important de distinguer ce qui est effectivement disponible de ce qui est encore en cours de déploiement.
En disponibilité générale depuis le 27 octobre 2026 :
- IBM Agent Identity : Agent Registry, modèle d'accès OAuth pour agents, reporting d'audit, workflows de risque et remédiation.
- HashiCorp Vault 2.2 Agentic IAM : Agent Registry Vault, émission de credentials éphémères formalisée, audit logs structurés par identité agent.
Encore en technical preview au moment de l'annonce :
- Découverte multi-cloud : l'inventaire automatique des agents déployés sur Amazon Bedrock, Microsoft Foundry et Google Gemini. La couverture d'agents non-IBM reste partielle — les agents watsonx Orchestrate sont couverts en priorité.
- Sandboxes d'isolation : permettent de contenir un agent qui se comporte de manière inattendue, sans couper l'application entière. En preview pour les environnements OCP (OpenShift Container Platform).
- Secure Hub : interface unifiée de gestion des politiques et des accès agents, avec intégration NVIDIA OpenShell. En public preview.
Cette distinction est importante pour les équipes qui évaluent la solution : les fonctionnalités core de gouvernance sont disponibles, mais la couverture complète des environnements multi-cloud nécessitera d'attendre la sortie GA des composants de découverte.
Cas d'usage concrets pour les PME/ETI
La gouvernance des agents IA s'applique concrètement à des situations que beaucoup d'entreprises commencent à rencontrer.
Agent de traitement de documents entrants
Un agent qui lit des factures fournisseurs, en extrait les données et les dépose dans votre ERP nécessite accès à votre stockage de documents et à votre ERP. Avec IBM Agent Identity, l'agent est enregistré dans IBM Verify avec un profil clair (propriétaire : responsable comptable, périmètre : lecture dossier factures + écriture ERP fournisseurs). Vault émet un credential éphémère valable le temps de la session de traitement. Si l'agent tente d'accéder au module RH ou commercial, le credential est invalide — et la tentative est tracée.
Agent de reporting hebdomadaire
Un agent qui consolide des données de plusieurs systèmes pour générer un tableau de bord reçoit des credentials en lecture seule sur chaque source, valides 30 minutes. L'audit trail documente chaque requête avec l'identité de l'agent et l'identité du collaborateur qui a déclenché la génération. En cas de question sur l'origine d'une donnée, la traçabilité est complète.
Gestion d'un incident : un agent sort de son périmètre
Sans gouvernance, stopper un agent qui dépasse son périmètre implique de changer la clé API, redéployer, et investiguer dans des logs épars. Avec IBM Agent Identity : révocation immédiate dans IBM Verify, audit trail structuré qui permet de reconstituer les actions en quelques minutes, remédiation ciblée sans impacter les autres agents.
Ces scénarios s'appliquent à une gamme large d'architectures : automatisation de processus métier, outils internes sur mesure intégrant des agents de traitement, ou projets d'développement sur mesure avec des composants agentiques. Anticiper la gouvernance dès la phase de conception simplifie considérablement l'audit et la maintenance.
Points de vigilance et limites actuelles
Quelques éléments à garder en tête avant d'investir dans cette solution.
Couverture partielle des agents non-IBM
La découverte automatique des agents sur Amazon Bedrock, Microsoft Foundry et Google Gemini est en preview. Si votre infrastructure est principalement AWS ou Azure, la couverture complète de gouvernance n'est pas encore disponible. IBM recommande de déployer son propre orchestrateur (watsonx Orchestrate) pour une couverture optimale — ce qui crée une dépendance à l'écosystème IBM plus forte qu'une solution véritablement multi-cloud.
Politique répartie sur plusieurs produits
La politique de gouvernance est distribuée entre IBM Verify, HashiCorp Vault et watsonx Orchestrate. Des analystes indépendants notent que la documentation ne précise pas encore clairement quel produit a priorité en cas de conflit de politique. Pour les équipes qui ne sont pas déjà clientes IBM, cela représente une courbe d'intégration significative.
LangChain, LangGraph, Crew AI ne sont pas couverts nativement
Ces frameworks populaires d'orchestration d'agents ne sont pas gérés par la découverte multi-cloud d'IBM. L'intégration est techniquement possible via les APIs IBM Verify et HashiCorp Vault, mais nécessite un travail de configuration non négligeable.
La gouvernance doit s'anticiper dès le premier agent
Le message central de l'annonce IBM reste valable indépendamment du produit choisi : 87 % des organisations n'ont pas encore structuré leur gouvernance d'agents. Attendre d'avoir un incident ou un audit pour mettre en place un registre et une politique d'accès revient à construire une ceinture de sécurité après l'accident. Le bon moment est dès les premiers agents en production, avec un périmètre modeste — même un registre simple et des credentials à durée limitée représentent une amélioration substantielle par rapport à des clés API permanentes non documentées. Si cette question se pose dans le cadre de votre stratégie IA, parlons-en directement.
FAQ
Sources
FAQ — Gouverner les agents IA comme des identités d'entreprise : IBM Agent Identity en disponibilité générale avec HashiCorp Vault 2.2
IBM Agent Identity fonctionne-t-il uniquement avec IBM Cloud ?
Non. IBM Verify et HashiCorp Vault peuvent être déployés on-premise ou sur d'autres clouds. La contrainte principale est que la découverte automatique des agents sur AWS Bedrock, Microsoft Foundry et Google Gemini reste en preview. Les fonctionnalités core (registre, credentials éphémères, révocation, audit) sont disponibles en GA quelle que soit l'infrastructure.
Qu'est-ce qu'un credential éphémère et pourquoi est-ce mieux qu'une clé API permanente ?
Une clé API permanente reste valide indéfiniment jusqu'à révocation manuelle. Un credential éphémère expire automatiquement après une durée définie (quelques minutes à quelques heures). Si un agent est compromis ou dépasse son périmètre, le credential expire de lui-même sans action requise. Couplé au moindre privilège — chaque credential n'accorde que les droits strictement nécessaires pour la tâche en cours — cela réduit drastiquement la surface d'attaque en cas d'incident.
La solution IBM Agent Identity est-elle adaptée aux PME ou uniquement aux grands comptes ?
IBM Verify est disponible en SaaS et HashiCorp Vault en version Enterprise. Les deux produits proposent des modèles de tarification qui couvrent les entreprises de taille intermédiaire. La complexité d'intégration est plus accessible si vous avez déjà une infrastructure IBM ou HashiCorp. Pour une PME démarrant avec un ou deux agents, Vault open source avec une configuration manuelle simple peut être un point de départ raisonnable avant d'investir dans les versions Enterprise.
À quel moment faut-il mettre en place une gouvernance des agents IA ?
Dès le premier agent en production. L'erreur classique est d'attendre d'avoir suffisamment d'agents pour justifier l'investissement. En pratique, les dettes de gouvernance s'accumulent vite : clés API dispersées, audit logs inexistants, périmètres d'accès non définis. Démarrer avec un registre simple et des credentials à durée limitée dès le premier agent coûte peu et prévient des problèmes de sécurité et d'audit bien plus coûteux à corriger rétrospectivement.
Quelle est la différence entre IBM Agent Identity et ce qu'a annoncé ServiceNow AI Passport en octobre 2026 ?
ServiceNow AI Passport se concentre sur les credentials cryptographiques par agent et le kill switch runtime, avec un ancrage dans la CMDB ServiceNow. IBM Agent Identity cible la couche IAM d'entreprise : moindre privilège, credentials éphémères via HashiCorp Vault, audit unifié liant identités humaines et agents. Les deux approches sont complémentaires — l'une travaille au niveau du registre CMDB, l'autre au niveau des politiques d'accès IAM. Les entreprises qui ont les deux environnements peuvent les faire coexister.