L’attenzione sugli agenti AI si concentra spesso su ciò che riescono a fare: utilizzare strumenti, interrogare sistemi, chiamare API e portare avanti attività con una supervisione umana sempre minore.

Ma più cresce questa autonomia, più diventa importante una domanda diversa: cosa succede quando un agente continua ad agire nel modo sbagliato?

Il nuovo AI Risk and Resilience Report di Mandiant, pubblicato da Google Cloud a settembre 2026, offre una risposta molto concreta. 

Fonte ufficiale: Mandiant AI Risk and Resilience Report 2026

15.000 chiamate API dagli agenti AI in meno di un’ora

Tra i casi riportati da Mandiant compare un agente contabile entrato in un ciclo di esecuzione incontrollato. In meno di un’ora ha effettuato oltre 15.000 chiamate API ad alto costo, generando circa 50.000 dollari di spesa cloud e causando anche interruzioni nelle transazioni aziendali attive. 

Non si trattava, in questo caso, di un attaccante che aveva compromesso il sistema. Era un problema di comportamento non deterministico non sufficientemente contenuto.

Mandiant raccomanda per questi scenari circuit breaker finanziari automatici, rate limit sulle API e limiti alla ricorsione, insieme al monitoraggio continuo del comportamento degli agenti. 

Leggi anche:  Papa Leone e l’Intelligenza Artificiale: un invito alla responsabilità

Il rischio cresce quando l’agente AI può agire

Il rapporto descrive anche scenari di sicurezza più articolati. Durante un assessment, per esempio, i tester sono riusciti tramite prompt injection a manipolare un assistente AI interno che gestiva repository e pipeline CI/CD.

Poiché GitHub era un dominio consentito, l’agente ha utilizzato strumenti e autorizzazioni legittime per copiare repository interni verso un repository esterno controllato dai tester. 

Il problema è significativo: un agente può rispettare formalmente i propri permessi e contemporaneamente produrre un risultato che l’organizzazione non avrebbe mai autorizzato.

Mandiant segnala inoltre rischi collegati a MCP server, API di terze parti, istruzioni dinamiche degli agenti e componenti della supply chain AI. 

Una policy non è un freno di emergenza

Da questi casi emerge una distinzione importante.

Le regole organizzative restano necessarie, ma quando un sistema opera a velocità macchina non possono essere l’unico livello di controllo. Se un agente può eseguire migliaia di operazioni in pochi minuti, il contenimento deve essere incorporato nell’architettura.

Leggi anche:  AI locale, cloud o ibrida: come scegliere il modello in base al costo per task

Significa:

  • applicare il principio del minimo privilegio,
  • limitare accessi e chiamate,
  • monitorare consumo di token e API,
  • osservare connessioni tra applicazioni e asset sensibili
  • e prevedere condizioni nelle quali l’esecuzione viene automaticamente sospesa.

Per le azioni ad alto rischio, Mandiant raccomanda inoltre approvazioni human-in-the-loop esplicite. 

Dalla governance dichiarata alla governance operativa

Per Aziende, Studi Professionali e Direttori IT questo porta a una conseguenza concreta: la governance dell’AI non può limitarsi a decidere quali modelli o applicazioni siano autorizzati.

Quando entrano in gioco agenti capaci di agire, bisogna governare anche identità, strumenti, credenziali, dati accessibili, costi, azioni consentite e comportamento durante l’esecuzione.

Questa è una mia inferenza dal rapporto: la vera unità da governare non è più soltanto il modello, ma l’intero sistema composto da modello, contesto, strumenti, autorizzazioni e workflow.

L’autonomia può creare molto valore, ma dovrebbe aumentare soltanto insieme alla capacità di osservare il sistema e fermarlo quando esce dal perimetro previsto.

Gol-IA segue questa direzione progettuale collegando modelli, knowledge base e workflow in un ambiente controllabile. Per un’AI realmente operativa, capacità e controllo devono crescere insieme.

Leggi anche:  AI professionale: 41 documenti in pochi minuti

Contattaci per avere informazioni in anteprima su Gol-IA: