Approvazioni exec avanzate in OpenClaw

La pagina principale sulle approvazioni exec spiega la policy e la richiesta di approvazione. La pagina avanzata è dove stanno gli spigoli: quali binari possono saltare l’allowlist perché possono leggere solo stdin, come il gateway vincola un comando di interprete ai file esatti che eseguirà, quale scope serve a una dashboard per approvare qualsiasi cosa, e come una richiesta raggiunge un canale di chat e torna indietro come decisione. Ecco quella pagina in sintesi.

Safe bin

• L’impostazione safe bins elenca i binari solo stdin che girano in modalità allowlist senza voci esplicite, per impostazione predefinita cut, uniq, head, tail, tr e wc; rifiutano gli argomenti di file posizionali e i token simili a percorsi, trattano gli argomenti come testo letterale senza globbing né espansione di variabili, e la validazione è deterministica in base alla sola forma degli argomenti: i flag lunghi sconosciuti e le abbreviazioni ambigue vengono rifiutati in modalità fail-closed e i flag brevi non riconosciuti ricadono sulla policy di approvazione.
• grep e sort non sono safe bin predefiniti e mantengono voci esplicite nell’allowlist per i loro usi non basati su stdin, con grep in modalità safe bin che accetta il pattern solo tramite il flag esplicito per il pattern; awk, sed e jq sono sempre negati come safe bin perché la loro semantica non può essere validata come solo stdin; interpreti e runtime non vanno mai aggiunti, i safe bin personalizzati richiedono un profilo esplicito, l’audit avvisa dei binari di interpreti senza profilo e la correzione di doctor può predisporre profili personalizzati vuoti da restringere in seguito.
• I safe bin devono essere risolti da directory fidate, i due percorsi di sistema predefiniti, e le voci del percorso di ricerca non sono mai considerate fidate in automatico, quindi i percorsi dei gestori di pacchetti vanno aggiunti esplicitamente all’elenco delle directory fidate; l’elenco dei flag negati per profilo blocca le opzioni che leggono file, come i flag ricorsivo e di file di grep, le opzioni di output e di elenco file di sort, l’opzione follow di tail e l’opzione di elenco file di wc.
• La concatenazione nella shell è consentita quando ogni segmento di primo livello soddisfa l’allowlist, i reindirizzamenti restano non supportati, la sostituzione di comando viene rifiutata anche tra virgolette doppie, i wrapper della shell riducono gli override d’ambiente della richiesta a un breve elenco, le decisioni allow-always rendono persistente l’eseguibile interno dietro i wrapper trasparenti ed estraggono gli applet dei multiplexer di shell, e la valutazione inline rigorosa mantiene l’eval inline soggetto a revisione quando gli interpreti sono nell’allowlist.

La consegna nella sessione controlla solo dove appare la richiesta. Da sola non autorizza ogni partecipante di quella chat ad approvare.

Vincolo degli interpreti e scope approvals

Le esecuzioni di interpreti soggette ad approvazione sono volutamente prudenti. Argomenti, directory di lavoro e ambiente esatti vengono vincolati; sul gateway l’intera catena di dispatch esterna, ogni eseguibile wrapper e quello finale, viene vincolata prima della revisione e ricontrollata prima dell’avvio, gli eseguibili protetti tramite il percorso reale e quelli scrivibili anche tramite hash del contenuto, quindi un nuovo eseguibile che compare prima nel percorso di ricerca fa negare l’esecuzione. Gli script diretti e i file di runtime vengono vincolati a una singola istantanea del file, i wrapper comuni dei gestori di pacchetti vengono prima estratti, e quando il gateway non riesce a identificare esattamente un file locale, come con gli script di pacchetto, le forme eval o le catene di loader, l’esecuzione soggetta ad approvazione viene negata invece di fingere di coprirla. In modalità automatica il revisore gestisce solo le catene completamente vincolate: wrapper di comandi shell, assegnazioni d’ambiente, applet e dispatch dei builtin saltano la revisione automatica e passano per l’approvazione umana una tantum, i wrapper di shell di login e interattive richiedono un umano perché i loro file di avvio stanno fuori dal vincolo, e le opzioni interattive di caricamento del codice restano negate. Quando serve un’approvazione lo strumento restituisce subito un ID di approvazione, una decisione che non arriva mai è un timeout presentato come negazione del comando host, con la sessione di origine ripresa così che l’agente veda che il comando non è stato eseguito, e le approvazioni in sospeso scadono dopo 30 minuti. Risolvere un’approvazione richiede lo scope dedicato approvals, che write non include, e la documentazione lo definisce un’autorità di livello esecuzione remota, da concedere con cognizione di causa anche a una piccola interfaccia di approvazione.

Inoltro alla chat

• Il blocco di inoltro delle approvazioni exec invia le richieste a qualsiasi canale di chat attraverso la normale pipeline in uscita, in modalità session, targets o both, con filtri per agente e per sessione e target composti da canale più destinatario; l’agente inoltra un comando di approvazione solo a partire da un’approvazione realmente in sospeso con il suo ID esatto, un ID nudo o inventato non approva nulla, una concessione allow-once copre un solo comando, e lo stesso comando risolve le approvazioni dei plugin quando l’ID non è quello di un’exec in sospeso, con la famiglia dei plugin configurata in modo indipendente.
• La chat di origine può approvare per impostazione predefinita su Slack, Matrix, Teams e superfici simili in cui la consegna è possibile, mentre Discord, Telegram e il bot QQ usano i loro elenchi di approvatori risolti anche nella stessa chat; i client di approvazione nativi aggiungono messaggi diretti agli approvatori, la diffusione nella chat di origine e schede interattive, attivati per canale con approvatori risolvibili, con Telegram impostato di default sulla modalità automatica e sui messaggi agli approvatori, e una scheda che non raggiunge alcun target ripiega su un avviso nella stessa chat con il comando esatto.
• Un target può includere un ID account per inviare tramite uno specifico account bot e un ID thread per restare all’interno di un topic del forum; le app mobili ufficiali esaminano le approvazioni in sospeso su una connessione admin o quando il loro dispositivo di approvazione è stato scelto come target, rileggendo il record quando una conferma di ricezione va persa; e il percorso macOS passa per un socket dello stesso utente con un token, una challenge e una durata breve.

Le approvazioni exec di OpenClaw sono la policy di base che questa pagina estende e la sandbox di OpenClaw è il perimetro che la documentazione preferisce per i flussi di lavoro che il vincolo non può coprire.

Perché la corsia rapida è stretta

L’intero design dei safe bin poggia su una sola proprietà: un binario che può leggere solo il proprio stdin non può esfiltrare un file che la policy non intendeva esporre. Ogni regola ne deriva: il rifiuto dei percorsi posizionali, gli argomenti letterali, i flag di file negati, il divieto per gli interpreti e per jq, e le directory fidate che fermano un binario sosia posto prima nel percorso di ricerca. Nel momento in cui uno strumento può aprire file o valutare codice, la documentazione lo manda invece all’allowlist con una richiesta di approvazione. Telegram su Diali e Slack su Diali sono due canali Diali su cui possono arrivare le richieste inoltrate.

Su Diali

Su Diali la configurazione di runtime viene generata dalla dashboard e sostituita a ogni rilascio, e ogni runtime del cliente è un perimetro a sé. OpenClaw ospitato su Diali descrive l’assistente ospitato e la pagina sulla sicurezza di Diali i controlli attorno a ogni comando che esegue.

• I safe bin leggono solo stdin; gli interpreti non si qualificano mai.
• Le esecuzioni di interpreti vincolano l’intera catena o vengono negate.
• Per approvare serve lo scope approvals, non write.