Prodotto · Identity & NHI
Dai a ogni agente la propria identità — e scopri quando non ce l'ha
Un service account condiviso rende impossibile rispondere alla domanda «quale agente lo ha fatto?». Olivares associa un agente a una non-human identity, genera una NHI dedicata per agente e individua gli agenti che ne condividono una — la differenza tra attribuire l'accesso in modo certo e farlo solo in modo approssimativo. Un'identità che non riesce a risolvere non viene mai trattata in silenzio come se fosse reale. L’inventario delle identità e i collegamenti degli agenti fanno parte di Community; i connettori di directory e roster, la federazione delle identità degli agenti e PIV/CAC fanno parte di Business (Identity & Scale). La registrazione degli agenti fa parte di Business (Identity & Scale).
Nel prodotto
Identità e accesso
Dati di esempio. Le fonti di utenti da cui si accede, ogni utente con gruppi, ruolo e metodo di accesso, e i gruppi associati ai ruoli. Più origini utente e l’associazione dei gruppi ai ruoli fanno parte di Business (Identity & Scale).
Cosa governi
Da un account condiviso a un'identità per agente
L'identità è l'asse su cui la mappa degli accessi attribuisce. Una NHI dedicata per agente trasforma l'«approssimativo» in «certo»; tutto quanto segue è onesto su quanto lontano può arrivare.
Associa o genera una NHI
Associa un agente a una non-human identity esistente, oppure genera una NHI dedicata per agente. Una NHI dedicata è ciò che permette alla mappa degli accessi di attribuire l'accesso in modo certo a un singolo agente — non in modo approssimativo a un pool.
Rilevamento di identità condivisa
Quando più agenti usano lo stesso account, l'attribuzione per agente è realmente ambigua. Olivares la segnala come rilevamento e lo dichiara — non fa una media e non finge di sapere quale agente abbia agito.
Grafo WIF in sola lettura
Consulta i requisiti della connessione WIF e i limiti delle query in tempo reale.
L'ignoto onesto
Un'identità che Olivares non riesce a risolvere viene rappresentata come ignota e segnalata — mai promossa in silenzio a una NHI con nome. Nessun segnale di identità significa nessuna attribuzione, detto chiaramente.
Come funziona
Registri di identità e relazioni dichiarate
Creare una NHI aggiunge in Olivares un record di identità per agente. Quel record non emette da solo una credenziale SPIFFE né stabilisce una federazione. Il diagramma illustra relazioni dichiarate; un’identità non risolta resta sconosciuta.
Cosa è reale
Record di identità, verifica aggiuntiva configurabile e visibilità della federazione
Il grafo WIF in sola lettura parte dalle regole di federazione configurate. Con una connessione Anthropic WIF configurata e un token OAuth org:admin, Olivares confronta quelle regole con la configurazione di federazione attuale e mostra provenienza e differenze. Senza quel token mostra solo dichiarazioni; una query live fallita viene indicata come non disponibile. Ciò non dimostra la federazione con ogni provider di identità. La federazione delle identità degli agenti fa parte di Business (Identity & Scale).
- Consegnato come ingestione in sola lettura: connettori di roster leggono i registri di identità degli agenti degli hyperscaler — Microsoft Entra Agent ID, AWS Bedrock AgentCore e il registro degli agenti di Google. La federazione verificata live in transito rispetto a quei registri resta nella roadmap, e non la rivendichiamo prima che sia disponibile.
- Community include un provider di identità OIDC o SAML attivo. Business: Identity & Scale aggiunge il server SCIM 2.0 in ingresso per utenti e gruppi, più provider di identità e una policy SSO obbligatoria.
Business: directory e più provider di identità
Community accede con un provider OIDC o SAML. Business aggiunge il server SCIM 2.0 in ingresso, fino a cinque provider di identità attivi, importazione della directory da Okta, Entra ID, Keycloak e altri, reparti, provisioning SCIM in uscita e step-up PIV/CAC.
Identity & NHI — domande
Oggi Olivares si federa live con Entra Agent ID, AWS AgentCore o Google Agent Identity?
Due agenti condividono un unico service account. Quale dei due dice Olivares che ha agito?
Nessuno, con certezza. Un'identità condivisa rende l'attribuzione per agente realmente ambigua, quindi Olivares solleva un rilevamento di identità condivisa e attribuisce l'accesso solo in modo approssimativo — non fabbricherà una certezza su quale agente abbia agito. Genera una NHI dedicata per agente e la mappa degli accessi potrà allora attribuire quell'agente in modo certo.
Supportate lo step-up WebAuthn AAL3 o PIV-CAC per i login privilegiati?
Olivares supporta WebAuthn/FIDO2 e PIV/CAC. L’amministratore sceglie la politica di verifica aggiuntiva: none (predefinita, senza cerimonia aggiuntiva), totp (codice dell’autenticatore o MFA compatibile del provider di identità) oppure passkey (verifica recente con passkey o PIV). L’accesso di emergenza e le approvazioni critiche seguono questa politica. Autenticazione, permessi e isolamento dei tenant restano applicabili. AAL3 è un obiettivo di garanzia, non una certificazione NIST o FIPS. PIV/CAC e il break-glass fanno parte di Business.
Community e Business includono SSO e provisioning SCIM?
Community include un provider di identità OIDC o SAML attivo. Business: Identity & Scale aggiunge il server SCIM 2.0 in ingresso per utenti e gruppi, più provider di identità e una policy SSO obbligatoria.
Dai ai tuoi agenti identità che puoi attribuire
Distribuisci Olivares sulla tua infrastruttura, genera una NHI dedicata per agente e trasforma l'«approssimativo» in «certo» sulla tua mappa degli accessi.