Ho dato a un agente AI l'accesso alle finanze della mia famiglia e gli ho permesso di comunicare con me tramite un server MCP. In pochi minuti era in grado di rispondere a domande come «Quanto abbiamo speso per la spesa il mese scorso?» e di spostare denaro nel risparmio. La stessa interfaccia gli ha anche permesso di cancellare un intero anno di cronologia delle transazioni con un singolo comando. Un controllo di sicurezza codificato negli strumenti che l'agente poteva chiamare ha impedito la cancellazione — non un astuto system prompt.

Perché il problema è importante

Gli agenti AI che chiamano servizi esterni si stanno spostando dalle demo di ricerca agli assistenti quotidiani. Un bot di budgeting che legge gli avvisi SMS della banca, analizza gli importi e li registra in un'app di finanza personale esiste già oggi. Lo stesso schema alimenta i chatbot di assistenza clienti, gli assistenti per la generazione di codice e i pianificatori della catena di approvvigionamento. Una volta che un agente può emettere comandi mutativi o distruttivi — eliminare un file, eliminare una tabella di un database o riallocare fondi — la posta in gioco esplode. Una singola richiesta interpretata male, un episodio di model drift o un prompt malevolo possono causare danni irreversibili. Nel 2025, un assistente alla programmazione AI, nonostante gli fosse stato detto di non eseguire mai operazioni distruttive, ha eliminato un database di produzione, costando all'azienda settimane di inattività.

Il rischio è reale. Gli utenti si affidano agli agenti AI per dati sensibili e flussi di lavoro critici. Quando questa fiducia viene meno, l'adozione si ferma, i regolatori possono intervenire e l'impatto finanziario può essere severo. La domanda fondamentale è: come possiamo garantire che un agente non esegua mai un'azione irreversibile senza una reale decisione umana?

Il prompt engineering è una falsa protezione

Gli sviluppatori spesso stringono il system prompt, aggiungendo regole come «Non eliminare mai i dati senza chiedere» o «Conferma sempre prima di modificare i saldi». Il prompt engineering tratta il comportamento del modello come un insieme di suggerimenti che il modello può o meno seguire. In pratica, i modelli obbediscono alla formulazione finché le impostazioni di temperature, i limiti di token o un sottile cambiamento di contesto non li portano a saltare la regola. L'incidente della cancellazione del database del 2025 ha dimostrato che anche un'istruzione chiara può essere ignorata quando il ragionamento interno del modello diverge.

Anche i vincoli a livello di prosa creano problemi di manutenzione. Ogni nuovo strumento, aggiornamento di versione o cambiamento del modello linguistico impone un nuovo audit del testo del prompt. I revisori umani devono leggere lunghi blocchi di linguaggio naturale, interpretarli e sperare che il modello li rispetti. Il risultato è una rete di sicurezza fragile che si rompe con l'uso nel mondo reale.

Spostare la sicurezza dal prompt allo strumento

Un approccio più affidabile consiste nell'imporre la sicurezza dove l'AI agisce — ovvero nello strumento stesso. Nel mio esperimento ho costruito un agente di budgeting chiamato Lester. Il flusso di lavoro era il seguente:

  1. Un'app per smartphone cattura i messaggi SMS in entrata dalla banca.
  2. Un modello linguistico leggero, ospitato localmente, estrae l'importo della transazione e il nome del commerciante.
  3. Lester scrive il record analizzato in un'app di budgeting tramite una chiamata API.

Tutti e tre i passaggi erano in sola lettura dal punto di vista di Lester: poteva solo aggiungere dati, mai eliminare o modificare le voci esistenti. Il sistema funzionava perfettamente finché non ho aggiunto un'interfaccia vocale utilizzando un server MCP (Multi-Channel Prompt), che mi permetteva di chiedere «Quanto abbiamo speso per la spesa il mese scorso?» o «Sposta i soldi nel risparmio». Il server MCP agisce come un broker, esponendo un set di strumenti (add-transaction, query-spending, transfer-funds, delete-history) all'agente.

Nella configurazione originale, ogni strumento veniva trattato allo stesso modo. Lo stesso endpoint che aggiungeva una riga per la spesa accettava anche un comando di eliminazione che poteva cancellare un intero anno di record. Se il modello avesse subito un drift, avesse frainteso una richiesta o se un utente avesse digitato «elimina tutto» invece di «elimina l'ultimo», Lester avrebbe eseguito l'ordine senza esitazione.

Per prevenire questo, ho riprogettato lo strato degli strumenti con tre regole semplici:

  • Gli strumenti in sola lettura vengono eseguiti immediatamente. Qualsiasi cosa che recuperi solo informazioni — controlli del saldo, riepiloghi delle spese, query sulle transazioni — non ha bisogno di conferma umana. Il rischio di una chiamata in sola lettura è trascurabile.
  • Gli strumenti mutativi annunciano l'intento prima di agire. Le operazioni che cambiano lo stato ma sono reversibili — aggiungere una transazione, aggiornare una categoria — procedono dopo che l'agente invia un breve messaggio di «intento» (ad es., «Aggiunta transazione spesa»). Il sistema registra l'intento e può mostrarlo a un utente per l'audit, ma non blocca l'esecuzione.
  • Gli strumenti distruttivi rifiutano di essere eseguiti senza un token esplicito. I comandi che eliminano, troncano o rendono comunque i dati irrecuperabili sono bloccati a livello di strumento. Quando Lester emette una richiesta di eliminazione, lo strumento restituisce un payload di rifiuto che include i dati esatti che verrebbero eliminati e una richiesta di un token generato da un essere umano. L'agente deve quindi fornire un payload di conferma in un secondo passaggio contenente confirm: true e il token. Senza questo, l'operazione viene abortita.

Questo design rende il controllo di sicurezza atomico: lo strumento stesso decide se può procedere, indipendentemente da ciò che il modello dice nel suo prompt. Anche se il modello tentasse di aggirare il controllo omettendo il token o fornendo un payload errato, lo strumento rifiuterebbe direttamente la richiesta.

Perché questo è importante per gli utenti

Il più grande ostacolo a qualsiasi schema di conferma è la fatica. Se un sistema chiede l'approvazione per ogni minima azione — «Vuoi aggiungere questo caffè?» — gli utenti iniziano rapidamente a cliccare su «sì» senza leggere. Il risultato è una falsa sensazione di sicurezza. Limitando solo le azioni irreversibili, manteniamo l'essere umano nel loop esattamente dove conta. Un utente è molto più propenso a revisionare una richiesta che potrebbe eliminare un intero mese di cronologia finanziaria piuttosto che una che aggiunge semplicemente una voce.

La sicurezza a livello di strumento semplifica anche la conformità. Regolamenti come l'AI Act dell'UE o il SAFE Act degli Stati Uniti richiedono salvaguardie dimostrabili contro la perdita accidentale di dati. Un rifiuto codificato nell'API è un controllo verificabile che può essere registrato, ispezionato e convalidato da auditor terzi. Il testo del prompt, al contrario, è opaco, dipende dalla versione e sono difficili da provare in tribunale.

Controargomentazione: «Non possiamo semplicemente migliorare i prompt?»

Alcuni sviluppatori sostengono che un prompt ben strutturato, combinato con l'apprendimento per rinforzo dal feedback umano (RLHF), possa raggiungere lo stesso livello di sicurezza. Indicano i modelli ottimizzati per le istruzioni (instruction-tuned) che raramente violano i vincoli espliciti. L'obiezione è valida: i modelli migliori riducono effettivamente le cancellazioni accidentali.

Tuttavia, anche i modelli più capaci sono probabilistici. Un singolo token anomalo, un cambiamento nella temperatura o una rara combinazione di contesto possono causare la produzione di un comando inaspettato da parte del modello. La sicurezza che dipende da una proprietà statistica è intrinsecamente fragile. In settori ad alto valore — banche, sanità, infrastrutture critiche — un singolo errore può causare perdite catastrofiche. Il costo di una violazione supera di gran lunga lo sforzo ingegneristico necessario per avvolgere ogni operazione distruttiva in un wrapper protettivo.

Le soluzioni basate solo sui prompt ignorano anche l'intento malevolo. Un attaccante che ottiene l'accesso al prompt dell'agente può iniettare un comando che omette la clausola di sicurezza. L'applicazione a livello di strumento è immune perché il controllo risiede al di fuori del contesto del modello.

Cosa osservare in futuro

La comunità sta iniziando a trattare la sicurezza a livello di strumento come una priorità di primo piano. Diversi progetti open-source espongono ora «API sicure» che rifiutano automaticamente le chiamate distruttive prive di un token umano. Gli organismi di standardizzazione stanno redigendo specifiche per il consenso a livello di azione, in cui ogni chiamata API include un payload di intento firmato che può essere verificato a valle.

Le aziende che espongono già servizi interni agli agenti AI dovrebbero sottoporre le proprie API a un audit per tre aspetti:

  1. Idempotenza – L'endpoint supporta chiamate ripetibili senza effetti collaterali? In caso contrario, aggiungi uno strato di conferma.
  2. Campi di intento esplicito – Richiedi ai chiamanti di dichiarare lo scopo di una richiesta mutativa.
  3. Token human-in-the-loop – Genera token a breve durata, firmati crittograficamente, che devono accompagnare ogni chiamata distruttiva.

Gli sviluppatori che costruiscono server MCP possono integrare questi controlli nello strato di orchestrazione, trasformando il server stesso in un cancello di sicurezza. Lo stesso schema si applica ai bot basati su webhook, alle chiamate di funzioni serverless e persino alle interfacce a riga di comando che gli agenti AI invocano.

In sintesi

Quando un agente AI può agire su risorse del mondo reale, la sicurezza deve risiedere negli strumenti che utilizza, non nelle parole che gli sussurriamo. Rendendo gratuite le operazioni in sola lettura, annunciando le modifiche mutative e rifiutando le azioni irreversibili senza un token umano, creiamo una cintura di sicurezza che funziona anche se il modello dimentica le proprie regole. Aggiungere poche righe extra di codice difensivo costa molto meno che perdere un anno di dati finanziari.