I limiti di un agente IA non si scrivono nel prompt. Si scrivono nel modello dei permessi. La regola pratica pubblicata da Meta a novembre 2025, la Agents Rule of Two, afferma che un agente dovrebbe soddisfare al massimo due proprietà su tre: elaborare input non attendibili, accedere a dati sensibili e modificare uno stato o comunicare verso l’esterno. Un agente che le riunisce tutte e tre può essere trasformato in uno strumento di esfiltrazione dei dati da un singolo testo iniettato. Un modello dei permessi che funziona opera su quattro livelli — identità, strumento, argomento e budget — e marca in anticipo le azioni irreversibili per l’approvazione umana.
Perché un prompt non è un controllo di sicurezza
L’istruzione più comune che troviamo nei progetti che ereditiamo suona più o meno così: non cancellare clienti, non inviare email senza approvazione, non esporre informazioni interne. Quella frase sta nel prompt di sistema e dà la sensazione di una protezione. Non lo è.
Un prompt è un suggerimento statistico, non un permesso. Compete per l’attenzione del modello con ogni altro testo presente nel contesto — compreso quello arrivato dall’esterno. Nel momento in cui l’agente legge un’email, una pagina web, un file caricato da un cliente o il risultato di uno strumento, quel testo occupa lo stesso spazio delle vostre istruzioni. È tutta qui l’idea della prompt injection, ed è il motivo per cui non se ne esce riformulando.
La separazione corretta è semplice: il prompt definisce l’intenzione, il modello dei permessi definisce la capacità. Ciò che l’agente tecnicamente non può fare, non lo farà — per quanto lo si convinca che dovrebbe.
Prova rapida: se la vostra unica difesa contro un’azione distruttiva è una frase in un prompt, non avete una difesa. Avete una richiesta cortese.
La Rule of Two: il framework più pratico pubblicato finora
Il 1° novembre 2025 Meta ha pubblicato un framework insolitamente semplice per progettare agenti più sicuri. Individua tre proprietà e sostiene che un agente, all’interno di una singola sessione, dovrebbe soddisfarne al massimo due.
| Proprietà | Che cosa significa | Esempio tipico |
|---|---|---|
| A. Input non attendibile | L’agente legge contenuti controllati da qualcun altro | Email in arrivo, moduli, pagine web, documenti caricati |
| B. Accesso a dati sensibili | L’agente può leggere dati privati o sistemi interni | CRM, buste paga, base di conoscenza interna, casella di posta |
| C. Cambio di stato o comunicazione esterna | L’agente può scrivere, inviare o pubblicare | Invio di email, chiamata a un’API esterna, aggiornamento di un record, addebito |
Il pericolo sta nella combinazione di tutte e tre. Un agente che legge un’email in arrivo (A), estrae dati cliente dal CRM (B) e può inviare email (C) diventa una macchina per l’esfiltrazione nel momento in cui qualcuno gli manda un messaggio con un’istruzione nascosta. L’attaccante non deve rompere nulla; gli basta scrivere del testo.
Meta stessa sottolinea che la regola non è un traguardo. Non protegge dagli errori dell’agente, né dalle injection che si limitano a produrre disinformazione nella risposta, né da permessi troppo ampi all’interno dei due assi che avete mantenuto. È uno strumento per ridurre lo scenario peggiore, non un sostituto della difesa in profondità.
Come spezzare la combinazione nella pratica
Nella maggior parte dei casi non dovete rinunciare a una capacità; dovete distribuirla su due agenti o due fasi. Questi sono i tre pattern che funzionano.
| Pattern | Che cosa viene separato | Quando usarlo |
|---|---|---|
| Lettore ed esecutore | Un agente legge l’input non attendibile e restituisce solo un riassunto strutturato; un secondo agente agisce su quel riassunto contro i sistemi reali | Elaborazione di email, moduli, documenti dei clienti |
| Firma umana | L’agente soddisfa tutte e tre le proprietà, ma l’azione C passa da un’approvazione umana | Quando il processo davvero non può essere diviso |
| Canale di uscita chiuso | L’agente può scrivere solo verso destinazioni presenti in una allowlist fissa | Reportistica interna, aggiornamento di record, generazione di bozze |
Il secondo pattern è il più diffuso ed è anche quello che si degrada: un’approvazione diventata riflesso smette di essere un controllo. Dove collocare esattamente il punto di approvazione, e come mantenerlo significativo, è trattato nella nostra guida all’approvazione umana.
Un modello dei permessi su quattro livelli
Il permesso di un agente non è una questione binaria di accesso ai sistemi. Si costruisce su quattro livelli, e ogni livello saltato apre un’intera classe di guasti.
| Livello | La domanda a cui risponde | Che cosa succede quando manca |
|---|---|---|
| Identità | Per conto di chi agisce l’agente | Azioni attribuite a un account di servizio anonimo; nessuna traccia di audit, nessuna ricostruzione |
| Strumento | Quali azioni esistono per lui | L’agente scopre una capacità che non doveva avere, come la cancellazione tramite uno strumento di aggiornamento generico |
| Argomento | Su che cosa può eseguire quell’azione | Strumento giusto, ambito sbagliato — un aggiornamento applicato a tutti i record invece che a uno |
| Budget | Quanto, quanto in fretta e fino a quando | Un ciclo che percorre centinaia di passi o migliaia di chiamate prima che qualcuno se ne accorga |
Il livello degli argomenti è quello più spesso dimenticato, e quello che provoca la maggior parte dei danni reali. Un agente autorizzato ad aggiornare lo stato di un ordine senza limiti di ambito può aggiornare tutti gli ordini. La regola semplice: ogni strumento di scrittura valida i propri argomenti lato server, non nelle istruzioni al modello.
Prompt injection e uso improprio degli strumenti: che cosa è già successo
A dicembre 2025 OWASP ha pubblicato la sua Top 10 dei rischi per le applicazioni agentiche. Il rischio siglato ASI02, Tool Misuse and Exploitation, descrive esattamente il caso in cui un agente usa in modo distruttivo uno strumento autorizzato — e la mitigazione raccomandata sono permessi granulari e una validazione rigorosa degli argomenti prima dell’esecuzione. Non è una raccomandazione teorica.
Un esempio concreto: la CVE-2025-59528 in Flowise, piattaforma low-code per costruire applicazioni agentiche, nasceva da una gestione non sicura dei dati di configurazione CustomMCP e consentiva l’iniezione e l’esecuzione di JavaScript arbitrario. La falla non era nel modello. Era nel livello tra il modello e gli strumenti — esattamente il punto che la maggior parte dei team tratta come idraulica.
La specifica stessa va nella stessa direzione: la revisione stabile del Model Context Protocol datata 28 luglio 2026 elenca il rafforzamento dell’autorizzazione tra i cambiamenti principali, accanto al passaggio a un protocollo senza stato. Chi costruisce oggi un livello di strumenti parte da una base migliore rispetto a un anno fa, ma quella base non sostituisce le vostre decisioni.
Che cosa un agente non fa mai da solo
L’elenco che segue è indipendente dal settore. Sono azioni in cui il costo di un errore supera il costo dell’attrito.
- Muovere denaro. Addebitare, accreditare, rimborsare, modificare condizioni di pagamento.
- Comunicare all’esterno per conto dell’azienda. Email ai clienti, messaggi, pubblicazione — scrivere sì, inviare no.
- Cancellare o qualunque azione irreversibile. Tutto ciò che non ha un pulsante di annullamento.
- Modificare i permessi. Un agente che può allargare i propri permessi non è un agente, è una falla.
- Agire su ampia scala. Aggiornamenti massivi, export di database, modifiche alla configurazione di sistema.
- Decisioni con conseguenze legali o normative. Respingere un sinistro, classificare un dipendente, quotare un prezzo vincolante.
Che cosa un agente possa leggere è una questione distinta e altrettanto importante — la classificazione delle informazioni che potete dare in pasto a un modello è trattata nella nostra guida alla classificazione dei dati aziendali.
Che aspetto ha quando è fatto bene
Un buon modello dei permessi è noioso. Somiglia a una tabella: ogni strumento ha un responsabile, un livello di rischio, un intervallo di argomenti consentito, un tetto giornaliero di chiamate e un indicatore che dice se richiede approvazione. Quella tabella si scrive prima del primo prompt e si rivede a ogni modifica.
Tre test da eseguire su qualunque agente prima della produzione: provare a iniettare un’istruzione attraverso ogni canale di input non attendibile e verificare che non raggiunga mai uno strumento di scrittura; eseguire ogni strumento di scrittura con un argomento fuori intervallo e verificare che venga rifiutato lato server; e lanciare l’agente su un obiettivo impossibile e verificare che si fermi al tetto di budget invece di proseguire. Il metodo completo per questi test è nella nostra guida alla valutazione, e la struttura su cui tutto poggia è spiegata in Anatomia di un agente IA aziendale.
Domande frequenti
Che cos’è la Rule of Two di Meta?
Un framework di sicurezza pubblicato da Meta a novembre 2025 secondo cui un agente, all’interno di una singola sessione, dovrebbe soddisfare al massimo due proprietà su tre: elaborare input non attendibili, accedere a dati sensibili e poter modificare uno stato o comunicare verso l’esterno. Riunirle tutte e tre trasforma una singola prompt injection in una fuga di dati.
Si può prevenire completamente la prompt injection?
Non con i metodi disponibili oggi. Qualunque testo entri nel contesto compete per l’attenzione del modello, incluso quello di provenienza esterna. La difesa quindi non è la prevenzione ma la limitazione del danno: permessi minimi, separazione tra la lettura dell’input e l’esecuzione delle azioni, e approvazione umana per i passi irreversibili.
Qual è la differenza tra i permessi di un utente e quelli di un agente?
I permessi di un utente si verificano una volta al login e presuppongono un giudizio umano per tutta la sessione. Quelli di un agente vanno verificati a ogni chiamata, a livello di strumento e a livello di argomento, perché tra un passo e l’altro non c’è alcun giudizio umano. In pratica significa validazione lato server invece che fiducia nelle istruzioni date al modello.
Come si limita un agente senza renderlo inutile?
Dividere invece di bloccare. Un agente lettore che restituisce un riassunto strutturato, più un agente esecutore che agisce solo su quel riassunto, preserva l’intera capacità di business eliminando la combinazione pericolosa. Dove dividere è impossibile, aggiungete un punto di approvazione solo sull’azione in uscita.
Di chi dovrebbe essere il modello dei permessi?
Di chi ne porta le conseguenze se parte un’azione sbagliata — di solito il responsabile del processo di business, non il team di sviluppo. Il team tecnico lo implementa, ma decidere quali azioni sono irreversibili e quali richiedono approvazione è una decisione di business.
Per approfondire
Far girare agenti IA sulla vostra infrastruttura – Dove i confini dei permessi vengono davvero applicati, una volta che l’agente parla con strumenti reali.
Come valutare un agente prima di esporlo a un cliente – Il metodo per verificare che i confini reggano, esecuzione dopo esecuzione.