Sintesi Tecnica: Sovereign Execution Broker

Definizione del Problema

Man mano che gli agenti autonomi alimentati da Large Language Models (LLM) transitano da strumenti analitici passivi a pianificatori operativi attivi, essi vengono sempre più integrati nei flussi di lavoro delle infrastrutture di produzione (ad esempio, auto-scaling, deployment di container, gestione di security group). Tuttavia, concedere credenziali di accesso permanenti e dirette a questi processi di ragionamento non deterministici crea gravi rischi di sicurezza. Un singolo errore di allucinazione o un attacco di prompt injection avversario potrebbe innescare mutazioni infrastrutturali non autorizzate o distruttive.

Le architetture esistenti tentano di mitigare il problema introducendo un gate di ammissione, come il Sovereign Assurance Boundary (SAB), che valida le azioni proposte ed emette un certificato crittograficamente firmato ($\Omega$). Tuttavia, un certificato di ammissione da solo è insufficiente per l'enforcement. Senza un meccanismo di runtime che richieda attivamente il certificato per l'esecuzione, gli agenti o i wrapper compromessi possono bypassare l'intero processo di ammissione utilizzando credenziali permanenti. Inoltre, anche se il processo di ammissione viene seguito, il ritardo temporale tra l'ammissione della proposta e l'effettiva esecuzione crea una finestra di vulnerabilità in cui lo stato del sistema può subire derive, o le policy di sicurezza possono cambiare (vulnerabilità Time-of-Check to Time-of-Use, o TOCTOU).

Metodologia: Il Sovereign Execution Broker (SEB)

Il documento introduce il Sovereign Execution Broker (SEB), un confine di enforcement a runtime progettato per colmare il divario tra le proposte certificate e la reale mutazione dell'infrastruttura. Il principio architettonico centrale è la separazione tra proposta, ammissione ed esecuzione.

Architettura Core

1. Zero Standing Privileges (Privilegi Permanenti Nulli): Nella configurazione di deployment prevista, nessun runtime di agente o wrapper detiene credenziali di mutazione di produzione permanenti. Tutte le richieste di mutazione autonoma devono passare attraverso il SEB.
2. Pipeline di Verifica del Certificato: Il SEB funge da guardiano che consuma un certificato SAB ($\Omega$) e una richiesta di esecuzione ($req$). Prima dell'esecuzione, esegue una pipeline di verifica formale controllando:
   • Firma ($\Phi_{sig}$): Validità della firma SAB.
   • Corrispondenza del Contratto ($\Phi_{match}$): Assicurarsi che i parametri della richiesta, il target e l'operazione corrispondano esattamente al contratto certificato $C$.
   • Validità ($\Phi_{time}$): Assicurarsi che la richiesta rientri nella finestra di validità del certificato.
   • Policy e Revoca ($\Phi_{policy}, \Phi_{rev}$): Verificare che il certificato corrisponda alla versione attiva della policy e che non sia stato revocato tramite un contatore di epoca globale.
   • Rilevamento della Deriva ($\Phi_{drift}$): Confrontare lo stato live del target ($St$) con lo stato di evidenza ($E_{admit}$) catturato al momento dell'ammissione per rilevare cambiamenti TOCTOU.
   • Resistenza al Replay ($\Phi_{replay}$): Assicurarsi che il nonce del certificato non sia già stato utilizzato in precedenza.
3. Identità di Esecuzione Limitata (Scoped Execution Identity): Dopo la verifica riuscita, il SEB non esegue l'azione utilizzando le proprie credenziali master. Al contrario, agisce come un broker di token, emettendo un'identità di esecuzione a breve durata ($ID_{exec}$) strettamente vincolata al contratto certificato, alla risorsa target e alla finestra di validità.
4. Pattern di Enforcement: Per prevenire il bypass, l'infrastruttura target (ad esempio, AWS, Kubernetes) deve essere configurata per rifiutare tutte le richieste di mutazione che non provengano dal broker o da sessioni emesse dal broker. Ciò è ottenuto tramite Service Control Policies (SCP), IAM permission boundaries e la validazione di admission webhook.
5. Auditabilità: Ogni decisione di verifica (rifiuto o ri-ammissione) e ogni esito di esecuzione viene registrato in un registro firmato e append-only, fornendo una prova crittografica che collega l'azione al certificato originale.

Contributi Chiave

Il documento presenta quattro contributi primari:

1. Autonomia Enforced dal Broker: Identifica il gap di enforcement tra le proposte certificate e la mutazione effettiva, definendo il SEB come il confine di runtime che impedisce agli agenti di detenere credenziali permanenti.
2. Modello di Esecuzione basato sulla Verifica del Certificato: Formalizza l'interfaccia del broker $Execute(\Omega, req, St, Platform) \rightarrow D | O$, dettagliando i predicati per firma, corrispondenza del contratto, validità, policy, revoca, deriva e replay.
3. Identità Scoped e Revoca Pre-Esecuzione: Introduce un modello di least-privilege in cui le credenziali vengono emesse solo al momento dell'esecuzione, limitate allo scope del contratto, e soggette a controlli di revoca immediatamente prima dell'esecuzione.
4. Implementazione del Prototipo e Valutazione: È stato implementato un prototipo in Go (circa 4.200 linee di codice) con adapter per AWS STS e Kubernetes TokenRequest, distribuito come percorso di mutazione obbligatorio, ed è stato valutato sotto carichi di lavoro realistici.

Risultati Sperimentali

Il prototipo è stato valutato su cluster AWS e Kubernetes (Amazon EKS) per misurare latenza, throughput e sicurezza sotto iniezione di guasti.

• Overhead di Latenza:
  • Kubernetes: Il broker aggiunge circa 28,2 ms (p50) di overhead alle operazioni di mutazione. I colli di bottiglia principali sono i controlli di deriva live (42,9%) e l'emissione di credenziali (42,9%).
  • AWS: L'overhead è maggiore, circa 136,9 ms (p50), dominato dall'emissione di credenziali AWS STS e dai controlli di deriva (chiamate API DescribeSecurityGroups).
  • Confronto: Sebbene l'IAM diretto e il logging di sola audit abbiano un overhead quasi nullo, essi mancano delle garanzie di sicurezza fornite dal SEB. L'overhead del SEB è considerato gestibile per mutazioni ad alto rischio e bassa frequenza (ad esempio, cambiamenti ai firewall, auto-scaling), ma è notato come non adatto per loop di controllo a scala di microsecondi.
• Propagazione della Revoca: Con un intervallo di polling di 5 secondi per l'epoca di revoca, il sistema raggiunge un ritardo massimo di propagazione di 5,2 secondi dall'avanzamento dell'epoca al rifiuto totale delle richieste.
• Sicurezza e Tolleranza ai Guasti:
  • In 1.000 casi di test iniettati che coprivano minacce come il bypass del broker, il replay di certificati obsoleti, la discrepanza tra richiesta e certificato e le partizioni di rete, il SEB ha raggiunto un tasso di rifiuto del 100% per richieste non autorizzate o non valide.
  • Semantica Fail-Closed: In caso di partizioni di rete o guasti ai servizi, il broker predefinisce il rifiuto delle richieste per evitare un'esecuzione non sicura.
  • Ripristino da Crash: Il sistema ha gestito con successo i crash del broker utilizzando token di idempotenza per prevenire mutazioni duplicate, garantendo la coerenza dello stato.

Significato e Rivendicazioni

Il documento sostiene che il SEB fornisce uno strato di enforcement a runtime necessario per i piani di controllo agentici che l'Identity and Access Management (IAM) tradizionale e i motori di policy non possono fornire.

• Passaggio da Identità ad Azione: A differenza dell'IAM, che autorizza chi può fare cosa, il SEB autorizza questa specifica azione certificata sotto l'attuale evidenza del sistema.
• Mitigazione del TOCTOU: Controllando la deriva dello stato live e le epoche di revoca immediatamente prima dell'esecuzione, il SEB chiude la finestra di vulnerabilità tra l'ammissione e la mutazione.
• Teorema di Enforcement: Il documento presenta una prova formale (Teorema 1) affermando che, sotto specifiche assunzioni di deployment (nessuna credenziale permanente per gli agenti, i target API rifiutano identità non appartenenti al broker), un agente non fidato non può causare una mutazione dello stato di produzione a meno che non corrisponda a un certificato valido, non scaduto, non revocato e non riutilizzato con uno scope applicabile.

Gli autori concludono che, sebbene il SEB introduca un overhead di latenza, esso trasforma l'autorità certificata in capacità di runtime a breve durata, revocabili e auditabili, rendendolo una soluzione valida per mettere in sicurezza gli agenti autonomi in ambienti di produzione dove il costo di una violazione della sicurezza supera il costo della latenza.