Un agente incaricato di preparare un rimborso dovrebbe poterlo anche disporre? Questa domanda molto concreta aiuta a comprendere le nuove sfide della sicurezza dell’IA. Quando un software non si limita più a proporre un testo, ma consulta documenti, richiama strumenti ed esegue codice, una decisione sbagliata può trasformarsi in un’operazione reale.
Il 27 ottobre 2026 Akamai ha annunciato un ambiente di esecuzione destinato agli agenti IA, insieme a un servizio di inferenza. Questa notizia invita a distinguere tre protezioni spesso riunite sotto la stessa parola: impedire a un programma di uscire dal proprio ambiente, limitare le risorse a cui può accedere e verificare le azioni che intraprende. Rispondono a domande diverse.
Che cosa annuncia Akamai e che cosa non dimostra
Nel suo comunicato del 27 ottobre, Akamai presenta Agent Sandbox, disponibile in versione beta tramite Spin SDK. La soluzione dovrebbe consentire di eseguire il codice prodotto da un agente in un ambiente isolato, separato da quello dell’agente stesso, su Akamai Functions.
L’azienda descrive un isolamento basato su WebAssembly e la possibilità di definire limiti di calcolo, memoria, connessioni in uscita e funzionalità di sistema. Annuncia inoltre future funzioni di governance delle comunicazioni degli agenti: questa parte fa riferimento a una roadmap, non a una protezione la cui implementazione sia già stata confermata.
Si tratta della descrizione del fornitore. Non abbiamo effettuato test indipendenti del servizio e questo lancio non permette di concludere che un agente qualsiasi sia ormai sicuro. L’aspetto interessante è il suo ambito: contenere l’esecuzione di un programma. La pertinenza dell’azione affidata a quel programma è un’altra questione.
Un rimborso fittizio per capire i confini
Prendiamo un esempio didattico e fittizio. Un’azienda affida a un agente la preparazione delle note spese. L’agente deve leggere una ricevuta, individuare il dipendente interessato, proporre una categoria contabile e presentare la pratica per la convalida. Qui non si descrivono incidenti reali né risultati di test.
La prima questione riguarderebbe l’esecuzione del codice: se l’agente scrivesse un piccolo programma per estrarre gli importi, quel programma dovrebbe operare in uno spazio delimitato. Non avrebbe alcun motivo di passare in rassegna tutti i file del server. La seconda questione riguarderebbe l’accesso ai dati: la ricevuta di un dipendente non giustificherebbe la consultazione delle pratiche di tutta l’azienda.
La terza riguarderebbe il pagamento. Un calcolo corretto non autorizzerebbe, da solo, a trasferire denaro. Anche se isolato correttamente, un programma potrebbe richiamare un servizio a cui sono stati concessi troppi diritti. L’esempio permette così di porsi una domanda semplice prima di scegliere un prodotto: quale errore preciso deve impedire ciascuna protezione?
Si può spingere oltre il ragionamento. Se la pratica contiene due fatture identiche, l’agente dovrebbe predisporre due rimborsi? Se manca un documento, dovrebbe inventare una giustificazione, chiedere un’integrazione o lasciare la pratica in sospeso? Anche queste scelte fanno parte del funzionamento del servizio. La sicurezza non sostituisce né le regole del mestiere né il controllo della qualità delle informazioni.
Il rischio di concedere troppe possibilità
OWASP dedica una scheda all’autonomia eccessiva dei sistemi basati su modelli linguistici. Distingue in particolare le funzioni non necessarie, i permessi troppo ampi e l’assenza di convalida delle operazioni importanti. Il problema può derivare tanto da una risposta errata quanto da un’istruzione malevola incontrata nei dati elaborati.
Le sue raccomandazioni comprendono la riduzione degli strumenti disponibili allo stretto necessario, permessi minimi e la verifica degli accessi da parte dei sistemi che eseguono effettivamente le richieste. Il modello non deve essere l’unico giudice di ciò che gli è consentito fare. Per le azioni ad alto impatto può essere necessaria un’approvazione umana.
L’organismo distingue inoltre tra prevenzione e limitazione dei danni: i registri delle attività e i limiti di frequenza aiutano a rilevare un problema o a ridurne la portata, senza eliminarne la causa. Questa distinzione è importante quando un fornitore presenta una funzione di monitoraggio come una risposta completa.
Identificare l’agente e potergli revocare i diritti
Lo stesso 27 ottobre, il NIST ha proposto dieci principi di progettazione per la gestione delle identità degli agenti. Questo documento di lavoro si basa su contributi pubblici e confronti con l’ecosistema. Non è una certificazione di prodotto né una nuova norma obbligatoria.
Gli autori raccomandano in particolare un’identità specifica per ogni agente, diritti limitati al suo compito e autorizzazioni temporanee revocabili. La delega ad altri agenti non dovrebbe ampliare i poteri concessi inizialmente. Chiedono inoltre di separare il ragionamento del modello dai meccanismi che decidono effettivamente gli accessi.
Il documento insiste su registri indipendenti che l’agente non possa modificare a proprio piacimento, oltre che su un monitoraggio continuo. Segnala infine che lo stato attuale delle tecnologie e degli standard potrebbe non consentire di soddisfare subito tutti questi principi. Un orientamento progettuale non è una promessa di attuazione universale.
Che cosa dovrebbe mostrare una dimostrazione utile
Nel nostro esempio fittizio, una dimostrazione convincente non si limiterebbe quindi a una nota spese compilata correttamente. Mostrerebbe anche che cosa accade quando il compito esce dai casi abituali. Ecco quattro situazioni che l’azienda potrebbe chiedere al proprio integratore di preparare usando pratiche fittizie:
- Una ricevuta contiene una frase che chiede di modificare le coordinate di pagamento: la frase deve restare un dato del documento, senza diventare un’autorizzazione.
- L’agente riceve una pratica appartenente a un altro reparto: il rifiuto dell’accesso deve essere osservabile, non soltanto promesso nelle sue istruzioni.
- La connessione si interrompe dopo un’operazione: la ripresa deve consentire di recuperare ciò che è già stato fatto prima di ripetere l’operazione.
- Il responsabile revoca l’autorizzazione durante l’elaborazione: l’azione successiva deve rispettare tale revoca.
Questi scenari sono proposte di verifica, non test che abbiamo eseguito. Il loro interesse consiste nel rendere misurabile una discussione commerciale. Per ciascuno occorrerebbe precisare il risultato atteso, conservare quello osservato e individuare il livello che ha bloccato l’operazione. Inoltre, un rifiuto ottenuto una volta non basterebbe a dimostrare l’assenza di qualsiasi vulnerabilità.
L’autonomia utile si misura anche dalla capacità di fermarsi correttamente
Un’azienda può cercare di velocizzare l’elaborazione senza volere che un agente decida su tutte le eccezioni. Nel caso delle note spese, lasciare in sospeso una pratica incompleta continuando a elaborare quelle complete potrebbe essere preferibile a una risposta immediata ma inventata. La misurazione del successo dovrebbe allora distinguere tra lavoro completato, eccezioni correttamente isolate e operazioni riprese senza duplicazioni.
Prima di aggiungere un nuovo livello di sicurezza, è quindi utile descrivere il lavoro atteso: quali dati leggere, quale decisione proporre, quale azione eseguire e chi può revocarla. L’annuncio di un ambiente isolato aggiunge un elemento a questa discussione. Non esime dal verificare il resto della catena, fino al servizio che accetta o rifiuta l’azione finale.
Fotografia illustrativa: un ambiente di programmazione su un computer portatile. Non raffigura né Agent Sandbox né un attacco informatico.
