Un chatbot risponde. Un agente agisce!.
Ed è proprio qui che iniziare a parlare di sicurezza della AI inizia a diventare più complicato. Mi piacerebbe approfondire con voi questo argomento, anche se tra gli argomenti relativi alla sicurezza informatica non è proprio al primo posto dei miei pensieri!.
Piano piano in altri articoli approfondirò, nel frattempo, vi intrattengo con questa introduzione all’argomento che potrebbe capire anche chi di intelligenza artificiale non ne ha mai capito niente!.
Partiamo pero dalle basi: cosa è un chatbot? e se c’è: dove è? e se dove è: perché?. eh! cit.
Detto in parole semplici, un chatbot è un robot che sta dietro una chat. Quando per esempio chiamate il numero di poste e vi risponde quella opinabile voce robotica che cerca di capire cosa volete ma che non è mai capace di dirci quello che ci serve sapere davvero (ovvero perché il nostro pacco non è ancora arrivato!). Quello è un chatbot!
Non è altro che un software che tramite algoritmi matematici (per lo più statistici) tenta di capire la vostra richiesta e di trovare la risposta più probabilmente giusta.
Dire “più probabilmente giusta” non è un errore perché quando vi dicono che i chatbot capiscono cosa vuoi e sanno come risponderti eh… anche no!.
Per l’LLM (tipo chatgpt per intenderci) si tratta di un algoritmo che fornisce a ogni “pezzo” di parola un numero in base alla attinenza di quella parola al resto della frase e cerca di calcolare la parola più probabile da aggiungere per completare la frase. (e non si sa come ci riesce! XD).
Qualche volta vi porto degli articoli con degli esempi pratici di algoritmi utilizzati da chatGPT e magari proveremo a programmarli da zero (in piccolo visto che richiederebbero GB di memoria). Per ora accontentatevi di questa immagine generata dallo stesso chatGPT.
Passiamo adesso agli agenti AI! Cosa sono gli agenti AI? E che ne so io? ti sembro un agente AI?.
Per fortuna ci aiutano i milioni di libri sull’argomento che ormai si trovano nelle librerie. Ne apro uno a caso (l’ho comprato giuro!). Secondo Avery Smartwell, ad esempio, gli agenti AI sono: Entità digitali progettate per portare a termine un obiettivo specifico attraverso una sequenza intelligente di azioni.
Per chi parla come mangia. Un pupo che fa quello che gli chiedi utilizzando l’intelligenza artificiale per ragionare sul da farsi.
Poco tempo fa in RedHotCyber sono usciti questi due articoli:
“Un utente ha raccontato sul forum di Google Antigravity di aver perso un mese di lavoro dopo aver chiesto all’agente AI di liberare spazio sul PC Windows. Durante le operazioni sarebbero stati cancellati file personali e progetti. Il caso mostra il rischio concreto di affidare agli agenti AI l’esecuzione autonoma di comandi distruttivi.”
“Intelligenza Artificiale e CLI di Claude: cancellato l’intero disco D per errore”
Come questi ne esistono tanti e la colpa non è della specifica intelligenza ma della fiducia che gli affidiamo pensando che loro capiscano quello che fanno e non siano solo delle macchine stocastiche.
Il problema in questione si chiama blast radius e excessive agency. Il blast radius non è altro che il raggio di azione, misurato in estenzione di un agente o una intelligenza artificiale. Ad esempio il ragazzo che ha chiesto all’agente di pulire il proprio sistema operativo, poteva limitarne l’azione ai soli file temporanei o non necessari limitando il raggio di azione dell’agente. Dandogli spazio di azione, invece, esteso a tutti i suoi documenti. compresi quelli di lavoro, ha esteso il raggio di azione della macchina.
Vediamo quali sono le best practices per evitare eventuali danni con un agente, senza limitarne le possibilità:
1. Non dare all’agente un’identità propria
Ogni computer può ospitare più di un agente (esecutori automatici di compiti) ma spesso questi vengono creati in modo da agire con l’account di chi lo crea. Così facendo sarà difficile capire chi ha eseguito il compito da bloccare per evitare danni e anche nei log dove raccoglieremo tutte le azioni svolte dai vari agenti diventa difficile controllare chi di loro stia facendo danni.
L’idea sarebbe dare a ogni agente un proprio nome ma non è sufficiente. Affinché sia sicuro il nome deve essere associato alla azione ma anche alle singole responsabilità e ai singoli permessi. Ogni agente deve avere permesso di accedere solo a ciò che veramente gli serve per eseguire il proprio lavoro.
2. Trasformare le policy in controlli eseguibili
Naturalmente il tutto deve essere poi applicato poiché “scripta manent” ma “exempla trahunt”. Le azioni hanno più effetto dei documenti.
Quello che stiamo realizzando infondo ha un nome: si chiama Governance della AI. Ne parlano nell’AIAct e negli standard ma se tali azioni non vengono messe in pratica diventa difficile governare (da “governum”, il timone delle vecchie navi”).
Questo significa:
- Definire delle allow-list (liste di cose permesse)
- Separare chi propone una azione da chi l’approva
Un agente non deve avere la liberta di ignorare le policy.
Meglio che tali policy non siano sole istruzioni nel prompt ma facciano proprio parte del codice della macchina.
3. Filtrare il contesto, non soltanto gli strumenti
L’idea di questo punto sarebbe: meglio non limitare solo le azioni ma anche letteralmente lo spazio di movimento.
Non è sufficiente inserire delle policy ma sarebbe molto più sicuro impedire all’agente di sapere che i file che non deve toccare esistano impedendole di vederli.
Questo naturalmente richiede un lavoro di classificazione dei file in base a importanza, utilizzo e scopo.
4. Trattare ogni input come non fidato
Meglio evitare che qualcun altro (magari un amico hacker) possa accedere alla macchina anche da internet. Pero potrebbe non essere un amico hacker ma anche un malware oppure del codice messo in internet apposta cosicché prima o poi qualcuno lo avrebbe scaricato.
Verificare ogni ingresso è utile quanto fondamentale.
5. Graduare l’autonomia in base a rischio ed evidenze
Come abbiamo detto, meglio limitare l’uso ma che ne dite se in caso di lavori con maggiore rischio siamo noi a premere il pulsante?.
Infondo perché devo fare scegliere a una macchina se quei file di lavoro sono fondamentali?. Ricordiamo che è pur sempre una serie di formule di probabilità.
Rimane uno strumento utile che velocizza i lavori ma se nel caso di lavori ad alto rischio le dessimo la possibilità di decidere il da farsi e poi fossimo noi non sarebbe sbagliato.
L’autonomia con cui una macchin aggisce è sempre meglio sia commisurata al rischio del lavoro che deve compiere.
6. Progettare audit e rollback prima dell’autonomia
Passiamo alla Accountability. La fiducia che devi infondere.
“Mamma, il cane mi ha mangiato i compiti!”. Questa scusa funziona ancora pero dire l’IA mi ha cancellato il tema no!.
Questo perché se dai all’IA di cancellare o lavorare su documenti importanti senza che tu ne tenga un backup da recuperare in caso di problemi. Sei tu ad avere sbagliato.
Questo è il motivo per cui conviene sempre (e dico sempre, non solo in questo caso!) avere una copia di backup di tutti i file oppure trovare un modo di potere fare il rollback delle modifiche (magari gli fai buttare i file in un cestino e poi sei tu a eliminarli).
Di solito questo pero lo si fa lavorando in una macchina virtuale che ha degli snap point periodici che permettono di ripristinare il lavoro in caso di problemi tornando a prima che una certa azione sia stata fatta o cancellandone gli effetti.
Conclusione
La sicurezza degli agenti AI non nasce da un guinzaglio sempre più corto. Nasce, come in ogni caso da un cambio di mentalità, di paradigma realizzando un recinto all’interno del quale essa possa operare a piene capacità ma senza fare danni, come un cavallo che può correre nel suo bel recinto di legno.
Questo è solo l’inizio di un lungo viaggio all’interno di questo mondo. Questo era un articolo basico anche per chi non era del mestiere. Presto usciranno altri articoli che approfondiranno il tema.
Saluti
Fonti e note redazionali
- Balaji Sivasubramanian, “The Goldilocks Problem: Sandboxing AI Agents Without Neutering Them”, Medium, 25 agosto 2026. Framework esperienziale e opinioni personali dell’autore; non è uno standard tecnico.
- Ali Al Mokdad, “AI Privilege: Policy Considerations for Access, Authority, and Accountability in Artificial Intelligence Systems”, Medium, 19 settembre 2025. Saggio individuale non peer-reviewed; la tassonomia è usata qui come lente concettuale.