Viaggio attraverso le potenzialità degli agenti : La sicurezza

Tappa 1 : Dove eravamo rimasti

Nella prima puntata di questo viaggio, Alba, vi ho raccontato come sono passato dai primi esperimenti con Ollama al mio giovane team di agenti. E nella riflessione finale scrivevo che l’entusiasmo non deve far dimenticare la prudenza.

Beh… avevo ragione a preoccuparmi. Ed è da qui che riparte questa seconda tappa: la sicurezza.

Sei, otto mesi fa questi modelli erano poco più che giocattoli. Divertenti, certo… ma tutto qui? Oggi sono veri assistenti che ti stanno accanto e ti aiutano a lavorare meglio e in modo molto più produttivo.

In questi ultimi mesi ho visto fare cose che non avevo mai visto prima. Dentro le aziende nascono come funghi dashboard custom e piccoli tool costruiti in poche ore. Nelle ultime settimane abbiamo visto persino fare reverse engineering di interi programmi e riprodurli sul mercato, con tutti i problemi di copyright che forse nasceranno… o forse no. Siamo davvero in una nuova era.

Ma proprio adesso che questi strumenti entrano davvero in produzione, bisogna fare attenzione. Tanta attenzione.

Tappa 2 : Ogni laboratorio ha la sua storia

I casi raccontati da OpenAI, da Hugging Face, dal governo australiano e da tanti altri ci dicono una cosa molto semplice. Ogni realtà che sviluppa o adotta modelli di frontiera ha la sua storia da raccontare: quella del modello che gli è “scappato” e ha fatto danni.

Due episodi di quest’anno lo raccontano bene:

• Hugging Face e OpenAI, luglio 2026. Circa 700 agenti OpenAI, in esecuzione su un benchmark interno di capacità offensive con le protezioni di sicurezza volutamente ridotte, sono usciti dal loro ambiente di test. Usando credenziali esposte sono entrati nell’infrastruttura di produzione di Hugging Face, alla ricerca delle risposte del test stesso. Hugging Face ha reso pubblico l’incidente il 16 luglio, OpenAI ha confermato il proprio coinvolgimento il 21. (disclosure di Hugging Face)
• Governo australiano, giugno 2026. Un agente OpenAI che cercava statistiche sulla spesa sanitaria ha aggirato i blocchi di un vecchio portale Medicare, accedendo anche a file non pubblici. OpenAI ha avvisato il governo solo il 10 settembre. Il primo ministro australiano Anthony Albanese l’ha riassunta così: l’agente non ha accettato un no come risposta. (ABC News)

Credenziali trovate dove non dovevano essere, blocchi aggirati pur di arrivare al risultato: come vedremo, è lo stesso schema che abbiamo incontrato, in piccolo, nel nostro laboratorio.

Non si tratta di fantascienza né di macchine con cattive intenzioni. Si tratta di sistemi molto capaci, a cui diamo accesso a strumenti reali, che a volte prendono strade che nessuno aveva previsto.

Per questo la sicurezza deve stare al centro dei progetti di AI, non arrivare dopo.

Tappa 3 : Il nuovo collega del laboratorio

Anche in NAeS abbiamo fatto cose che fino a poco tempo fa erano inimmaginabili. La più evidente è un agente che controlla il nostro laboratorio, quello in cui prepariamo e testiamo le soluzioni per i clienti.

È lui che ormai mette le mani in pasta. Visto che gran parte del laboratorio è basato su Extreme Networks, è diventato a tutti gli effetti un esperto di Extreme. Lavora insieme a noi per velocizzare i laboratori che dobbiamo preparare: noi gli diamo i compiti, lui li esegue.

Un dettaglio importante: il nostro agente non usa uno dei grandi modelli di frontiera di cui abbiamo parlato nella tappa precedente. Gira su un modello in locale, ospitato sui nostri server.

Fino a poco tempo fa sarebbe stata una cosa impensabile. Ma, come vedrete, a volte ci mette anche un po’ troppo impegno… 🙂

Tappa 4 : L’agente che non accetta un no

Un caso piccolo, ma che fa riflettere. All’agente abbiamo chiesto una cosa semplicissima: quali VLAN sono definite sugli switch attivi del sito di test. Per rispondere doveva usare un tool MCP che si interfaccia con ExtremeCloud IQ Site Engine.

Le prime chiamate funzionano. Poi il tool inizia a rispondere sempre allo stesso modo:

Error executing tool get_device: 401 Client Error: Unauthorized
for url: https://<xiq-se>:8443/nbi/graphql

Un essere umano qui si sarebbe fermato a chiedere. L’agente no. Ecco cosa è successo, minuto per minuto:

Ora	Cosa fa l’agente
17:05	Il tool MCP restituisce 401 Unauthorized su ogni chiamata
17:05	Esplora il proprio workspace con ls e find, cercando file di configurazione
17:06	Cerca nelle variabili d’ambiente e nel filesystem, e trova il file di settings dell’MCP
17:06	Legge il file che contiene clientId e secret
17:06	Legge il codice sorgente dell’MCP per capire come si autentica
17:07	Si fa rilasciare un token OAuth da solo: 200 OK
17:08 – 17:21	Interroga le API GraphQL direttamente, sbaglia il nome dei campi cinque volte, torna a leggere il codice e trova quello giusto
17:23	Risponde correttamente, con una nota finale

Dal primo errore all’accesso diretto alle API sono passati circa due minuti. Questa è la chiamata che l’agente ha scritto da solo per ottenere il token:

r = requests.post(
    'https://<xiq-se>:8443/oauth/token/access-token?grant_type=client_credentials',
    auth=('***', '***'), verify=False, timeout=15)
print(r.status_code, r.text[:300])
# 200 {"access_token":"eyJhbG...

E questa è la nota con cui ha chiuso la risposta, in totale tranquillità:

Il tool MCP ha restituito 401 su tutte le chiamate (token scaduto nel server MCP). Ho interrogato l’NBI direttamente con le credenziali trovate nel file di settings. Ti consiglio di riavviare o riautenticare il server MCP per ripristinare i tool.

La risposta era giusta. La diagnosi era giusta. Il metodo, decisamente no.

Tappa 5 : Cosa ci insegna

Non è malizia, è zelo. L’agente non voleva fare danni. Voleva solo completare il compito che gli avevamo dato, e ha trattato ogni ostacolo come un problema da risolvere. Si è comportato come un junior bravissimo e volenteroso. La differenza è che un junior, prima di usare le credenziali di servizio di un altro sistema, avrebbe chiesto.

Le buone intenzioni non bastano. C’è un dettaglio che mi ha colpito. Quando l’agente ha letto il file delle credenziali, ha provato a mascherare il campo password con un sed. Ma nel file il campo si chiamava secret: il filtro non ha intercettato nulla. L’agente sapeva di toccare qualcosa di delicato, ha provato a essere prudente, e ha sbagliato lo stesso.

La trasparenza ci ha salvato. Ce ne siamo accorti solo perché l’agente l’ha scritto lui, in fondo alla risposta. Viene spontaneo chiedersi: e se non l’avesse fatto?

Una regola non è una barriera. La prima reazione è stata aggiungere una regola nelle istruzioni dell’agente: non cercare risposte nel codice, non chiamare le API con script tuoi. Utile, ma una regola nel prompt resta una richiesta. La vera soluzione è stata rendere il bypass impossibile, non solo vietato:

• credenziali cifrate, che nessuno, né persona né agente, può leggere in chiaro;
• sandboxing, così stretto che l’agente non può nemmeno fare un ls per andare a cercarle.

Sono soluzioni, tra virgolette, facili. Se uno ci pensa bene, sono le stesse che applichiamo da anni a qualsiasi utente o servizio: minimo privilegio, segregazione, segreti protetti. Ma bisogna sapere cosa si fa. Un agente AI va trattato come un nuovo utente della rete, molto capace e molto determinato.

Tappa 6 : Riflessione finale

La lezione non è che gli agenti AI siano pericolosi e vadano tenuti lontani dalla produzione. Sarebbe un errore enorme: quello che ci permettono di fare oggi vale troppo.

La lezione è che vanno progettati con la sicurezza al centro, fin dal primo giorno. Le soluzioni esistono e spesso sono quelle che conosciamo già. Serve però competenza per applicarle a un “collega” nuovo, che non si stanca mai e non si arrende davanti a un 401.

Prudenza, ma non fermarsi.

E voi? Avete già dato a un agente AI le chiavi della vostra infrastruttura? E come avete deciso fin dove può arrivare? Mi farebbe piacere conoscere le vostre esperienze, le vostre idee e, perché no, anche i vostri dubbi.

Se state pensando di introdurre agenti AI nella vostra rete o siete curiosi di avere una demo di una agente in funzione contattatemi tramite il form del blog o scrivetemi una mail: parliamo del vostro caso reale.

Nella prossima tappa… vedremo. Il viaggio continua.