L'identité des agents IA
Fini les agents cachés derrière un compte partagé. Chacun porte sa propre identité, son propre périmètre de moindre privilège et sa propre ligne dans le journal d'audit — la responsabilité par construction.
Qu'est-ce que l'identité des agents IA ?
Le raccourci habituel consiste à faire partager un seul compte, aux droits larges, à tous les agents IA. Cela tient jusqu'au premier incident, où plus personne ne peut dire quel agent a agi. Donner à chaque agent sa propre identité permet de restreindre ses droits et d'attribuer ses actions.
À lire si vous êtes architecte ou auditeur et vous avez déjà demandé « quel agent a fait cela, et qui l'y a autorisé ? » sans obtenir de réponse satisfaisante.
L'identité des agents IA est la pratique consistant à délivrer à chaque agent IA autonome sa propre identité distincte et vérifiable — distincte de tout utilisateur humain ou compte de service partagé — afin que ses permissions puissent être restreintes au moindre privilège, que ses appels vers d'autres agents et outils puissent être authentifiés, et que chaque action qu'il effectue soit attribuable à cette identité et à l'autorité sous laquelle il a agi.
Une clé d'API ou un compte de service partagé ne peut pas vous dire quel agent a fait quoi, ni pour le compte de qui. À mesure que les organisations font passer les agents du pilote à la production, cette ambiguïté devient un risque : un identifiant non restreint qui touche des systèmes de production est un risque permanent, et une action que personne ne peut attribuer n'est ni auditable ni défendable. Sur l'AI OS, chaque agent — qu'il exécute une seule tâche ou orchestre tout un workflow — se voit délivrer sa propre identité, est autorisé par action sous politique zero-trust et est authentifié lorsqu'il appelle d'autres agents ou outils. Le résultat est une autonomie des agents que votre équipe compliance peut réellement valider : le moindre privilège par défaut, et un enregistrement complet de ce qui s'est passé, à l'intérieur de votre périmètre.
Une identité distincte par agent
Pas de comptes de service partagés. Chaque agent — et chaque instance d'un agent — se voit délivrer sa propre identité vérifiable, ancrée à votre fournisseur d'identité.
Permissions restreintes, au moindre privilège
Les agents obtiennent exactement les outils, les données et les actions qu'exige leur tâche — rien de plus — au lieu d'un accès global hérité d'un identifiant partagé.
Appels d'agent à agent authentifiés
Lorsqu'un agent appelle un autre agent via A2A ou invoque un outil via MCP, l'appel porte son identité, de sorte que chaque saut reste autorisé et attribuable.
Identité des agents IA dans la plateforme Scrydon
Une architecture souveraine unique et intégrée. Voici où se situe Identité des agents IA — mis en évidence au sein de la pile complète avec laquelle il fonctionne.
L'AI OS pour les humains et les agents IA
Couche d'ontologie et couche sémantique : un modèle unique et connecté pour vos données, connaissances et processus
Le meilleur des data lakes, des entrepôts de données et de la recherche réuni
Accès gouverné à tous les modèles, et les agents et workflows qui s'exécutent à travers vos systèmes
Intégrez via A2A, MCP, systèmes existants et sources de données
Fédération de domaines sécurisée, partage de données de confiance et intelligence au-delà des frontières
Fondations Souveraines
Identité des agents IA en détail
L'AI Runtime est là où l'IA s'exécute réellement : l’AI Gateway qui gouverne chaque appel de modèle, et les workflows d'IA agentique qui transforment ces appels en travail accompli à travers vos systèmes. L'un est la porte d'entrée, l'autre ce qui se passe ensuite — et les deux s'exécutent sous la même identité, la même politique et la même chaîne d'audit.
Deux moitiés, un seul plan de contrôle :
- Gateway — une route gouvernée vers tous les modèles : Les applications existantes et les agents de code pointent vers un endpoint unique plutôt que vers un fournisseur. N'importe quel modèle derrière, la clé fournisseur jamais remise à un développeur, et chaque appel attribué à une personne, plafonné et audité.
- Workflows — l'IA agentique qui exécute : Des workflows orchestrés relient en toute sécurité les modèles frontier, les outils internes et la mémoire d'entreprise, combinant le raisonnement de l'IA frontier avec des étapes strictement déterministes pour que les processus critiques restent prévisibles.
- Exécution autonome dans des limites définies : Les agents agissent de manière autonome dans des limites définies, récupérant le contexte depuis votre data lakehouse et agissant via des outils approuvés — avec un humain dans la boucle partout où votre politique l'exige.
Déployée en toute sécurité au sein de votre propre infrastructure, la runtime puise dans votre cognitive enterprise pour agir avec discernement. Quelle que soit la moitié où commence un appel, il résout les mêmes identifiants, rencontre la même politique et atterrit dans le même journal d'audit — ajouter plus tard des agents gouvernés n'implique donc jamais un second plan de contrôle.
L'AI OS ne fonctionne que s'il est digne de confiance. Chaque couche de la plateforme repose sur une infrastructure zero-trust et une fondation d'identité qui fonctionnent de manière cohérente, des déploiements on-premises entièrement air-gap jusqu'aux environnements cloud à grande échelle. La souveraineté n'est pas une fonctionnalité ajoutée par-dessus — c'est la condition dans laquelle tout le reste opère.
- Architecture zero-trust : Vérification continue de chaque requête, chaque utilisateur et chaque charge de travail — aucune confiance implicite, même à l'intérieur du périmètre.
- Identité fédérée : Intégration transparente avec votre IdP existant (SAML, OAuth 2.0, OIDC) pour un contrôle d'accès unifié et régi par des politiques.
- Déploiement air-gap : Exécutez la plateforme complète sans aucune dépendance réseau externe — idéal pour la défense, les infrastructures nationales critiques et les charges de travail classifiées.
- Calcul confidentiel : Chiffrement matériel des données en cours d'utilisation via AMD SEV-SNP et Intel SGX, protégeant les charges de travail même des administrateurs d'infrastructure.
Deployment Options: From Air-gapped to Cloud
Déployez la plateforme Scrydon où cela a du sens pour vous — des environnements air-gap au cloud public — avec souveraineté, conformité et auditabilité intégrées.
Aucune donnée ne quitte votre juridiction. Pas d'IA boîte noire. Aucun compromis sur le contrôle.
C'est la souveraineté par conception.
Vous lisez ceci pour une décision à venir ?
Recevez la prochaine évolution de la souveraineté numérique européenne, et ce que nous en apprenons en construisant. Quelques fois par an.
Donner à chaque agent IA sa propre identité
Lorsqu'un agent est déployé sur l'AI OS, il se voit provisionner sa propre identité — on ne lui remet pas une copie d'un jeton que d'autres agents utilisent aussi. Cette identité se fédère à votre fournisseur d'identité existant, porte des permissions restreintes à la tâche et aux outils spécifiques dont l'agent a besoin, et voyage avec l'agent dans tout ce qu'il fait : chaque appel d'outil, chaque passage de relais à un autre agent, chaque action sur un système réel. Rien de ce qu'un agent touche n'est atteignable anonymement ou sous le nom de quelqu'un d'autre.
Une identité, un agent — Chaque agent se voit provisionner sa propre identité au déploiement — pas un jeton partagé copié à travers une flotte d'agents.
Ancrée à votre IdP — Les identités d'agents se fédèrent à votre fournisseur d'identité existant, au même titre que les identités humaines et de workloads.
Restreinte par tâche et par outil — Les permissions sont accordées par tâche et par outil, de sorte qu'un agent ne peut atteindre que ce que son travail exige réellement.
Portée à chaque appel — L'identité voyage avec l'agent dans chaque appel d'outil et chaque échange d'agent à agent qu'il effectue.
Pourquoi un compte de service partagé ne suffit pas pour les agents
Un compte de service unique partagé par une flotte d'agents paraît pratique jusqu'à ce que quelque chose tourne mal. Il accorde à chaque agent derrière lui le même accès large, de sorte que contenir un agent compromis ou déviant signifie révoquer l'identifiant pour tous d'un seul coup. Pire, un identifiant partagé rend les agents indiscernables dans vos journaux — vous pouvez voir que « le compte de service » a agi, pas quel agent, sur quelle tâche, ni sous quelle autorité il opérait. Des identités distinctes sont ce qui rend possibles, en premier lieu, le moindre privilège et une réponse aux incidents propre.
Aucun contrôle du rayon d'impact — Un identifiant partagé donne à chaque agent derrière lui le même accès large, de sorte qu'un seul agent compromis ou déviant expose tout ce que les autres peuvent atteindre.
Des acteurs indiscernables — Lorsque dix agents partagent un compte, une entrée de journal vous indique que l'identifiant a agi — pas quel agent, sur quelle tâche, ni sous quelle autorité.
Le moindre privilège devient impossible — Vous ne pouvez pas restreindre les permissions à la tâche d'un seul agent si le même identifiant est également utilisé par tous les autres agents de la flotte.
La révocation frappe tout le monde — Désactiver un compte partagé pour contenir un agent malveillant met hors service tous les autres agents qui en dépendent.
Chaque action traçable jusqu'à une identité et une portée
Vous ne pouvez ni auditer ni gouverner les actions d'un agent s'il est indiscernable d'un identifiant partagé. Parce que chaque agent agit sous sa propre identité et sous une portée autorisée pour cette tâche précise, chaque action arrive dans la piste d'audit attribuable à un acteur réel — quel agent, ce qu'il a fait, et qui ou quoi l'a autorisé. C'est la traçabilité au niveau de l'acteur qu'attendent les obligations du règlement IA et les revues de gouvernance internes, et elle transforme « un agent a fait quelque chose de mal » d'une impasse forensique en une révocation précise, d'une seule identité.
Piste d'audit immuable — Chaque action effectuée par un agent est journalisée au regard de sa propre identité, de la portée sous laquelle il a agi et de l'humain ou du workflow qui l'a autorisée.
Preuves prêtes pour le règlement IA — Des identités d'agents distinctes donnent aux auditeurs la traçabilité au niveau de l'acteur qu'attendent les obligations du règlement IA pour les systèmes à haut risque et à usage général.
Zero-trust pour les agents — Une autorisation continue, par action, remplace l'accès large permanent, de sorte qu'un agent compromis ne peut pas élargir silencieusement ce qu'il peut toucher.
Réponse aux incidents rapide et précise — Lorsque quelque chose tourne mal, vous pouvez isoler et révoquer l'identité d'exactement un agent — sans toucher à l'accès d'aucun autre agent.
Questions fréquentes
Qu'est-ce que l'identité des agents IA ?+
Pourquoi les agents ne peuvent-ils pas simplement partager un compte de service ?+
Comment les permissions des agents sont-elles restreintes ?+
Comment l'identité des agents fonctionne-t-elle avec A2A et MCP ?+
L'identité des agents aide-t-elle à la conformité au règlement IA ?+
Cela remplace-t-il la gestion des identités et des accès humains ?+
Explorer la plateforme
Vous préférez écrire ? Envoyez un e-mail à hello [at] scrydon.com et nous vous répondrons.
Partenaires
