🤖 AI

LACUNA: Safe Agents as Recursive Program Holes

LACUNA è un modello di programmazione sicuro per agenti LLM che tratta le azioni come buchi di programma tipizzati riempiti dal modello e validati tramite controllo statico dei tipi prima dell'esecuzione, unificando così il flusso di controllo dell'agente con il codice generato mentre previene i fallimenti a runtime e delimita l'accesso agli strumenti.

Autori originali: Yaoyu Zhao, Yichen Xu, Oliver Bračevac, Cao Nguyen Pham, Frank Zhengqing Wu, Martin Odersky

Pubblicato 2026-05-28

📖 6 min di lettura🧠 Approfondimento

CC BY 4.0

Autori originali: Yaoyu Zhao, Yichen Xu, Oliver Bračevac, Cao Nguyen Pham, Frank Zhengqing Wu, Martin Odersky

Articolo originale sotto licenza CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Questa è una spiegazione generata dall'IA dell'articolo qui sotto. Non è stata scritta né approvata dagli autori. Per precisione tecnica, consulta l'articolo originale. Leggi il disclaimer completo

Immagina di essere il CEO di un'azienda e di assumere un assistente brillante ma leggermente inaffidabile (l'IA) per svolgere il tuo lavoro.

Il Vecchio Metodo (Agenti Attuali):
Di solito, dai all'assistente un'istruzione specifica e minuscola: "Chiama la compagnia telefonica". L'assistente fa esattamente questo, poi si ferma e attende il tuo prossimo comando. Tu tieni il blocco note, decidi l'ordine dei compiti e conservi le chiavi dell'ufficio. L'assistente non può decidere di chiamare invece la banca o di riscrivere le regole dell'ufficio, perché ha a disposizione un solo pulsante da premere alla volta.

Il Problema:
A volte, l'assistente si confonde a causa di una nota ingannevole che hai scritto (una "iniezione di prompt"), oppure si ferma a metà di un compito e commette un errore, lasciando l'ufficio in uno stato disordinato e inconsistente. Poiché all'assistente è consentito solo premere pulsanti, non può distruggere l'edificio, ma può comunque causare un grande caos all'interno della stanza in cui si trova.

Il Nuovo Metodo (LACUNA):
Il documento introduce LACUNA, che modifica la relazione. Invece di dare all'assistente un singolo pulsante da premere, gli dai uno spazio vuoto in un contratto (un "buco tipizzato") e dici: "Riempi questo spazio con il codice necessario per risolvere questo problema, ma deve adattarsi perfettamente al nostro contratto legale".

Ecco come funziona, utilizzando analogie semplici:

1. Il "Contratto Magico" (Buchi Tipizzati)

Immagina di avere un contratto che recita: "Il risultato finale di questa sezione deve essere un Elenco di Numeri".

Chiedi all'IA: "Vai a trovare i numeri primi in questo elenco".
L'IA scrive un intero paragrafo di istruzioni (codice) per risolverlo.
Il Controllo di Sicurezza: Prima che all'IA sia consentito effettivamente fare qualcosa, un rigoroso Ispettore (il compilatore) verifica il paragrafo dell'IA.
- Il paragrafo produce effettivamente un "Elenco di Numeri"? Se l'IA tenta di restituire un "Elenco di Mele", l'Ispettore lo rifiuta immediatamente.
- Ha tentato di utilizzare uno strumento che non le è consentito toccare? (ad esempio, tentare di aprire un file per cui non possiede la chiave). Anche questo viene rilevato dall'Ispettore.
- Il Risultato: Se l'IA commette un errore, il contratto viene rifiutato prima che avvenga qualsiasi azione. L'ufficio rimane pulito. L'IA riceve l'avviso di rifiuto, riprova e scrive un paragrafo migliore.

2. La Regola "Tutto o Niente"

Nel vecchio metodo, se un'IA tentasse di "Eliminare un file" e poi "Calcolare una somma", e il calcolo fallisse, il file potrebbe essere già stato eliminato.
In LACUNA, è come un singolo blocco di argilla indivisibile.

L'IA scolpisce l'intero blocco.
L'Ispettore verifica l'intero blocco in una sola volta.
Se qualsiasi parte della scultura è errata (la forma sbagliata, il materiale sbagliato), l'intero blocco viene scartato. Non accade nulla. L'ufficio rimane esattamente com'era prima che l'IA iniziasse. Questo previene disastri "a metà".

3. Il "Portachiavi" (Capacità)

Il documento parla anche delle Capacità. Immagina che all'IA venga fornito un set specifico di chiavi (un portachiavi) per il lavoro.

Se il lavoro è "Leggi il menu", l'IA riceve la "Chiave del Menu".
Se il lavoro è "Invia un'email", l'IA riceve la "Chiave dell'Email".
Anche se l'IA viene ingannata da una nota cattiva che dice: "Usa la Chiave Bancaria per rubare denaro", fisicamente non può farlo. Non ha la Chiave Bancaria nella tasca. L'Ispettore verifica il suo portachiavi prima che le sia consentito girare la chiave nella serratura.
Ciò significa che anche se un hacker inganna l'IA tentando di farle fare qualcosa di male, l'IA letteralmente manca delle "chiavi" per aprire quelle porte.

4. Le "Bambole Matryoshka Annidate" (Ricorsione)

L'IA può scrivere codice che include ulteriori istruzioni per se stessa.

Chiedi: "Scrivi un rapporto su tre argomenti".
L'IA scrive un piano che dice: "Prima, chiederò all'IA di ricercare l'Argomento A, poi l'Argomento B, poi l'Argomento C, e infine li combinerò".
Ciascuna di queste richieste più piccole è anch'essa un "buco" che viene verificato dall'Ispettore prima dell'esecuzione. È come un set di bambole russe annidate, dove ogni singola bambola viene ispezionata prima che le sia consentito aprirsi.

Cosa il Documento Ha Effettivamente Scoperto

I ricercatori hanno testato questo sistema (LACUNA) utilizzando un linguaggio di programmazione chiamato Scala 3.

Sicurezza: Hanno scoperto che l'Ispettore ha intercettato circa l'8,6% dei tentativi dell'IA prima che potessero essere eseguiti. Si trattava di tentativi che avevano la forma sbagliata o che tentavano di utilizzare strumenti per cui l'IA non aveva l'autorizzazione.
Riprova: Quando l'IA commetteva un errore, il sistema le chiedeva di riprovare. In media, sono state necessarie solo 0,7 tentativi per ottenere una risposta valida.
Prestazioni: Il sistema ha risolto circa il 27% dei compiti di ricerca difficili e il 76% dei compiti di assistenza clienti. Questo è stato approssimativamente lo stesso degli altri agenti IA standard, dimostrando che l'aggiunta di questo rigoroso controllo di sicurezza non ha reso l'IA "più stupida", ma solo più sicura.
Sicurezza: Hanno testato il sistema contro hacker che tentavano di ingannare l'IA (iniezione di prompt). Poiché l'IA era limitata dal suo "portachiavi" (capacità), gli hacker non potevano indurre l'IA a compiere azioni al di fuori del suo ambito consentito, anche se riuscivano con successo a ingannarla nel tentare di farlo.

La Contropartita (Limitazioni)

Il documento ammette alcune cose:

Non è perfetto: L'Ispettore verifica se l'IA ha seguito le regole (ha usato gli strumenti giusti? ha restituito il tipo di risposta corretto?), ma non verifica se l'IA ha fatto la cosa giusta logicamente. Se l'IA scrive un codice perfetto che calcola la matematica sbagliata, l'Ispettore lo lascia passare.
Richiede un'IA intelligente: Se l'IA non è molto brava a scrivere codice, verrà rifiutata spesso e il processo sarà lento.
È più lento: Poiché il sistema deve fermarsi, verificare e ricontrollare il codice ogni volta, richiede più tempo e potenza di calcolo rispetto al semplice lasciare che l'IA prema un pulsante.

In sintesi: LACUNA trasforma l'IA da un premipulsanti in un appaltatore che deve presentare un piano completo per l'approvazione prima di svolgere qualsiasi lavoro. Se il piano viola le regole, il lavoro non inizia mai, mantenendo il sistema al sicuro da errori e trucchi.

Riepilogo Tecnico: LACUNA: Agenti Sicuri come Buchi di Programma Ricorsivi

Enunciato del Problema

Gli attuali agenti basati su Modelli Linguistici (LLM) affrontano una divisione architetturale fondamentale tra il runtime che guida il ciclo dell'agente e il codice scritto dal modello. Negli approcci dominanti come ReAct, il runtime possiede il flusso di controllo, la gestione del contesto e la distribuzione degli strumenti, mentre il modello si limita a emettere singole chiamate agli strumenti o passaggi di ragionamento. Negli agenti "codice come azione", il modello scrive codice per comporre strumenti e logica, ma questo codice rimane distinto dal runtime.

Questa separazione crea un dilemma di sicurezza. Se il runtime controlla rigorosamente il ciclo, l'agente manca di espressività. Se il modello modella il runtime stesso per aumentare l'espressività, i rischi per la sicurezza si intensificano: un modello deviato da un'iniezione di prompt, un errore di chiamata agli strumenti o un fallimento parziale possono lasciare l'ambiente in uno stato inconsistente o compromettere il runtime. Le difese esistenti (sandbox, interpreti limitati, linguaggi di policy) sono spesso frammentarie, operando a runtime o sugli input, e nessuna verifica un'azione generata intera rispetto al contesto del programma circostante prima dell'inizio dell'esecuzione.

Metodologia: LACUNA

Gli autori propongono LACUNA, un modello di programmazione che colma la divisione tra runtime dell'agente e codice scritto dal modello, preservando la sicurezza attraverso la tipizzazione statica. Il primitivo fondamentale è un "buco" tipizzato nel programma host:

def agent[T](task: String): T

Meccanismo Principale

Buchi Tipizzati: Una chiamata all'agente funge da segnaposto dove il programma circostante si aspetta staticamente un valore di tipo T. L'LLM viene sollecitato a generare codice Scala che produce tale valore.
Compilazione Consapevole del Contesto: Quando l'esecuzione raggiunge la chiamata agent, l'LLM genera codice basato sul task in linguaggio naturale, sul tipo atteso T e sullo scope lessicale attivo (variabili, funzioni, strumenti e importazioni disponibili in quel punto specifico).
Verifica Pre-Esecuzione: Il codice generato viene compilato dal compilatore host (Scala 3) nel contesto del programma circostante prima che venga mai eseguito.
- Controllo dei Tipi: Il codice deve produrre un valore di tipo T.
- Controllo dello Scope: Tutti i nomi utilizzati devono essere nello scope.
- Controllo delle Capacità: Se abilitato, il controllo di acquisizione garantisce che il codice acceda solo alle risorse (file, rete, strumenti) esplicitamente concesse nello scope lessicale.
Esecuzione Tutto-o-Niente: Se il codice supera tutti i controlli, viene eseguito. Se fallisce (ad esempio, mismatch di tipo, strumento mancante, accesso non autorizzato), l'intero frammento viene rifiutato. Non si verifica alcuna esecuzione parziale, prevenendo stati inconsistenti. I diagnostici del compilatore vengono restituiti all'LLM per guidare un ciclo di riprova.

Implementazione

Il prototipo è costruito in Scala 3, sfruttando due caratteristiche specifiche:

Ricompilazione in-process: La capacità di invocare il compilatore all'interno di un programma in esecuzione per unire e compilare una stringa di codice sorgente contro il contesto corrente.
Controllo di Acquisizione (Capture Checking): Un meccanismo per tracciare quali effetti e risorse un frammento di codice è autorizzato a utilizzare, applicando la sicurezza basata sulle capacità.

Il primitivo agent è un sottile wrapper attorno a un'operazione eval di livello inferiore. Gestisce la costruzione del prompt (incluso il sorgente racchiudente e i legami disponibili), chiama l'LLM, passa il risultato a eval e gestisce il ciclo di riprova in caso di fallimento della compilazione.

Contributi Chiave

Un Modello Codice-come-Azione con Garanzie Statiche: Un modello in cui l'LLM scrive azioni come codice che viene eseguito come parte del proprio runtime, verificato nel punto di chiamata prima dell'esecuzione.
Analisi di Sicurezza: Dimostra che il rifiuto pre-esecuzione di nomi non disponibili e mismatch di tipo, combinato con un'esecuzione atomica (nessuna esecuzione parziale), fornisce forti garanzie di sicurezza. Dimostra inoltre come la delimitazione delle capacità limiti l'autorità e il flusso di informazioni dell'agente.
Espressività tramite Flusso di Controllo Ordinario: Mostra che chiamate annidate all'agente e costrutti di codice standard possono esprimere pattern complessi di agenti (cicli ReAct, sub-agent, abilità, decomposizione parallela, pianificazione multi-modello) senza la necessità di un protocollo di agente separato.
Valutazione Empirica: Una realizzazione in Scala 3 valutata su casi di test di verifica, BrowseComp-Plus (ricerca di informazioni difficile) e $\tau^2$ -bench (conversazioni multi-turno con uso di strumenti).

Risultati

La valutazione evidenzia il compromesso tra sicurezza, espressività e capacità del modello:

Sicurezza e Tassi di Rifiuto: Su BrowseComp-Plus, l'8,6% delle generazioni è stato rifiutato prima dell'esecuzione a causa di errori di tipo o di scope. Il sistema ha mediato 0,7 riprove per query, con un tasso di successo di compilazione end-to-end del 91,4%. Ciò conferma che il compilatore blocca efficacemente azioni mal tipizzate o fuori scope.
Prestazioni su Compiti Complessi:
- BrowseComp-Plus: Utilizzando il modello deepseek-flash, LACUNA ha raggiunto un'accuratezza del 27,1%, paragonabile agli agenti baseline, guidando al contempo una ricerca genuina multi-step (media di 5,9 round, 15,5 ricerche).
- $\tau^2$ -bench: Su 392 compiti in quattro domini (Retail, Airline, Telecom, Tel.-WF), LACUNA ha risolto il 76,0% dei compiti con un modello capace, performando alla pari di un agente di chiamata strumenti di riferimento.
Dipendenza dal Modello: Il successo del sistema dipende fortemente dalla capacità di codifica del modello. Modelli più deboli (ad esempio gemini-3.1-flash-lite) hanno faticato con domini complessi (ad esempio, tasso di rifiuto dell'89% nelle telecomunicazioni), portando a tassi di risoluzione inferiori. La garanzia di sicurezza vale indipendentemente dalla competenza del modello (i tentativi infruttuosi non vengono mai eseguiti), ma il progresso si arresta se il modello non può generare codice valido.
Robustezza Adversariale: Nei test di iniezione di prompt (AgentDojo), il livello di capacità ha confinato con successo le azioni dell'agente al suo scope concesso. Anche quando influenzato da contenuti iniettati, l'agente non ha potuto accedere a risorse esterne al suo scope lessicale.

Significato e Affermazioni

Il documento posiziona LACUNA non come una sostituzione per le architetture di agenti esistenti, ma come una base più sicura e flessibile.

Unificazione di Esecuzione e Ragionamento: Fondendo l'esecuzione del programma e il ragionamento del modello in un unico processo in cui il modello scrive il flusso di controllo, LACUNA permette agli agenti di essere più espressivi mantenendo le garanzie di sicurezza del linguaggio host.
Sicurezza tramite Compilazione: Il contributo principale è lo spostamento della sicurezza dalle sandbox runtime alla verifica statica pre-esecuzione. Un frammento rifiutato lascia l'ambiente intatto, e i diagnostici del compilatore guidano l'autocorrezione.
Sicurezza delle Capacità: Il sistema dimostra che il "minimo autorizzato" può essere imposto attraverso lo scope lessicale e il controllo di acquisizione, limitando ciò che un modello avversario o errato può fare anche se influenzato da iniezione di prompt.
Limitazioni Modeste: Gli autori riconoscono che "ben tipizzato" non significa "corretto" (gli errori semantici non vengono rilevati), che il sistema si affida alla competenza di codifica del modello (che varia per linguaggio e dominio), e che l'esaurimento delle risorse (latenza, ricorsione infinita) deve essere gestito tramite budget runtime piuttosto che sistemi di tipi.

In sintesi, LACUNA propone che trattare le azioni degli agenti come buchi tipizzati in un linguaggio host staticamente tipizzato permetta un design di agenti ricorsivo ed espressivo, dove la sicurezza è garantita dalla correttezza del compilatore piuttosto che da euristiche runtime.