Módulo 4 · Parte A de 3

Sandbox do OpenShell

O Módulo 3 deu ao OpenClaw contexto persistente e gatilhos sem supervisão. Regras no prompt e verificações do harness influenciam o que ele tenta fazer. O OpenShell deixa a decisão final de permitir ou negar com um sandbox que o agente não pode reescrever.

Nesta página, você enviará comandos reais ao launchable, lerá cada veredito e o relacionará à regra responsável. Depois, inspecionará um segundo limite: o plano de controle do operador acima do sandbox.

O OpenShell separa entrada de controle, aplicação de políticas, estado do agente, acesso a ferramentas e roteamento de modelos. Use este mapa ao passar do conceito de sandbox para a política ativa.

Separe os três papéis ao acompanhar uma execução.

OpenClaw é o framework do agente. Ele escolhe a ferramenta e a ação a tentar.
OpenShell é o runtime de segurança. Ele limita arquivos, destinos de rede e operações do sistema operacional disponíveis à ação.
NemoClaw é a stack de referência que reúne OpenClaw e OpenShell com comandos de ciclo de vida, políticas predefinidas, roteamento de inferência e padrões de implantação.

O OpenShell é independente do agente. O mesmo limite pode conter OpenClaw, Hermes, LangChain Deep Agents ou outro processo que exija contenção no sistema operacional.

Onde cada camada de defesa intervém

Suponha que conteúdo não confiável instrua um agente a ler uma credencial e enviá-la para fora do ambiente. Três camadas podem interromper essa ação, e cada uma responde a uma pergunta diferente.

O prompt orienta a intenção. Uma regra como “não revele credenciais” descreve o comportamento esperado. Ainda assim, conteúdo recuperado malicioso, a saída de uma ferramenta ou outro agente podem enganar o modelo. Essa camada influencia a decisão; não reduz a autoridade concedida pelo runtime.
O harness valida a solicitação. OpenClaw ou Hermes pode rejeitar uma forma de shell não aceita, uma ferramenta proibida ou um argumento malformado antes de chegar ao sistema operacional. A verificação determinística ajuda, mas continua sendo lógica da aplicação, sujeita a configuração incorreta, desatualização ou comprometimento.
O sandbox limita o resultado. O OpenShell concede ao processo somente a autoridade permitida pela política. Se prompt e harness falharem, o sistema operacional ainda pode negar uma operação de arquivo, rede ou processo antes que ela ocorra.

O trabalho ao vivo nesta página mede essa camada final. Você tentará uma ação, observará o veredicto de permissão ou negação, e conectará o veredicto ao mecanismo que o executou.

Por que a execução pertence abaixo do modelo

Assumir que um pedido de aparência válida ainda pode ser prejudicial

Zero trust rejeita a confiança implícita baseada apenas em de onde veio uma solicitação. O prompt-injection guidelines da OWASP aplica a mesma disciplina aos agentes: restringir ferramentas, restringir privilégios e assumir que o conteúdo externo pode orientar o modelo.

Conceda apenas a autoridade de que a tarefa necessita

Saltzer e Schroeder descreveram isso como o princípio do menor privilégio: cada componente recebe apenas as permissões necessárias para o seu trabalho. Porque a disciplina precede os agentes, transfere-se de forma limpa para esta configuração.

Medir limites em vez de tentar provar intenção

O teorema de Rice exclui um teste geral para propriedades não triviais de programas arbitrários. Um agente que executa código exige a mesma cautela: meça os limites ao redor da execução em vez de supor que uma verificação estática provará a segurança de todas as ações futuras.

Como os mecanismos sandbox respondem perguntas testáveis

Este launchable combina quatro mecanismos de sistema operacional. Cada um responde a uma pergunta que você pode testar, e juntos eles aplicam a política em mais de um limite. Leia a política ao vivo mais tarde nesta página antes de tratar qualquer garantia como universal.

Regras de prompt e proteções da aplicação orientam o agente; a contenção do kernel impõe o limite final. A seta bloqueada representa uma ação interrompida antes de chegar ao disco ou à rede.

1 · Onde este processo pode se conectar?

Um namespace de rede (netns) fornece ao agente uma stack de rede isolada. A saída começa bloqueada. Um proxy HTTP CONNECT oferece o único caminho externo. O Open Policy Agent (OPA) compara o binário solicitante, host, porta e caminho com a política. Quem controla essa política decide quais conexões são permitidas.

2 · Quais arquivos ele pode alcançar?

O Landlock é um módulo de segurança do Linux que restringe acessos futuros ao sistema de arquivos. Aqui, ele limita novas operações aos caminhos concedidos pela política. A aplicação é forte, mas o modo de compatibilidade, o OverlayFS e descritores abertos antes da restrição ainda importam. Leia a política ativa e teste o caminho que pretende expor.

3 · Quais as operações do kernel que ele pode solicitar?

Uma chamada de sistema, ou syscall, pede ao kernel Linux que execute uma operação. O seccomp filtra syscalls; um filtro BPF compara cada solicitação com uma lista permitida. Uma chamada negada retorna EPERM (“operação não permitida”) antes da execução. Este launchable bloqueia primitivas perigosas como ptrace, mount e setuid.

4 · Com que autoridade começa?

O agente é executado como um processo sem privilégios de root sob o usuário sandbox. Portanto, uma exploração bem-sucedida começa com menos autoridade. Isso reduz o raio de impacto, mas não prova que uma escalada seja impossível. A configuração do host e do contêiner e a política de syscalls continuam fazendo parte do limite de segurança.

Vocabulário nestes quatro mecanismos

Política da rede

Espaço de nomes da rede / netns: Rede Linux isolada stack: dispositivos, rotas, regras de firewall e portas de soquete. network_namespaces(7)
Entrada / saída: Entrada é tráfego entrando no sandbox; saída é tráfego deixando-o. Negação padrão significa que nenhuma direção está aberta, a menos que a política o conceda.
Proxy CONNECT: Proxy de túnel HTTP para uma máquina e porta solicitadas; implementações seguras restringem alvos permitidos. MDN CONNECT
OPA: Motor de política que avalia a entrada estruturada e retorna decisões ao código de execução. Documentos da OPA
Binário, máquina, porto, caminho: Entradas de política de saída: identidade executável, nome do alvo, porta TCP e caminho de URL solicitado.

Limite do sistema de arquivos

Landlock: Módulo de segurança Linux que permite que um processo sem privilégios restrinja seu próprio acesso futuro. Docs Kernel
Direitos ambientais: O acesso a um processo herdaria do sistema operacional, processo pai, montagens ou credenciais.
Árvore Workspace: O diretório subtree uma política concede. Verifique a política ao vivo e compatibilidade do kernel antes de tratá-lo como um limite completo do sistema de arquivos.
Montagem de ligação: Uma subárvore do sistema de arquivos é exposta em outro caminho, inclusive através de limites de chroot. mount(2)
Corrida Symlink: Um caminho marcado muda através de um link simbólico antes de ser usado. ligação simbólica( 7)

Limite do Syscall

seccomp: Linux syscall filtrando que reduz a superfície do kernel alcançável por um processo. Docs Kernel
Syscall allowlist: Conjunto de syscalls permitidas; todas as demais recebem a ação definida pela política.
Camada de FBP: Filtrar o programa que verifica os números e argumentos do syscall antes da execução. Docs Kernel
TOCTOU / corrida de inspecção: Erro de tempo de verificação/tempo de uso; seccomp evita corridas de desreferência de ponteiros dentro do filtro. Docs Kernel
EPERM / EACCES: Linux errno nomes para operação não permitidos e permissão negada. errno(3)

Identidade do processo

Processo do agente: O processo OS rodando o agente e ferramentas dentro desses limites.
Usuário sem privilégios de root: Um UID não-zero sujeito a verificações normais de permissões do kernel. capacidades(7)
Capacidade do Linux: Um poder de raiz dividido, como CAP_SYS_ADMIN ou CAP_SETUID. capacidades(7)
ptrace, mount, setuid: Primitivas perigosas para controle de processos, montagem do sistema de arquivos e mudança de identidade. ptrace(2) · mount(2) · setuid(2)
Aumento do privilégio: Ganhando autoridade além da atribuição: root, recursos extras, acesso a arquivos mais amplos ou acesso à rede mais amplo.

Formar primeiro o runtime

Antes de dirigir o sandbox você mesmo, torne o agente saudável recuperando o runtime se ele estiver degradado, de modo que cada célula viva abaixo tenha um agente de trabalho para conversar.

O diagrama mostra o caminho de cada chamada de ferramenta. As células seguintes permitem executar essas chamadas e ler a resposta do kernel.

O mesmo runtime do Kickstart. Cada célula controla o agente OpenClaw conectado naquela página.

Assista ao kernel decidir

Os quatro mecanismos anteriores estão ativos no ambiente do laboratório. Assim, você pode observar cada decisão em vez de confiar apenas no diagrama.

A célula abaixo executa um comando de cada vez no sandbox e devolve três informações:

o veredito que o kernel devolveu,
o mecanismo que o decidiu,
e a linha de provas por trás dessa decisão.

O catálogo inicial reúne perguntas que vão do acesso à internet aberta até a reescrita da persona do agente. Você pode editar qualquer comando ou adicionar outra sonda.

Profundo · TrajetóriaExecutar uma trajetória de vários comandos no sandbox?

Indo mais longe: uma trajetória inteira

Um agente real encadeia vários comandos para alcançar um objetivo que nenhuma célula isolada tentou. Descreva um objetivo abaixo. O agente planeja a sequência de comandos de shell, executa cada um no sandbox e mostra os resultados em ordem. Observe onde o kernel interrompe a trajetória porque a política nega a próxima ação.

A regra dos comandos isolados continua válida: um segredo exibido em qualquer etapa já vazou, mesmo que uma tentativa posterior de saída seja negada. Depois de observar esse limite, edite o objetivo ou o prompt de planejamento e execute outra trajetória.

Leia a política ao vivo do seu launchable e veja-a como um mapa

Os vereditos observados vêm de um arquivo de política. Leia a política do launchable antes de confiar em suas garantias. A célula abaixo chama helpers.policyGet(), executa openshell policy get pelo terminal do operador e analisa o resultado.

A partir daqui, a página usa a política da sua instância, não um exemplo fixo. O código da célula fica recolhido; abra-o quando quiser inspecionar a chamada exata.

A célula desenha a política como um mapa interativo. Os nós à direita incluem endpoints citados pela política e alguns destinos não permitidos. Troque o binário chamador e observe as conexões mudarem. A decisão considera o programa, não apenas o host: integrate.api.nvidia.com pode ser acessível ao openclaw e negado ao curl.

Clique em um destino para abrir a regra correspondente, os binários autorizados e a justificativa do veredito. Ver código-fonte da política mostra o mesmo YAML lido na etapa anterior.

Plano de escalada. A faixa âmbar representa o plano de controle acima do ponto de aplicação. As regras de saída do agente não enxergam esse eixo.

Preveja o veredito e confirme na instância ativa

openshell policy prove verifica uma propriedade da política ou devolve um contraexemplo. Em cada conexão, o proxy também produz uma decisão determinística de permitir ou negar. A célula calcula o resultado a partir da política do launchable, executa a ação no sandbox e compara a resposta real com a previsão.

O exercício destaca a identidade do binário. A política concede saída por programa, não apenas por host. Por isso, openclaw pode alcançar o endpoint de inferência enquanto um curl para o mesmo destino é negado. Escolha uma ação para ver o veredito estático e a confirmação ativa.

A confirmação usa a instância real. Cada ação é executada no launchable conectado no Kickstart por openshell sandbox exec. Mantenha o launchable aberto em outra aba para preservar a sessão de acesso.

Quando previsão e resultado concordam, a política ativa corresponde à análise estática. Uma divergência indica configuração inesperada, diferença no ambiente ou lacuna no modelo de análise. Investigue antes de confiar no limite.

Acima do sandbox: o plano de controle

Até aqui, você mediu o que o agente pode fazer. Agora considere quem pode reconfigurá-lo pelo plano acima do sandbox. Nesta instância, esse plano é o gateway acessado pelo OPENCLAW_GATEWAY_TOKEN do Módulo 3, com escopo operator.admin. Suas operações não passam pelo sandbox do agente.

O que aquela credencial alcança:

agents.files.get lê e define diretamente os arquivos da persona, como SOUL.md e AGENTS.md.
cron.add e cron.list controlam tarefas que podem disparar depois do fim da conversa.
config.get e config.patch toda a configuração do agente: modelo, ferramentas, até mesmo toolSearch.
chat.send injeta uma mensagem durante uma tarefa e pode redirecionar o agente.
sessions.reset e delete apagam memória; gateway.restart.request reinicia o runtime.

Combinadas, essas chamadas formam um caminho de escalada. Um invasor pode ler a persona, criar uma tarefa cron para execução posterior, ampliar a configuração, redirecionar uma tarefa ativa e reiniciar o runtime para aplicar a nova forma.

O sandbox governa as syscalls do agente; essas operações pertencem ao plano de controle. A robustez do sandbox e o alcance administrativo são propriedades diferentes. Avalie as duas.

O sandbox pode conter erros e até o comprometimento direto do agente, mas não enxerga quem controla o plano administrativo. Proteja esse acesso como root. Nesta instância, ele permite reconfigurar a identidade e criar agendamentos fora do alcance das verificações do sandbox.

Enumere esse alcance no launchable. A célula apenas lê e não altera a configuração.

O que o sandbox não pode capturar

O kernel limitou as ações do agente, mas duas classes de dano permanecem. A primeira vem do plano de controle, que reconfigura o agente acima do ponto de aplicação. A segunda usa um envelope autorizado: cada ação isolada é permitida, mas sua composição causa o dano.

Entrada não confiável, acesso a dados privados e comunicação externa formam a tríade letal.

Dados privados são informações que o agente pode ler, mas não deve divulgar: arquivos do workspace, e-mails, tokens, memória ou registros internos.
Entrada não confiável é conteúdo não escrito pelo operador que o modelo pode interpretar como instrução: página web, issue, documento, resultado de ferramenta ou resposta de outro agente.
Comunicação externa é qualquer caminho capaz de transportar bytes para fora: HTTP, pull request, chat, linha de log, carregamento de imagem ou link aberto pelo usuário.

O risco surge da composição. A política pode autorizar corretamente um endpoint, mas a conexão continua bidirecional: a solicitação sai e a resposta volta como nova entrada. Conteúdo hostil pode orientar o modelo a ler dados privados e enviá-los por um canal permitido. Um controle acima do sandbox precisa interromper pelo menos uma dessas três condições.

O centro vermelho mostra um caminho formado por recursos permitidos, não uma ação isolada proibida. Conteúdo hostil orienta um runtime que lê estado protegido e usa um canal aprovado. Como o canal também recebe respostas, uma lista de permissões de rede não basta para decidir se a conexão é segura.

Essas lacunas existem em uma configuração padrão, e a política de rede e do sistema de arquivos não consegue resolvê-las sozinha:

Alteração da persona. SOUL.md pertence ao agente e permite gravação; um agente confuso ou comprometido pode reescrever a própria identidade. O proprietário consegue desfazer chmod. Um chattr +i aplicado por root, fora do sandbox, cria um limite mais forte.
Plano de controle no nível da identidade. Quem possui OPENCLAW_GATEWAY_TOKEN pode ler a persona, criar uma tarefa cron e injetar um turno acima do ponto de aplicação do kernel.
Injeção por entrada. Bloquear a saída por padrão impede alguns vazamentos, mas não remove instruções maliciosas recebidas por um canal autorizado. Essa é a injeção indireta de prompt descrita por Greshake e colegas. Mitigá-la exige procedência, classificação de entrada e avaliação comportamental.
Exfiltração por canal permitido. Um endpoint autorizado ainda pode transportar dados indevidos. A política prova que o canal é permitido; não determina se o conteúdo é benigno.
Intenção oculta. O gateway encaminha ações sem expor o raciocínio do modelo. Um agente comprometido pode executar um workflow prejudicial inteiramente com ações que, isoladas, parecem válidas.
Preservação entre pares. Em uma frota, o contexto social pode alterar o julgamento de um agente ao avaliar ou desligar outro. Testes de regressão comportamental precisam detectar essa mudança.

Escolha o controle pelo modo de falha

Um sandbox limita o que um processo comprometido pode alcançar. A aplicação e prática operacional ainda possuem decisões cujo significado é invisível para o kernel.

Modo de falha	O que o sandbox contribui	Controle ainda necessário acima dele
Sequestro de objetivos ou injeção de prompt	Limita arquivos, processos e destinos alcançáveis depois que o modelo é desviado	Procedência da entrada, aprovação de ações com consequências e avaliação comportamental
Mau uso da ferramenta	Restringe o OS e o envelope de rede em que a ferramenta é executada	Autorização por ferramenta, validação de argumentos, limites de taxa e confirmação de chamadas irreversíveis
Abuso de identidade ou privilégio	Inicia o processo sem root e bloqueia caminhos selecionados de escalada	Identidades por carga de trabalho, escopos mínimos, tokens de curta duração, rotação e auditoria
Cadeia de fornecimento ou execução inesperada de código	Reduz os arquivos, syscalls e egress disponíveis para o código instalado	Dependências definidas e verificadas, política de instalação e monitoramento da integridade
Envenenamento de memória ou contexto	Pode proteger arquivos específicos quando a política os torna somente para leitura	Procedência das gravações, histórico auditável, rótulos de confiança e restauração de um estado conhecido

As categorias se alinham com o OWASP Top 10 para Aplicações Agenticas. Use a tabela para escolher um ponto de execução em vez de pedir uma camada para reconhecer todos os tipos de dano.

O sandbox estabelece uma base, não uma defesa completa. Conceda ao agente o menor envelope necessário, prove o que ele garante e acrescente controles nas camadas superiores para as falhas invisíveis ao kernel.

Referências

Simon Willison, The lethal trifecta (2025). Define a combinação de dados privados, conteúdo não confiável e acesso à rede representada pelo diagrama da tríade letal no Passo 3.
Greshake et al. (2023) Not what you've signed up for. Trabalho de referência sobre injeção indireta de prompt: ataques entregues por conteúdo recuperado ou renderizado no qual o modelo confia.
Saltzer e Schroeder, The Protection of Information in Computer Systems (1975). Trabalho que nomeou o princípio do menor privilégio, base da contenção com bloqueio por padrão.
seccomp filter e Landlock. Primitivas do kernel para listas de syscalls permitidas e controle de acesso ao sistema de arquivos, usadas pelo openshell nos mecanismos 2 e 3.
Open Policy Agent. Mecanismo de política como dados que avalia o proxy CONNECT e controla cada conexão de saída.
NeMo Guardrails. Complemento na camada da aplicação para a contenção no kernel; detecta violações de política que o kernel não consegue interpretar.
OWASP Top 10 for Agentic Applications. Taxonomia atual de sequestro de objetivos, uso indevido de ferramentas, abuso de identidade, comprometimento da cadeia de suprimentos, execução inesperada de código e envenenamento de memória.

Lista completa em Próximos passos · Referências.

← Módulo 3c: Sempre ligado Módulo 4b: CLIs modernos →