Sintesi Tecnica: Confine di Assicurazione Sovrana per Infrastrutture Agentiche

1. Definizione del Problema

L'integrazione di agenti basati su Large Language Model (LLM) nei flussi di lavoro operativi introduce una lacuna critica di autorizzazione nel piano di controllo. Sebbene gli agenti possano proporre mutazioni ad alto impatto sulle risorse di produzione (ad esempio, scalare nodi, ruotare credenziali, modificare i security group di rete), i meccanismi di sicurezza esistenti sono insufficienti per governare questi sistemi di ragionamento non deterministici.

• Statico vs. Dinamico: L'Identity and Access Management (IAM) tradizionale e i motori di policy applicano permessi statici o conformità strutturale, ma non possono determinare se una proposta autonoma sia semanticamente giustificata da prove in tempo reale.
• Limiti Post-Hoc: I log di audit e i protocolli di consenso registrano le azioni o concordano sulle transizioni di stato solo dopo l'esecuzione o senza valutare la sicurezza semantica della transizione.
• Accumulo del Rischio: Azioni individualmente plausibili degli agenti possono accumularsi in guasti sistemici, inclusi blackout di disponibilità, esposizione di dati, bypass delle policy e perdita di contesto forense.
• Il Nucleo della Lacuna: Non esiste un confine di ammissione a runtime che converta la proposta di un agente in autorità di esecuzione solo dopo che essa sia stata vincolata a prove, policy e stato di revoca.

2. Metodologia: Il Confine di Assicurazione Sovrana (Sovereign Assurance Boundary - SAB)

Il documento propone il Sovereign Assurance Boundary (SAB), un confine di ammissione a runtime vincolato da certificati che si interpone tra il ragionamento dell'agente e la mutazione dell'infrastruttura. Il SAB opera sul principio che l'istituzione mantiene il controllo locale su policy, prove e autorità di esecuzione, trattando l'ambiente di esecuzione dell'agente come un propositore non attendibile.

2.1 Architettura: Modello Airlock–Broker

Il SAB separa il sistema in due livelli distinti:

1. Ambiente di Esecuzione dell'Agente Non Attendibile (Untrusted Agent Runtime): Genera proposte ma non possiede credenziali permanenti o privilegi di esecuzione diretti.
2. Broker di Esecuzione Sovrana Attendibile (Trusted Sovereign Execution Broker): L'unica entità autorizzata a invocare le API dell'infrastruttura. Esso esegue le mutazioni esclusivamente verificando un Certificato di Assicurazione Sovrana ($\Omega$) firmato.

La pipeline di ammissione consiste nei seguenti stadi:

• Compilazione del Contratto: I comandi grezzi dell'agente vengono normalizzati in un Contratto di Esecuzione ($C$) fortemente tipizzato, che definisce target, precondizioni, postcondizioni e rollback.
• Vincolo delle Prove (Evidence Binding): Un collettore di prove assembla telemetria, log e ticket per calcolare un digest crittografico $H(E)$ dello stato del sistema al momento della decisione.
• Scoring delle Conseguenze: Uno scorer calcola una metrica di rischio $R(C)$ basata su raggio d'impatto (blast radius), espansione dei privilegi, sensibilità dei dati, irreversibilità e incertezza. Questo determina il Livello di Autonomia ($L(C)$) (che varia da L0 Advisory a L5 Prohibited).
• Routing del Percorso di Certificazione: In base a $L(C)$ e alla policy, il contratto viene instradato attraverso un percorso specifico (ad esempio, PolicyOnly, LightweightQuorum, SQA, SQAPlusHuman).
  • Semantic Quorum Assurance (SQA): Una mesh di validatori esterni non attendibili fornisce attestazioni firmate ($\Gamma_{SQA}$) riguardo l'ammissibilità semantica dell'azione.
  • Approvazione Umana: Per azioni ad alto impatto, gli operatori forniscono approvazioni multi-firma legate allo specifico contratto e alle prove.
• Emissione del Certificato: L'Airlock di Assicurazione (parte del Trusted Computing Base) verifica tutti i requisiti del percorso e rilascia un Certificato di Assicurazione Sovrana ($\Omega$) firmato.
  • $\Omega$ contiene: $C$, $H(E)$, $R(C)$, $L(C)$, percorso di certificazione, firme dei validatori, identità di esecuzione ($ID_{exec}$), finestra di validità ($T_{valid}$), versione della policy ($P_{ver}$) ed epoca di revoca ($\rho_{rev}$).
• Verifica del Broker: Prima dell'esecuzione, il Sovereign Broker verifica la firma di $\Omega$, controlla l'epoca di revoca, valida la versione della policy e esegue un controllo di deriva dello stato ($\Phi_{drift}$) per garantire che lo stato live non sia deviato dalle prove $E$ vincolate.

2.2 Invarianti Formali

Il SAB impone cinque invarianti del confine di autorità:

1. Decoupling tra Proposta ed Esecuzione: Nessuna proposta di un agente innesca una mutazione senza l'ammissione dell'airlock.
2. Esecuzione Vincolata al Certificato: L'esecuzione avviene solo se il broker verifica un $\Omega$ valido contenente il contratto specifico $C$.
3. Vincolo delle Prove: Le approvazioni e le attestazioni sono criptograficamente legate a $C$ e $H(E)$, impedendo il riutilizzo in contesti diversi.
4. Selezione del Percorso Monotona: I contratti sono ammessi solo se tutti i requisiti del loro percorso di certificazione selezionato sono soddisfatti; i percorsi a minore assicurazione non possono sovrascrivere i requisiti di rischio maggiore.
5. Autorità Effimera: I certificati vengono rifiutati se l'epoca di revoca è obsoleta o se il tempo di esecuzione cade al di fuori della finestra di validità.

3. Contributi Principali

Il documento presenta quattro contributi primari:

1. Ammissione Vincolata al Certificato: Definisce un confine di ammissione a runtime che converte l'autorità di esecuzione autonoma da un permesso ambientale in un artefatto revocabile e vincolato alle prove.
2. Architettura Airlock–Broker: Introduce i componenti specifici (Contratto $C$, Digest delle Prove $H(E)$, Certificato $\Omega$ e Sovereign Broker) che separano proposta, ammissione ed esecuzione.
3. Certificazione Consapevole delle Conseguenze: Formalizza lo scoring delle conseguenze, i livelli di autonomia, i percorsi di certificazione e i meccanismi di revoca che supportano l'escalation, il rifiuto e la sospensione prima dell'esecuzione.
4. Prototipo e Valutazione della Fattibilità: Implementa un prototipo in Go che dimostra la fattibilità del sistema, inclusa la serializzazione dei contratti, i controlli di policy OPA/Rego, la firma Ed25519 e un ledger supportato da PostgreSQL.

4. Risultati e Valutazione

Gli autori hanno valutato il prototipo utilizzando 500 contratti di esecuzione etichettati attraverso 2.500 tentativi di ammissione in un ambiente di test locale.

• Latenza:
  • Ammissione solo policy: ~1,84 ms (p50).
  • Ammissione SQA (con mesh di validatori): ~185 ms (p50) / 380 ms (p95).
  • Verifica del broker: ~0,15 ms (p50).
  • Propagazione della revoca: ~12,4 ms (p95).
• Accuratezza:
  • Accuratezza del routing (accordo con un oracle etichettato da esperti): 96,8%.
  • Tasso di ammissione non sicura: 0,4%.
• Efficienza:
  • Riduzione dell'approvazione umana: 68,2% rispetto a una coda gestita solo da umani.
  • Overhead di archiviazione del certificato: ~3,4 KB per azione.
• Riproducibilità: Il 100% delle voci del ledger era riproducibile con il contesto dello schema.

I risultati indicano che l'overhead del piano di controllo è fattibile su una singola workstation, scambiando la latenza con l'assicurazione e la riproducibilità.

5. Significato e Rivendicazioni

Il documento afferma che il SAB affronta una specifica lacuna di autorizzazione senza sostituire i livelli di sicurezza esistenti.

• Sovranità Operativa: Il SAB definisce la sovranità come il mantenimento da parte dell'istituzione del controllo locale su valutazione delle policy, ritenzione delle prove, chiavi di firma e autorità di esecuzione. I modelli esterni sono limitati alla generazione di proposte e non possono bypassare la certificazione locale.
• Componibilità: Il SAB non è un sostituto di IAM, della verifica formale, dei protocolli di consenso o della revisione umana. Al contrario, compone questi meccanismi in un confine di ammissione a livello di sistema. Tratta l'autorità di esecuzione delegata come un artefatto a runtime, vincolato al certificato, vincolato alle prove, revocabile e riproducibile.
• Mitigazione del Rischio: Decoupling tra la generazione della proposta e l'esecuzione e legando l'esecuzione a prove fresche e a una policy attiva, il SAB impedisce al ragionamento autonomo di mutare lo stato da solo, mitigando così i rischi di fallimento sistemico, fuga di dati e bypass delle policy.

Gli autori mantengono una posizione modesta, riconoscendo che il SAB dipende dall'integrità del Trusted Computing Base (TCB), dalla freschezza delle prove esterne e dalla calibrazione dei validatori. Notano che i risultati del prototipo dipendono dal carico di lavoro e non garantiscono prestazioni generali, suggerendo una strategia di implementazione incrementale partendo da domini ad alta conseguenza.