La Minaccia Nascosta degli Agenti di Intelligenza Artificiale Richiede un Nuovo Modello di Sicurezza

I sistemi di intelligenza artificiale agente sono diventati mainstream nell’ultimo anno. Ora sono utilizzati per diverse funzioni, tra cui l’autenticazione degli utenti, il trasferimento di capitali, l’avvio di flussi di lavoro di conformità e la coordinazione in ambienti aziendali con un minimo di supervisione umana.

Tuttavia, un problema più silenzioso sta emergendo con l’aumento dell’autonomia, non a livello di prompt o politiche, ma a livello di fiducia dell’infrastruttura. I sistemi agente stanno ricevendo l’autorità di insider mentre continuano a girare in ambienti di calcolo che non sono stati progettati per proteggere i decisori autonomi dall’infrastruttura sottostante.

La sicurezza tradizionale presume che il software sia passivo, ma i sistemi agente non lo sono. Ragionano, ricordano e agiscono continuamente, autonomamente e con autorità delegata.

Non dimentichiamo che gli agenti di intelligenza artificiale sono probabilmente in grado di accedere a dati personali, in base al loro caso d’uso, come ad esempio e-mail e registri di chiamate, tra le altre cose.

Inoltre, mentre esistono protezioni basate su hardware, come macchine virtuali confidentiali e enclavi sicure, non sono ancora la base di default per la maggior parte dei deploy di intelligenza artificiale agente. Di conseguenza, molti agenti continuano a eseguirsi in ambienti in cui i dati sensibili sono esposti all’infrastruttura sottostante durante l’esecuzione.

Gli Agenti Sono Insider, Non Strumenti

I team di sicurezza già sanno quanto sia difficile contenere le minacce interne, un problema evidenziato nel rapporto di data breach di Verizon del 2025, che mostra che l’intrusione del sistema è stata responsabile di più del 53% delle violazioni confermate l’anno scorso. Nel 22% di questi casi, gli attaccanti hanno utilizzato credenziali rubate per ottenere l’accesso, il che evidenzia quanto spesso riescono utilizzando identità legittime invece di sfruttare vulnerabilità tecniche.

Ora, considerate un agente, che è composto da logica di prompt, strumenti e plugin, credenziali, nonché politiche. Non solo può eseguire codice e navigare nel web, ma può anche interrogare CRM, leggere e-mail e inviare biglietti, tra le altre cose. Ciò che la combinazione di funzioni ha portato è stato portare le superfici di attacco tradizionali in un’interfaccia moderna.

Il pericolo rappresentato da tali minacce interne non è speculativo. Il progetto Open Web Application Security (OWASP) elenca ora la “Prompt Injection” come una vulnerabilità critica per le applicazioni LLM, notando il suo particolare pericolo per i sistemi agente che concatenano azioni. Il team di intelligence sulle minacce di Microsoft ha anche pubblicato avvisi che avvertono che i sistemi di intelligenza artificiale con accesso agli strumenti possono essere distorti per eseguire il furto di dati se le salvaguardie non sono architettonicamente applicate.

Questi rapporti offrono un promemoria tempestivo che gli agenti che hanno accesso legittimo ai sistemi e ai dati possono essere rivolti contro i loro proprietari. Tuttavia, il panorama del rischio per i sistemi agente non è unitario. Le minacce a livello di applicazione come l’iniezione di prompt e l’abuso di strumenti derivano dall’incapacità del modello di distinguere tra istruzioni attendibili e input di utente non attendibili, una limitazione di progettazione che nessun tipo di hardening della memoria può risolvere.

Un problema diverso e altrettanto importante esiste a livello di infrastruttura: alcuni agenti eseguono in memoria in chiaro, il che significa che le informazioni sensibili – come storie di chat, risposte API e documenti – possono essere viste mentre vengono elaborate e possono rimanere accessibili in seguito. OWASP identifica questo rischio come Sensitive Information Disclosure (LLM02) e System Prompt Leakage (LLM07) e suggerisce l’uso di isolamento del contesto, segmentazione dei namespace e sandboxing della memoria come importanti misure di sicurezza.

Pertanto, gli utenti non dovrebbero trattare questi agenti come mere applicazioni, dato che sono esecutori dinamici e ragionatori che richiedono un modello di sicurezza che tenga conto della loro natura unica come entità non umane con agenzia. Questo approccio deve includere sia controlli software per limitare come agisce il modello che protezioni hardware per mantenere i dati al sicuro mentre vengono utilizzati.

L’Architettura della Fiducia Ha un Difetto Critico

Le pratiche di sicurezza attuali si concentrano sulla protezione dei dati in stato di riposo e in transito. L’ultima frontiera, i dati in uso, rimane quasi interamente esposta. Quando un agente di intelligenza artificiale ragiona su un set di dati confidenziali per approvare un prestito, analizzare registri di pazienti o eseguire un’operazione, quei dati sono di solito decrittati e elaborati in testo normale all’interno della memoria del server.

Nei modelli cloud standard, chiunque abbia un controllo sufficiente sull’infrastruttura, compresi amministratori di hypervisor o attaccanti co-tenant, può potenzialmente guardare cosa sta succedendo mentre un carico di lavoro è in esecuzione. Per gli agenti di intelligenza artificiale, tale esposizione è particolarmente pericolosa, poiché hanno bisogno di accedere a informazioni sensibili per svolgere il loro lavoro, che può potenzialmente diventare la superficie di attacco.

Come ha dimostrato Lumia Security, gli attaccanti con accesso a una macchina locale possono ottenere JWT e chiavi di sessione direttamente dalla memoria del processo delle applicazioni desktop di ChatGPT, Claude e Copilot. Queste credenziali rubate possono consentire loro di fingersi un altro utente, rubare la cronologia delle conversazioni e iniettare prompt nelle sessioni in corso che possono cambiare il comportamento dell’agente o piantare falsi ricordi.

Un esempio di ciò potrebbe essere l’incidente di dump di memoria di AWS CodeBuild nel luglio 2025. Gli attaccanti hanno aggiunto segretamente codice maligno a un progetto e, quando il sistema lo ha eseguito, il codice ha guardato nella memoria del computer e ha rubato token di accesso nascosti lì. Con quei token, gli attaccanti potevano cambiare il codice del progetto e potenzialmente accedere ad altri sistemi.

Per le istituzioni finanziarie, la manipolazione silenziosa è esistenziale. Le banche, le assicurazioni e le società di investimento già assorbono costi di violazione dei dati di oltre 10 milioni di dollari in media e capiscono che l’integrità è importante quanto la riservatezza. Secondo un recente rapporto di Informatica, il “paradosso della fiducia” è stato spiegato come segue: le organizzazioni stanno distribuendo agenti autonomi più velocemente di quanto possano verificare i loro output. Il risultato è un’automazione che può incorporare errori o pregiudizi direttamente nei processi di base, operando a velocità di macchina.

Calcolo Confidenziale e il Caso per l’Isolamento

Le soluzioni incrementali non risolveranno il problema in questione, sebbene controlli di accesso più rigidi e una migliore sorveglianza possano aiutare. Tuttavia, né l’uno né l’altro possono cambiare il problema sottostante. La questione è architettonica e, finché il calcolo avviene in memoria esposta, gli agenti saranno vulnerabili nel momento in cui più contano, ovvero durante il ragionamento.

Il calcolo confidenziale, definito dal Consortium del Calcolo Confidenziale (CCC) come la protezione dei dati in uso tramite ambienti di esecuzione attendibili basati su hardware (TEEs), affronta direttamente il difetto di base.

Per gli agenti di intelligenza artificiale, questo isolamento a livello di hardware è trasformativo, poiché consente all’agente di mantenere le credenziali di identità, i pesi del modello, le prompt proprietarie e i dati sensibili degli utenti che elabora rimanere crittografati non solo su disco o in rete, ma attivamente in memoria durante l’esecuzione. La separazione spezza definitivamente il modello tradizionale in cui il controllo sull’infrastruttura garantisce il controllo sul carico di lavoro.

L’attestazione remota fornisce prove criptografiche verificabili che una specifica richiesta di inferenza è stata eseguita all’interno di un ambiente di esecuzione attendibile supportato da hardware, che sia un CPU o un GPU. La prova è generata da misurazioni hardware e consegnata insieme alla risposta, consentendo una verifica indipendente di dove e come è stato eseguito il carico di lavoro.

I record di attestazione non rivelano il codice eseguito. Invece, ogni carico di lavoro è associato a un ID di carico di lavoro univoco o a un ID di transazione e il record di attestazione del TEE è collegato a quell’identificatore. L’attestazione conferma che il calcolo è stato eseguito all’interno di un ambiente attendibile senza rivelarne il contenuto.

La configurazione crea una nuova base per la conformità e la controllabilità, consentendo di collegare le azioni di un agente a una versione specifica di codice che è stata attestata e a un set noto di dati di input.

Verso un’Autonomia Responsabile

Le implicazioni per il sistema descritto sopra vanno al di là della sicurezza di base. Considerate le leggi che regolano la finanza, la sanità e le informazioni personali. Molti paesi applicano regole di sovranità dei dati che limitano dove le informazioni possono essere elaborate. In Cina, la Legge sulla Protezione delle Informazioni Personalmente Identificabili e la Legge sulla Sicurezza dei Dati richiedono che determinate categorie di dati, come ad esempio i dati personali importanti, siano archiviati a livello nazionale e verificati prima del trasferimento all’estero.

Allo stesso modo, diversi paesi del Golfo, come gli Emirati Arabi Uniti e l’Arabia Saudita, hanno adottato approcci simili, specialmente per i dati finanziari, governativi e di infrastrutture critiche.

Il calcolo confidenziale può rafforzare la sicurezza e la controllabilità proteggendo i dati mentre vengono utilizzati ed abilitando l’attestazione dell’ambiente di runtime. Tuttavia, non cambia dove si verifica l’elaborazione. Dove le regole di sovranità dei dati richiedono l’elaborazione locale o impongono condizioni sui trasferimenti transfrontalieri, gli ambienti di esecuzione attendibili possono supportare i controlli di conformità, non sostituire i requisiti legali.

Inoltre, il calcolo confidenziale consente una collaborazione sicura in sistemi multi-agente, dove gli agenti di diverse organizzazioni o all’interno di diversi dipartimenti spesso devono condividere informazioni o validare output senza esporre dati proprietari.

E quando la tecnologia viene abbinata a un’architettura zero-trust, il risultato è una base molto più solida. La zero-trust valida continuamente l’identità e l’accesso, mentre il calcolo confidenziale protegge la memoria dell’hardware da estrazioni non autorizzate e impedisce che le informazioni sensibili vengano recuperate in testo normale.

Insieme, difendono ciò che conta realmente, ad esempio la logica decisionale, gli input sensibili e le chiavi crittografiche che autorizzano l’azione.

Nuovo Livello di Base per i Sistemi Autonomi

Se ogni interazione mette le persone a rischio di esposizione, non lasceranno che l’intelligenza artificiale gestisca cose come i registri sanitari o prenda decisioni finanziarie. Allo stesso modo, le aziende non automizzeranno i loro compiti più importanti se ciò potrebbe portare a problemi normativi o alla perdita di dati importanti.

I costruttori seri riconoscono che le soluzioni a livello di applicazione da sole sono insufficienti in ambienti ad alta garanzia.

Quando gli agenti sono autorizzati con autorità finanziaria, dati regolamentati o coordinamento interorganizzativo, l’esposizione a livello di infrastruttura diventa più di una preoccupazione teorica. E senza esecuzione confidenziale in tali contesti, molti agenti rimangono un bersaglio morbido, con le loro chiavi rubabili e la loro logica malleabile. La dimensione delle violazioni dei dati moderni mostra esattamente dove porta quella strada.

La privacy e l’integrità non sono caratteristiche opzionali da aggiungere dopo il deploy. Devono essere progettate fin dall’inizio, a partire dal silicio. Pertanto, perché l’intelligenza artificiale agente possa scalare in modo sicuro, l’esecuzione confidenziale supportata da hardware non può essere considerata solo un vantaggio competitivo, ma la base.