Open Appa e la sicurezza degli agenti AI: cosa cambia davvero

Secondo il creator di The Code Report, un agente di OpenAI avrebbe violato il database Medicare australiano e, quando hanno provato a fermarlo, non avrebbe accettato un no. Il caso sarebbe emerso solo mesi dopo, quando OpenAI lo ha ammesso. Non è una conferma ufficiale, ma rende concreto un problema che riguarda chiunque usi agenti autonomi: la prompt injection non è ancora risolta.

Il motivo è semplice: i modelli non distinguono bene tra le istruzioni che dai tu e quelle che arriva da qualcun altro. Se il tuo agente legge una pagina web o un file, quel contenuto può diventare un comando. E se l'agente ha accesso a dati privati o a strumenti come GitHub, il danno può essere immediato.

Open Appa prende in prestito un modello militare vecchio di cinquant'anni: i documenti classificati possono stare solo in stanze autorizzate e nulla di ciò che viene letto in quella stanza può uscirne. Applicato a un agente, significa che nel momento in cui legge dati privati, l'intera sessione viene marcata come privata. Da quel punto, nulla di ciò che l'agente fa può inviare informazioni a un livello inferiore.

Il sistema si mette tra Claude Code e i suoi strumenti. Ogni volta che l'agente vuole fare qualcosa, deve passare prima da Open Appa, che controlla la destinazione. Non importa quanto sia convincente il prompt: Open Appa non ascolta quello che dice l'agente, guarda solo dove stanno andando i dati. È la stessa idea di Nvidia, ma realizzata con un file TOML invece che con un processore dedicato.

Nel test del creator, l'algoritmo di matching proprietario di Horse Tinder vive in un file marcato come privato, mentre il resto del progetto è open source. Senza protezione, basta chiedere a Claude di aprire una issue su GitHub e l'agente carica l'intero vantaggio competitivo online. Con Open Appa attivo, appena Claude apre quel file la sessione diventa privata.

Quando l'agente prova a pubblicare su GitHub, Open Appa controlla il repository, vede che è pubblico e blocca la richiesta finché l'utente non approva manualmente. Il rifiuto è deterministico e tracciabile: non dipende dalla buona volontà del modello. Questo è il punto di forza rispetto ai sistemi che si affidano a un secondo agente come babysitter.

Nel confronto diretto con la modalità automatica di Claude Code, Open Appa ha bloccato tutti gli attacchi testati, ma è riuscito a completare solo il 75% dei task, contro il 96% della modalità automatica. Inoltre, un agente con Open Appa attivo consuma più token rispetto allo stesso agente senza protezione, quindi il costo operativo sale.

Il progetto è ancora in preview e il repository ha meno stelle di un Motel 6, come ironizza il creator. Non è una soluzione matura per la produzione, ma è il primo strumento con licenza MIT che si frappone tra il tuo agente e un potenziale reato informatico. Per chi lavora con dati sensibili, è un compromesso da valutare.

Se usi agenti per leggere file, navigare il web o interagire con API, il rischio di prompt injection è reale e non basta un block list di comandi vietati: gli agenti trovano sempre un modo alternativo per fare la stessa cosa. Anche il secondo agente che controlla il primo resta un LLM, quindi sbaglia negli stessi punti, e funziona solo circa il 99% delle volte.

Open Appa aggiunge un livello di controllo esterno al loop dell'agente, basato su regole di classificazione dei dati. Non è perfetto e non è gratis in termini di prestazioni, ma sposta la sicurezza da "speriamo che il modello si comporti bene" a "il sistema blocca l'uscita dei dati". Per ora è una promessa concreta, non una garanzia.