Módulo 4 · Parte A de 3

Sandbox do OpenShell

No módulo 3, os arquivos forneciam contexto persistente e as tarefas agendadas iniciavam trabalho sem supervisão. Essas operações dependem das permissões disponíveis para o processo do agente. O OpenShell limita essas permissões por meio da política ativa e de sua aplicação.

Execute comandos no sandbox, examine a saída e o código de saída e investigue a causa. Depois, examine o acesso de leitura pelo plano de controle do operador.

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.

Por que a aplicação de políticas deve ficar 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. A orientação sobre injeção de prompts 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.

A seta bloqueada ilustra uma possível ação negada. O resultado de um comando, por si só, não identifica o mecanismo responsável.

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: Stack de rede Linux isolada: dispositivos, rotas, regras de firewall e portas de sockets. 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 que aplica as políticas. Documentos da OPA
Binário, host, porta, 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
Permissões herdadas do ambiente: Acesso que um processo herdaria do sistema operacional, do processo pai, das montagens ou das credenciais.
Árvore Workspace: A subárvore de diretórios permitida por uma política. Verifique a política ativa e a compatibilidade do kernel antes de tratá-la 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. symlink(7)

Limite do Syscall

seccomp: Filtragem de syscalls do Linux que reduz a superfície do kernel acessível a um processo. Docs Kernel
Syscall allowlist: Conjunto de syscalls permitidas; todas as demais recebem a ação definida pela política.
Camada BPF: Programa de filtragem que verifica os números e argumentos das syscalls 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: Nomes errno do Linux para “operação não permitida” 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. capabilities(7)
Capacidade do Linux: Um privilégio de root separado, como CAP_SYS_ADMIN ou CAP_SETUID. capabilities(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 representa os limites de aplicação. Os comandos seguintes retornam observações; identificar o mecanismo responsável exige evidências da política ou de auditoria.

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

A seta bloqueada ilustra uma possível ação negada. O resultado de um comando, por si só, não identifica o mecanismo responsável.

Examinar os resultados dos comandos

Execute um comando por vez e examine sua saída, seu status de saída e se ele terminou. Uma falha pode decorrer da política, de software ausente, de uma solicitação inválida ou do próprio serviço. Use as evidências e a política atual para investigar a causa.

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.

Executar uma trajetória de vários comandos no sandbox?

Indo mais longe: uma trajetória inteira

Um agente pode planejar vários comandos para um objetivo. Examine o plano e compare cada comando com a saída e o status de saída retornados pelo sandbox. Identifique quais resultados indicam acesso negado e quais precisam de mais investigação.

Um segredo impresso por um comando permitido já chegou ao canal de saída. Examine tanto as etapas bem-sucedidas quanto as falhas: uma negação de acesso à rede posterior não desfaz uma divulgação anterior.

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

Leia a política do ambiente de execução antes de interpretar os resultados dos comandos. A célula chama helpers.policyGet() pelo terminal do operador e exibe seu status e o YAML analisado. Verifique se a política retornada está ativa.

O mapa avalia os destinos propostos com base na política carregada. Altere o binário que faz a chamada para comparar suas permissões e examine a regra correspondente. São previsões do navegador; as solicitações reais fornecem uma observação separada.

Ao clicar em um destino, você abre a regra que o governa e pode consultar quais binários esse endpoint permite e qual regra o avaliador do navegador usa. O controle View policy source exibe o YAML usado como origem, o mesmo texto que você acabou de buscar.

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.

Compare uma previsão da política com uma solicitação real

Escolha uma ação, preveja seu resultado com base na política carregada e execute a mesma solicitação pelo sandbox. Compare as evidências sem pressupor que um erro de comando comprova a aplicação da política ou que um resultado coincidente comprova todas as suas regras.

A previsão considera a identidade do binário, o destino, a porta, o método e o caminho. Confirm executa a solicitação curl selecionada. As outras identidades de binário continuam sendo previsões até você testar cada programa por sua própria interface.

Examine as duas observações. O navegador avalia a política, enquanto openshell sandbox exec retorna a saída e o status de saída do comando. Um erro HTTP pode vir de um proxy ou da aplicação de destino; identifique sua origem antes de atribuir uma causa.

A concordância sustenta a previsão para a ação testada. Uma divergência indica que é preciso verificar a solicitação, a política ativa, a origem da resposta e as premissas do avaliador.

Acima do sandbox: o plano de controle

A célula solicita operator.admin com o token de gateway existente e chama métodos de leitura de persona, agendamentos, sessões, modelos e configuração. Examine quais solicitações funcionam. A configuração do servidor pode permitir gravações administrativas, mas esta verificação não as testa. Ela não envia solicitações de edição; conexões e leituras ainda podem gerar registros.

O que o sandbox não pode capturar

A verificação de leitura não comprova autoridade de gravação. Separadamente, um fluxo prejudicial pode combinar leituras e canais de saída permitidos individualmente.

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.

Considere estes modos de falha diante da configuração real:

Alteração da persona. Se o agente puder modificar SOUL.md, examine a propriedade e as permissões de gravação. A política, a proteção de arquivos gerenciada pelo host e um histórico revisável podem ajudar a proteger as alterações de persona.
Autoridade do plano de controle. O escopo do token e a configuração do servidor determinam os métodos administrativos disponíveis. Leituras bem-sucedidas não comprovam permissão para alterar a persona, o agendamento ou a conversa.
Injeção de entrada. Um canal permitido pode transportar instruções adversárias. Restrições de rede não comprovam que o conteúdo recebido seja confiável; avalie separadamente o tratamento das entradas e as ações com consequências.
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. Ações permitidas individualmente podem se combinar em um workflow prejudicial. Revise seus efeitos conjuntos ao avaliar um log de ferramentas.
Preservação entre pares. O veredito de um agente sobre outro pode mudar conforme o contexto social. Compare seus julgamentos ao variar esse contexto de forma controlada.

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 aplicação de políticas em vez de pedir uma camada para reconhecer todos os tipos de dano.

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 →