💻 computer science

Delegation-Aware Runtime Contracts for Open LLM Multi-Agent Systems: Constraint Preservation, Capability Revocation, and State Recovery

Questo articolo introduce i Delegation-Aware Runtime Contracts (DARC), un framework formale che tratta il trasferimento di autorità nei sistemi multi-agente LLM come un processo verificabile da una macchina per imporre la preservazione dei vincoli, la revoca delle capacità e il ripristino dello stato attraverso una mediazione deterministica a runtime, affrontando così i rischi di sicurezza derivanti dal trattare la delega come mero linguaggio naturale.

Autori originali: Vinay Bamil

Pubblicato 2026-08-13

📖 8 min di lettura🧠 Approfondimento

CC BY 4.0

Autori originali: Vinay Bamil

Articolo originale sotto licenza CC BY 4.0 (https://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 un mondo in cui non parli solo con un singolo robot intelligente, ma con un intero team di loro che lavorano insieme. In questo mondo, un robot "manager" potrebbe dire: "Ehi, tu vai a trovare il miglior prezzo per un nuovo laptop", e poi quel robot potrebbe dire a un terzo robot: "Tu vai a controllare i siti web". Questo è chiamato un sistema multi-agente. È come una staffetta digitale dove il testimone è un compito. Ma ecco la parte difficile: quando il primo robot passa il compito al secondo, di solito gli sussurra le istruzioni in linguaggio naturale. Se il primo robot dice: "Non spendere più di 500 dollari", il secondo robot potrebbe sentire "Trova un laptop" e dimenticarsi completamente del limite di prezzo. Questo accade perché i computer sono bravissimi a seguire le regole, ma non sono sempre bravi a ricordare i dettagli importanti quando passano una conversazione lungo la catena. Gli scienziati sono preoccupati che, se lasciamo che questi team di robot corrano allo sregolate senza regole migliori, potrebbero accidentalmente spendere tutti i nostri soldi, far trapelare i nostri segreti o fare cose che non abbiamo mai chiesto loro di fare.

Questo articolo introduce un nuovo modo per gestire questi passaggi di consegne tra robot, chiamato DARC (Delegation-Aware Runtime Contracts - Contratti di Esecuzione Consapevoli della Delega). Immagina che sia come dare ai robot uno zaino speciale e indistruttibile invece di un semplice sussurro. Ogni volta che un robot passa un compito a un altro, non dice solo "vai"; consegna un contratto digitale all'interno di quello zaino. Questo contratto elenca esattamente cosa il nuovo robot è autorizzato a fare, cosa non può fare, quanto denaro può spendere e quando il suo lavoro scade. L'articolo dimostra che, se si utilizzano questi contratti, si può provare matematicamente che il nuovo robot non può improvvisamente ottenere più potere di quello che aveva l'originale, e non può dimenticare i limiti di budget. L'autore ha costruito un sistema per controllare questi zaini automaticamente. Ha scoperto che, senza questi contratti, le regole spesso scompaiono man mano che i compiti vengono passati, ma con essi, le regole rimangono bloccate. Tuttavia, l'articolo avverte che, mentre le parti "matematiche" (come i limiti di denaro o di tempo) sono perfettamente sicure, le parti che richiedono la comprensione del significato del linguaggio umano (come "sii educato") sono ancora un po' complicate e necessitano di ulteriori test.

Il Problema: Il "Telefono Senza Fili" dei Team di Robot

Immagina di giocare al gioco del "Telefono" con un gruppo di amici. Sussurri un segreto alla prima persona, che lo sussurra alla successiva, e così via. Quando arriva all'ultima persona, il segreto è solitamente cambiato. Magari "Non mangiare la torta" diventa "Mangia la torta!".

Nel mondo dell'IA, questo è esattamente ciò che accade quando un team di agenti basati su Large Language Model (LLM) lavora insieme. Un agente (il capo) assegna un compito a un altro agente (l'operaio). Il capo potrebbe dire: "Trova un fornitore, ma non spendere più di 1.000 dollari e non mostrare a nessuno la nostra lista dei dipendenti". L'operaio sente questo e passa il compito a un terzo agente (il navigatore web). Ma poiché il messaggio è solo testo semplice, il terzo agente potrebbe sentire solo: "Trova un fornitore". Il limite di budget e la regola sulla privacy sono svaniti nel nulla!

Questo è pericoloso. Se un team di robot sta gestendo il budget di un'azienda o gestendo dati privati, perdere quelle regole significa che i robot potrebbero accidentalmente spendere milioni o far trapelare segreti. Il problema non è che i robot siano "cattivi"; è che il modo in cui si parlano tratta le regole di sicurezza importanti come suggerimenti opzionali piuttosto che come leggi ferree.

La Soluzione: Lo Zaino Indistruttibile (DARC)

L'autore di questo articolo, guidato da Vinay Bamil, propone una soluzione chiamata DARC. Invece di passare semplicemente un messaggio di testo, ogni volta che un agente delega un compito, deve consegnare un Contratto di Delega.

Pensa a questo contratto come a uno zaino speciale e indistruttibile che arriva con il compito. All'interno di questo zaino, ci sono etichette chiare e leggibili dalle macchine che dicono:

Cosa puoi fare: (es. "Puoi controllare i prezzi, ma non puoi acquistare nulla.")
Cosa non puoi fare: (es. "Non puoi consultare i record dei dipendenti.")
Il budget: (es. "Hai esattamente 500 dollari rimasti da spendere.")
La scadenza: (es. "Questo compito è valido solo per 1 ora.")
La cronologia: (es. "Questo compito proviene dall'Agente A, che l'ha ricevuto dal Capo.")

La magia di DARC è che tratta queste regole come matematica, non solo come parole. Quando un robot cerca di passare un compito a un nuovo robot, un "Mediatore" (un guardiano della sicurezza) controlla lo zaino. Se il nuovo robot prova a prendere una regola che non era presente prima, o se prova ad aggiungere un nuovo potere che non aveva, il guardiano dice: "No!" e blocca il passaggio.

Come Funziona: Il Guardiano della Sicurezza e lo Zaino

Il sistema funziona in tre fasi principali, come un controllo di sicurezza in un aeroporto:

Il Passaggio di Consegne (Mediatore): Quando l'Agente A vuole dare un compito all'Agente B, il Mediatore controlla lo zaino. Si assicura che l'Agente B non stia chiedendo più potere di quello che aveva l'Agente A. Se l'Agente A aveva un budget di 500 dollari, l'Agente B non può avere un budget di 600 dollari. Se l'Agente A aveva una regola su "nessun dato dei dipendenti", l'Agente B deve mantenere quella regola. Lo zaino viene costruito prima che il compito venga passato, rendendo impossibile dimenticare le regole.
L'Azione (Gateway): Quando l'Agente B prova effettivamente a fare qualcosa (come comprare un laptop o leggere un file), il Gateway controlla nuovamente lo zaino. Chiede: "Hai il permesso di farlo? Hai abbastanza budget rimasto? È permesso leggere questo dato?". Se la risposta è no, l'azione viene bloccata immediatamente.
La Pulizia (Incident Controller): E se un robot venisse hackerato o impazzisse? Il sistema può "revocare" lo zaino. Se il Capo dice: "Ferma l'Agente B!", il sistema non si limita a fermare l'Agente B; traccia la cronologia dello zaino. Trova ogni robot a cui l'Agente B ha passato un compito e ferma anche loro. Inoltre, mette in quarantena i dati che quei robot hanno toccato, assicurandosi che l'"infezione" non si diffonda.

Cosa ha Scoperto l'Autore (e Cosa Non Ha Scoperto)

L'autore ha costruito un prototipo di questo sistema e lo ha testato rigorosamente. Ecco cosa ha scoperto:

La Matematica Funziona: Ha dimostrato che, se si utilizzano questi contratti, le regole non possono essere accidentalmente abbandonate. Se un budget è impostato a 500 dollari, rimane 500 dollari (o meno), indipendentemente da quante volte il compito viene passato. Ha scoperto che, senza questo sistema, le regole spesso scompaiono dopo solo pochi passaggi.
Il Bug di "Omissione": Durante i test, ha trovato un bug subdolo. Si è reso conto che se un robot genitore dimenticava di scrivere un limite specifico (come un numero di budget), il robot figlio poteva pensare di avere denaro illimitato. Ha risolto il problema stabilendo una nuova regola: se un limite manca, il sistema deve assumere il limite più rigido possibile (come 0 dollari) per essere al sicuro. Questa è una grande lezione per costruire IA sicure.
Il Problema del "Significato": Il sistema è perfetto nel controllare numeri, date e regole chiare. Ma non è perfetto nel comprendere le sfumature del linguaggio umano. Ad esempio, se una regola dice "Sii educato", il sistema non può provare matematicamente se un robot è stato educato o meno. L'autore ammette che, per queste regole "basate sul significato", il suo sistema è solo un monitoraggio a "tentativo ed errore", non una garanzia perfetta. È onesto su questo: può provare che la matematica funziona, ma non può ancora provare che la "politezza" funzioni.
I Test: Ha condotto uno studio pilota per vedere quanto bene un giudice automatizzato potesse individuare questi errori. Tuttavia, il giudice non ha ancora superato il loro test di accordo rigoroso. Pertamente, non stanno sostenendo di aver risolto il problema della "politezza", ma stanno solo mostrando che il loro sistema può tracciare questi problemi e che sono necessari ulteriori test.

Perché Questo è Importante

Questo articolo è un ponte tra due mondi: il vecchio mondo della sicurezza informatica rigorosa (dove le regole sono dure e indistruttibili) e il nuovo mondo dei team di IA flessibili (dove i robot parlano in linguaggio naturale).

L'autore dimostra che non possiamo lasciare che i robot IA parlino liberamente tra loro se vogliamo che siano sicuri. Dobbiamo dare loro un "contratto" che viaggi con il compito. Ciò assicura che, anche se i robot sono loquaci e creativi, non possano rompere le regole che abbiamo stabilito per loro.

Sebbene il sistema non sia ancora perfetto (specialmente per la comprensione dei significati umani complessi), fornisce una solida base. Dimostra che possiamo costruire team di IA che siano potenti ma anche sicuri, proteggendo i nostri soldi e i nostri segreti, trattando ogni passaggio non come un semplice sussurro nel buio, ma come un serio contratto controllato.

Sintesi Tecnica: Contratti di Runtime Sensibili alla Delega per Sistemi Multi-Agente Open LLM

Definizione del Problema
Gli attuali sistemi multi-agente basati su Large Language Models (LLM) delegano frequentemente compiti, generano sotto-agenti e condividono la memoria. Tuttavia, i controlli di sicurezza sono tipicamente applicati ai singoli agenti o ai modelli di comunicazione, piuttosto che al trasferimento dell'autorità stesso. Il documento sostiene che trattare la delega come ordinario testo in linguaggio naturale sia un errore fondamentale di modellazione. In questo paradigma, gli obiettivi tendono a sopravvivere a ripetuti passaggi di consegna, mentre i vincoli critici — come budget, restrizioni sui dati, obblighi e condizioni di revoca — tendono a indebolirsi o a scomparire man mano che vengono parafrasati dai modelli linguistici. Le difese esistenti (guardrail per singolo agente, rilevamento a livello di topologia o giudici LLM) non riescono a risolvere questo problema perché non possono tracciare la propagazione dei vincoli attraverso le catene di delega, mancano di meccanismi per la revoca transitiva dell'autorità derivata e non offrono recupero per stati corrotti.

Metodologia: Contratti di Runtime Sensibili alla Delega (DARC)
L'autore propone DARC, un framework che tratta la delega come un punto di enforcement di prima classe, verificabile meccanicamente. Invece di passare prompt in testo semplice, ogni passaggio di autorità porta con sé un Contratto di Delega ( $C_{i \to j}$ ) che codifica:

Obiettivi delegati, capacità e scope dei dati.
Obblighi, proibizioni e budget di risorse.
Scadenza, catene di provenienza e condizioni di revoca.

Il sistema opera sotto un disciplina a due livelli:

Core Deterministico: Un insieme di vincoli (attenuazione delle capacità, preservazione dello scope dei dati, limiti di budget, scadenza, integrità della linea di discendenza e chiusura della revoca) che sono meccanicamente verificabili. Questi ricevono garanzie formali sotto l'assunto di interposizione completa (tutte le deleghe, le chiamate agli strumenti e le scritture nella memoria governata passano attraverso un mediatore).
Livello Semantico: Le clausole dipendenti dal significato in linguaggio naturale (ad esempio, interpretazioni specifiche di un obbligo) sono gestite da monitor "best-effort". Queste ricevono analisi empiriche ma non garanzie formali.

Contributi Chiave

Modello Formale (C1): Un modello di delega ricorsiva per sistemi LLM aperti dove i contratti codificano obiettivi, capacità, scope dei dati, obblighi, proibizioni, budget, scadenza, provenienza e revoca.
Framework delle Proprietà a Due Livelli (C2):
- Proprietà Deterministiche: Monotonicità dell'autorità (un delegato non riceve mai più autorità di quanto ne abbia il delegante), preservazione dello scope dei dati, preservazione degli obblighi (tramite trasformazioni registrate), chiusura della revoca (revoca transitiva dei discendenti) e completezza della provenienza.
- Proprietà Semantiche: Coerenza degli obiettivi e ereditarietà degli obblighi in linguaggio naturale, trattate empiricamente.
Architettura di Runtime (C3): Un sistema composto da un Compilatore di Contratti (registro di trasformazione), un Mediatore di Delega (imponendo le regole di attenuazione), un Monitor di Comunicazione, un Gateway di Capacità (controlla le chiamate agli strumenti rispetto ai contratti attivi), uno Strato di Memoria Governata (delimita letture/scritture in base al contratto) e un Controller di Incidenti (gestisce la revoca e il recupero).
Protocollo di Recupero (C4): Un protocolo di contenimento guidato dalla provenienza che consente la revoca delle capacità transittive e la quarantena della memoria basata sulla linea di discendenza. Distingue tra quarantena conservativa (qualsiasi input contaminato contamina l'output) e quarantena minima (pianificata).
Evidenza di Conformità (C5): Una suite di test meccanizzati e una matrice di bypass degli adapter che valuta la corrispondenza dell'implementazione rispetto alla specifica deterministica.

Risultati e Conclusioni

Garanzie Formali: Sotto l'interposizione completa, il sistema garantisce formalmente che le capacità siano attenuate, gli scope dei dati siano preservati, i budget siano rispettati e la revoca sia transitiva.
Insight Ingegneristici: Il processo di formalizzazione ha esposto due difetti critici di escalation a livello di implementazione:
1. Omissione di Limiti Numerici: Un contratto figlio poteva omettere un limite numerico del genitore, apparendo illimitato al gateway pur avendo subito l'attenuazione.
2. Omissione di Assi di Budget: Un figlio poteva omettere un asse di budget, diventando illimitato su quell'asse.
- Risoluzione: Questi difetti hanno portato a un principio di design generale: i vincoli opzionali con chiave devono assumere l'interpretazione più restrittiva per default. L'omissione non deve mai significare "illimitato".
Conformità dell'Implementazione: Il prototipo congelato ha superato 75 test meccanizzati, inclusi i casi di regressione per i difetti di escalation identificati. I test di bypass degli adapter hanno confermato che le azioni governate non potevano essere eseguite al di fuori del percorso vincolato dal contratto tramite sei specifici vettori di evasione (es. riferimenti diretti agli strumenti, sottografi annidati).
Stato del Pilota Empirico: Il documento riporta un pilota esplorativo di un giudice automatizzato riguardante la ritenzione dei vincoli attraverso la profondità di delega. Tuttavia, l'autore dichiara esplicitamente che non vengono fatte alcuna affermazione empirica confermativa in questa versione, poiché il round di qualificazione del giudice automatizzato non ha soddisfatto la soglia di accordo preregistrata (80% di accordo, $\kappa \ge 0.70$ ) e la validazione indipendente è incompleta.

Significato e Rivendicazioni
Il documento posiziona DARC come un ponte tra sistemi multi-agente normativi, sicurezza delle capacità (capability security) e enforcement di runtime. Il suo significato primario risiede in:

Riframing della Delega: Passare dal trattare la delega come testo al trattarla come un'azione istituzionale con vincoli eseguibili.
Recupero di Prima Classe: Trattare il recupero dello stato (quarantena e rollback basato sulla linea di discendenza) come parte integrante del guardrail, non come un elemento successivo.
Confini Disciplinati: Separare chiaramente ciò che può essere provato formalmente (vincoli deterministici) da ciò che deve essere misurato empiricamente (clausole semantiche), evitando l'eccesso di pretese comune nella ricerca sulla sicurezza degli LLM.

L'autore sottolinea che il contributo non è una nuova teoria della delega o dello shielding in isolamento, ma la loro composizione in un'architettura di enforcement e recupero per sistemi aperti dove agenti, strumenti e topologie cambiano a runtime. Il lavoro rimane un prototipo e una dimostrazione di meccanismo, con la necessità di futuri sviluppi per la compensazione delle azioni degli strumenti, la riassegnazione dei compiti e la piena validazione empirica delle clausole semantiche.