OpenAPA: una vecchia idea militare per bloccare la prompt injection negli agenti (senza nuovi chip)

Il problema reale: gli agenti non distinguono “chi comanda”

Gli agenti basati su LLM sono bravissimi a portare a termine task complessi, ma hanno una debolezza strutturale: faticano a separare le istruzioni dell’utente da input ostili infilati in contenuti esterni (pagine web, issue, email, log, documenti).

Quando un agente ha accesso a strumenti potenti (filesystem, GitHub, DB, browser, deploy, email), questa debolezza diventa pratica, non teorica: un prompt “iniettato” può convincerlo a esfiltrare segreti, modificare risorse, o aggirare i “no” dell’applicazione.

Perché le soluzioni più comuni non bastano

Negli ultimi anni l’industria ha provato più strade. Le due più diffuse hanno limiti prevedibili.

1) Blocklist di comandi/azioni

L’idea: mantenere una lista di operazioni vietate.

Il limite: gli agenti trovano facilmente equivalenti funzionali. Blocchi un comando, e l’agente ottiene lo stesso risultato con un percorso alternativo (un altro tool, un altro endpoint, un altro formato di output). È sicurezza “a whack-a-mole”.

2) Un secondo LLM che “fa da babysitter”

L’idea: un modello supervisiona l’altro e blocca azioni rischiose.

Il limite: è comunque un LLM. Quindi eredita lo stesso tipo di vulnerabilità (può essere confuso, manipolato, o “persuaso”). Anche introducendo separazioni (per esempio impedendo al supervisore di vedere certi contenuti), resta un approccio probabilistico: va bene per mitigare spam o contenuti borderline, meno per azioni con conseguenze irreversibili.

OpenAPA: policy deterministiche tra agente e strumenti

OpenAPA propone una terza via: invece di “convincere” l’agente a comportarsi bene, gli mette davanti un cancello.

L’idea è ispirata a un modello di sicurezza usato da decenni in contesti militari/classificati:

• i documenti hanno un livello di classificazione
• possono esistere solo in “stanze” abilitate a quel livello
• ciò che viene letto in una stanza classificata non può uscire in ambienti a classificazione inferiore

Trasportato sugli agenti:

1. Ogni risorsa e destinazione (file, repo, tool, endpoint) può avere una classificazione (es. private vs public).
2. La sessione dell’agente eredita il livello più alto dei dati che ha letto.
3. Da quel momento, qualunque azione che tenti di far uscire informazioni verso una destinazione “più bassa” viene bloccata o richiede approvazione.

Il punto chiave: OpenAPA non valuta la “bontà” delle intenzioni dell’LLM. Applica regole.

Perché questo approccio è interessante per chi fa frontend (e non solo)

Nei progetti moderni, specialmente in team frontend, l’agente viene spesso usato per:

• generare fix rapidi aprendo PR/issue
• scrivere changelog o note di rilascio
• leggere .env, token, config di CI
• interagire con repo pubblici e privati

È un mix tossico: dati sensibili + canali di output pubblici (issue tracker, paste, commenti, commit). Se la sessione legge un file segreto, qualsiasi successiva azione verso un target “public” dovrebbe essere considerata sospetta per definizione.

Con OpenAPA la protezione è indipendente dal prompt: anche una prompt injection “perfetta” non cambia le policy.

Un esempio concreto: il file privato che non deve finire in un’issue pubblica

Scenario tipico:

• repository in gran parte open source
• una porzione privata (algoritmo, chiavi, token, licenze, endpoint interni)
• l’agente viene incaricato di aprire un’issue su GitHub con una spiegazione tecnica

Senza controlli: l’agente potrebbe incollare interi blocchi di codice o file “segreti” nel testo dell’issue.

Con OpenAPA:

• appena l’agente legge un file marcato private, la sessione diventa private
• quando tenta di aprire un’issue su un repo pubblico, la policy intercetta la richiesta
• l’azione viene fermamente bloccata o messa in attesa di un via libera esplicito

Due dettagli utili in produzione:

• rifiuto deterministico: non dipende dall’umore del modello
• tracciabilità: sai quale regola ha bloccato cosa (fondamentale per audit e debugging)

Trade-off: sicurezza vs produttività (e costo in token)

Questo tipo di guardrail ha un prezzo.

• Riduce il completion rate su task “end-to-end” rispetto a modalità più permissive: più step richiedono conferme o vengono stoppati.
• Consuma più token: più controlli e più interazioni attorno alle policy possono aumentare il costo operativo.
• È un progetto giovane: va valutato con attenzione in base a maturità, ecosistema, integrazioni e qualità delle policy predefinite.

Detto questo, è una delle prime proposte che mette tra agente e strumenti un meccanismo chiaro: non “fidarti dell’LLM”, ma isola e applica policy.

Implicazione pratica

Se stai introducendo agenti nel workflow (anche solo per repo frontend), la domanda non è “quanto è bravo il modello?”, ma:

• quali dati può leggere?
• quali destinazioni può scrivere?
• cosa succede dopo che ha letto un segreto?

Un modello di classificazione a sessione, con enforcement esterno e deterministico, sposta la sicurezza da un piano “probabilistico” (prompt, filtri, supervisori) a uno “ingegneristico” (policy, livelli, blocchi, audit). In altre parole: meno psicologia del modello, più controllo dei confini. È un cambio di paradigma che vale la pena tenere d’occhio mentre gli agenti diventano sempre più autonomi.