Uscire dalla sandbox di proposito

Mettere un agente in sandbox è facile da decidere e più difficile da gestire nel tempo, perché nel momento in cui un compito reale ha bisogno di qualcosa fuori dalla scatola serve un modo per farlo uscire che sia deliberato e non accidentale. La modalità elevated è la risposta di OpenClaw. Non cambia nulla per un agente che non è mai stato in sandbox, e per uno che lo è apre un percorso stretto e controllato verso l’host. Vale la pena leggere con attenzione i gate, perché diversi devono allinearsi prima che un solo comando si muova.

Cosa fa la modalità elevated

• La modalità elevated permette a un agente in sandbox di uscire dal normale sandboxing configurato per l’agente ed eseguire invece i comandi fuori dalla sandbox, con gate di approvazione che restano configurabili.
• Cambia il comportamento solo quando l’agente è in sandbox, perché un agente senza sandbox esegue già i suoi comandi shell sull’host.
• L’host effettivo è il Gateway per impostazione predefinita e diventa il nodo solo quando il target exec configurato o della sessione è già un nodo, quindi l’elevazione non è un override tra host diversi.
• Per ogni sessione sono disponibili quattro direttive: un livello on che mantiene le approvazioni, un livello ask che ne è un alias, un livello full che può saltare le approvazioni e un livello off che torna all’esecuzione confinata nella sandbox.

Le sessioni il cui ruolo del creatore richiede la sandbox non possono usare la modalità elevated per uscirne.

I gate che devono allinearsi

La disponibilità è una congiunzione, non un interruttore. Il gate globale deve essere attivo, e il mittente deve comparire nell’allowlist del proprio canale, conservata come elenchi di identificatori per canale. Un gate per agente può solo restringere ulteriormente, quindi sia il gate globale sia quello per agente devono essere attivi perché un agente sia idoneo. L’allowlist per agente funziona allo stesso modo, e un mittente deve corrispondere sia all’elenco globale sia a quello per agente. I plugin di canale possono fornire un’allowlist di fallback tramite un hook dell’adapter dell’SDK, ma oggi nessun canale incluso implementa quell’hook, quindi in pratica ogni provider ha bisogno della propria voce esplicita nell’allowlist. Se un qualsiasi gate fallisce, la modalità elevated viene considerata non disponibile invece che concessa in parte. Le voci stesse possono essere semplici identificatori, che corrispondono a un ID mittente, a un numero E.164 o a un campo From, oppure possono avere un prefisso che punta a un nome visualizzato, a un nome utente o a un tag, con prefissi di identità espliciti disponibili quando serve evitare ambiguità. C’è anche una dipendenza più discreta, dato che il comando bash in chat sta dietro un proprio flag e richiede inoltre che la modalità elevated sia attiva, quindi disattivare elevated blocca anche quei messaggi shell.

Livelli e precedenza

• Un messaggio che contiene solo la direttiva imposta il valore predefinito della sessione, mentre la stessa direttiva usata inline davanti a una richiesta si applica solo a quel messaggio.
• La risoluzione parte dalla direttiva inline, poi passa all’override di sessione, poi al valore predefinito globale impostato nella configurazione.
• In modalità full le approvazioni vengono saltate solo quando la modalità exec risolta e la policy di approvazione dell’host sono già completamente permissive, e nei livelli on e ask si applicano sempre le regole di approvazione configurate.

La modalità elevated presuppone che tu abbia già una sandbox del Gateway da cui valga la pena uscire, e presuppone che tu abbia deciso cosa può fare un comando una volta arrivato, che è il compito delle approvazioni exec. Nessuna delle due è qualcosa che l’elevazione sostituisca.

Perché i limiti reggono

Il design tratta l’elevazione come una leva su un solo asse e si rifiuta di farla diventare un override generale. Se la policy degli strumenti nega del tutto lo strumento exec, l’elevazione non può riportarlo, perché le due rispondono a domande diverse e vince la più restrittiva. Se il ruolo di operatore del creatore della sessione autenticata richiedeva una sandbox, l’elevazione non può eseguire alcun comando sul Gateway né su un nodo, il che mantiene una decisione dell’operatore al di sopra di una direttiva in chat. La selezione dell’host è trattata allo stesso modo, quindi un target automatico non si trasforma in una libera scelta della macchina. Tenere separati questi gate è ciò che rende la composizione prevedibile, e la documentazione ha una pagina su come i tre interagiscono al momento di una chiamata a uno strumento, che vale la pena leggere una volta per intero (come si compongono i tre gate). La direttiva exec correlata è ancora un’altra leva, che regola i valori predefiniti di exec per sessione per i mittenti autorizzati senza richiedere alcuna elevazione. Nel complesso, le regole fanno sì che attivare l’elevazione allarghi esattamente una cosa e lasci ogni altro confine dov’era.

Su Diali

Su Diali ogni cliente ha il proprio assistente, e la configurazione di runtime di OpenClaw ospitato su Diali viene generata dalla dashboard e sostituita a ogni rilascio. Se vuoi vedere dove si trovano i confini prima di allargarne qualcuno, parti dalla nostra pagina sulla sicurezza di Diali.

• La modalità elevated non cambia nulla se l’agente non è davvero in sandbox.
• Ogni gate deve passare: globale, per agente e l’allowlist di quel canale.
• Solo il livello full salta le approvazioni, e solo quando la policy è già permissiva.