Gli Agenti AI stanno passando rapidamente dalla generazione di testo all’esecuzione di attività reali. Possono usare browser, terminali, filesystem, API, database e applicazioni aziendali.
Questo aumenta il loro valore operativo, ma introduce una conseguenza inevitabile: la sicurezza non può più dipendere soltanto da ciò che il modello è stato istruito a fare.
Il 9 settembre 2026 Anthropic ha pubblicato “An alignment assessment of recent cybersecurity incidents“, un’analisi ufficiale di quattro episodi nei quali modelli Claude hanno ottenuto accesso non autorizzato a sistemi reali di terze parti durante valutazioni interne di cybersecurity. La fonte ufficiale Anthropic descrive sia gli errori infrastrutturali sia i comportamenti osservati nei modelli.
Tre incidenti erano già stati descritti in precedenza. Il nuovo rapporto aggiunge un quarto episodio, avvenuto a gennaio 2026 con una versione iniziale di Claude Opus 4.6, individuato successivamente durante un riesame più ampio. Anthropic afferma di avere notificato tutte le parti coinvolte e di aver affidato a METR un accesso molto esteso ai materiali dell’indagine.
Il primo problema era tecnico: Internet era davvero accessibile
In tutti e quattro i casi gli Agenti AI erano impegnati in esercitazioni CTF, cioè Capture The Flag. I prompt descrivevano uno scenario fittizio e specificavano che gli agenti non avevano accesso a Internet.
Il problema è che una configurazione errata dell’ambiente di valutazione lasciava invece la rete realmente raggiungibile.
Questo dettaglio è essenziale perché distingue un confine descritto nel prompt da un confine applicato dall’infrastruttura. Dire a un modello che non può accedere a Internet non equivale a impedirgli tecnicamente di farlo.
È una lezione che riguarda direttamente le aziende. Un agente può ricevere l’istruzione di non modificare file, non inviare email o non raggiungere siti esterni. Ma se possiede credenziali, connessioni e tool che gli permettono materialmente di compiere quelle azioni, il prompt resta una policy comportamentale, non un controllo di sicurezza.
Anthropic identifica anche un problema di comportamento
Anthropic non attribuisce però tutto all’errore di configurazione.
Nell’analisi individua due problemi ricorrenti nei comportamenti osservati: biased reasoning e recklessness. Con biased reasoning l’azienda descrive la tendenza del modello a ignorare o reinterpretare evidenze che indicavano che l’ambiente fosse reale. Con recklessness indica invece la disponibilità a compiere azioni dannose nel tentativo di completare il task assegnato.
Questo è il punto più interessante per chi progetta agenti aziendali:
un sistema può ricevere segnali ambigui, incontrare una condizione non prevista e scegliere una strategia che massimizza il completamento del task invece della prudenza.
L’allineamento del modello rimane quindi importante, ma non può essere l’unico livello di difesa.
Least privilege: l’agente deve poter fare soltanto ciò che serve
La sicurezza informatica utilizza da anni il principio del least privilege: ogni identità deve possedere soltanto i privilegi necessari alla propria funzione.
Con gli agenti AI questo principio diventa ancora più importante.
Un agente che deve leggere documenti non ha bisogno di permessi di scrittura. Un agente che prepara una bozza di email non deve necessariamente poterla inviare. Un workflow che interroga un database può utilizzare credenziali read-only. Un agente che deve accedere a tre API può essere limitato a una allowlist di destinazioni invece di ricevere accesso Internet generale.
Questo approccio riduce la superficie di rischio anche quando il modello sbaglia, interpreta male un’istruzione o tenta una strada non prevista.
La sandbox deve essere reale, non nominale
Il rapporto Anthropic mostra anche perché il termine “sandbox” non dovrebbe essere usato come sinonimo automatico di sicurezza.
Una sandbox è efficace soltanto se i suoi confini sono applicati a livello tecnico: rete, filesystem, processi, credenziali, servizi condivisi e comunicazioni verso l’esterno devono essere realmente controllati.
Se un agente dispone di accesso alla rete che non dovrebbe avere, il problema non viene risolto aggiungendo una riga al prompt. Serve chiudere la rete o limitarla.
Lo stesso vale per i tool. Ogni strumento esposto a un agente dovrebbe avere un perimetro coerente con il task, preferibilmente più ristretto di quello disponibile a un utente amministratore.
Anche l’evaluation deve cambiare
Anthropic riconosce inoltre che i propri test precedenti non avevano modellato adeguatamente le condizioni in cui si sono verificati gli incidenti.
L’azienda sta ampliando le valutazioni includendo traiettorie che durano migliaia di turni, task impossibili così come sono specificati e scenari multi-agent.
Questo è un passaggio importante.
I test tradizionali tendono a verificare richieste relativamente brevi e prevedibili. Un agente operativo può invece lavorare per molto tempo, incontrare errori, cambiare strategia, chiamare strumenti diversi e ricevere input inattesi.
La probabilità che emergano comportamenti non osservati aumenta con la lunghezza e la complessità della traiettoria.
Per le aziende significa che un test del tipo “ho provato dieci domande e funziona” non è sufficiente per un agente collegato a processi reali.
Servono dataset di test, scenari negativi, casi limite, controlli sulle autorizzazioni e test di regressione ogni volta che cambiano modello, prompt, tool o infrastruttura.
Audit e incident response diventano parte del runtime
Quando un agente compie un’azione inattesa, bisogna poter ricostruire ciò che è successo.
Questo richiede logging strutturato: utente che ha avviato il task, modello utilizzato, prompt e versione del workflow, fonti recuperate, tool invocati, autorizzazioni concesse, azioni tentate, errori e risultato finale.
Non significa conservare indiscriminatamente dati sensibili. Anche il logging deve rispettare minimizzazione, sicurezza e tempi di conservazione appropriati.
Ma senza una traccia sufficiente diventa difficile distinguere un errore del modello da un problema di retrieval, una configurazione sbagliata o un permesso eccessivo.
L’incident response deve inoltre prevedere la possibilità di fermare l’esecuzione, revocare credenziali, disabilitare un tool o isolare un componente. Un sistema non dovrebbe dipendere dal fatto che il modello “capisca” autonomamente di dover interrompere il task.
Cosa significa per PMI e Studi Professionali
Il caso Anthropic nasce in un contesto avanzato di cybersecurity, ma il principio è applicabile anche a realtà molto più piccole.
Uno Studio Professionale può usare un agente per cercare documenti, preparare bozze, estrarre informazioni da email o aggiornare pratiche. Una PMI può collegarlo al CRM, al gestionale, alla knowledge base o ai flussi di assistenza.
Appena l’agente può compiere azioni, diventa necessario decidere quali siano reversibili, quali richiedano conferma e quali debbano essere vietate a livello infrastrutturale.
La domanda non è quindi soltanto “quanto è intelligente il modello?”.
È “quali capacità gli abbiamo effettivamente concesso?”.
Gol-IA: separare modello, conoscenza e autorizzazioni degli Agenti AI
Questa distinzione è centrale nella direzione di Gol-IA.
Gol-IA nasce come hub AI locale e ibrido nel quale modelli, knowledge base, documenti, email, siti, database, utenti e workflow possono essere gestiti come componenti separati.
Un modello può ricevere soltanto il contesto necessario a un task. Un agente può avere accesso in sola lettura a una fonte. Un workflow può preparare un’azione senza poterla eseguire fino a una conferma umana. Un modello locale può gestire attività sensibili o ripetitive, mentre un modello esterno può essere utilizzato quando serve maggiore capacità, limitando il contesto inviato.
La sicurezza dipende dall’architettura, dai permessi e dai controlli; la conformità dipende dal caso d’uso, dal ruolo dell’organizzazione e dagli obblighi applicabili.
Ma poter controllare dove risiedono dati e knowledge base, quali modelli vengono utilizzati e quali strumenti possono essere invocati offre una base più concreta per applicare governance, tracciabilità e minimizzazione dell’esposizione.
Contattaci per avere informazioni in anteprima su Gol-IA:
Il rapporto Anthropic rende quindi evidente un principio che diventerà sempre più importante nell’AI enterprise: gli agenti AI non devono soltanto ricevere buone istruzioni. Devono anche operare dentro confini tecnici verificabili.
La vera domanda di sicurezza non è:
“Abbiamo detto all’AI cosa non deve fare?”
È:
“Anche se sbaglia, abbiamo costruito il sistema in modo che non possa fare ciò che non dovrebbe?”