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.
Nel prodotto
La console delle identità
Uno screenshot reale, con dati di esempio. Schede per l'elenco delle NHI, l'autenticazione MCP, il grafo WIF, lo stato di conformità di chiavi e residenza e i login privilegiati. La scheda SSO/SCIM è onesta sul proprio limite: l'endpoint di backend non è ancora attivo, quindi non mostra nulla invece di inventarlo.
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
Un grafo di workload identity federation mappa le tue identità per agente sul tuo IdP. Viene reso in sola lettura a partire dalle regole di federazione che dichiari — una vista di ciò che hai dichiarato, non una verifica live della fiducia effettivamente in transito.
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
Federare un'identità per agente al tuo IdP
Ogni agente riceve un'identità per agente — una credenziale SPIFFE/WIF — che si federa al tuo identity provider. Un agente senza identità risolvibile non viene assorbito da una reale: viene rappresentato a parte e segnalato.
Cosa è reale
L'associazione agli NHI e il grafo WIF sono attivi; la federazione live e lo step-up AAL3 no
Su questo siamo precisi, perché la differenza è l'intero senso di una superficie di identità:
- Attivo: associare un agente a una NHI, generare una NHI dedicata per agente, il rilevamento di identità condivisa e il grafo WIF in sola lettura. Il grafo riflette le regole di federazione che dichiari — non è un'immagine verificata live della federazione in transito.
- Roadmap: la federazione live con i registri di identità degli agenti GA degli hyperscaler — Microsoft Entra Agent ID, AWS AgentCore, Google Agent Identity. Oggi pubblichiamo le regole dichiarate e non rivendichiamo una verifica live prima che sia disponibile.
- Non implementato: lo step-up WebAuthn AAL3 / PIV-CAC. Non è implementato e oggi fallisce in modo sicuro a AAL1 — diciamo AAL1, non un livello di assurance che non ci siamo guadagnati. Alcune fonti di identità live (LDAP, IdP, secret manager) e i Gruppi SCIM non sono ancora collegati, e la scheda SSO/SCIM è onesta al riguardo: backend in attesa, niente da mostrare, mai fabbricato.
Identity & NHI — domande
Oggi Olivares si federa live con Entra Agent ID, AWS AgentCore o Google Agent Identity?
No — non live. Il grafo WIF è in sola lettura e viene reso a partire dalle regole di federazione che dichiari, quindi mostra ciò che hai dichiarato, non una relazione di fiducia verificata live in transito. La federazione live con quei registri di identità degli agenti GA degli hyperscaler è in roadmap, e non la rivendichiamo prima che sia disponibile.
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?
Non ancora. Lo step-up AAL3 tramite WebAuthn o PIV-CAC non è implementato; oggi il percorso fallisce in modo sicuro a AAL1, ed è esattamente così che lo etichettiamo — non mostriamo un livello di assurance che non ci siamo guadagnati. La scheda dei login privilegiati mostra ciò che è effettivamente applicato ora.
Perché la scheda SSO/SCIM è vuota?
Perché il relativo endpoint di backend non è ancora attivo, quindi non c'è realmente nulla da mostrare — e il prodotto lo dichiara invece di riempirla con dati dall'aspetto plausibile. Lo stesso vale per le fonti di identità live come LDAP, IdP e secret manager, e per i Gruppi SCIM: non ancora collegati, mostrati onestamente vuoti.
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.