Skip to main content

openclaw policy

openclaw policy é fornecido pelo Plugin de Política incluído. Ele é uma camada de conformidade empresarial sobre as configurações existentes do OpenClaw, não um segundo sistema de configuração. Você define os requisitos em policy.jsonc; o OpenClaw observa o workspace ativo como evidência; a política relata desvios por meio de doctor --lint. A política não impõe chamadas de ferramentas nem reescreve o comportamento do runtime no momento da solicitação e não atesta armazenamentos de credenciais por agente, como auth-profiles.json. A política verifica canais configurados, servidores MCP, provedores de modelos, postura de SSRF da rede, acesso de entrada/canais, exposição do Gateway e postura de comandos de Node, acesso dos agentes ao workspace, postura de sandbox, postura de tratamento de dados, postura de provedores de segredos/perfis de autenticação e metadados de ferramentas sob governança (TOOLS.md). Use-a quando um workspace precisar de uma declaração durável e verificável, como “o Telegram não deve estar habilitado” ou “ferramentas sob governança devem declarar metadados de risco e responsável”. Se você precisar apenas de comportamento local, sem atestação ou detecção de desvios, a configuração comum é suficiente.

Início rápido

O Plugin permanece habilitado mesmo quando policy.jsonc está ausente, para que o doctor possa relatar a ausência do artefato em vez de ignorar silenciosamente as verificações. Crie policy.jsonc manualmente; ele não é gerado com base nas configurações atuais. Cada seção de nível superior é um namespace de regras: uma verificação só é executada quando há uma regra concreta nela (seções ou chaves não compatíveis falham como policy/policy-jsonc-invalid, em vez de serem ignoradas silenciosamente). Exemplo mínimo que abrange todas as seções compatíveis:
Observações abrangentes que não são evidentes nas tabelas de regras abaixo:
  • Omitir gateway.bind enquanto associações que não sejam local loopback são negadas significa que você aceita o padrão do runtime; defina gateway.bind: "loopback" para obter conformidade estrita.
  • Para um agente somente leitura, defina o mode do sandbox como all ou non-main nos padrões ou no agente aplicável e defina workspaceAccess como none ou ro. Um modo de sandbox ausente ou definido como off não atende a uma política somente leitura.
  • agents.workspace.denyTools aceita exec, process, write, edit, apply_patch. Os grupos de negação de ferramentas da configuração group:fs (alteração de arquivos) e group:runtime (shell/processo) atendem à postura equivalente.
  • As verificações de aprovações de execução leem o artefato ativo exec-approvals.json somente quando há uma regra execApprovals; um artefato ausente ou inválido constitui evidência não observável, não uma aprovação sintética.
  • As evidências de segredos e perfis de autenticação registram apenas a postura do provedor/origem e os metadados de SecretRef, nunca valores brutos. A política não lê nem atesta armazenamentos de credenciais por agente, como auth-profiles.json.
  • A evidência de tratamento de dados representa apenas a postura no nível da configuração (modo de redação, controle de captura de telemetria, modo de manutenção de sessões e configuração de indexação de transcrições). Ela não inspeciona logs, exportações de telemetria, transcrições ou arquivos de memória, e um resultado sem problemas não comprova que eles não contenham dados pessoais ou segredos.

Referência das regras de política

Todas as regras abaixo são opcionais; uma verificação só é executada quando a regra está presente. O estado observado corresponde à configuração existente do OpenClaw ou aos metadados do workspace.

Sobreposições com escopo

Use scopes.<scopeName> quando agentes ou canais específicos precisarem de uma política mais estrita que a linha de base de nível superior. O nome do escopo é apenas um rótulo; a correspondência usa o seletor dentro do escopo. As sobreposições são aditivas: a regra global continua sendo executada, e a regra com escopo pode adicionar sua própria constatação sobre a mesma evidência. Se uma entrada de agentIds não estiver presente em agents.list[], o OpenClaw avalia a regra com escopo em relação à postura global/padrão herdada para esse ID de agente de runtime, em vez de ignorá-la.
O mesmo agente pode aparecer em vários escopos se cada escopo controlar um campo diferente, como no exemplo acima. Um campo com escopo repetido para o mesmo agente deve ser igualmente ou mais restritivo; uma declaração duplicada mais permissiva é rejeitada (listas de permissões devem ser subconjuntos, listas de negações devem ser superconjuntos e booleanos obrigatórios são fixos). As regras de postura de contêiner (sandbox.containers.*) são verificadas apenas em relação às evidências que o backend de sandbox do agente correspondente consegue expor. Se um backend não puder observar uma regra habilitada para ele, a política relatará policy/sandbox-container-posture-unobservable em vez de aprová-la; aplique as regras de contêiner aos grupos de agentes que usam um backend capaz de expô-las. ingress.session.requireDmScope no nível superior permanece global; session.dmScope não é uma evidência atribuível a um canal e, portanto, não pode receber escopo por channelIds. Todos os escopos presentes em policy.jsonc devem ser válidos e aplicáveis.

Canais

Servidores MCP

Provedores de modelos

Rede

Entrada e acesso a canais

Gateway

gateway.nodes.denyCommands é uma regra exata, com distinção entre maiúsculas e minúsculas, que exige um superconjunto de negações. Use-a quando a política precisar comprovar que comandos privilegiados de Node estão explicitamente negados pela configuração do OpenClaw. Uma implantação que permita intencionalmente um comando privilegiado de Node deve atualizar policy.jsonc após a revisão, em vez de depender apenas de gateway.nodes.allowCommands.

Espaço de trabalho do agente

Postura do sandbox

A política considera a ausência de sandbox.mode como seu padrão implícito off; portanto, sandbox.requireMode informa que um sandbox novo ou não configurado está fora de uma lista de permissões como ["all"].

Tratamento de dados

Segredos

Aprovações de execução

As verificações de aprovação de execução leem o artefato de runtime exec-approvals.json: ~/.openclaw/exec-approvals.json por padrão ou $OPENCLAW_STATE_DIR/exec-approvals.json quando OPENCLAW_STATE_DIR estiver definido. As regras de postura em execApprovals.defaults.* ou execApprovals.agents.* exigem evidências legíveis do artefato; um artefato ausente ou inválido é informado como evidência não observável, em vez de uma aprovação baseada em melhor esforço. Quando o artefato é legível, os campos omitidos herdam os padrões do runtime: a ausência de defaults.security equivale a full, e a ausência da segurança do agente herda esse padrão. As evidências incluem defaults, agents.*, agents.*.allowlist[].pattern, o argPattern opcional, a postura efetiva de autoAllowSkills e a origem da entrada — nunca o caminho/token do socket, commandText, lastUsedCommand, caminhos resolvidos ou carimbos de data e hora. Exemplo: exigir o artefato de aprovações, negar padrões permissivos e permitir apenas a postura revisada de aprovação de execução para agentes selecionados.

Perfis de autenticação

Metadados de ferramentas

Postura das ferramentas

Executar verificações

Execute verificações exclusivas da política durante a criação:
policy check executa apenas o conjunto de verificações da política e emite evidências, constatações e hashes de atestado. As mesmas constatações também aparecem em openclaw doctor --lint quando o Plugin Policy está ativado. Compare um arquivo de política do operador com uma linha de base criada:
policy compare compara a sintaxe de um arquivo de política com a sintaxe de outro arquivo de política; ele não inspeciona o estado de execução, as evidências, as credenciais nem os segredos. Ele usa os mesmos metadados de regras que regem as sobreposições por escopo: as allowlists devem permanecer iguais ou mais restritas, as listas de bloqueio devem permanecer iguais ou mais abrangentes, os booleanos obrigatórios devem manter seu valor, as strings ordenadas só podem avançar em direção à extremidade mais restritiva da ordem configurada e as listas exatas devem corresponder. A linha de base pode ser uma política criada pela organização; a política verificada pode adicionar valores mais restritivos ou regras adicionais. Uma regra de nível superior na política verificada pode satisfazer uma regra de linha de base com escopo quando for igualmente ou mais restritiva. Os nomes dos escopos não precisam coincidir entre os arquivos; a comparação é indexada pelo seletor (agentIds/channelIds) e pelo campo. Comparação sem constatações (--json):
A saída sem constatações de policy check --json inclui hashes estáveis que um operador ou supervisor pode registrar:

Configurar a política

A configuração da política fica em plugins.entries.policy.config.
Defina plugins.entries.policy.config.enabled como false para desativar as verificações da política em um espaço de trabalho sem desinstalar o Plugin.

Aceitar o estado da política

Exemplo de saída JSON:
attestation.policy.hash identifica o artefato de regras criado. evidence registra o estado observado do OpenClaw usado pelas verificações, e workspace.hash identifica essa carga de evidências. findingsHash identifica o conjunto exato de constatações. checkedAt registra quando a verificação foi executada. attestationHash identifica a declaração estável (hash da política, hash das evidências, hash das constatações e estado sem/com constatações) e exclui deliberadamente checkedAt, portanto o mesmo estado da política sempre produz o mesmo hash de atestado. Juntos, esses quatro valores formam a tupla de auditoria de uma verificação da política. Se um Gateway ou supervisor usar a política para bloquear, aprovar ou anotar uma ação de execução, ele deverá registrar o hash de atestado da última verificação sem constatações. checkedAt permanece na saída JSON para os logs de auditoria, mas não faz parte do hash estável. Ciclo de vida para aceitar o estado da política:
  1. Crie ou revise policy.jsonc.
  2. Execute openclaw policy check --json.
  3. Se não houver constatações, registre attestation.policy.hash como expectedHash.
  4. Registre attestation.attestationHash como expectedAttestationHash.
  5. Execute novamente openclaw doctor --lint na CI ou nos controles de lançamento.
Se as regras de política mudarem intencionalmente, atualize ambos os hashes aceitos com base em uma verificação limpa. Se apenas as configurações do espaço de trabalho mudarem (a política permanecer igual), normalmente apenas expectedAttestationHash será alterado. Ativar ou atualizar as regras de agents.workspace adiciona evidências de agentWorkspace ao hash do espaço de trabalho e ao hash de atestação; revise as novas evidências e atualize os hashes de atestação aceitos após a ativação. Ativar ou atualizar as regras de postura das ferramentas adiciona evidências de toolPosture da mesma forma. openclaw policy watch executa novamente a verificação e informa quando as evidências atuais deixam de corresponder a expectedAttestationHash:
Use --once em CI ou scripts que precisem de uma única avaliação de desvio. Sem --once, por padrão, ele consulta a cada dois segundos; use --interval-ms para alterar o intervalo.

Constatações

Uma constatação pode incluir tanto target (o item observado no espaço de trabalho que não está em conformidade) quanto requirement (a regra definida que originou a constatação). Atualmente, ambos são strings de endereço oc://, mas os nomes dos campos descrevem a função na política, e não o formato do endereço. Exemplos de constatações:

Reparo

doctor --lint e policy check são somente leitura. doctor --fix edita as configurações do espaço de trabalho gerenciadas por política somente quando workspaceRepairs está explicitamente habilitado; caso contrário, as verificações informam o que reparariam e deixam as configurações inalteradas. Nesta versão, o reparo pode desabilitar canais negados por channels.denyRules e aplicar os reparos automáticos de restrição listados abaixo. Habilite workspaceRepairs somente depois que o arquivo de política tiver sido revisado, pois uma regra válida pode alterar a configuração do espaço de trabalho:
  • definir tools.elevated.enabled=false quando uma política global proíbe ferramentas elevadas
  • adicionar IDs ausentes de ferramentas cuja negação é obrigatória a tools.deny ou agents.list[].tools.deny quando a política exige que essas ferramentas sejam negadas
  • definir opções inseguras de gateway.controlUi.* como false
  • definir gateway.mode=local quando a política nega o modo remoto do Gateway
  • definir os caminhos informados de gateway.http.endpoints.*.enabled como false quando a política nega endpoints da API HTTP do Gateway
  • definir os caminhos informados de groupPolicy da entrada do canal como allowlist quando a política nega a entrada aberta de grupos
  • definir os caminhos informados de requireMention da entrada do canal como true quando a política exige menções em grupos
  • definir logging.redactSensitive=tools quando a política exige a ocultação de dados sensíveis nos logs
  • definir diagnostics.otel.captureContent=false, ou diagnostics.otel.captureContent.enabled=false para configurações de captura de telemetria no formato de objeto, quando a política nega a captura de conteúdo de telemetria
Os reparos com escopo para ferramentas elevadas são somente de detecção. Os reparos com escopo para tratamento de dados também são ignorados quando a constatação informa uma configuração compartilhada de logs ou telemetria, pois alterar a configuração compartilhada afetaria mais do que o alvo da política com escopo. Os reparos com escopo para negação obrigatória são ignorados quando a constatação informa tools.deny raiz herdado, pois adicionar a ferramenta obrigatória à configuração raiz afetaria mais do que o alvo da política com escopo. Os reparos de negação obrigatória locais do agente podem atualizar o caminho informado de agents.list[].tools.deny. Os reparos com escopo da entrada do canal são ignorados quando a constatação informa channels.defaults.* herdado, pois alterar o padrão compartilhado do canal afetaria mais do que o alvo da política com escopo. As constatações de lista de permissões para busca de URLs HTTP do Gateway permanecem manuais, pois o reparo automático não pode escolher os valores corretos da lista de permissões de URLs do endpoint. As constatações de vinculação e de comandos de Node do Gateway continuam exigindo revisão. Quando policy/gateway-non-loopback-bind ou policy/gateway-node-command-denied podem ser mapeadas para um caminho de configuração, doctor --fix informa a alteração proposta de gateway.bind ou gateway.nodes.denyCommands como uma orientação de prévia ignorada. Ele não aplica a alteração, e a constatação não é considerada reparada até que um operador revise e atualize a configuração ou a política.

Códigos de saída

Relacionado