Nel 2026, l’adozione degli agenti AI in ambito enterprise sta prendendo la forma di un “Far West” tecnologico, con automazioni sempre più autonome, diffuse ovunque, abilitate in pochi minuti e, soprattutto, lasciate spesso crescere senza un vero controllo. Il punto non è se gli agenti funzionino o quanto siano utili, ma l’infrastruttura invisibile che li rende operativi, ovvero account, token, credenziali e permessi con cui questi sistemi entrano nelle applicazioni aziendali e nei dati.

Le organizzazioni gestiscono identità umane da decenni. IAM e PAM sono diventati standard proprio perché, nel tempo, è stato chiaro che un accesso non governato equivale a un rischio strutturale. Least privilege, segmentazione, policy zero trust e auditing sono nati per evitare che un dipendente o un account privilegiato potessero leggere o modificare ciò che non serve al loro lavoro, riducendo la superficie d’attacco e contenendo l’impatto di credenziali rubate.

Gli agenti AI stanno entrando nello stesso ecosistema senza una disciplina altrettanto matura. In molte aziende vengono creati, collegati e autorizzati con una leggerezza che sarebbe impensabile per un utente umano. Il risultato è una situazione paradossale, per la quale ambienti di produzione che non concederebbero mai privilegi eccessivi a un nuovo assunto finiscono per consegnare a un agente software accessi estremamente ampi, spesso senza nemmeno sapere con precisione quali.

Il motivo è in parte “intrinseco” al valore degli agenti. Un agente AI infatti diventa utile quando può agire dove i dati già esistono, ovvero all’interno di email, cloud storage, CRM, repository di codice, strumenti di ticketing e knowledge base. In altre parole, deve vivere dentro l’infrastruttura SaaS e ciò significa appoggiarsi ai meccanismi di autenticazione già disponibili, come token OAuth per Gmail o OneDrive, access token per GitHub e chiavi API per servizi interni. È una scelta che riduce l’attrito, accelera l’integrazione e rende più semplice portare rapidamente in produzione un prototipo.

Il rovescio della medaglia è che gli agenti AI ereditano tutto ciò che nell’identità enterprise è già fragile, ovvero permessi assegnati in modo “generoso”, ruoli poco segmentati, token che vivono troppo a lungo e mancanza di visibilità sulle deleghe. Se poi la creazione di agenti diventa accessibile a chiunque grazie a framework, orchestratori e strumenti di coding assistito, la diffusione assume un carattere quasi consumer, con la conseguenza che un dipendente può creare un agente per semplificarsi la vita con la stessa mentalità con cui installerebbe un’estensione del browser.

TA584

Crediti: Shutterstock

Dal punto di vista della sicurezza, tutto ciò cambia la natura del rischio. Non è più solo un attaccante esterno a cercare di entrare, ma è l’organizzazione stessa che moltiplica identità operative senza un inventario affidabile. E quando un’azienda non sa quanti agenti abbiano accesso ai propri sistemi, parlare di governance diventa un esercizio solo teorico.

In questo modo, gli agenti AI, se dotati di accessi ampi, possono diventare “superuser” di fatto. Non perché siano stati creati per essere amministratori, ma perché possono concatenare accessi e risorse. Un agente che legge documenti su OneDrive, apre ticket su Jira, interagisce con Slack e scrive su GitHub può trasformarsi in un ponte tra domini che normalmente verrebbero tenuti separati.

Purtroppo il rischio non è solo ipotetico. Esercizi di red teaming hanno già mostrato come agenti interni possano essere manipolati tramite prompt injection fino a eseguire azioni malevole, come distribuire malware su endpoint aziendali. Questo anche perché gli agenti AI sono progettati per completare un compito, ridurre l’attrito e trovare il modo giusto per eseguire un compito.

Questa predisposizione li rende vulnerabili alle stesse tecniche di inganno che funzionano sugli esseri umani, con però la grande differenza che l’agente opera più velocemente, può ripetere tentativi, può agire in modo continuo e può farlo senza quella percezione istintiva del pericolo che un dipendente spesso sviluppa con l’esperienza.

La complessità cresce perché gli agenti non si comportano come le identità macchina tradizionali. Mentre un service account o uno script eseguono procedure deterministiche, un agente è dinamico e contestuale e può affrontare lo stesso task con approcci diversi, creare nuovi percorsi di accesso e interagire con risorse critiche come server MCP, API, database, servizi interni, altri LLM e sistemi di orchestrazione. Questa imprevedibilità rompe le assunzioni su cui sono stati costruiti molti strumenti IAM e PAM, basati sulla distinzione netta tra identità umane e identità macchina.

Crediti: Shutterstock

Crediti: Shutterstock

Il problema, quindi, non è soltanto “quanti” agenti esistono, ma “che tipo” di identità rappresentano. Per questo diversi esperti sostengono che inserirli semplicemente nella categoria delle machine identities sia fuorviante. Un agente non è umano, ma nemmeno un account tecnico statico. È un’entità che agisce in autonomia e, in termini operativi, può somigliare più a un dipendente sempre attivo che a un processo schedulato.

In parallelo, sta esplodendo la cosiddetta shadow AI, evoluzione diretta dello shadow IT. Un fenomeno per il quale i dipendenti usano account personali per strumenti di produttività come ChatGPT, Cursor o Claude Code, oppure creano agenti sperimentali collegandoli a fonti dati aziendali senza supervisione. Questi agenti “ombra” sono spesso workflow di prova che nessun team IT o security monitora, ma che possono essere connessi a più data source, accumulare token e creare un blast radius enorme. In alcuni casi, il punto debole ricorrente diventa l’ecosistema dei token, visto che se un agente viene compromesso, ciò che l’attaccante ottiene è un portafoglio di credenziali riutilizzabili.

In questo scenario, la prima contromisura sensata non è bloccare gli agenti, perché sarebbe irrealistico, ma serve visibilità, ovvero discovery e inventory. Le scansioni in ambienti reali producono spesso risultati sorprendenti (in negativo) quando l’azienda scopre migliaia di identità già presenti, molte sconosciute. E i numeri possono crescere rapidamente, con reparti come R&D e ingegneria che adottano agenti con una velocità superiore al resto dell’organizzazione.

Una volta ottenuta la mappa degli agenti, la gestione deve passare da un approccio “a policy generiche” a un profiling continuo basato su configurazione, connettività, permessi, storico delle attività, log e pattern d’uso. Solo così diventa possibile introdurre guardrail di postura, cioè vincoli capaci di impedire all’agente di accedere a risorse sensibili o di eseguire azioni fuori contesto.

C’è infine un aspetto culturale visto che gli agenti non nascono dal nulla. Ogni agente ha un creatore, qualcuno che gli ha delegato accessi e che ha approvato un’integrazione. Legare in modo esplicito l’identità agentica alla responsabilità umana è il vero “ground zero” della sicurezza, perché permette di capire quali ruoli erano coinvolti e quale impatto potrebbe avere quell’agente se finisse in mani sbagliate.

(Immagine in apertura: Shutterstock)