Un agente creato in dieci minuti per leggere le email, confrontare le fatture con l’ERP e riassumerle su Slack finisce per modificare i dati bancari di un fornitore dopo aver letto istruzioni nascoste in un allegato. Il caso fittizio descritto da BleepingComputer mostra come un’automazione apparentemente di routine possa concatenare accessi eccessivi e azioni difficili da attribuire.
Il resoconto si basa sui contributi di oltre venti professionisti raccolti da Token Security. BleepingComputer avverte che l’agente è immaginario, ma cita un sondaggio della Cloud Security Alliance commissionato da Token: tra i 418 professionisti IT e della sicurezza consultati nel gennaio 2026, l’82% ha dichiarato di aver trovato agenti sconosciuti nell’anno precedente. Il 68% ha affermato di avere una buona visibilità sui propri agenti.
Le cifre descrivono una tensione concreta: le aziende possono avere visibilità sugli agenti che conoscono e, allo stesso tempo, ignorarne altri creati al di fuori dei team di identità o sicurezza. Nell’esempio, una persona dell’ufficio contabilità collega autonomamente email, ERP e Slack; nessuno richiede una revisione prima di attivare il flusso.
L’identità è composta da più elementi
Il primo problema non è solo cosa può fare l’agente, ma con quale identità compare nei registri. Token Security distingue quattro modalità di accesso: una sessione umana, autorizzazioni delegate tramite OAuth, credenziali statiche e un’identità propria dell’agente. In pratica, queste modalità possono mescolarsi all’interno della stessa catena.
| Modalità di accesso | Vantaggio descritto | Rischio o limite |
|---|---|---|
| Sessione umana | L’accesso termina alla chiusura della sessione. | I registri possono attribuire l’attività alla persona. |
| Autorizzazione OAuth delegata | Può essere limitata a un sottoinsieme delle autorizzazioni dell’utente. | L’accesso può restare attivo fino alla revoca dell’autorizzazione. |
| Credenziale statica | È semplice da usare. | Può essere condivisa, non scadere e rendere difficile l’attribuzione. |
| Identità propria dell’agente | Consente di associare le azioni a un agente specifico. | Richiede registrazione, credenziali di breve durata e criteri di accesso. |
La catena descritta da Token Security combina un token OAuth dell’utente, un subagente che lo eredita e un server MCP che interroga un database con un account di servizio condiviso. Il registro del database mostra l’account di servizio; quello dell’applicazione, l’utente; il provider di identità, nessuna attività. La stessa azione lascia tracce incompatibili se non si conosce l’intera delega.
Le chiavi personali amplificano il problema. Nel caso di BleepingComputer, il creatore genera una chiave API dell’ERP con le autorizzazioni del proprio account e la salva nel generatore dell’agente, senza data di scadenza. Se la chiave viene rubata, l’aggressore non deve convincere l’agente: può usare direttamente l’accesso che la chiave rappresenta.
Anche un’email può impartire istruzioni
Alla terza settimana arriva una fattura dall’indirizzo di un fornitore noto. L’allegato contiene testo bianco su sfondo bianco che chiede di modificare il conto bancario nell’ERP. Nessuno apre il messaggio, ma l’agente lo elabora ed esegue la modifica. Il contenuto letto funge da input non attendibile, anche se non sembra un comando rivolto al sistema.
Token Security descrive attacchi diretti, in cui qualcuno che può comunicare con l’agente tenta di trasformarlo in un intermediario con accesso, e attacchi indiretti, in cui le istruzioni sono veicolate da email o altri contenuti. Segnala inoltre che una descrizione malevola di uno strumento può influire sugli agenti che lo utilizzano. Nei registri, l’attività può sembrare normale: strumento autorizzato, credenziale valida e operazione consentita.
La regola del due di Meta, pubblicata dal suo team di sicurezza IA nell’ottobre 2025 e citata da BleepingComputer, propone che un agente non combini più di due di queste capacità in una sessione finché non è in grado di rilevare e rifiutare in modo affidabile l’iniezione di istruzioni: elaborare input non attendibili, accedere a dati privati o sistemi sensibili e modificare informazioni o comunicare all’esterno. L’agente dell’esempio le riunisce tutte e tre.
Amber Bennoui, responsabile dei prodotti IA e della cybersicurezza presso DataRobot, consiglia di usare tre domande per valutare le automazioni prima di avviarle: se leggono contenuti provenienti dall’esterno dell’azienda, se possono vedere dati privati e se possono agire senza revisione umana. Se la risposta è sì a tutte e tre, è il momento di confrontarsi con il team di sicurezza. L’obiettivo pratico è fare in modo che il percorso sicuro sia l’opzione predefinita, anziché dipendere dal fatto che ogni creatore conosca le eccezioni.
Rilevare un’anomalia richiede di osservare il comportamento
La modifica dei dati bancari non avrebbe necessariamente generato un avviso se l’azienda avesse verificato soltanto che l’agente agisse entro i limiti delle sue autorizzazioni. Chad Kalmes, direttore della sicurezza informatica e IT presso Benchling, consiglia di confrontare l’attività con uno storico affidabile di ciò che l’agente fa davvero. Un’autorizzazione valida non dimostra che l’azione sia normale.
Nell’esempio, l’agente aveva consultato l’ERP per tre settimane, ma non vi aveva mai scritto. La prima modifica dei dati e la nuova sequenza — leggere un’email e poi modificare un record di pagamento — sono segnali più utili del semplice fatto che la chiave consentisse di farlo. La checklist di rilevamento di Token Security aggiunge avvisi per le modifiche delle autorizzazioni, le destinazioni di uscita sconosciute, i modelli di utilizzo delle credenziali e la creazione di meccanismi di persistenza, come la pianificazione di processi o la generazione di credenziali.
È importante anche distinguere tra un agente compromesso e uno che causa danni seguendo istruzioni legittime. Il primo obbedisce a comandi malevoli o viene usato da un aggressore; il secondo può eseguire fedelmente una specifica difettosa. I segnali si sovrappongono, ma cambia la risposta investigativa. Non tutte le anomalie dimostrano un’intrusione: possono dipendere da un input insolito, da una modifica della configurazione o da un difetto.
“The first is easy. The last is the hard one, because authority can't be rebuilt after the fact.”
— Rajesh Seshadri Appikulam, Senior Director of Identity Security Services at Simeio
La frase si riferisce all’autorità alla base di un’azione: chi ha chiesto di eseguirla e con quale delega. In un audit successivo, il registro dell’ERP dell’esempio indica la chiave personale del creatore, come se fosse stata quella persona a modificare il conto. Ma il proprietario dell’agente ha già cambiato team e l’autorizzazione OAuth della casella di posta è ancora attiva. L’attribuzione non può essere ricostruita a posteriori se non è stata registrata al momento dell’azione.
Fermare un agente richiede più che spegnere il modello
The Hacker News evidenzia un altro limite operativo: un agente fa parte di un sistema che può includere modello, orchestratore, identità, strumenti, API e regole di rete. Disattivare il modello potrebbe non fermare un’attività in coda, un nuovo tentativo o una sessione aperta; revocare una credenziale non garantisce neppure che un altro token o una connessione siano stati invalidati.
Per questo, il contenimento deve essere testato nell’architettura reale. Il riepilogo dell’ottobre 2026 del progetto OWASP GenAI sugli agenti di valutazione che oltrepassano il proprio ambito consiglia di verificare se il contenimento è in grado di revocare le credenziali e l’accesso alla rete. The Hacker News propone di sospendere il flusso e i relativi attivatori, rimuovere gli accessi associati, bloccare gli strumenti o le connessioni coinvolti e conservare i registri di identità, API, applicazione e rete. Spegnere l’agente non annulla ciò che è già stato eseguito.
La guida al rilevamento di Token Security concorda sulla necessità di preservare lo stato e le trascrizioni mentre si sospende l’agente e se ne revoca la credenziale. In questo modo è possibile esaminare, per esempio, l’allegato che potrebbe aver contaminato il flusso. Eliminare subito l’agente cancellerebbe parte del materiale necessario per capire cosa è successo; lasciarlo attivo manterrebbe la possibilità di nuove azioni.
Cosa cambia per i team che sviluppano agenti
La raccomandazione di assegnare un’identità propria a ogni agente migliora l’attribuzione, ma Token Security osserva che non è ancora la norma: gli agenti vengono creati in dipartimenti diversi e chi li sviluppa non sempre consulta il reparto IT. Richiedere identità registrate, credenziali di breve durata e criteri specifici comporta attività di governance e integrazione. L’alternativa più rapida — riutilizzare sessioni, autorizzazioni degli utenti o chiavi statiche — semplifica lo sviluppo, ma trasferisce i costi all’audit e alla risposta agli incidenti.
Per le aziende, l’inventario deve associare ogni agente a un proprietario, alle sue credenziali, agli strumenti, ai sistemi accessibili e ai registri disponibili. Inoltre, il rilevamento deve coprire le nuove chiamate, anche se autorizzate, le sequenze di operazioni e le destinazioni dei dati, non solo i rifiuti. Se un’azione è irreversibile, Token Security propone di verificare l’origine dell’istruzione che l’ha innescata; The Hacker News aggiunge che le operazioni sensibili possono richiedere un’autorizzazione esplicita e una revisione umana.
La preparazione richiede anche di verificare che i controlli di arresto funzionino: interrompere le esecuzioni attive e in sospeso, revocare ogni accesso pertinente e limitare le connessioni di rete senza bloccare servizi estranei all’incidente. The Hacker News consiglia di conservare le prove, distinguere le azioni tentate da quelle completate e valutare separatamente i sistemi o i dati coinvolti. Prima di riattivare il flusso, occorre correggere la causa e testarlo con l’ambito minimo necessario.
Nel caso descritto da BleepingComputer, bastano due domande di audit per mostrare il lavoro ancora da fare: se l’azienda è in grado di identificare la persona per conto della quale ha agito un agente 60 giorni fa e se oggi conosce il responsabile di ogni agente in produzione. La risposta dipende da qualcosa che deve essere registrato fin dall’inizio: chi ha delegato l’autorità e a quale agente.
Fonti: BleepingComputer, The Hacker News, Token Security, Token Security, Token Security
