Google ha pubblicato il 17 agosto 2026 una guida all'architettura e alle pratiche, accompagnata da un dimostratore open source, per agenti capaci di modificare un sistema di produzione. Il suo messaggio centrale è chiaro: un prompt, anche molto dettagliato, non è un confine di sicurezza. Le regole importanti devono essere imposte tramite codice, permessi e prove crittografiche indipendenti dal modello.
1. Il nuovo rischio: l’agente che scrive
Un chatbot che risponde male produce principalmente un problema d’informazione. Un agente che modifica un prezzo, rimborsa un ordine, crea un utente o cambia una configurazione può provocare un danno diretto.
Gli errori non derivano solo da un'intenzione malevola. Il modello può fraintendere un contesto, usare lo strumento sbagliato, ripetere un'azione dopo un ritardo o seguire un'istruzione inserita in una fonte esterna.
La sicurezza deve quindi concentrarsi sulla capacità d'azione stessa. Il sistema target non dovrebbe fidarsi di una richiesta semplicemente perché proviene dal servizio “agente”.
2. Perché le istruzioni non sono sufficienti
Un prompt può dire “non rimborsare mai più di 100 euro” o “chiedi una convalida umana”. Queste istruzioni migliorano il comportamento medio, ma rimangono interpretate da un modello probabilistico.
Un'iniezione può cercare di aggirarle. Un aggiornamento del modello può modificare il modo in cui vengono tracciate. Un errore di contesto può infine portare l'agente a credere che un'eccezione sia autorizzata.
Le regole di sicurezza devono essere scritte in un gateway deterministico o nell'API di destinazione. Il modello propone un'azione; un componente classico decide se è ammissibile.
3. Primo strato: firmare ogni modifica
L'architettura di Google raccomanda una chiave distinta per ciascun agente, gestita da Cloud KMS e protetta materialmente da Cloud HSM nella configurazione descritta. Ogni mutazione del ledger del dimostratore è firmata. Per un'architettura di produzione, consigliamo di estendere questo principio a ciascuna scrittura verso il sistema target. L'API può quindi verificare l'identità dell'agente, l'integrità della richiesta e l'assenza di alterazioni.
La firma deve coprire più del corpo JSON. Includere l'identificativo dell'agente, l'utente che ha originato la richiesta, l'azione, la risorsa, l'importo, il timestamp, un identificativo unico e la politica applicata. Un nonce o identificativo di idempotenza blocca le ripetizioni solo se l'API memorizza gli identificativi già trattati e ne rifiuta il riutilizzo.
Una chiave propria per ogni agente facilita la revoca. Se un servizio viene compromesso, è possibile bloccare le sue scritture senza interrompere tutte le altre.
La firma fornisce anche una prova di attribuzione tecnica. Non dimostra che la decisione fosse corretta, ma permette di sapere quale componente ha emesso la richiesta e se questa è stata modificata.
4. Secondo strato: eseguire in una sandbox
Google illustra l'isolamento con gVisor, un ambiente che intercetta le chiamate di sistema nello spazio utente. Il principio generale è ridurre le capacità del codice generato o degli strumenti chiamati: nessun accesso alla rete di default, sistema di file limitato, privilegi rimossi, risorse limitate e durata massima.
Il deposito precisa che l'interfaccia del dimostratore simula la sandbox e che l'esecuzione reale sotto gVisor è opzionale. Si tratta quindi di una guida e di un punto di partenza da rafforzare, non della prova che un'architettura di produzione completa sia stata auditata.
Una sandbox è utile solo se le uscite sono controllate. Un agente isolato che può scrivere un file poi interpretato ciecamente da un servizio privilegiato mantiene un percorso di attacco.
I dati iniettati nell’ambiente devono essere minimi e temporanei. Un segreto di produzione non dovrebbe essere copiato nella sandbox quando l’azione può essere eseguita tramite un’API limitata dietro un gateway.
5. Terzo strato: un ponte semantico deterministico
Il gateway verifica il senso dell’azione prima dell’esecuzione. Applica regole verificabili: importo massimo, ruolo dell’utente, stato dell’ordine, frequenza, paese, presenza di una validazione e coerenza dei campi.
Il modello non deve poter scegliere da solo la politica. Fornisce un'intenzione strutturata, idealmente conforme a uno schema. Il gateway arricchisce con i dati di riferimento e decide se autorizzare, rifiutare o chiedere un'approvazione.
Il dimostratore di Google si basa soprattutto su espressioni regolari, parole chiave e un controllo dei valori SQL. I controlli aziendali più avanzati proposti qui costituiscono una raccomandazione di architettura da adattare e testare, non una capacità dimostrata universalmente dallo strumento.
Le regole devono essere testate in CI come il codice di business. Un cambiamento di soglia o di eccezione passa attraverso una revisione, una versione e una cronologia.
6. Il registro di audit indipendente
Le tracce generate dall’agente non sono sufficienti, perché un componente compromesso può modificarle. Conservate un registro indipendente lato gateway o sistema target: richiesta ricevuta, firma, politica, decisione, risposta e stato finale.
Per andare oltre il dimostratore Google, che verifica periodicamente le firme del ledger e raccomanda Cloud Logging in produzione, uno storage append-only o una catena di hash può rafforzare la rilevazione di manomissioni. I log devono rimanere utilizzabili dai team di sicurezza e business senza esporre inutilmente i dati completi.
L'audit deve permettere di ricostruire una decisione: chi l'ha richiesta, quale contesto è stato utilizzato, quale versione della politica è stata applicata e quale azione è stata effettivamente eseguita.
7. Progettare i permessi per capacità
Evitate un account tecnico polivalente. Create capacità specifiche: leggere un ordine, proporre un rimborso, avviare un rimborso limitato o aprire una richiesta di convalida.
Ogni capacità possiede il suo schema, i suoi limiti e i suoi diritti. Un agente di supporto non deve accedere alla configurazione del cluster semplicemente perché le due funzioni utilizzano la stessa piattaforma di strumenti.
I permessi devono anche tenere conto dell’utente finale. L’agente non può ampliare i diritti della persona che assiste. Questo principio è centrale per qualsiasi agente connesso al sistema informativo.
8. Un esempio concreto: rimborso cliente
Consideriamo uno scenario illustrativo, distinto dal dimostratore Google: l’agente analizza la conversazione e propone un rimborso di 42 euro per l’ordine X. Non possiede direttamente la chiave di pagamento. Richiama una capacità propose_refund con uno schema rigoroso.
Il gateway raccoglie l'importo pagato, lo stato, i rimborsi precedenti e il ruolo dell'operatore. Autorizza importi inferiori a 50 euro in alcuni casi, richiede una convalida fino a 200 euro e rifiuta oltre.
Dopo l'autorizzazione, un servizio dedicato esegue l'operazione e firma il risultato. Il registro collega la proposta, la politica e la transazione. Una ripetizione con lo stesso identificativo non crea un secondo rimborso.
9. La checklist di messa in produzione
Prima di aprire una scrittura a un agente, verificate che l’azione possieda uno schema chiuso, una politica deterministica, un'identità dedicata, una firma, un'idempotenza e un registro indipendente. Testate i limiti, le ripetizioni, i ritardi e i dati malformati.
Simulate poi gli attacchi: istruzione nascosta in un documento, strumento che restituisce contenuto ostile, chiave revocata, data e ora vecchia, azione fuori ruolo e tentativo di eludere il limite massimo.
Iniziate in sola lettura, poi in modalità proposta. Consentite l’esecuzione automatica solo per operazioni reversibili, a basso impatto e sufficientemente osservate.
L'approccio zero-trust non cerca di rendere il modello infallibile. Parte dal presupposto che possa sbagliare e limita ciò che un errore può produrre. È questa inversione che permette di passare da una dimostrazione a una capacità sfruttabile.
Partitech accompagna la messa in sicurezza degli agenti aziendali: progettazione delle capacità, passaggi di politiche, firme KMS, sandboxing, audit e test di scenari avversi.