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 SSO et SCIM, 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. La capture est antérieure au backend SSO/SCIM désormais livré : son onglet SSO/SCIM affiche encore l’avis honnête « backend en attente » de cette version — des écrans réels, jamais de données fabriquées.
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, le step-up matériel et SSO/SCIM sont live ; la fédération vérifiée en direct ne l’est 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.
- Livré comme ingestion en lecture seule : des connecteurs de roster lisent les registres d’identité d’agent des hyperscalers — Microsoft Entra Agent ID, AWS Bedrock AgentCore et le registre d’agents de Google. La fédération vérifiée en direct sur le réseau face à ces registres reste sur la roadmap, et nous ne l’affirmons pas avant sa disponibilité.
- Livré pour les personnes : step-up WebAuthn/FIDO2 et par carte PIV/CAC pour les connexions privilégiées, appliqué en sécurité fermée — le break-glass et les approbations critiques refusent en dessous du niveau AAL3 vérifié par matériel, et une session sans cérémonie récente est affichée AAL1, jamais gonflée (NIST SP 800-63B est un standard cible ; aucune conformité n’est revendiquée). Le SSO single-IdP OIDC/SAML avec configuration gérée et scellée et le provisionnement SCIM des utilisateurs et des groupes font partie du build ouvert ; la fédération multi-IdP par tenant et le SSO imposé relèvent d’Enterprise.
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 ?
Pas comme une confiance vérifiée en direct. Des connecteurs en lecture seule ingèrent ces registres d’agents sous forme d’instantanés de roster, et le graphe WIF lui-même est rendu à partir des règles de fédération que vous déclarez — il montre ce que vous avez déclaré et ce que rapportent les rosters, pas une relation de confiance vérifiée en direct sur le réseau. La fédération en direct face à ces registres 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 ?
Oui. Une session privilégiée effectue un step-up avec WebAuthn/FIDO2 ou un certificat de carte PIV/CAC jusqu’au niveau AAL3 vérifié par matériel de NIST SP 800-63B — un standard cible ; aucune conformité NIST ou FIPS n’est revendiquée. Le step-up est en sécurité fermée : l’élévation expire après une courte fenêtre de fraîcheur, une session sans cérémonie vérifiée est affichée AAL1, et le break-glass ou les approbations critiques refusent d’avancer en dessous d’AAL3.
Proposez-vous le SSO et le provisionnement SCIM ?
Oui. Le build ouvert fournit un SSO single-IdP OIDC et SAML avec une configuration gérée adossée au magasin — secrets scellés au repos, écritures de configuration protégées par un step-up AAL3 — plus le provisionnement SCIM des utilisateurs et des groupes. Ce qu’un groupe d’annuaire peut conférer reste une décision de l’opérateur : les correspondances de rôles ne sont jamais modifiables depuis l’IdP. La fédération multi-IdP par tenant et la politique SSO imposée sont des capacités Enterprise.
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.