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. L’inventaire des identités et les liaisons d’agents relèvent de Community. Les connecteurs d’annuaires et de rosters, la fédération des identités d’agents et PIV/CAC relèvent de Business (Identity & Scale). L’enregistrement des agents relève de Business (Identity & Scale).
Dans le produit
Identité et accès
Données d’exemple. Les sources d’utilisateurs depuis lesquelles on se connecte, chaque utilisateur avec ses groupes, son rôle et sa méthode de connexion, et les groupes associés aux rôles. Plusieurs sources d’utilisateurs et l’association des groupes aux rôles relèvent de Business (Identity & Scale).
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
Consultez les conditions de connexion WIF et les limites des requêtes en direct.
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
Enregistrements d’identité et relations déclarées
Créer une NHI ajoute un enregistrement d’identité par agent dans Olivares. Cet enregistrement ne délivre pas à lui seul un identifiant SPIFFE et n’établit pas de fédération. Le schéma illustre des relations déclarées ; une identité non résolue reste inconnue.
Ce qui est réel
Enregistrements d’identité, vérification supplémentaire configurable et visibilité de la fédération
Le graphe WIF en lecture seule part des règles de fédération configurées. Avec une connexion Anthropic WIF configurée et un jeton OAuth org:admin, Olivares compare ces règles à la configuration de fédération en direct et montre la provenance et les écarts. Sans ce jeton, il montre uniquement les déclarations ; une requête en direct qui échoue est signalée comme indisponible. Cela ne prouve pas une fédération avec tous les fournisseurs d’identité. La fédération des identités d’agents relève de Business (Identity & Scale).
- 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é.
- Community comprend un fournisseur d’identité OIDC ou SAML actif. Business : Identity & Scale ajoute le serveur SCIM 2.0 entrant pour les utilisateurs et les groupes, plusieurs fournisseurs d’identité et une politique de SSO obligatoire.
Business : annuaires et plusieurs fournisseurs d’identité
Community se connecte avec un fournisseur OIDC ou SAML. Business ajoute le serveur SCIM 2.0 entrant, jusqu’à cinq fournisseurs d’identité actifs, l’import d’annuaire depuis Okta, Entra ID, Keycloak et d’autres, les départements, le provisionnement SCIM sortant et l’authentification renforcée PIV/CAC.
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 ?
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 ?
Olivares prend en charge WebAuthn/FIDO2 et PIV/CAC. L’administrateur choisit la politique de vérification supplémentaire : none (par défaut, sans cérémonie supplémentaire), totp (code d’authentification ou MFA compatible du fournisseur d’identité), ou passkey (vérification récente par passkey ou PIV). L’accès d’urgence et les approbations critiques suivent cette politique. L’authentification, les permissions et l’isolation des tenants restent applicables. AAL3 est un objectif d’assurance, pas une certification NIST ou FIPS. PIV/CAC et l’accès d’urgence relèvent de Business.
Community et Business incluent-ils le SSO et le provisionnement SCIM ?
Community comprend un fournisseur d’identité OIDC ou SAML actif. Business : Identity & Scale ajoute le serveur SCIM 2.0 entrant pour les utilisateurs et les groupes, plusieurs fournisseurs d’identité et une politique de SSO obligatoire.
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.