Vai al contenuto

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 SSO e SCIM, l'elenco delle NHI, l'autenticazione MCP, il grafo WIF, lo stato di conformità di chiavi e residenza e i login privilegiati. La cattura è precedente al backend SSO/SCIM ormai consegnato: la sua scheda SSO/SCIM mostra ancora l'avviso onesto «backend in attesa» di quella build — schermate reali, mai dati fabbricati.

Screenshot reale
Console delle identità di Olivares: schede per SSO e SCIM, l'elenco delle NHI, l'autenticazione MCP, il grafo WIF, lo stato di conformità di chiavi e residenza e i login privilegiati; in questa cattura precedente la scheda SSO/SCIM mostra un avviso di backend in attesa invece di dati fabbricati.

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.

Diagramma: gli agenti vengono mappati su un'identità per agente (SPIFFE/WIF) che si federa con Entra ID, AWS IAM e Google Cloud; un agente non ha identità ed è disegnato tratteggiato e segnalato come «nessuna identità».
L'agente ignoto è disegnato tratteggiato e segnalato come «nessuna identità» — mai assorbito in una NHI reale. La federazione mostrata riflette le regole che dichiari.

Cosa è reale

L'associazione agli NHI, lo step-up hardware e SSO/SCIM sono attivi; la federazione verificata live 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.
  • 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.
  • Consegnato per le persone: step-up WebAuthn/FIDO2 e con smartcard PIV/CAC per i login privilegiati, applicato fail-closed — break-glass e le approvazioni critiche rifiutano sotto la soglia AAL3 verificata via hardware, e una sessione senza cerimonia recente è indicata come AAL1, mai gonfiata (NIST SP 800-63B è uno standard obiettivo; non si rivendica conformità). L'SSO single-IdP OIDC/SAML con configurazione gestita e sigillata e il provisioning SCIM di utenti e gruppi fanno parte della build open; la federazione multi-IdP per tenant e l'SSO imposto sono Enterprise.

Identity & NHI — domande

Oggi Olivares si federa live con Entra Agent ID, AWS AgentCore o Google Agent Identity?

Non come fiducia verificata live. Connettori in sola lettura ingeriscono quei registri di agenti come snapshot di roster, e il grafo WIF stesso è reso a partire dalle regole di federazione che dichiari — mostra ciò che hai dichiarato e ciò che i roster riportano, non una relazione di fiducia verificata live in transito. La federazione live rispetto a quei registri è 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?

Sì. Una sessione privilegiata esegue lo step-up con WebAuthn/FIDO2 o con un certificato smartcard PIV/CAC fino alla soglia AAL3 verificata via hardware di NIST SP 800-63B — uno standard obiettivo; non si rivendica conformità NIST o FIPS. Lo step-up è fail-closed: l'elevazione scade dopo una breve finestra di freschezza, una sessione senza cerimonia verificata è indicata come AAL1, e break-glass o le approvazioni critiche rifiutano di procedere sotto AAL3.

Fornite SSO e provisioning SCIM?

Sì. La build open fornisce SSO single-IdP OIDC e SAML con una configurazione gestita basata sullo store — segreti sigillati a riposo, scritture di configurazione protette da uno step-up AAL3 — più il provisioning SCIM di utenti e gruppi. Ciò che un gruppo di directory può conferire resta una decisione dell'operatore: le mappature dei ruoli non sono mai scrivibili dall'IdP. La federazione multi-IdP per tenant e la policy SSO imposta sono capacità Enterprise.

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.