Ogni agente verificato è affidabile, giusto? È come dire che ogni automobilista con la patente è un buon guidatore. Il settore dell'IA sta correndo per risolvere il problema dell'identità per gli agenti autonomi — e gli operatori storici dell'IAM corrono insieme a esso. Stanno risolvendo il problema giusto. Ne stanno risolvendo la metà. Questa guida ripercorre le due domande a cui bisogna rispondere separatamente, perché OAuth e i ruoli non possono rispondere a entrambe, e come appare il livello comportamentale quando viene effettivamente implementato.
Ogni decisione di accesso per un agente autonomo risponde a due domande distinte, e confonderle è il motivo per cui la governance fallisce in produzione.
Livello di identità. Chi è questo agente? Chi lo ha creato? Chi rappresenta? La credenziale che presenta è verificabile crittograficamente? È stata revocata? Ogni piattaforma IAM risponde bene a questa domanda.
Livello comportamentale. Questo agente è rimasto nel proprio ambito? Ha avuto allucinazioni? Ha divulgato PII tramite chiamate a strumenti? Il suo profilo di rischio sta cambiando? Le piattaforme IAM non possono rispondere a questo — e non sono mai state progettate per farlo.
Un agente che non supera la verifica dell'identità dovrebbe essere bloccato. Un agente che supera la verifica dell'identità ma si comporta male dovrebbe essere limitato. Nessuno dei due livelli da solo è sufficiente.
Gli operatori storici dell'IAM — Okta, SailPoint, Microsoft Entra, IBM, Auth0, Curity e il resto dell'ecosistema guidato dagli standard (W3C DID, OpenID Foundation) — stanno convergendo verso una risposta sofisticata alla questione dell'identità per gli agenti autonomi. Il vocabolario è coerente tra i vari fornitori: provisioning just-in-time, concessione dinamica dei permessi, credenziali effimere, autorità delegata, catene di attestazione. L'NCCoE del NIST ha un progetto su identità e autorizzazione di software e agenti IA che mappa lo stesso spazio.
È un buon lavoro. Il livello di identità è difficile ed è il punto giusto da cui partire. Nulla di quanto segue sostiene che l'identità sia superflua o che gli operatori storici abbiano torto al riguardo. Non hanno torto.
Per capire cosa rende davvero verificabile l'identità di un agente — non solo provisionata — vedi Identità verificabile degli agenti.
L'IAM risponde a chi è stato provisionato con quale accesso nel momento in cui abbiamo emesso la credenziale. Gli agenti autonomi hanno bisogno di una risposta a una domanda diversa: questa entità, con questa credenziale, in questo contesto, si sta comportando in un modo tale da giustificare il mantenimento del suo accesso adesso?
Il bilancio 2025–2026 mostra come appare questo divario nella pratica:
Ognuno di questi incidenti avrebbe superato un audit Okta nel momento in cui si è verificato. La credenziale è stata emessa correttamente, il ruolo delimitato correttamente, l'autenticazione riuscita. Nulla di tutto ciò ha impedito il fallimento, perché il fallimento era a valle dell'identità.
Il livello comportamentale valuta un agente in modo continuo su cinque dimensioni — fiducia dell'identità (sì, l'identità è una delle cinque, ma con un modello di decadimento onesto anziché un dato permanente), rischio, affidabilità, autonomia e calibrazione (se la fiducia dichiarata da un agente corrisponde ai suoi risultati effettivi) — ed emette un livello di policy (allow / review / deny) per ogni decisione. È fondamentale che le cinque dimensioni siano ortogonali: un agente può essere verificato crittograficamente (alta fiducia dell'identità) e avere comunque un punteggio di affidabilità in peggioramento, e il livello di policy tiene conto di entrambi.
La guida completa al modello di valutazione a cinque dimensioni si trova in Punteggio di fiducia degli agenti — Una guida tecnica. L'argomentazione più approfondita sul perché un punteggio composito non sopravviva in produzione si trova in Identità, rischio, affidabilità, autonomia: perché un unico punteggio di fiducia non basta per gli agenti in produzione.
OAuth e i sistemi di identità macchina (SPIFFE/SPIRE, mTLS, credenziali client OIDC) sono stati progettati per servizi con identificatori stabili, credenziali di lunga durata e persone nel ciclo decisionale per le decisioni di accesso. Gli agenti autonomi infrangono tutte e tre le ipotesi: sono effimeri, prendono decisioni di accesso in autonomia a velocità macchina, e le loro credenziali devono trasportare autorità delegata, ambito e segnali di livello comportamentale che i protocolli originali non erano progettati per esprimere.
L'aggiunta di OAuth 2.1 a MCP nel 2026 è un progresso reale. Ma una scansione di sicurezza su circa 2.000 server MCP ha rilevato che ognuno di essi, senza eccezioni, era privo di autenticazione. La specifica esiste; la sua adozione no. (Quadro completo in Sicurezza dei server MCP: la falla PII.) Le Agent Card di A2A sono firmate ma autodichiarate — non c'è alcun vincolo di attestazione, nessuno storico comportamentale, nessun meccanismo per revocare la fiducia in base al comportamento osservato. Entrambi i protocolli risolvono la scoperta e l'interoperabilità. Nessuno dei due ti dice se ci si può fidare dell'agente dall'altra parte per ciò che sta per fare.
I due livelli, collegati insieme in VeriSwarm:
Il livello di identità. Verifica crittografica, credenziali JWT ES256 con TTL di 1 ora, catene di delega per flussi multi-agente, un endpoint JWKS per consentire a qualsiasi piattaforma di verificare senza chiamare la nostra API. Tutti i dettagli in Agent Passport: credenziali portatili.
Il livello comportamentale. Valutazione continua sulle cinque dimensioni, livelli di policy dinamici, la tassonomia a 24 eventi. Piano gratuito. Lo stesso registro di audit concatenato tramite hash usato dai piani a pagamento.
Il livello di prova. Registro di audit immutabile concatenato tramite hash che copre eventi di identità, segnali comportamentali, decisioni di policy e ogni cambio di stato. Verifica della catena su richiesta — guida pratica in Verificare una catena Vault.
Quando un agente presenta una credenziale Passport, la piattaforma ricevente sa chi è. Quando quella credenziale porta con sé un punteggio di fiducia Gate, la piattaforma sa anche come si è comportato. Vault dimostra che l'intera sequenza è realmente avvenuta. Questa è la differenza tra una patente e uno storico di guida.
L'EU AI Act non richiede solo trasparenza su chi ha costruito un sistema IA. L'articolo 9 impone un processo continuo di gestione del rischio lungo tutto il ciclo di vita — non un controllo di identità una tantum. L'articolo 12 richiede la registrazione automatica degli eventi per tutta la vita del sistema — registrazione comportamentale, non verifica dell'identità. L'articolo 14 richiede una supervisione umana che consenta l'interpretazione degli output — interpretare richiede il monitoraggio del comportamento. La normativa presuppone già che l'identità non sia fiducia; la conformità richiede entrambe. Quadro completo dell'EU AI Act per gli stack di agenti.
Sì. L'identità è il livello uno — VeriSwarm non lo sostituisce. Se i tuoi agenti si autenticano tramite Okta, SailPoint, Entra, Auth0 o qualsiasi IAM personalizzato, mantienilo. VeriSwarm si affianca, aggiunge il livello comportamentale che il tuo IAM non ha, e si integra con l'identità che la tua piattaforma già emette. I due livelli lavorano insieme; non sono in competizione.
No. Quelli sono provider di identità — rispondono a «chi è questa entità e quale ruolo ricopre?». È un problema difficile e lo risolvono bene. VeriSwarm risponde a una domanda diversa: «questa entità si sta comportando in un modo tale da giustificare il mantenimento del suo accesso adesso?». Uno stack di identità ti dice che l'Agente A è stato provisionato con il ruolo X sei mesi fa. Lo stack comportamentale ti dice che l'Agente A ha avuto allucinazioni da martedì e oggi dovrebbe essere rimosso dal ruolo X. Domande diverse, entrambe necessarie.
Una scommessa diversa. L'identità di agente basata su blockchain (ERC-8004, OriginTrail, passaporti decentralizzati) privilegia la resistenza alla censura e l'attestazione on-chain. VeriSwarm Passport utilizza JWT ES256 con verifica JWKS — un approccio basato su standard, senza necessità di blockchain, più veloce da verificare (nessuna consultazione della catena) e integrabile con l'infrastruttura di identità aziendale esistente. Entrambi sono validi per il livello di identità; la scelta dipende dalla necessità o meno di provenienza on-chain. In ogni caso, il livello comportamentale resta la metà mancante.
Gate — il livello comportamentale — funziona nel piano gratuito con ingestione di eventi illimitata, 5.000 decisioni di fiducia al giorno, il motore di valutazione a cinque dimensioni, e lo stesso registro concatenato tramite hash usato dai piani a pagamento. Anche le credenziali portatili di base — JWT ES256 con verifica JWKS — sono gratuite e illimitate. Ciò che è riservato ai piani Pro e superiori è la suite Passport completa: catene di delega per flussi multi-agente, manifesti firmati e verifica dell'identità tra organizzazioni. Puoi iniziare con il monitoraggio comportamentale e le credenziali di base sugli agenti che il tuo IAM esistente già autentica, e poi aggiungere il Passport completo quando avrai bisogno della delega multi-agente.
I sistemi di identità macchina sono stati progettati per servizi con identificatori stabili, credenziali di lunga durata e operatori umani che prendono le decisioni di accesso. Gli agenti sono effimeri (spesso da pochi secondi a pochi minuti), prendono decisioni di accesso in autonomia e hanno bisogno di credenziali che esprimano esplicitamente autorità delegata e ambito. Passport è basato su JWT per compatibilità, ma il suo modello di credenziali trasporta catene di delega, espressioni di ambito e segnali di livello comportamentale che i formati di identità macchina non erano progettati per esprimere. Usa l'identità macchina per il tuo livello servizio-a-servizio; usa Passport per il livello agente-ad-agente sopra di esso.
Entrambe, combinate a livello della decisione. Una decisione di policy prende l'identità dell'agente, il suo punteggio di fiducia attuale su tutte e cinque le dimensioni, l'azione specifica tentata, ed eventuali override tramite kill switch o verifica Passport, ed emette un singolo allow / review / deny con un codice motivo. Né l'identità né il punteggio di fiducia da soli determinano l'esito — il motore decisionale valuta prima la policy Cedar del tenant (o una matrice predefinita hardcoded se non ne è configurata alcuna) rispetto a tutto quel contesto insieme.
Sì, ed è esattamente questo il senso del livello comportamentale. Una credenziale Passport valida o un token emesso dall'IAM dimostra che l'identità dell'agente è legittima; non dice nulla sul fatto che ci si debba fidare dell'agente per una determinata azione in questo momento. Il kill switch è l'esempio più chiaro: uccidere un agente non revoca né altera la sua credenziale di identità, ma ogni verifica di decisione su quell'agente restituisce deny con reason_code: "agent_killed" finché un operatore non lo annulla — il livello di identità resta verde mentre il livello comportamentale lo sovrasta.
No. La verifica dell'identità soddisfa i requisiti di trasparenza e provenienza — chi lo ha costruito, chi lo gestisce — ma entrambi i framework richiedono evidenze comportamentali continue, non un controllo una tantum. Il requisito di registrazione automatica degli eventi dell'articolo 12 dell'EU AI Act e le aspettative di monitoraggio continuo del NIST AI RMF sono soddisfatti dalla registrazione degli eventi del livello comportamentale e dal registro concatenato tramite hash di Vault, non da una sola credenziale di identità.
Il motore di valutazione di Gate funziona nel piano gratuito e si integra con l'identità che la tua piattaforma già emette. Non devi eliminare nulla. Devi aggiungere il livello che manca al tuo IAM.