Gli agenti AI hanno bisogno di un'identità prima che di un gateway

Hush Security è arrivata su Google News con un'affermazione netta: le imprese devono identificare ogni agente AI prima di collocare un gateway attorno al suo traffico. Il tema è rilevante perché molti agenti continuano a ereditare autorizzazioni umane o a condividere credenziali. Un gateway può ispezionare le connessioni, ma non può stabilire responsabilità quando tutti i chiamanti appaiono uguali.

L'argomentazione ha seguito l'annuncio di finanziamento di Hush Security del luglio 2026 e l'espansione della sua piattaforma per identità non umane. L'azienda ha raccolto 30 milioni di dollari e introdotto un Identity Gateway progettato per scoprire gli agenti, assegnare loro identità, mediare accessi limitati e registrarne le azioni. L'idea centrale è semplice: i controlli di sicurezza non possono governare un agente in modo affidabile finché non sanno quale agente sta agendo.

Questa posizione mette in discussione un approccio gateway-first che sta emergendo nell'AI aziendale. Cisco, Palo Alto Networks, Microsoft e altri fornitori di sicurezza stanno ora collocando controlli tra agenti e strumenti. Eppure un gateway vede le richieste, non necessariamente l'identità completa, il proprietario, l'autorità delegata o la cronologia di esecuzione che vi sono dietro. Il risultato è un perimetro di sicurezza familiare con un problema di attribuzione inedito.

Non è un dibattito sull'utilità dei gateway. Restano punti di applicazione utili per autenticazione, verifiche delle policy, ispezione del traffico e restrizioni sugli strumenti. La domanda è se le imprese stiano installando il posto di controllo prima di rilasciare credenziali distinte a chiunque lo attraversi.

Il titolo di Google News indica un cambiamento più ampio nell'identità

Hush Security sta riformulando la sicurezza degli agenti AI come un problema di identità che i soli gateway non possono risolvere.

L'azienda è uscita dalla fase stealth nel 2025 concentrandosi sulle identità non umane. Queste includono account di servizio, chiavi API, token di accesso e altre credenziali utilizzate dal software anziché dai dipendenti. Inizialmente Hush ha affrontato un problema aziendale di lunga data: le organizzazioni spesso accumulano credenziali macchina difficili da inventariare, ruotare e revocare.

Gli agenti autonomi aumentano la posta in gioco. Possono interpretare istruzioni, selezionare strumenti, recuperare dati e compiere azioni in più sistemi durante un singolo incarico. Un'automazione convenzionale segue una sequenza predeterminata. Un agente può modificare il proprio percorso dopo aver ricevuto nuove informazioni, rendendo più difficile prevederne le autorizzazioni effettive.

Nel suo report del 30 luglio, VentureBeat ha descritto come Hush stesse estendendo quel lavoro precedente in un agent identity gateway. La piattaforma proposta si colloca tra gli agenti e le risorse aziendali. Hush afferma di poter scoprire gli agenti, collegarli a proprietari umani, emettere accessi specifici per attività, registrare l'attività e revocare centralmente un agente.

Hush definisce il proprio modello di accesso “least agency”. Il termine adatta il principio di sicurezza del privilegio minimo, che assegna a un utente o a un carico di lavoro solo l'accesso necessario per un'attività. Least agency aggiunge a tale decisione l'obiettivo dell'agente, il contesto di esecuzione e l'autorità delegata.

Si consideri un agente di coding incaricato di diagnosticare un errore in produzione. Potrebbe aver bisogno di accesso in lettura a log, codice sorgente e metadati di deployment. Non dovrebbe ricevere automaticamente l'autorizzazione a modificare registri di fatturazione, scaricare database dei clienti o riscrivere la propria policy di sicurezza.

La stessa distinzione vale per gli agenti di produttività. Un assistente che prepara un briefing per una riunione potrebbe cercare in calendari, note e documenti approvati. Non ha bisogno di accesso illimitato a ogni casella di posta, cloud drive o console amministrativa disponibile per il dipendente che lo ha avviato.

Un gateway può bloccare destinazioni vietate o richieste malformate. Tuttavia, le sue policy diventano grossolane quando più agenti usano lo stesso token OAuth o account di servizio. Può sapere che una credenziale approvata ha richiesto un file. Potrebbe non sapere quale agente ha effettuato la richiesta, perché ha agito o se l'azione rientrasse nella delega originaria.

Ecco perché il titolo di Google News ha un peso maggiore di una tipica storia di finanziamento. Hush non sta semplicemente aggiungendo un ulteriore livello di ispezione. Sostiene che l'identità debba diventare il registro organizzativo per proprietario, scopo, autorizzazioni, sessioni e azioni di un agente.

Questo modello cambia anche la risposta agli incidenti. I team di sicurezza iniziano di solito un'indagine chiedendosi chi abbia avuto accesso a una risorsa. Le credenziali condivise possono ridurre la risposta a un'applicazione, un dipendente o un account di servizio. Un'identità distinta dell'agente offre un punto di partenza più circoscritto, soprattutto quando diversi processi autonomi operano sotto l'autorità di una sola persona.

Le credenziali condivise costringono i gateway a fare supposizioni

Un gateway può applicare una policy solo con la stessa precisione dell'identità e del contesto associati a ciascuna richiesta.

Molti dei primi agenti aziendali sono stati distribuiti come script. Gli sviluppatori hanno memorizzato una chiave API, assegnato un account di servizio o inoltrato il token OAuth dell'utente umano. Questo approccio rende rapidamente operativo un prototipo, ma comprime diversi attori in un'unica identità di sicurezza.

Il dipendente, l'host dell'agente, il modello, il singolo agente e la sessione dello strumento possono tutti apparire sotto la stessa autorizzazione. Se l'agente crea sotto-agenti, la catena diventa ancora più difficile da ricostruire. Un servizio a valle potrebbe ricevere un token valido senza sapere quale componente abbia avviato l'azione.

L'indagine di VentureBeat del giugno 2026 su 107 intervistati aziendali ha rilevato che il 69 percento utilizzava chiavi API condivise nelle distribuzioni di agenti. La sua ricerca sulla sicurezza degli agenti ha inoltre rilevato che l'82 percento faceva affidamento principalmente sui controlli forniti dai provider di modelli o dagli hyperscaler.

Questi controlli offrono protezioni utili. I filtri per prompt possono rilevare schemi di injection noti, i sistemi di prevenzione della perdita di dati possono segnalare contenuti sensibili e le policy cloud possono limitare l'accesso alle risorse gestite. Nessuna di queste funzionalità crea automaticamente un'identità distinta per ogni istanza di agente.

L'indagine ha rilevato un'adozione del 13 percento di Microsoft Entra Agent ID tra gli intervistati. Altri prodotti specifici per l'identità apparivano a una sola cifra percentuale. Questo divario suggerisce che le imprese abbiano implementato protezioni AI generali più rapidamente della responsabilità specifica per gli agenti.

Lo squilibrio diventa più grave quando un agente riceve autorità eccessiva. Una credenziale amministrativa condivisa non diventa sicura perché un gateway la monitora. Se la policy consente alla credenziale di eseguire un'azione, il gateway può approvare una richiesta pericolosa che è tecnicamente valida.

La prompt injection illustra il problema. Un agente potrebbe leggere testo non attendibile che gli ordina di recuperare materiale riservato o modificare una configurazione. L'istruzione può entrare attraverso un documento, un sito web, un'email, una risposta di uno strumento o un record di database. Un filtro linguistico deve quindi affrontare il difficile compito di distinguere un intento legittimo da uno manipolato.

I controlli dell'identità affrontano un livello diverso. Non devono stabilire se ogni frase sia malevola. Possono limitare l'autorità massima disponibile per l'agente, indipendentemente da ciò che decide il modello.

Per esempio, un agente di ricerca con accesso in sola lettura non può eliminare un repository sorgente dopo aver incontrato un'istruzione ostile. Un agente di supporto temporaneo non può conservare l'accesso ai dati dei clienti dopo la chiusura del ticket. Un agente finanziario autorizzato a redigere un pagamento non può anche approvare quel pagamento, a meno che la policy non conceda entrambe le azioni.

Le credenziali a breve durata riducono ulteriormente l'esposizione. Invece di collocare un segreto riutilizzabile nell'ambiente dell'agente, un sistema di identità può emettere un token per una singola attività, risorsa e finestra temporale. Il token scade automaticamente e può essere revocato al termine della sessione.

Questo modello supporta anche log migliori. Un record di audit dovrebbe identificare l'agente, il suo sponsor umano, l'attività, la decisione di policy, la credenziale utilizzata e l'azione risultante. Registrare solo la richiesta al gateway lascia agli investigatori troppe inferenze da fare dopo un incidente.

Le imprese già preservano il contesto nella gestione delle attività umane importanti. Registrano utente, dispositivo, applicazione, sessione, metodo di autenticazione e risorsa. Il software autonomo necessita almeno di un livello di dettaglio comparabile, perché può eseguire molte azioni senza fermarsi per una revisione umana.

La sfida è il volume. Un'organizzazione può creare, copiare o terminare agenti più rapidamente di quanto assuma dipendenti. Il provisioning delle identità deve quindi diventare automatico. La registrazione manuale creerebbe ritardi, incoraggerebbe aggiramenti e lascerebbe agenti ombra fuori dalla governance.

Questa pressione rende essenziale la gestione del ciclo di vita. Ogni identità dell'agente necessita di un evento di creazione, un proprietario, uno scopo approvato, un insieme di policy, una regola di scadenza e un percorso di revoca. Se una qualsiasi parte resta indefinita, il gateway riceve traffico da un attore che l'organizzazione non è in grado di spiegare pienamente.

Un gateway controlla il traffico, ma l'identità stabilisce l'autorità

L'architettura più solida tratta l'identità come fonte dell'autorità e il gateway come uno dei luoghi in cui tale autorità viene applicata.

Un gateway AI media di solito la comunicazione tra modelli, agenti, strumenti e servizi dati. Può autenticare le connessioni, ispezionare le richieste, applicare limiti di frequenza, filtrare contenuti e generare log. Un gateway MCP svolge funzioni simili per le connessioni Model Context Protocol.

MCP è un protocollo aperto che consente alle applicazioni AI di scoprire e chiamare strumenti esterni attraverso un'interfaccia comune. Riduce la necessità di codice di integrazione personalizzato, ma le connessioni standardizzate possono anche ampliare la superficie raggiungibile da un agente.

Un gateway diventa utile perché fornisce un punto centrale di controllo delle policy. I team di sicurezza possono collocare regole davanti a molti strumenti invece di modificare ciascun backend. Questa comodità architetturale non risponde alla domanda su chi sia l'agente o da dove provenga la sua autorità.

L'identità fornisce quella base. Un'identità distinta può associare l'agente al suo codice, host, proprietario, attività e capacità approvate. L'autorizzazione può quindi decidere cosa quell'identità può fare nelle condizioni attuali.

La distinzione ricorda un controllo aeroportuale. Esaminare ogni viaggiatore è prezioso, ma il processo dipende dal sapere quale viaggiatore presenta ciascun documento. Ispezionare i bagagli senza stabilire l'identità produce un record di sicurezza incompleto.

Il National Institute of Standards and Technology degli Stati Uniti ha collocato gli stessi componenti in un quadro più ampio nel 2026. Il suo progetto sull'identità degli agenti ha identificato identificazione degli agenti, autorizzazione, delega, logging, trasparenza e provenienza dei dati come aree di lavoro collegate.

NIST ha inoltre indicato tecnologie consolidate anziché proporre un'unica risposta proprietaria. OAuth può trasportare autorizzazioni delegate, OpenID Connect può esprimere informazioni di autenticazione e SCIM può supportare il provisioning delle identità. SPIFFE e SPIRE possono emettere identità verificabili crittograficamente per i carichi di lavoro software.

Queste tecnologie risolvono parti diverse del problema. OAuth indica quale accesso veicola un token. OpenID Connect aiuta a descrivere una parte autenticata. SCIM può creare o disattivare record di identità. SPIFFE può attestare che un carico di lavoro in esecuzione in un'infrastruttura controllata sia davvero il carico di lavoro che dichiara di essere.

Nessuna di esse cattura autonomamente l'intero ciclo di vita di un agente autonomo. Un'impresa deve comunque collegare un'identità di carico di lavoro con la delega umana, la policy, l'ambito dell'attività e la cronologia delle azioni.

Quella connessione mancante spiega perché non basta assegnare un nome a un agente. Un identificatore dichiarato autonomamente all’interno di una richiesta può essere modificato o copiato. Un’identità affidabile deve essere emessa o verificata da un sistema accettato dal servizio ricevente.

L’identità deve inoltre sopravvivere agli spostamenti attraverso l’infrastruttura. Gli agenti possono operare in applicazioni desktop, container cloud, ambienti di sviluppo, piattaforme gestite e servizi di terze parti. Una credenziale radicata esclusivamente in un cluster può perdere significato quando un agente attraversa un confine organizzativo.

Un documento dell’OpenID Foundation sulla gestione delle identità degli agenti descrive questa sfida di portabilità. Osserva che un identificatore del client MCP non costituisce necessariamente un’identità affidabile del workload o dell’agente. Spiega inoltre come l’attestazione basata sull’infrastruttura diventi più difficile quando gli agenti attraversano domini di fiducia.

Questa questione separa l’autenticazione dall’agency. L’autenticazione stabilisce che un componente software controlli una credenziale. L’agency descrive perché quel componente agisce, per conto di chi agisce e quale delega detiene in quel momento.

Un gateway necessita di entrambi i tipi di informazione. Dovrebbe respingere un chiamante non verificato, ma dovrebbe anche respingere un agente verificato che supera i limiti del compito delegato. Il superamento dell’autenticazione non può trasformarsi nell’autorizzazione a eseguire ogni azione disponibile per l’utente sponsor.

L’approccio di Hush colloca l’intermediazione dell’identità guidata dalle policy prima dell’accesso alle risorse. Il gateway diventa quindi un meccanismo di applicazione per tale autorità intermediata. Questa sequenza supporta autorizzazioni più ristrette e un’attribuzione più chiara rispetto a un gateway che scopre prima l’identità dal traffico.

L’architettura dipende comunque dall’integrazione. Applicazioni e server di strumenti devono rispettare le attestazioni di identità, gli scope o i token di capacità ricevuti. Se i sistemi downstream riducono ogni richiesta a un singolo account backend privilegiato, il record d’identità perde valore ai fini dell’applicazione delle policy.

I fornitori di sicurezza convergono sullo stesso punto di controllo

Il mercato si sta muovendo verso l’identità degli agenti, ma i fornitori divergono sul fatto che l’applicazione delle policy debba partire dall’identità, dal traffico di rete o dal comportamento degli endpoint.

Hush non è l’unica realtà a trattare gli agenti come una nuova classe di attori non umani. Microsoft, Cisco, Palo Alto Networks, 1Password, Okta, Ping Identity e diverse startup hanno introdotto funzionalità di identità o governance incentrate sugli agenti.

Duo Agentic Identity di Cisco registra gli agenti come oggetti distinti associati a proprietari umani. La sua architettura di sicurezza più ampia può instradare le chiamate agli strumenti attraverso un gateway MCP. Palo Alto Networks ha presentato un registro degli agenti, un provider d’identità per gli agenti e controlli gateway all’interno di Prisma AIRS.

Microsoft distribuisce la governance degli agenti tra Entra, Purview, Defender e Sentinel. Entra Agent ID si concentra sulla creazione e sulla governance delle identità degli agenti. Altri servizi Microsoft affrontano controlli sui dati, rilevamento delle minacce e monitoraggio.

CrowdStrike pone l’accento sull’attività degli endpoint. Questo approccio traccia ciò che i processi software fanno su un dispositivo, anziché affidarsi esclusivamente all’intenzione espressa da un modello. Può aiutare a rilevare modifiche ai file, avvii di processi e altre azioni concrete dopo il successo dell’autenticazione.

Le diverse strade sono complementari, ma competono per diventare il piano di controllo principale. I fornitori di identità sostengono che ogni azione debba iniziare da un attore affidabile e da un’autorità delimitata. I fornitori di rete vedono nei gateway punti centrali di ispezione. I fornitori di endpoint si concentrano sull’esecuzione osservabile.

RSAC 2026 ha mostrato quanto rapidamente queste categorie stessero convergendo. L’analisi di VentureBeat sui framework di sicurezza degli agenti ha rilevato che i principali fornitori avevano introdotto registri, gateway, oggetti identità e monitoraggio in fase di esecuzione.

Le lacune rimanenti rivelano perché nessun singolo controllo sia sufficiente. Un agente potrebbe superare ogni verifica delle credenziali e comunque modificare la policy che governa il proprio comportamento. Un gateway potrebbe vedere ogni chiamata agli strumenti senza ricostruire una catena di delega. Un sensore endpoint potrebbe osservare un’azione senza sapere se l’agente disponeva di una valida autorità aziendale.

La delega multi-agente crea il caso più difficile. Supponiamo che un agente di procurement chieda a un agente di ricerca di confrontare i fornitori. L’agente di ricerca crea quindi un agente di navigazione, che richiede documenti a un servizio di terze parti.

Ogni passaggio dovrebbe restringere o preservare l’autorità, senza ampliarla silenziosamente. Il servizio finale necessita di prove sufficienti per determinare chi ha avviato il compito, quali agenti hanno partecipato e se l’azione richiesta rientra nello scopo originario.

La tradizionale impersonificazione dell’utente si comporta male in questo contesto. Se ogni agente figlio eredita l’identità del dipendente, i sistemi downstream non possono distinguere l’utente originale dai delegati autonomi. Revocare un singolo figlio compromesso potrebbe richiedere la chiusura dell’intera sessione utente.

Un modello migliore assegna a ciascun agente un’identità distinta, mantenendo al contempo una catena di delega firmata. Il figlio riceve soltanto il sottoinsieme di autorizzazioni necessario al proprio incarico. I log preservano la relazione tra il proprietario umano, l’agente padre, l’agente figlio e l’azione risultante.

Questa struttura ricorda il modo in cui i workload cloud sicuri scambiano credenziali di breve durata. Tuttavia, gli agenti introducono comportamenti incerti e obiettivi espressi in linguaggio naturale. Le policy devono tenere conto sia dell’identità tecnica sia del contesto mutevole dell’attività.

Esiste anche un problema pratico di integrazione. Le aziende gestiscono già provider d’identità, sistemi di accesso privilegiato, gateway API, service mesh, agenti endpoint e piattaforme di monitoraggio della sicurezza. L’aggiunta di un livello separato per l’identità degli agenti può creare un’altra console e un’altra fonte di verità.

Gli approcci vincenti dovranno collegarsi all’infrastruttura di identità esistente. I team di sicurezza opporranno resistenza ai sistemi che richiedono a ogni applicazione di adottare un protocollo proprietario o di mantenere una directory duplicata dei dipendenti.

Questa pressione favorisce attestazioni basate su standard, token di breve durata e record di audit portabili. Favorisce inoltre i prodotti in grado di individuare agenti ombra prima che richiedano un’iscrizione formale.

La scoperta è importante perché i dipendenti possono installare assistenti di programmazione o collegare agenti locali senza approvazione della sicurezza. Una policy d’identità perfetta non serve a nulla per un agente della cui esistenza l’organizzazione non è a conoscenza. La telemetria di rete, endpoint, cloud e identità contribuisce a individuare tali deployment.

La convergenza del mercato sostiene quindi la premessa di Hush senza convalidare ogni affermazione sul prodotto. L’identità sta diventando necessaria, ma opererà accanto a gateway, sandbox, monitoraggio degli endpoint e controlli sui dati. La vera competizione riguarda quale livello definisca il record autorevole.

L’identità non rende un agente sicuro

Un’identità verificata migliora il controllo e la responsabilità, ma non dimostra che il comportamento di un agente sia affidabile.

Questa limitazione rappresenta la sfida più forte a una narrazione incentrata sull’identità. Un agente autenticato può comunque prendere una decisione sbagliata, seguire un’istruzione dannosa, esporre dati o invocare uno strumento non sicuro. L’identità dice ai difensori chi ha agito. Non garantisce che l’azione fosse sensata.

La sicurezza tradizionale offre un avvertimento. Account legittimi causano molti incidenti dannosi perché gli attaccanti rubano credenziali, i dipendenti ricevono accessi eccessivi oppure software approvato si comporta in modo inatteso. Un’identità valida è soltanto l’inizio di una decisione di policy.

I sistemi agentici aggiungono incertezza perché i loro piani possono cambiare durante l’esecuzione. Un modello può selezionare uno strumento diverso dopo aver letto nuove informazioni. Può fraintendere un vincolo o trattare contenuti non attendibili come un’istruzione.

Per questo il sandboxing rimane importante. Una sandbox isola l’esecuzione affinché un agente compromesso o in errore non possa influire liberamente sul sistema host. L’identità può limitare le risorse consentite, mentre l’isolamento vincola ciò che il processo può raggiungere tecnicamente.

Anche i controlli sui prompt e sugli output mantengono un ruolo. Possono intercettare schemi di attacco noti, dati sensibili o contenuti vietati prima che una richiesta raggiunga un altro sistema. La loro debolezza consiste nel trattare l’interpretazione semantica come unica difesa.

Un’architettura completa necessita di difesa in profondità. Il livello di identità stabilisce l’attore e l’autorità delegata. Il gateway applica le policy di connessione. La sandbox limita l’esecuzione. Il monitoraggio di endpoint e cloud registra il comportamento effettivo. I controlli sui dati limitano le informazioni sensibili.

Il motore delle policy deve rimanere fuori dal controllo dell’agente. Se un agente può modificare le regole che definiscono le proprie autorizzazioni, un’identità valida potrebbe aiutare gli investigatori ad attribuire il danno senza impedirlo.

Anche la protezione delle credenziali presenta un rischio. Assegnare a ogni agente un segreto unico e di lunga durata migliorerebbe l’attribuzione, moltiplicando però il numero di segreti che gli attaccanti possono rubare. I sistemi d’identità dovrebbero emettere credenziali di breve durata e mantenere i segreti riutilizzabili fuori dall’ambiente dell’agente.

Le organizzazioni devono inoltre evitare una proliferazione permanente degli agenti. Creare automaticamente identità è utile, ma le identità inattive necessitano di una scadenza automatica. Altrimenti, l’azienda sostituisce chiavi API non gestite con account di agenti non gestiti.

Anche la proprietà umana può diventare fuorviante. Associare un agente a un dipendente non significa che quel dipendente abbia esaminato ogni azione. I record di responsabilità dovrebbero distinguere tra sponsorizzazione, approvazione, operatività ed esecuzione.

Un manager può approvare un workflow mentre uno sviluppatore distribuisce l’agente e un altro dipendente avvia un’attività. Comprimere tutti e tre i ruoli in un unico campo “proprietario” può creare una falsa certezza.

La provenienza dei dati richiede un’attenzione simile. Un agente può combinare documenti, testo generato, risposte degli strumenti e contesto memorizzato. I log di sicurezza dovrebbero preservare quali informazioni hanno influenzato azioni importanti, senza raccogliere più contenuti sensibili del necessario.

Per i lavoratori della conoscenza, questa questione va oltre la cybersecurity. Gli agenti agiscono sempre più spesso su note personali, documenti di progetto, trascrizioni e decisioni precedenti. Una base di conoscenza personale ben organizzata può migliorare il contesto, ma l’accesso necessita comunque di confini chiari.

Un agente che prepara un aggiornamento settimanale può aver bisogno di record selezionati del progetto. Non dovrebbe ereditare un accesso illimitato a ogni nota privata soltanto perché tutte le informazioni appartengono a un solo utente. Identità e ambito dell’attività aiutano a separare il contesto utile dall’esposizione non necessaria.

Le affermazioni di Hush richiedono quindi una convalida indipendente in ambienti di produzione. Gli acquirenti dovrebbero chiedersi se il suo sistema identifichi crittograficamente le istanze degli agenti, si integri con i provider d’identità esistenti e propaghi l’identità agli strumenti downstream.

Dovrebbero inoltre testare la velocità di revoca, il comportamento in caso di errore delle policy, il tracciamento delle deleghe e la completezza dei log. Un piano di controllo che perde contesto durante una chiamata a uno strumento o che, durante un’interruzione, adotta per impostazione predefinita un accesso ampio può ricreare il rischio che promette di ridurre.

Il finanziamento e l’annuncio del prodotto dell’azienda stabiliscono l’intento di mercato, non risultati di sicurezza misurati. Le prove pubbliche non mostrano ancora come la piattaforma si comporti in ogni ambiente desktop, cloud e con agenti gestiti.

Questa incertezza non invalida un’architettura incentrata sull’identità. Definisce lo standard in base al quale i prodotti dovrebbero essere valutati. La domanda utile non è se una dashboard elenchi un agente. È se l’identità limiti, attribuisca e termini con coerenza l’autorità di quell’agente.

Cosa dovrebbero osservare i lettori di Google News

Tre segnali mostreranno se l’identità degli agenti diventerà una vera infrastruttura o rimarrà una categoria di marketing per la sicurezza.

Il primo segnale è l’adozione di identità distinte in produzione. I team di sicurezza dovrebbero guardare oltre il numero di agenti individuati o registrati. La misura significativa è quanti agenti attivi hanno smesso di usare credenziali condivise o token umani senza restrizioni.

Le prove del cambiamento includerebbero credenziali di breve durata, accesso limitato al singolo task, scadenza automatica e servizi downstream che conservano l’identificatore dell’agente. Se le chiavi condivise restano diffuse, la sola adozione di un gateway non colmerà il divario di accountability.

Questo segnale rafforzerà l’argomentazione identity-first quando le imprese segnaleranno un minor numero di account di servizio condivisi e più sessioni di agenti revocabili. La indebolirà se i prodotti di identity resteranno limitati a dashboard di inventario mentre l’accesso in fase di esecuzione rimarrà invariato.

Il secondo segnale è il supporto alle catene di delega. Gli agenti enterprise creeranno sempre più spesso sottoattività, chiameranno agenti specializzati e attraverseranno confini organizzativi. I prodotti dovranno preservare l’autorità durante questi passaggi.

Un’implementazione credibile dovrebbe mostrare lo sponsor umano originario, ogni agente partecipante, i permessi trasferiti e le azioni risultanti. Ogni identità figlia non dovrebbe ricevere più autorità di quanta il suo genitore possa delegare.

Osservate organismi di standardizzazione e fornitori per individuare modalità interoperabili di esprimere queste relazioni. Registri di delega proprietari possono funzionare all’interno di una singola piattaforma, ma le imprese usano agenti di più provider. La verifica cross-platform determinerà se l’identità rimane intatta al di fuori dell’ambiente di un fornitore.

Questo segnale rafforza la tesi se gli strumenti MCP, le piattaforme agentiche e gli identity provider possono scambiarsi prove verificabili della delega. La indebolisce se ogni piattaforma riconverte gli agenti in normali token utente al confine.

Il terzo segnale è il contenimento degli incidenti. L’identità conta soprattutto quando un agente si comporta in modo errato o viene compromesso. I fornitori devono dimostrare che i difensori possono isolare un singolo agente senza disabilitare un dipendente, un’applicazione o un intero workflow.

Test utili includono la revoca immediata, il rifiuto delle sessioni esistenti, il blocco degli agenti figli e la ricostruzione della catena di azioni. Le organizzazioni dovrebbero inoltre verificare che l’applicazione delle policy fallisca in modo sicuro quando l’infrastruttura di identità diventa indisponibile.

I team di sicurezza dovrebbero confrontare i log dei sistemi di identità, dei gateway, degli endpoint e delle applicazioni downstream. Se questi record non possono essere correlati, l’impresa non dispone ancora di una ricostruzione affidabile dell’incidente.

Il successo rafforzerebbe la posizione di Hush dimostrando che l’identità degli agenti cambia gli esiti, non soltanto la visibilità. Incidenti ripetuti che coinvolgono agenti autenticati ma non contenuti mostrerebbero che il mercato ha sopravvalutato l’identità come difesa autonoma.

L’impostazione di Google News coglie perlopiù l’ordine corretto. Le imprese dovrebbero stabilire chi è un agente, quale autorità detiene e per quanto tempo tale autorità rimane valida prima di considerare un gateway una forma di governance sufficiente.

Il passo successivo è pratico: sottoporre ad audit un agente di produzione, dalla sua creazione fino alla chiamata finale a uno strumento. Il vostro team è in grado di identificare proprietario, attività, credenziali, permessi, subagenti, accesso ai dati e percorso di revoca? Se una risposta dipende da un token condiviso o da un’inferenza basata sul traffico, il gateway è arrivato prima che le fondamenta dell’identità fossero pronte.