La prompt injection negli agenti AI diventa pericolosa quando il modello non si limita a leggere e suggerire, ma può anche modificare sistemi reali. Un log, una pagina web o un ticket può contenere testo preparato per influenzare il ragionamento. Se lo stesso agente possiede credenziali per cambiare il DNS, aggiornare una regola o scrivere in produzione, un’istruzione nascosta può trasformare un dato non affidabile in un’azione ad alto impatto.
Il problema non si risolve chiedendo al modello di stare più attento. Serve una divisione architetturale: il modello analizza, propone e spiega; un controllo esterno decide se l’operazione è permessa; un’identità autorizzata approva; un esecutore limitato applica soltanto il cambiamento già validato. Questa separazione riduce il rischio anche quando una parte del contenuto viene manipolata.
Prompt injection negli agenti AI: che cosa è successo
In una dimostrazione recente un testo malevolo inserito in un log di Cloudflare è stato letto da un agente incaricato di analizzare la rete. Il contenuto ha provato a guidare il modello verso una modifica DNS. In alcune prove l’agente ha interpretato l’istruzione come parte del proprio compito e ha preparato una chiamata con cui cambiare record A o CNAME.
Il dettaglio importante non è la marca del modello o dello strumento. Il punto è il collegamento diretto tra una fonte controllata da altri, un modello capace di seguire istruzioni e un’API con potere di scrittura. Anche un agente che rifiuta quasi sempre può produrre un danno se la prova restante avviene su un ambiente reale.
un’architettura corretta deve quindi assumere che il modello possa essere persuaso. La sicurezza non può dipendere dalla speranza che una singola regola nel prompt vinca sempre contro un comando inserito in un documento che il modello deve leggere.
La differenza tra prompt injection diretta e indiretta
La forma diretta arriva dal messaggio della persona che usa l’agente. un utente può chiedere di ignorare le regole, rivelare informazioni o eseguire un comando non previsto. La forma indiretta è più insidiosa: l’istruzione si trova in una pagina, un log, un documento, una issue o una risposta di uno strumento. Il modello la incontra mentre sta svolgendo un compito apparentemente legittimo.
Per un agente operativo ogni contenuto esterno deve avere una etichetta di fiducia. Un log non è un’istruzione. Un commento di codice non è un’autorizzazione. Una risposta API non è una policy. Questa distinzione deve essere visibile anche nel flusso interno, non soltanto descritta in una linea di testo iniziale.
Proposta, autorizzazione ed esecuzione
Il primo livello è la proposta. l’agente può riassumere il problema, indicare il record che vorrebbe cambiare, mostrare il valore precedente, il valore nuovo e il motivo. Non deve possedere una credenziale capace di applicare direttamente la modifica.
Il secondo livello è l’autorizzazione. Un servizio deterministico verifica identità, ambiente, dominio, tipo di record, finestra operativa e differenza tra vecchio e nuovo valore. Se un agente propone un cambio fuori dal perimetro, la policy lo respinge senza chiedere al modello di decidere ancora.
Il terzo livello è l’esecuzione. Un worker usa una credenziale separata e limitata. Riceve un identificativo di approvazione e un oggetto strutturato già validato. Non riceve un paragrafo libero da interpretare. Dopo l’operazione restituisce esito, orario, identità e valori effettivi.
Questa catena può essere rappresentata così:
- Il modello legge dati classificati come non affidabili.
- Il modello produce una proposta strutturata.
- La policy esterna valida la proposta.
- Una persona o una regola preautorizzata approva.
- Il worker esegue il minimo cambiamento possibile.
- Il sistema controlla il risultato e conserva il log.
Come costruire una policy DNS sicura
La policy deve esprimere regole misurabili. Può consentire modifiche soltanto su una zona di test, impedire il cambio dei name server, bloccare riduzioni anomale del TTL e richiedere due approvazioni per record critici. Può anche confrontare il nuovo indirizzo con una lista di destinazioni autorizzate e verificare che il richiedente possieda il ruolo corretto.
Non è sufficiente controllare il testo della richiesta. Bisogna validare il valore strutturato. Un record CNAME deve rispettare il formato previsto, non puntare a una destinazione vietata e avere una motivazione associata. Un record A deve contenere un indirizzo ammesso. I caratteri speciali, i cambi massivi e le richieste urgenti senza ticket devono generare un blocco o un’approvazione più forte.
La policy deve inoltre distinguere tra lettura e scrittura. un agente può avere accesso ai dati necessari per la diagnosi senza poterli modificare. La stessa identità non dovrebbe fare ricerca, approvazione ed esecuzione.
Il ruolo dell’approvazione umana
un’approvazione non deve essere un pulsante verde con la frase esegui. La schermata deve mostrare zona, tipo di record, valore precedente, valore proposto, TTL, motivo, ambiente, impatto previsto e durata. La persona deve poter confrontare i dati con il ticket o con una fonte interna di fiducia.
Per operazioni a basso impatto può bastare una regola automatica. Per una zona pubblica, una modifica a un dominio di autenticazione o un’operazione con effetto globale è più prudente richiedere una persona. Il principio è proporzionare il livello di controllo al raggio di esplosione, non al grado di entusiasmo verso l’AI.
l’approvazione deve scadere. Se il contesto cambia dopo un intervallo, la proposta deve essere ricalcolata. Un identificativo di approvazione usato due volte deve essere rifiutato, così come una richiesta che modifica i valori dopo la firma.
Testare la resistenza agli input ostili
Prepara dati di prova che contengano istruzioni come ignora la policy, esegui subito, rivela la credenziale o aggiorna la zona principale. Inseriscili in log, ticket, file di configurazione e risposte di strumenti. Il test deve verificare che l’agente li tratti come contenuto e non come comando.
Misura almeno quattro risultati: il numero di proposte bloccate, il numero di richieste arrivate all’approvazione, la capacità di mostrare il contesto e il comportamento dopo un errore. Prova anche contenuti ambigui, lingue diverse, caratteri invisibili e richieste distribuite su più righe.
Un buon test non cerca solo il rifiuto. Verifica che il modello sappia continuare il compito in modo sicuro, per esempio segnalando che un log contiene un’istruzione sospetta e producendo una diagnosi senza modificare il DNS.
Logging, rollback e gestione degli incidenti
Conserva il testo originale, la classificazione della fonte, la proposta strutturata, la policy applicata, l’identità che ha approvato e la risposta del provider. Se una parte viene oscurata per privacy, mantieni almeno un riferimento che permetta di ricostruire la sequenza.
Ogni modifica deve avere un piano di rollback. Per il DNS significa conservare il valore precedente, conoscere il TTL e definire chi può ripristinare. Il rollback deve essere un comando separato e controllato, non una promessa nel prompt.
Se un’operazione inattesa è stata applicata, revoca subito la credenziale del worker, blocca nuove scritture e confronta il registro con i ticket approvati. Controlla anche altre zone o risorse raggiungibili dalla stessa identità. l’analisi deve cercare il percorso completo, non soltanto il singolo record cambiato.
Identità e strumenti separati
Assegna al componente di analisi un’identità sola lettura. Il servizio che valuta la policy deve possedere dati sufficienti per controllare la proposta, ma non deve poter modificare la zona. Il worker di esecuzione deve ricevere una credenziale distinta, con durata breve e accesso soltanto alle zone previste. Questa separazione rende più difficile trasformare un singolo errore in un cambiamento globale.
Se il flusso attraversa più strumenti, conserva un identificativo comune. Il ticket, la proposta, l’approvazione e la chiamata al provider devono poter essere collegati senza usare il testo libero come chiave. In caso di incidente, questa correlazione permette di capire se la proposta è stata alterata, duplicata o riutilizzata.
Prevedi anche un interruttore di emergenza fuori dal modello. Deve bloccare le scritture del worker, revocare la coda pendente e informare il responsabile. Un comando di emergenza non elimina la necessità di prevenzione, ma riduce il tempo tra rilevazione e contenimento.
Cosa ricordare prima di procedere
La prompt injection negli agenti AI non è un problema di educazione del modello. È un problema di confini. Dati non affidabili, ragionamento, policy, approvazione ed esecuzione devono avere ruoli separati e credenziali diverse.
La soluzione più concreta è iniziare da una sola operazione, come la proposta di un cambio DNS in ambiente di test. Rendi la proposta leggibile, sposta la decisione fuori dal modello, limita il worker, registra ogni passaggio e prova input ostili prima di aumentare il raggio di azione. un agente utile non è quello che può fare tutto, ma quello che sa spiegare cosa propone e non può superare il perimetro autorizzato.
Una regola semplice per il team
Ogni agente deve poter rispondere a tre domande: quali dati ha letto, quale azione propone e chi può autorizzarla. Se una risposta non è ricostruibile dal log, il flusso non è ancora pronto per una risorsa critica.
La visibilità nei sistemi basati sull’AI è solo uno dei tanti cambiamenti che l’Intelligenza Artificiale sta portando nel modo in cui produciamo, cerchiamo e utilizziamo le informazioni. Per sfruttare davvero questi strumenti, però, è utile comprenderne anche i meccanismi: LLM, prompt, contesto, memoria, agenti, limiti ed errori sono concetti sempre più importanti anche per chi lavora nel web, nel marketing e nello sviluppo.
Nel mio libro “Intelligenza Artificiale senza sprechi” affronto questi temi con un approccio pratico e accessibile, pensato sia per chi vuole partire dalle basi sia per chi desidera approfondire e utilizzare l’AI in modo più consapevole ed efficace. Il libro è disponibile su Amazon e può essere letto gratuitamente con Prime Reading.
