Riepilogo Tecnico: Canali Dormienti e Gate di Provenienza

Definizione del Problema: Canali Dormienti

Il documento identifica una nuova classe di minacce negli agenti AI autonomi "sempre attivi" (ad esempio, OpenClaw, Hermes Agent) denominata Canali Dormienti. A differenza dell'iniezione di prompt tradizionale, che tipicamente si verifica all'interno di un singolo turno o sessione, un attacco tramite canale dormiente disaccoppia l'ingresso ($T_0$) dall'effetto ($T_1$) nel tempo, nei substrati di archiviazione e nelle superfici di comunicazione.

In questo scenario, un input non attendibile (ad esempio, da una chat di gruppo o da un'email) viene ingerito dall'agente e persiste come nota di memoria, abilità auto-creata, attività pianificata o patch del filesystem. Questo artefatto sopravvive all'interno del confine di autorità dell'agente fino a quando un trigger benigno (come una successiva richiesta del proprietario o un ciclo autonomo) lo recupera ed esegue. L'attacco si attiva attraverso una superficie diversa rispetto all'ingresso, sfruttando spesso la condizione del "deputato confuso", in cui l'agente esegue un comando per conto del proprietario, ignaro che i parametri del comando provengano da una fonte non attendibile.

Gli autori definiscono la classe utilizzando due assi:

1. Substrato di Persistenza: Dove sopravvive l'istruzione malevola (Memoria, Abilità Auto-creata, Filesystem, Trigger Pianificato/Esterne).
2. Separazione di Attivazione: Il grado di disaccoppiamento tra ingresso ed esecuzione (Stessa sessione, Cross-canale, Cross-attore, Cross-contesto di esecuzione).

Il documento sostiene che la letteratura esistente tratta queste capacità in isolamento (ad esempio, iniezione a turno singolo o avvelenamento della memoria) e non affronta la minaccia unificata della persistenza multi-substrato combinata con un'attivazione ritardata e cross-superficie.

Metodologia e Modello di Minaccia

Gli autori adottano un modello di minaccia in cui l'attaccante è "non attendibile ma ammesso", il che significa che il suo contenuto raggiunge l'agente tramite canali abilitati ma a bassa fiducia (chat di gruppo, email, URL recuperati). Il difensore è il proprietario dell'agente. L'analisi è ancorata a un commit specifico fissato del runtime OpenClaw (commit 3120401f...1829b1b6), con tutte le affermazioni verificate contro il codice sorgente in vendita.

Il documento presenta una tassonomia (Tabella I) che mappa i substrati di persistenza ($M_1$–$M_5$) contro le separazioni di attivazione ($C_0$–$C_4$). Evidenzia quattro scenari illustrativi che il lavoro precedente sottodetermina:

• A4 (Esempio in Esecuzione): Un attacco "Cron tramite deputato confuso" ($M_5 \times C_4$). Un attaccante incorpora un URL webhook malevolo in un'email. L'agente lo riassume in memoria. Giorni dopo, il proprietario chiede all'agente di "configurare quel controllo di salute giornaliero". L'agente recupera la nota, sintetizza un lavoro cron con l'URL dell'attaccante e lo esegue. La persistenza è la voce del cron; l'attivazione avviene nel demone di sistema cron, al di fuori del processo dell'agente.
• A2: Un troiano per abilità tramite chat di gruppo ($M_3 \times C_2$).
• A3: Esfiltrazione cross-canale tramite memoria ($M_2 \times C_2$).
• A5: Patching di file nascosti (dotfile) ($M_4 \times C_4$).

Contributi Chiave: La Difesa di Provenienza (D2)

Il documento propone una strategia di difesa a livelli, con D2 come contributo principale. D2 sposta il confine di applicazione al di fuori del ciclo del modello, basandosi sul tracciamento della provenienza e sull'attestazione dell'istanza di azione.

Meccanismi Principali

1. Etichettatura e Propagazione degli Artefatti: Il runtime mantiene uno stato di provenienza ($\Pi$) per ogni artefatto (memoria, abilità, file, chiamate agli strumenti). I tag ($\tau$) registrano la fonte (Canale, Principale, Dispositivo). Gli input non attendibili espandono rigorosamente l'insieme della provenienza.
2. Digest dell'Istanza di Azione: Ogni azione consequenziale $\alpha$ viene hashata in un digest canonico $\delta(\alpha)$ utilizzando un hash resistente alle collisioni (SHA-256) sui byte normalizzati dell'azione (inclusi argomenti e destinazione). Questo sconfigge il "lavaggio tramite parafrasi" in cui un modello riscrive un'istruzione dell'attaccante per nasconderne l'origine.
3. Hook di Mediazione: La difesa richiede una mediazione completa tramite dieci hook di runtime (H1–H10).
   • Hook di Aggiornamento (H1–H5): Popolano i tag e propagano la provenienza durante l'ingresso e la creazione.
   • Hook di Gate (H6–H10): Punti decisionali prima delle distribuzioni con effetti collaterali (ad esempio, esecuzione shell, scritture su file, pianificazione).
4. Attestazione in un Colpo del Proprietario: Per le azioni con provenienza non attendibile, il gate richiede una concessione $g$ da un principale attendibile. Questa concessione deve corrispondere al digest dell'azione $\delta(\alpha)$, contenere un nonce unico (per prevenire il replay) e arrivare attraverso un canale compagno attestato hardware ($\Sigma$) che il modello non può emettere.

Teorema di Correttezza

Gli autori forniscono un teorema di correttezza per D2, assumendo sette invarianti di runtime (Mediazione, Tag, Causalità, Canale, Autorizzazione Concessione, Nonce, Hash). Il teorema afferma che una distribuzione è consentita solo se:

• Tutti gli artefatti contribuenti nell'insieme causale hanno provenienza attendibile ($\Pi_\alpha \subseteq T$), OPPURE
• Esiste un'attestazione valida, fresca e affidabile dal proprietario per l'esatta istanza di azione.

Questo design garantisce che, anche se il modello viene ingannato a generare un comando malevolo, il gate lo negherà a meno che il proprietario non attesti esplicitamente quella specifica istanza di azione tramite un canale sicuro.

Risultati e Valutazione

Il documento non rivendica un sistema di produzione distribuito, ma fornisce un argomento di fattibilità ancorato al sorgente e un'implementazione di riferimento eseguibile.

• Sonda Empirica (A4): In una "sonda di fumo" di 20 prove a colpo singolo, un modello di ragionamento all'avanguardia ha ricevuto l'avviso di sicurezza OpenClaw e il contesto malevolo. 19/20 modelli hanno emesso una chiamata allo strumento cron.add valida che puntava all'URL dell'attaccante, dimostrando che gli avvisi nel contesto (D1) sono insufficienti per prevenire l'attacco.
• Implementazione di Riferimento: Un artefatto compagno su github.com/maloyan/sleeper-channels include:
  • Un'implementazione TypeScript della funzione di decisione del gate D2.
  • Una suite di audit statica (13 casi) che verifica che le righe di sorgente citate in OpenClaw esistano e corrispondano al modello di minaccia.
  • Un adattatore di runtime che implementa gli hook H1, H2, H3, H6 e H9 attorno al percorso cron.
  • Una suite di test di 42 casi che copre le regole decisionali, il lavaggio multi-input e il replay delle concessioni.
• Verifica: L'adattatore di runtime ha dimostrato con successo che la chiamata dell'attaccante A4 viene negata a causa della provenienza non attendibile, mentre i lavori cron benigni solo del proprietario sono ammessi.

Significato e Affermazioni

Il documento si posiziona come un documento di posizione e progettazione che risolve la classe di minacce dei canali dormienti e fornisce una specifica formale per la difesa.

• Novità: È il primo lavoro a trattare la combinazione di persistenza multi-substrato e attivazione ritardata, cross-superficie, come una classe di minacce unificata negli agenti OS-live.
• Posizionamento della Difesa: Sostiene che i segnali di provenienza devono essere applicati al di fuori del ciclo del modello. Fare affidamento sul modello per rifiutare input non attendibili (D1) è fragile contro attacchi adattivi.
• Formalismo: Introduce un teorema di correttezza e un digest canonico dell'istanza di azione per sconfiggere il lavaggio tramite parafrasi e gli attacchi di replay, affrontando le lacune nelle precedenti proposte della comunità (ad esempio, issue upstream [10]) che mancavano di fondamento empirico e specifiche formali di applicazione.
• Modestia: Gli autori dichiarano esplicitamente che i tassi empirici di successo dell'attacco, l'efficacia della distribuzione completa e i compromessi costo-utilità sono rinviati a uno studio di follow-on preregistrato. Il lavoro attuale stabilisce la tassonomia, la difesa formale e la fattibilità dell'attacco e della difesa su un commit specifico del runtime.