Per anni la sicurezza informatica si è retta su un principio piuttosto lineare. Chi controlla le identità digitali controlla il rischio. I dipendenti si autenticano tramite provider, gli account di servizio collegano i sistemi, le chiavi API permettono ai carichi di lavoro di dialogare con cloud e database. Tutto sommato prevedibile. Poi sono arrivati gli agenti AI e questo equilibrio ha iniziato a scricchiolare, perché la maggior parte delle aziende continua a trattarli come semplici strumenti quando in realtà sono diventati qualcosa di molto più delicato.
All’inizio nessuno ci aveva fatto troppo caso. Gli agenti AI entravano in punta di piedi, riassumevano riunioni, scrivevano bozze di email, aiutavano a trovare informazioni. Sembravano strumenti di produttività e in fondo lo erano davvero. Il problema è nato quando le organizzazioni hanno cominciato a collegarli a servizi aziendali critici come Salesforce, Snowflake, GitHub, Jira, database di produzione e ambienti cloud. Da lì in poi questi agenti hanno iniziato a recuperare dati, avviare flussi di lavoro, aggiornare record, scrivere e distribuire codice. A volte per conto di una persona, a volte in autonomia, e non sempre è chiaro quale delle due cose stia accadendo.
Quando un agente diventa un’identità a tutti gli effetti
Ed è proprio qui che cambia tutto. Un agente che fa azioni del genere non è più uno strumento, è un’identità vera e propria. Solo che quasi nessuna azienda ha modelli di sicurezza e governance pensati per gestirla. Lo schema si ripete ovunque. Sopra l’infrastruttura esistente nasce un nuovo livello di identità privo di quasi tutti i controlli che i team hanno costruito negli ultimi dieci anni. Un agente magari viene creato da un reparto, usato da un altro, collegato a cinque applicazioni diverse e fatto girare con credenziali nate per tutt’altro scopo.
Spesso ottiene accessi ampi fin da subito, perché qualcuno aveva bisogno che funzionasse in fretta. Il risultato è una proliferazione di attori ad alti privilegi e bassa visibilità che molti team non riescono nemmeno a inventariare. Un dato lo fotografa bene. Secondo un’indagine CSA del 2026 commissionata da Token Security, l’82 per cento delle organizzazioni ha scoperto almeno un agente AI creato all’insaputa dei team di sicurezza, IT o governance nell’ultimo anno, e il 41 per cento ha riscontrato la cosa più volte.
C’è poi un equivoco di fondo nel dibattito sulla sicurezza AI. Quasi tutta l’attenzione si concentra sul rischio legato ai modelli, come prompt injection, jailbreak e output pericolosi. Sono temi importanti, per carità, ma non raccontano l’intera storia. La domanda che conta davvero è un’altra. A cosa può accedere concretamente l’agente? Uno che riassume documentazione pubblica ha un raggio d’azione limitato. Uno collegato a dati dei clienti, codice sorgente, sistemi finanziari e credenziali cloud con privilegi da amministratore è tutto un altro discorso.
Visibilità e intenzione, le due chiavi del controllo
Un prompt sbagliato, una sessione compromessa, un plugin malevolo o un’integrazione mal configurata possono trasformare un agente sovraprivilegiato in una via per l’esfiltrazione di dati o per il movimento laterale tra sistemi che non avrebbero mai dovuto comunicare. Non è più teoria. Il 65 per cento delle organizzazioni ha vissuto un incidente di sicurezza legato a un agente AI nell’ultimo anno, e il 61 per cento ha segnalato l’esposizione o la cattiva gestione di dati sensibili.
Tutto parte dalla visibilità. Serve una vera mappatura degli agenti che vada oltre il nome e la piattaforma. Chi possiede questo agente? Chi può invocarlo? A quali sistemi è collegato? Quali credenziali usa? Cosa può leggere, scrivere, cancellare o eseguire in ogni applicazione? Non è banale, perché la superficie non è quasi mai evidente. Un team potrebbe sapere che esiste un assistente alle vendite senza sapere che gira su un account Snowflake con privilegi di amministratore.
Poi c’è la questione dell’intenzione. La governance non può fondarsi solo sui permessi, deve tenere conto di cosa l’agente dovrebbe fare. Un agente per la preparazione delle vendite ha bisogno solo di leggere i record del CRM, non di cancellare tabelle del database. Uno per i flussi finanziari dovrebbe limitarsi a leggere le fatture, non creare nuovi utenti privilegiati. Capendo lo scopo si può verificare se i permessi corrispondono, e nella pratica quasi mai succede. Quel divario è dove vive il rischio reale, e si allarga col tempo per via della deriva delle policy di privilegio minimo.
Una volta chiarita l’intenzione l’applicazione delle regole diventa possibile. I permessi si possono ridurre, gli account sovraprivilegiati correggere, le credenziali inutilizzate ruotare o eliminare. Il punto che inganna molti è che non si tratta di un lavoro una tantum. Una revisione degli accessi dà una falsa sensazione di sicurezza, perché gli agenti cambiano, le istruzioni si aggiornano, le integrazioni si espandono. Per questo la governance deve essere continua, capace di intercettare agenti che iniziano a usare credenziali inattese o a compiere azioni fuori dal loro scopo dichiarato. Le aziende che avranno successo con l’AI non saranno quelle che bloccano gli agenti, ma quelle che li rendono governabili trattandoli come identità a pieno titolo, con proprietari, accessi, comportamenti e controlli sul ciclo di vita. Gli agenti AI stanno diventando insider privilegiati, e i programmi di sicurezza devono recuperare terreno prima che quegli insider si trasformino in percorsi d’attacco invisibili.