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
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:
- Omitir
gateway.bindenquanto associações que não sejam local loopback são negadas significa que você aceita o padrão do runtime; definagateway.bind: "loopback"para obter conformidade estrita. - Para um agente somente leitura, defina o
modedo sandbox comoallounon-mainnos padrões ou no agente aplicável e definaworkspaceAccesscomononeouro. Um modo de sandbox ausente ou definido comooffnão atende a uma política somente leitura. agents.workspace.denyToolsaceitaexec,process,write,edit,apply_patch. Os grupos de negação de ferramentas da configuraçãogroup:fs(alteração de arquivos) egroup:runtime(shell/processo) atendem à postura equivalente.- As verificações de aprovações de execução leem o artefato ativo
exec-approvals.jsonsomente quando há uma regraexecApprovals; 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
Usescopes.<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.
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 runtimeexec-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):
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 emplugins.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:
- Crie ou revise
policy.jsonc. - Execute
openclaw policy check --json. - Se não houver constatações, registre
attestation.policy.hashcomoexpectedHash. - Registre
attestation.attestationHashcomoexpectedAttestationHash. - Execute novamente
openclaw doctor --lintna CI ou nos controles de lançamento.
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:
--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=falsequando uma política global proíbe ferramentas elevadas - adicionar IDs ausentes de ferramentas cuja negação é obrigatória a
tools.denyouagents.list[].tools.denyquando a política exige que essas ferramentas sejam negadas - definir opções inseguras de
gateway.controlUi.*comofalse - definir
gateway.mode=localquando a política nega o modo remoto do Gateway - definir os caminhos informados de
gateway.http.endpoints.*.enabledcomofalsequando a política nega endpoints da API HTTP do Gateway - definir os caminhos informados de
groupPolicyda entrada do canal comoallowlistquando a política nega a entrada aberta de grupos - definir os caminhos informados de
requireMentionda entrada do canal comotruequando a política exige menções em grupos - definir
logging.redactSensitive=toolsquando a política exige a ocultação de dados sensíveis nos logs - definir
diagnostics.otel.captureContent=false, oudiagnostics.otel.captureContent.enabled=falsepara configurações de captura de telemetria no formato de objeto, quando a política nega a captura de conteúdo de telemetria
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.