Sintesi Tecnica: Autorità Residua negli Agenti di Coding

Definizione del Problema: Autorità Residua

Il documento identifica una specifica lacuna di sicurezza negli agenti di coding definita come autorità residua (lingering authority). Gli agenti di coding ricevono spesso un accesso esteso agli strumenti per l'intera durata di un task, anche quando una specifica risorsa o effetto è richiesto solo per un singolo sottotale (subgoal). Il problema centrale è temporale: l'autorità giustificata per un sottotale rimane esposta nell'interfaccia del pianificatore anche dopo la chiusura di quel sottotale.

Sebbene le difese esistenti affrontino i contenuti ostili, la fiducia negli strumenti e i controlli durante l'esecuzione, esse spesso lasciano l'interfaccia del pianificatore stessa esposta a capacità che non sono più giustificate. Se un'ampia opzione di lettura rimane visibile al pianificatore dopo la fine di un sottotale, il modello può continuare a pianificare attorno ad essa, creando uno stato di sicurezza in cui le capacità temporanee persistono oltre la loro giustificazione. Il documento sostiene che l'interfaccia esposta è parte dello stato di sicurezza, distinta dalla raggiungibilità a runtime o dai confini del sandbox.

Metodologia: Reference Monitor PORTICO

Gli autori introducono PORTICO, un reference monitor progettato per imporre cicli di vita limitati delle capacità (bounded capability lifetimes) per gli agenti di coding. PORTICO opera sotto un modello di isolamento dell'host fisso e si basa su contratti di task espliciti e un catalogo di strumenti tipizzato e coerente.

Meccanismi Core

PORTICO compila un contratto di task in quattro componenti:

1. Involucro Iniziale ($E_0$): L'insieme delle capacità esposte all'inizio del task.
2. Regole di Concessione ($\Gamma$): Regole che definiscono come l'autorità temporanea può essere espansa tramite richieste esplicite.
3. Regole di Chiusura ($\Lambda$): Predicati (ad es., superamento di un test, uscita da una fase, completamento di un sottotale) che attivano la revoca dell'autorità temporanea.
4. Regole di Divieto Globale ($G$): Invarianti come host di rete proibiti o accesso a file di credenziali.

Il Ciclo di Vita Request–Grant–Invoke

PORTICO materializza le espansioni come handle opachi legati a un'epoca (epoch-bound handles).

• Request (Richiesta): Il pianificatore può richiedere autorità basandosi sulle regole dichiarate, ma non può creare nuova autorità.
• Grant (Concessione): Se una regola corrisponde, il monitor genera un handle per la specifica risorsa/effetto/fase. Questo handle viene aggiunto alla prossima interfaccia del pianificatore.
• Invoke (Esecuzione): L'esecuzione è permessa solo se è presente un handle valido e attivo.
• Closure (Chiusura): Quando si verifica un evento di chiusura (ad es., il risultato di un test affidabile), il monitor rimuove gli handle corrispondenti dall'interfaccia del pianificatore. I successivi tentativi di utilizzare l'handle obsoleta vengono rifiutati prima che si verifichino effetti collaterali.

Crucialmente, la revoca rimuove l'autorità dall'interfaccia ma lascia intatto il contesto (ad es., i nomi dei file nella conversazione). Il pianificatore non può più selezionare lo strumento per quella risorsa senza una nuova concessione.

Contributi Chiave

Il documento presenta tre contributi primari:

1. Definizione di No-Stale-Use: Definisce il requisito per cui l'autorità derivante da una concessione chiusa deve scomparire dalle interfacce successive del pianificatore ed essere invalida al momento dell'esecuzione.
2. Formalizzazione e Implementazione: Formalizza la minimizzazione dell'esposizione, la espansione giustificata e la chiusura dell'autorità attorno a un protocollo request–grant–invoke. Questi sono implementati in PORTICO tramite handle legati a un'epoca.
3. Valutazione Empirica: Valuta i cicli di vita limitati su suite di fixture controllate e su repository reali fissati, dimostrando una riduzione della disponibilità di capacità obsolete post-chiusura rispetto ai design non revocanti.

Risultati Sperimentali

La valutazione utilizza tre suite di fixture controllate (A–C) e una suite di repository reali (D), confrontando PORTICO con i baseline (Full Access, Static Allowlist, Coarse Sandbox) e con specifici comparatori (Non-Revoking, All-Visible Same-Policy).

Risultati Chiave

• Minimizzazione (RQ1): Le varianti di PORTICO portano le violazioni delle policy e il "raggio d'azione" (risorse sensibili raggiunte) a 0.00 nella Suite A, mentre l'accesso completo e le allowlist statiche mostrano tassi di violazione significativi (1.00 e 0.82, rispettivamente).
• Espansione Giustificata (RQ2): PORTICO Core (solo l'involucro iniziale) è sicuro ma fragile, fallendo molti task che richiedono l'espansione dei confini (0.21 di successo nella Suite B). PORTICO Full recupera il lavoro legittimo sui confini, raggiungendo lo 0.87 di successo nella Suite B pur mantenendo la compliance dello scope a 1.00 e 0.00 violazioni.
• Chiusura (RQ3): Questo è il principale elemento differenziante del documento. Un Comparatore Non-Revocante (che riceve le stesse concessioni negli stessi tempi ma non le rimuove mai) eguaglia PORTICO nel successo dei task e nelle decisioni pre-chiusura. Tuttavia, sui ri-accessi post-chiusura:
  • PORTICO Full: Nega 10/10 tentativi di riutilizzo post-chiusura.
  • Comparatore Non-Revocante: Permette 10/10 tentativi di riutilizzo post-chiusura.
  • Audit degli Effetti Obsoleti: In test deterministici che coinvolgono scritture di file, mutazioni git ed egress di rete, PORTICO esegue 0/6 effetti proibiti, mentre il comparatore non revocante ne esegue 6/6.
• Ampiezza dell'Interfaccia (RQ3): Un Comparatore All-Visible Same-Policy (interfaccia ampia, stessa policy di esecuzione) eguaglia PORTICO negli effetti proibiti eseguti (0/20) ma genera significativamente più proposte bloccate (84 contro 67), indicando che un'interfaccia più ampia aumenta la pressione sulla pianificazione anche se l'esecuzione viene infine negata.
• Repository Reali (RQ4): Su repository Python reali fissati (Flask, Requests, ecc.), PORTICO Full materializza con successo le concessioni temporanee ed impone la chiusura, mantenendo la compliance dello scope e zero violazioni attraverso 14 contratti.

Significato e Rivendicazioni

Il documento sostiene che PORTICO isola con successo la "durata" dell'autorità come una variabile di sicurezza distinta. Il risultato chiave è che un sistema può preservare il successo del task e la compliance dello scope prima della chiusura, pur lasciando le capacità temporanee disponibili dopo la chiusura se la revoca non viene applicata.

Gli autori posizionano PORTICO non come un sostituto dei sandbox o delle difese sui contenuti, ma come uno strato complementare che rende le capacità temporanee esplicite, limitate e verificabili. Il significato risiede nella dimostrazione che la revoca è necessaria per prevenire l'autorità residua, anche quando la policy di esecuzione e il timing delle concessioni sono identici a quelli di un sistema non revocante.

Il documento rimane modesto riguardo al proprio ambito:

• Assume un catalogo di strumenti tipizzato e affidabile e un'esecuzione mediata; non pretende di proteggere contro comandi shell non mediati o bypass del sandbox.
• Riconosce che la qualità del contratto è un input di deployment; contratti scadenti possono portare a una concessione insufficiente (blocco del lavoro) o eccessiva (esposizione del rischio).
• Nota un costo di utilità: PORTICO Full scambia parte della pura velocità di completamento con un controllo più rigoroso dello scope, risultando in una visibile "incompletezza sicura" piuttosto che in un successo nascosto ma troppo ampio.

In definitiva, il lavoro sostiene che per gli agenti di coding, l'interfaccia del pianificatore stesso deve essere dinamica, restringendosi man mano che le giustificazioni scadono, invece di rimanere un menu statico e ampio di strumenti ammissibili.