Sair da sandbox de propósito

Colocar um agente em sandbox é fácil de decidir e mais difícil de conviver, porque no momento em que uma tarefa legítima precisa de algo fora da caixa, você precisa de um jeito de deixá-lo sair que seja deliberado, e não acidental. O modo elevado é a resposta do OpenClaw para isso. Ele não muda nada para um agente que nunca esteve em sandbox e, para um que está, abre um caminho estreito e controlado até o host. Vale ler os controles com atenção, porque vários deles precisam se alinhar antes que um único comando se mova.

O que o modo elevado faz

• O modo elevado permite que um agente em sandbox escape da sandbox comum configurada para o agente e execute comandos fora dela, com controles de aprovação que continuam configuráveis.
• Ele só muda o comportamento quando o agente está em sandbox, porque um agente sem sandbox já executa seus comandos de shell no host.
• O host efetivo é o Gateway por padrão e só passa a ser o nó quando o alvo de exec configurado ou da sessão já é um nó, então a elevação não é uma sobrescrita entre hosts.
• Quatro diretivas estão disponíveis por sessão: um nível on, que mantém as aprovações, um nível ask, que é um alias dele, um nível full, que pode pular as aprovações, e um nível off, que volta à execução confinada na sandbox.

Sessões cujo papel do criador exige sandbox não podem usar o modo elevado para escapar.

Os controles que precisam se alinhar

A disponibilidade é uma conjunção, não um interruptor. O controle global precisa estar ativado, e o remetente precisa aparecer na lista de permissões do seu canal, que é mantida como listas de identificadores por canal. Um controle por agente só pode restringir ainda mais, então tanto o controle global quanto o controle por agente precisam estar ativados para que um agente se qualifique. A lista de permissões por agente funciona da mesma forma, e um remetente precisa corresponder tanto à lista global quanto à lista do agente. Plugins de canal podem fornecer uma lista de permissões de fallback por um hook de adaptador do SDK, mas nenhum canal incluído implementa esse hook hoje, então, na prática, cada provedor precisa da própria entrada explícita na lista de permissões. Se qualquer controle falhar, o modo elevado é tratado como indisponível, em vez de concedido parcialmente. As próprias entradas podem ser identificadores simples, que correspondem a um ID de remetente, a um número E.164 ou a um campo From, ou podem ter um prefixo que aponta para um nome de exibição, um nome de usuário ou uma tag, com prefixos de identidade explícitos disponíveis quando você precisa evitar ambiguidade. Há também uma dependência mais discreta, já que o comando de chat bash fica atrás da própria flag e exige, além disso, que o modo elevado esteja ativado, então desativar o modo elevado também bloqueia essas mensagens de shell.

Níveis e precedência

• Uma mensagem só com a diretiva define o padrão da sessão, enquanto a mesma diretiva usada inline antes de um pedido se aplica apenas àquela mensagem.
• A resolução começa pela diretiva inline, depois passa pela sobrescrita de sessão e, por fim, pelo padrão global definido na configuração.
• No nível full, as aprovações só são puladas quando o modo de exec resolvido e a política de aprovação do host já são totalmente permissivos, e nos níveis on e ask as regras de aprovação configuradas sempre se aplicam.

O modo elevado pressupõe que você já tenha uma sandbox no Gateway da qual valha a pena sair, e pressupõe que você já decidiu o que um comando pode fazer depois que chega lá, que é o papel das aprovações de execução. Nenhuma das duas coisas é algo que a elevação substitua.

Por que os limites se sustentam

O design trata a elevação como uma alavanca em um único eixo e se recusa a deixá-la virar uma sobrescrita geral. Se a política de ferramentas nega a ferramenta exec de vez, a elevação não consegue trazê-la de volta, porque as duas respondem a perguntas diferentes e a mais restritiva vence. Se o papel de operador do criador autenticado da sessão exigia uma sandbox, a elevação não pode executar nenhum comando no Gateway nem em um nó, o que mantém uma decisão do operador acima de uma diretiva de chat. A seleção de host é tratada da mesma forma, então um alvo automático não vira uma escolha livre de máquina. Manter esses controles separados é o que torna a composição previsível, e a documentação tem uma página sobre como os três interagem no momento de uma chamada de ferramenta, que vale ler uma vez por inteiro (como os três controles se combinam). A diretiva exec relacionada é ainda outra alavanca, que ajusta os padrões de exec por sessão para remetentes autorizados sem exigir elevação nenhuma. Juntas, as regras significam que ativar a elevação amplia exatamente uma coisa e deixa todas as outras fronteiras onde estavam.

Na Diali

Na Diali, cada cliente roda o próprio assistente, e a configuração de execução do OpenClaw hospedado na Diali é gerada a partir do painel e substituída a cada nova versão. Se quiser ver onde ficam as fronteiras antes de ampliar qualquer uma delas, comece por nossa página de segurança.

• O modo elevado não muda nada, a menos que o agente esteja de fato em sandbox.
• Todos os controles precisam liberar: o global, o por agente e a lista de permissões daquele canal.
• Só o nível full pula as aprovações, e apenas quando a política já é permissiva.