Produit · Identité et NHI
Donnez à chaque agent sa propre identité — et sachez quand il n’en a pas
Un compte de service partagé laisse la question « quel agent a fait cela ? » sans réponse. Olivares lie un agent à une identité non humaine, émet une NHI dédiée par agent et fait apparaître les agents qui en partagent une — toute la différence entre attribuer l’accès avec certitude ou seulement de façon approximative. Une identité qu’il ne parvient pas à résoudre n’est jamais traitée en silence comme si elle était réelle.
Dans le produit
La console d’identité
Une véritable capture d’écran, avec des données d’exemple. Des onglets pour le roster des NHI, l’authentification MCP, le graphe WIF, la posture des clés et de la résidence, et les connexions privilégiées. L’onglet SSO/SCIM est franc sur sa propre couture : l’endpoint backend n’est pas encore live, il n’affiche donc rien plutôt que de l’inventer.
Ce que vous gouvernez
D’un compte partagé à une identité par agent
L’identité est l’axe sur lequel la carte d’accès fonde ses attributions. Une NHI dédiée par agent transforme l’« approximatif » en « certain » ; tout ce qui suit est honnête sur ses limites.
Lier ou émettre une NHI
Liez un agent à une identité non humaine existante, ou émettez une NHI dédiée par agent. Une NHI dédiée est ce qui permet à la carte d’accès d’attribuer l’accès avec certitude à un seul agent — et non de façon approximative à un pool.
Constat d’identité partagée
Lorsque plusieurs agents s’appuient sur le même compte, l’attribution par agent est véritablement ambiguë. Olivares fait apparaître cela comme un constat et le dit — il ne coupe pas la poire en deux et ne prétend pas savoir quel agent a agi.
Graphe WIF en lecture seule
Un graphe de fédération d’identité de charge de travail (WIF) met en correspondance vos identités par agent avec votre IdP. Il est rendu en lecture seule à partir des règles de fédération que vous déclarez — une vue de ce que vous avez déclaré, et non une vérification en direct de la confiance sur le réseau.
L’inconnu honnête
Une identité qu’Olivares ne parvient pas à résoudre est dessinée comme inconnue et signalée — jamais promue en silence au rang de NHI nommée. Sans signal d’identité, pas d’attribution, dit sans détour.
Comment ça marche
Fédérer une identité par agent à votre IdP
Chaque agent obtient une identité qui lui est propre — un identifiant SPIFFE/WIF — qui se fédère à votre fournisseur d’identité. Un agent sans identité résoluble n’est pas fondu dans une identité réelle : il est dessiné à part et signalé.
Ce qui est réel
Le rattachement de NHI et le graphe WIF sont live ; la fédération en direct et le step-up AAL3 ne le sont pas
Nous sommes précis sur ce point, car cette différence est tout l’intérêt d’une surface d’identité :
- Live : lier un agent à une NHI, émettre une NHI dédiée par agent, le constat d’identité partagée et le graphe WIF en lecture seule. Le graphe reflète les règles de fédération que vous déclarez — ce n’est pas une image vérifiée en direct de la fédération sur le réseau.
- Roadmap : fédération en direct face aux registres GA d’identité d’agent des hyperscalers — Microsoft Entra Agent ID, AWS AgentCore, Google Agent Identity. Aujourd’hui, nous affichons les règles déclarées et n’affirmons aucune vérification en direct avant sa disponibilité.
- Non construit : step-up WebAuthn AAL3 / PIV-CAC. Il n’est pas implémenté et bascule aujourd’hui en sécurité fermée vers AAL1 — nous indiquons AAL1, et non le niveau d’assurance que nous n’avons pas mérité. Certaines sources d’identité en direct (LDAP, IdP, gestionnaires de secrets) et les SCIM Groups ne sont pas encore raccordés, et l’onglet SSO/SCIM est franc à ce sujet : backend en attente, rien à montrer, jamais fabriqué.
Identité et NHI — questions
Olivares se fédère-t-il en direct avec Entra Agent ID, AWS AgentCore ou Google Agent Identity aujourd’hui ?
Non — pas en direct. Le graphe WIF est en lecture seule et rendu à partir des règles de fédération que vous déclarez ; il montre donc ce que vous avez déclaré, et non une relation de confiance vérifiée en direct sur le réseau. La fédération en direct face à ces registres GA d’identité d’agent des hyperscalers figure sur la roadmap, et nous ne l’affirmons pas avant sa disponibilité.
Deux agents partagent un même compte de service. Lequel Olivares désigne-t-il comme l’auteur ?
Aucun, avec certitude. Une identité partagée rend l’attribution par agent véritablement ambiguë ; Olivares lève donc un constat d’identité partagée et n’attribue l’accès que de façon approximative — il ne fabriquera pas de certitude sur l’agent qui a agi. Émettez une NHI dédiée par agent et la carte d’accès pourra alors attribuer cet agent avec certitude.
Prenez-vous en charge le step-up WebAuthn AAL3 ou PIV-CAC pour les connexions privilégiées ?
Pas encore. Le step-up AAL3 via WebAuthn ou PIV-CAC n’est pas construit ; aujourd’hui le parcours bascule en sécurité fermée vers AAL1, et c’est exactement ainsi que nous l’indiquons — nous n’affichons pas un niveau d’assurance que nous n’avons pas mérité. L’onglet des connexions privilégiées montre ce qui est réellement appliqué à présent.
Pourquoi l’onglet SSO/SCIM est-il vide ?
Parce que l’endpoint backend qui l’alimente n’est pas encore live ; il n’y a donc véritablement rien à montrer — et le produit le dit plutôt que de le garnir de données d’apparence plausible. Il en va de même pour les sources d’identité en direct comme LDAP, IdP et les gestionnaires de secrets, ainsi que pour les SCIM Groups : pas encore raccordés, affichés honnêtement vides.
Donnez à vos agents des identités que vous pouvez attribuer
Déployez Olivares sur votre propre infrastructure, émettez une NHI dédiée par agent et transformez l’« approximatif » en « certain » sur votre carte d’accès.