Aucun propriétaire responsable
Un compte de service partagé ne dit pas quel agent a agi, ni qui en est responsable.
HelixIAM AI Identity · souverain par conception
Savoir quel agent a fait quoi, pour qui — et pouvoir l'arrêter.
Donnez à chaque agent IA sa propre identité, avec un propriétaire responsable et un cycle de vie. Lorsqu'un agent agit pour un utilisateur, le jeton nomme les deux, et ses droits ne font que se réduire. Les workloads obtiennent une identité sans secret stocké.
Souverain par conception · votre infrastructure en Europe · vos clés · un éditeur néerlandais
Requête · agent agissant pour alice
POST /realms/acme/oauth2/token grant_type=urn:ietf:params:oauth:grant-type:token-exchange subject_token=eyJ… # alice actor_token=eyJ… # agent: invoice-assistant scope=invoices:read
Jeton d'accès émis · décodé
{
"sub": "alice",
"act": { "sub": "agent:invoice-assistant" },
"scope": "invoices:read",
"aud": "https://api.acme.example/invoices",
"iss": "https://id.acme.example/realms/acme"
}actL'agent est nommé dans chaque jeton ; l'utilisateur reste le sujet.scopeLes droits se réduisent à ce dont l'agent a besoin. Ils ne s'élargissent jamais.ownerSuspendez l'agent : il n'obtient plus de nouveaux jetons.
Le problème
Les agents fonctionnent avec des identités empruntées.
Clés d'API partagées et jetons d'utilisateurs copiés laissent trois questions sans réponse : qui a fait cela, pour qui, et comment l'arrêter sans tout casser ?
Pour qui agit-il ?
Quand un agent réutilise le jeton d'une personne, chaque action semble venir de cette personne — avec tous ses droits.
Aucun arrêt sûr
Faire tourner une clé partagée pour arrêter un agent casse tous les autres systèmes qui l'utilisent.
Fonctionnement
Propriétaire, délégation, limites, arrêt.
- 01
Enregistrer l'agent
Chaque agent est une identité à part entière dans un realm, avec un propriétaire responsable, un objectif, ses propres rôles et une date d'expiration.
- 02
Déléguer par échange de jetons
L'agent échange le jeton de l'utilisateur contre un nouveau jeton via l'échange de jetons OAuth standard (RFC 8693) :
subest l'utilisateur,actl'agent. - 03
Réduire les droits
Les droits délégués sont l'intersection de ce que l'utilisateur et l'agent peuvent faire, limitée à la portée et à l'audience demandées. Ils ne s'élargissent jamais.
- 04
Revoir et suspendre
Les agents dont le propriétaire est parti sont signalés pour revue. Suspendez un agent : il n'obtient plus de nouveaux jetons, et les serveurs de ressources qui font de l'introspection le voient immédiatement.
Souverain par conception
Pourquoi pas les géants du cloud ?
Microsoft, Okta et Auth0 proposent tous l'identité des agents IA, et le font bien. Ils la livrent sous forme de services cloud exploités par des entreprises dont le siège est aux États-Unis. HelixIAM vous donne l'identité des agents sur votre propre infrastructure en Europe, avec des jetons signés par des clés que vous détenez.
| Critère | Services cloud d'identité des agents | HelixIAM AI Identity |
|---|---|---|
| Produits | Microsoft Entra Agent ID ; Okta et Auth0 for AI Agents | HelixIAM, logiciel commercial de KubeDNA B.V. |
| Où il s'exécute | Services cloud exploités par l'éditeur (Auth0 mentionne aussi une option de déploiement privé dans son offre Enterprise) | Auto-hébergé sur votre propre infrastructure : vous choisissez où il s'exécute |
| Éditeur | Entreprises dont le siège est aux États-Unis | KubeDNA B.V., une entreprise néerlandaise |
D'après la documentation publique des éditeurs, consultée en octobre 2026 : Microsoft Entra Agent ID, Okta Agent SSO, Auth0 for AI Agents, offres Auth0. Les noms de produits sont des marques de leurs propriétaires.
Identité des workloads
Une identité sans secret pour Kubernetes et la CI.
Vos pods et pipelines portent déjà un jeton signé par leur plateforme. HelixIAM le vérifie auprès de l'émetteur que vous avez approuvé et renvoie un jeton HelixIAM de courte durée, lié aux rôles d'une application. Rien à stocker, rien à faire tourner.
- Émetteur, sujet et audience doivent correspondre à un identifiant enregistré
- Jetons liés à l'expéditeur (DPoP)
- Jetons à audience restreinte avec les resource indicators
Requête · le job CI présente le jeton de sa plateforme
POST /realms/acme/workload-identity/token grant_type=urn:ietf:params:oauth:grant-type:token-exchange subject_token=eyJ… # signed by the CI platform
Jeton émis · décodé
{
"sub": "service-account-deploy-pipeline",
"realm_access": { "roles": ["deployer"] },
"exp": 1798732800,
"iss": "https://id.acme.example/realms/acme"
}issL'émetteur de confiance, le sujet et l'audience doivent correspondre, sinon la requête est refusée.expCourte durée de vie, lié aux rôles d'une application.secretRien à stocker ni à faire tourner dans le pipeline.
Gouvernance
Un inventaire de tous les agents.
Propriétaires, statut, applications liées et dernière utilisation dans un seul écran de la console, à côté des utilisateurs, des applications et des clés du même realm. Chaque jeton d'agent émis ou refusé — direct ou délégué pour le compte d'un utilisateur — figure dans le journal d'audit consultable, avec les changements de cycle de vie, les actions d'administration et l'émission des jetons de workloads, et vous pouvez transmettre le journal à votre SIEM en HTTPS.
Fondé sur les standards
Prêt pour MCP et les outils que vos agents appellent.
Métadonnées de ressource protégée
Prêt pour MCP : les métadonnées de ressource protégée OAuth (RFC 9728) indiquent aux clients des serveurs d'outils IA où obtenir leurs jetons.
Échange de jetons standard
La délégation utilise la RFC 8693 : tout serveur de ressources compatible OAuth peut lire la revendication act.
Enregistrement dynamique de clients
Enregistrez des clients via l'API standard, selon une politique définie par l'administrateur.
Modèle de déploiement
Fonctionne à côté de votre fournisseur d'identité actuel.
Inutile de remplacer votre IdP. Les personnes continuent de se connecter comme aujourd'hui et sont fédérées vers HelixIAM via OpenID Connect ou SAML ; HelixIAM gouverne les agents et les workloads qui agissent pour elles, sur une infrastructure et des clés que vous maîtrisez.
- Fédération d'identité (brokering) depuis d'autres fournisseurs OIDC, SAML et sociaux
- Auto-hébergé sur votre Kubernetes avec un chart Helm
- Clés de signature dans votre HSM ou Vault / OpenBao
Questions des équipes plateforme et sécurité
Notre fournisseur d'identité propose déjà des fonctions pour les agents. Pourquoi HelixIAM ?
Plusieurs fournisseurs d'identité hébergés proposent désormais l'identité des agents. HelixIAM s'adresse aux équipes qui la veulent sur leur propre infrastructure, avec leurs propres clés, à côté de l'identité des workloads sans secret et des eID européennes — et il fonctionne à côté de votre IdP actuel.
Que deviennent les jetons quand on suspend un agent ?
L'agent n'obtient plus de nouveaux jetons, et les serveurs de ressources qui font de l'introspection voient la suspension immédiatement. Les jetons validés localement par les API restent valides jusqu'à leur courte expiration : gardez des durées de vie courtes pour les jetons d'agents.
Devons-nous auto-héberger ?
Oui, HelixIAM s'exécute sur votre infrastructure. KubeDNA propose un accompagnement au déploiement et à l'exploitation, sur votre infrastructure ou un cloud européen, avec un périmètre défini par contrat.
Quels standards la délégation utilise-t-elle ?
L'échange de jetons OAuth 2 (RFC 8693). Le jeton émis porte l'utilisateur comme
sub et l'agent comme act.Accès anticipé/ouvert aux partenaires de lancement
Voyez un agent agir pour un utilisateur — et l'arrêter.
Un pilote payant sur votre propre Kubernetes : quelques vrais agents ou serveurs d'outils MCP enregistrés avec leurs propriétaires, un parcours utilisateur délégué, une identité sans secret pour un pipeline, un exercice de suspension et l'export de l'audit vers votre SIEM. Puis un plan de mise en production.