openclaw policy

openclaw policy é fornecido pelo Plugin Policy incluído. A política é uma camada de conformidade empresarial sobre as configurações existentes do OpenClaw. Ela não adiciona um segundo sistema de configuração. policy.jsonc define requisitos declarados, o OpenClaw observa o workspace ativo como evidência, e as verificações de integridade da política relatam desvios por meio de doctor --lint. O sinal final de conformidade é uma execução limpa de doctor --lint; a política contribui com achados para essa superfície de lint compartilhada em vez de criar um gate de integridade separado.

Atualmente, a política gerencia canais configurados, servidores MCP, provedores de modelo, postura de SSRF de rede, postura de acesso de ingresso/canal, postura de exposição do Gateway, postura do workspace de agentes, postura de tratamento de dados, postura de provedor de segredo/perfil de autenticação da configuração do OpenClaw e declarações de ferramentas governadas. Por exemplo, a TI ou um operador de workspace pode registrar que Telegram não é um provedor de canal aprovado, restringir servidores MCP e refs de modelo a entradas aprovadas, exigir que o acesso de fetch/navegador à rede privada permaneça desativado, exigir que o isolamento de sessão de mensagem direta e a postura de ingresso de canal permaneçam dentro dos limites revisados, exigir que bind/autenticação/exposição HTTP do Gateway permaneçam dentro dos limites revisados, exigir que o acesso ao workspace do agente e negações de ferramentas permaneçam em uma postura revisada, exigir que SecretRefs da configuração do OpenClaw usem provedores gerenciados, exigir que perfis de autenticação da configuração carreguem metadados de provedor/modo, exigir que ferramentas governadas carreguem metadados de risco e sensibilidade, exigir redação de logs sensíveis, negar captura de conteúdo de telemetria, exigir manutenção de retenção de sessão, negar indexação em memória de transcrições de sessão e então usar doctor --lint como o gate de conformidade compartilhado.

Use a política quando um workspace precisar de uma declaração durável, como "estes canais não devem ser habilitados" ou "ferramentas governadas devem declarar metadados de aprovação", e de uma forma repetível de provar que o OpenClaw ainda está em conformidade com essa declaração. Use apenas a configuração regular e a documentação do workspace quando você só precisar de comportamento local e não precisar de achados de política ou saída de atestação.

Início rápido

Habilite o Plugin Policy incluído antes do primeiro uso:

openclaw plugins enable policy

Quando a política está habilitada, o doctor pode carregar verificações de integridade de política sem ativar plugins arbitrários. O Plugin permanece habilitado se policy.jsonc estiver ausente, para que o doctor possa relatar o artefato ausente.

A política é declarada, não gerada a partir das configurações atuais do usuário. Uma política mínima para canais, servidores MCP, provedores de modelo, postura de rede, acesso de ingresso/canal, exposição do Gateway, postura do workspace de agentes, postura de runtime de sandbox configurado, postura de tratamento de dados do OpenClaw, postura de provedor de segredo/perfil de autenticação da configuração, postura de arquivo de aprovação de exec e metadados de ferramenta se parece com isto:

{  "channels": {    "denyRules": [      {        "id": "no-telegram",        "when": { "provider": "telegram" },        "reason": "Telegram is not approved for this workspace.",      },    ],  },  "mcp": {    "servers": {      "allow": ["docs"],      "deny": ["untrusted"],    },  },  "models": {    "providers": {      "allow": ["openai", "anthropic"],      "deny": ["openrouter"],    },  },  "network": {    "privateNetwork": {      "allow": false,    },  },  "ingress": {    "session": {      "requireDmScope": "per-channel-peer",    },    "channels": {      "allowDmPolicies": ["pairing", "allowlist", "disabled"],      "denyOpenGroups": true,      "requireMentionInGroups": true,    },  },  "gateway": {    "exposure": {      "allowNonLoopbackBind": false,      "allowTailscaleFunnel": false,    },    "auth": {      "requireAuth": true,      "requireExplicitRateLimit": true,    },    "controlUi": {      "allowInsecure": false,    },    "remote": {      "allow": false,    },    "http": {      "denyEndpoints": ["chatCompletions", "responses"],      "requireUrlAllowlists": true,    },  },  "agents": {    "workspace": {      "allowedAccess": ["none", "ro"],      "denyTools": ["exec", "process", "write", "edit", "apply_patch"],    },  },  "dataHandling": {    "sensitiveLogging": {      "requireRedaction": true,    },    "telemetry": {      "denyContentCapture": true,    },    "retention": {      "requireSessionMaintenance": true,    },    "memory": {      "denySessionTranscriptIndexing": true,    },  },  "secrets": {    "requireManagedProviders": true,    "denySources": ["exec"],    "allowInsecureProviders": false,  },  "auth": {    "profiles": {      "requireMetadata": ["provider", "mode"],      "allowModes": ["api_key", "token"],    },  },  "execApprovals": {    "requireFile": true,    "defaults": { "allowSecurity": ["deny"] },    "agents": {      "allowSecurity": ["deny", "allowlist"],      "allowAutoAllowSkills": false,      "allowlist": { "expected": ["deploy", "status"] },    },  },  "tools": {    "requireMetadata": ["risk", "sensitivity", "owner"],    "profiles": {      "allow": ["messaging", "minimal"],    },    "fs": {      "requireWorkspaceOnly": true,    },    "exec": {      "allowSecurity": ["deny", "allowlist"],      "requireAsk": ["always"],      "allowHosts": ["sandbox"],    },    "elevated": {      "allow": false,    },    "denyTools": ["group:runtime", "group:fs"],  },}

As regras são a autoridade. Um bloco de categoria é apenas um namespace; as verificações são executadas quando uma regra concreta está presente. O OpenClaw lê as configurações atuais de channels.*, mcp.servers.*, models.providers.*, refs de modelo de agentes selecionados, configurações de SSRF de rede, escopo de sessão de mensagem direta, política de DM de canal, política de grupo de canal, gates de menção de canal/grupo, postura de bind/autenticação/Control UI/Tailscale/remoto/HTTP do Gateway, postura de acesso ao workspace de sandbox de agente da configuração do OpenClaw e negação de ferramentas, postura de configuração de tratamento de dados, proveniência de provedor de segredo e SecretRef da configuração, metadados de perfil de autenticação da configuração, postura de ferramenta global/por agente configurada e declarações de TOOLS.md como evidência, e então relata o estado observado que não está em conformidade. Se uma política negar binds de Gateway que não sejam local loopback, omita gateway.bind apenas quando você estiver disposto a revisar o padrão de runtime; defina gateway.bind=loopback para conformidade estrita da configuração. Para postura de agente somente leitura, configure o modo sandbox nos padrões ou agente aplicáveis e defina workspaceAccess como none ou ro; modo sandbox omitido ou off não satisfaz uma política somente leitura/sem escrita. agents.workspace.denyTools oferece suporte a exec, process, write, edit e apply_patch; a configuração do OpenClaw group:fs cobre ferramentas de mutação de arquivos e group:runtime cobre ferramentas de shell/processo. A política de postura de ferramentas observa tools.profile, tools.allow, tools.alsoAllow, tools.deny, tools.fs.workspaceOnly, tools.exec.security, tools.exec.ask, tools.exec.host, tools.elevated.enabled e as mesmas substituições por agente em agents.list[].tools.*. A política de aprovação de exec lê o artefato de produto exec-approvals.json nomeado somente quando uma regra execApprovals está presente; a evidência registra padrões, postura por agente e padrões de allowlist sem tokens de socket ou texto do último comando usado. A política não impõe chamadas de ferramentas em runtime. A evidência de segredo registra a postura de provedor/fonte e metadados de SecretRef, nunca valores brutos de segredo. A política não lê nem atesta armazenamentos de credenciais por agente, como auth-profiles.json; esses armazenamentos continuam pertencendo aos fluxos existentes de autenticação e credenciais. A evidência de tratamento de dados é apenas postura em nível de configuração: ela verifica o modo de redação configurado, alternâncias de captura de conteúdo de telemetria, modo de manutenção de sessão e configurações de indexação em memória de transcrições de sessão. Ela não inspeciona logs brutos, exportações de telemetria, conteúdos de transcrições, arquivos de memória nem prova que não existem dados pessoais ou segredos.

Referência de regras de política

Cada campo de política abaixo é opcional. Uma verificação é executada somente quando a regra correspondente está presente em policy.jsonc. O estado observado é a configuração existente do OpenClaw ou metadados do workspace; a política relata desvios, mas não reescreve o comportamento de runtime, a menos que um caminho de reparo esteja explicitamente disponível e habilitado. Arquivos de política são estritos: seções ou chaves de regra sem suporte são relatadas como policy/policy-jsonc-invalid em vez de serem ignoradas.

Sobreposições de política mantêm regras amplas de nível superior como globais e então permitem que blocos de escopo nomeados adicionem seções normais de política mais estritas para seletores explícitos. Um nome de escopo é apenas um agrupamento descritivo; a correspondência usa os valores de seletor dentro do escopo. A sobreposição é aditiva: declarações globais continuam sendo executadas, e uma declaração com escopo pode emitir seu próprio achado contra a mesma configuração observada.

Sobreposições com escopo

Use scopes.<scopeName> quando um conjunto de agentes ou canais precisar de política mais estrita do que a linha de base de nível superior. Seções com escopo de agente usam agentIds, que oferece suporte a tools.*, agents.workspace.*, sandbox.*, dataHandling.memory.* e execApprovals.*. Ingresso com escopo de canal usa channelIds, que oferece suporte a ingress.channels.*. Seções sem suporte são rejeitadas em vez de serem ignoradas. Se uma entrada agentIds não estiver presente em agents.list[], o OpenClaw avalia a regra com escopo contra a postura global/padrão herdada para esse id de agente de runtime.

{  "tools": {    "exec": {      "allowHosts": ["sandbox", "node"],    },  },  "sandbox": {    "requireMode": ["all", "non-main"],  },  "scopes": {    "release-workspace": {      "agentIds": ["release-agent", "review-agent"],      "agents": {        "workspace": {          "allowedAccess": ["none", "ro"],        },      },    },    "release-lockdown": {      "agentIds": ["release-agent"],      "tools": {        "exec": {          "allowHosts": ["sandbox"],          "allowSecurity": ["deny", "allowlist"],          "requireAsk": ["always"],        },        "denyTools": ["exec", "process", "write", "edit", "apply_patch"],      },      "sandbox": {        "requireMode": ["all"],        "allowBackends": ["docker"],      },      "dataHandling": {        "memory": {          "denySessionTranscriptIndexing": true,        },      },    },    "shell-sandbox": {      "agentIds": ["shell-agent"],      "sandbox": {        "allowBackends": ["openshell"],        "containers": {          "requireReadOnlyMounts": false,        },      },    },    "telegram-ingress": {      "channelIds": ["telegram"],      "ingress": {        "channels": {          "allowDmPolicies": ["pairing"],          "denyOpenGroups": true,          "requireMentionInGroups": true,        },      },    },  },}

O mesmo agente pode aparecer em vários escopos quando cada escopo governa campos diferentes, como mostrado acima. Um campo com escopo repetido para o mesmo agente deve ser igualmente ou mais restritivo de acordo com os metadados de política; declarações duplicadas mais fracas são rejeitadas. Metadados de rigor tratam allowlists como subconjuntos, denylists como superconjuntos e booleanos obrigatórios como requisitos fixos.

A política de postura de contêiner é avaliada somente contra evidências que o OpenClaw consegue observar para o agente correspondente. Se uma regra sandbox.containers.* habilitada se aplicar a um agente cujo backend de sandbox não consegue expor esse campo, a política relata policy/sandbox-container-posture-unobservable em vez de tratar a declaração como aprovada. Use escopos agentIds separados para grupos de agentes que usam backends de sandbox diferentes e deixe regras de contêiner sem suporte indefinidas ou falsas para os grupos em que esses campos não podem ser observados.

ingress.session.requireDmScope de nível superior permanece global porque session.dmScope não é evidência atribuível a canal.

Todo escopo presente em policy.jsonc deve ser válido e aplicável.

Canais

Servidores MCP

Provedores de modelo

Rede

Ingresso e acesso a canais

Gateway

Espaço de trabalho do agente

Postura do sandbox

A política trata sandbox.mode ausente como o padrão implícito off, portanto sandbox.requireMode relata um sandbox novo ou não configurado como fora de uma lista de permissões como ["all"].

Tratamento de dados

Segredos

Aprovações de exec

A política de aprovações de exec observa o artefato ativo de runtime exec-approvals.json. Por padrão, ele é ~/.openclaw/exec-approvals.json; quando OPENCLAW_STATE_DIR está definido, a Política lê $OPENCLAW_STATE_DIR/exec-approvals.json. Regras de postura reais como execApprovals.defaults.* ou execApprovals.agents.* exigem evidência de artefato legível; um artefato ausente ou inválido é relatado como evidência não observável em vez de se tornar uma aprovação de melhor esforço contra padrões sintéticos de runtime. Depois que o artefato é legível, campos de aprovação omitidos herdam os padrões de runtime: defaults.security ausente é full, e a segurança de agente ausente herda esse padrão. A evidência inclui defaults, agents.* e agents.*.allowlist[].pattern, além de argPattern opcional, postura efetiva de autoAllowSkills e origem da entrada. Ela não inclui caminho/token de socket, commandText, lastUsedCommand, caminhos resolvidos ou carimbos de data/hora.

Por exemplo, exija o artefato de aprovações, negue padrões permissivos e permita somente a postura revisada de aprovação de exec para agentes selecionados:

{  "execApprovals": {    "requireFile": true,    "defaults": {      // Security modes: "deny", "allowlist", or "full".      // This default permits only the locked-down deny posture.      "allowSecurity": ["deny"],    },  },  "scopes": {    "restricted-shell": {      "agentIds": ["family-agent", "groups-agent"],      "execApprovals": {        "agents": {          // Selected agents may use reviewed allowlist posture, but not "full".          "allowSecurity": ["allowlist"],          // false means skill CLIs must appear in the reviewed allowlist instead of          // being implicitly approved by autoAllowSkills.          "allowAutoAllowSkills": false,          "allowlist": {            "expected": [              // Simple entry: exact reviewed executable pattern with no argPattern.              "travel-hub",              // Constrained entry: pattern plus reviewed argument regex.              { "pattern": "calendar-cli", "argPattern": "^sync\\b" },              "/bin/date",            ],          },        },      },    },  },}

Perfis de autenticação

Metadados de ferramentas

Postura de ferramentas

Execute verificações somente de política durante a autoria:

openclaw policy checkopenclaw policy check --jsonopenclaw policy check --severity-min error

policy check executa somente o conjunto de verificações de política e emite evidências, achados e hashes de atestação. Os mesmos achados também aparecem em openclaw doctor --lint quando o Plugin de Política está habilitado.

Compare um arquivo de política do operador com um arquivo de política de baseline criado:

openclaw policy compare --baseline official.policy.jsoncopenclaw policy compare --baseline official.policy.jsonc --policy policy.jsonc --json

policy compare compara a sintaxe de arquivo de política com a sintaxe de arquivo de política. Ele não inspeciona estado de runtime do OpenClaw, evidências, credenciais ou segredos. O comando usa os mesmos metadados de regra de política que governam sobreposições com escopo: listas de permissão devem permanecer iguais ou mais restritas, listas de negação devem permanecer iguais ou mais amplas, booleanos obrigatórios devem manter seu valor obrigatório, strings ordenadas devem mover-se apenas em direção à extremidade mais restritiva da ordem configurada, e listas exatas devem corresponder.

O arquivo de baseline pode ser uma política criada pela organização. A política verificada pode usar valores mais estritos ou adicionar regras de política extras. Uma regra verificada de nível superior também pode satisfazer uma regra de baseline com escopo quando ela for igualmente ou mais restritiva porque a política de nível superior se aplica amplamente. Os nomes de escopo não precisam corresponder; a comparação com escopo é indexada pelo valor do seletor, como agentIds ou channelIds, e pelo campo de política verificado.

Exemplo de saída JSON limpa de comparação relata somente o estado de comparação de arquivo de política:

{  "ok": true,  "baselinePath": "official.policy.jsonc",  "policyPath": "policy.jsonc",  "rulesChecked": 3,  "findings": []}

Exemplo de saída limpa de policy check --json inclui hashes estáveis que podem ser registrados por um operador ou supervisor:

{  "ok": true,  "attestation": {    "policy": {      "path": "policy.jsonc",      "hash": "sha256:..."    },    "workspace": {      "scope": "policy",      "hash": "sha256:..."    },    "findingsHash": "sha256:...",    "attestationHash": "sha256:..."  },  "checksRun": 5,  "checksSkipped": 0,  "findings": []}

Configurar política

A configuração de política fica em plugins.entries.policy.config.

{  "plugins": {    "entries": {      "policy": {        "enabled": true,        "config": {          "enabled": true,          "path": "policy.jsonc",          "workspaceRepairs": false,          "expectedHash": "sha256:...",          "expectedAttestationHash": "sha256:...",        },      },    },  },}

Defina plugins.entries.policy.config.enabled como false para desabilitar verificações de política para um workspace enquanto mantém o plugin instalado.

Os requisitos de metadados de ferramentas são criados em policy.jsonc com tools.requireMetadata, por exemplo ["risk", "sensitivity", "owner"].

Aceitar estado de política

Exemplo de saída JSON:

{  "ok": true,  "attestation": {    "checkedAt": "2026-05-10T20:00:00.000Z",    "policy": {      "path": "policy.jsonc",      "hash": "sha256:..."    },    "workspace": {      "scope": "policy",      "hash": "sha256:..."    },    "findingsHash": "sha256:...",    "attestationHash": "sha256:..."  },  "evidence": {    "channels": [      {        "id": "telegram",        "provider": "telegram",        "source": "oc://openclaw.config/channels/telegram",        "enabled": false      }    ],    "mcpServers": [      {        "id": "docs",        "transport": "stdio",        "source": "oc://openclaw.config/mcp/servers/docs",        "command": "npx"      }    ],    "modelProviders": [      {        "id": "openai",        "source": "oc://openclaw.config/models/providers/openai"      }    ],    "modelRefs": [      {        "ref": "openai/gpt-5.5",        "provider": "openai",        "model": "gpt-5.5",        "source": "oc://openclaw.config/agents/defaults/model"      }    ],    "network": [      {        "id": "browser-private-network",        "source": "oc://openclaw.config/browser/ssrfPolicy/dangerouslyAllowPrivateNetwork",        "value": false      }    ],    "gatewayExposure": [      {        "id": "gateway-bind",        "kind": "bind",        "source": "oc://openclaw.config/gateway/bind",        "value": "loopback",        "nonLoopback": false,        "explicit": true      }    ],    "agentWorkspace": [      {        "id": "agents-defaults-workspace-access",        "kind": "workspaceAccess",        "source": "oc://openclaw.config/agents/defaults/sandbox/workspaceAccess",        "scope": "defaults",        "value": "ro",        "sandboxMode": "all",        "sandboxModeSource": "oc://openclaw.config/agents/defaults/sandbox/mode",        "sandboxEnabled": true,        "explicit": true      },      {        "id": "agents-defaults-tool-exec",        "kind": "toolDeny",        "source": "oc://openclaw.config/tools/deny",        "scope": "defaults",        "tool": "exec",        "denied": true,        "explicit": true      }    ],    "secrets": [      {        "id": "vault",        "kind": "provider",        "source": "oc://openclaw.config/secrets/providers/vault",        "providerSource": "env"      },      {        "id": "oc://openclaw.config/models/providers/openai/apiKey",        "kind": "input",        "source": "oc://openclaw.config/models/providers/openai/apiKey",        "provenance": "secretRef",        "refSource": "env",        "refProvider": "vault"      }    ],    "authProfiles": [      {        "id": "github",        "source": "oc://openclaw.config/auth/profiles/github",        "validMetadata": true,        "provider": "github",        "mode": "token"      }    ],    "tools": [      {        "id": "deploy",        "source": "oc://TOOLS.md/tools/deploy",        "line": 12,        "risk": "critical",        "sensitivity": "restricted",        "capabilities": ["IRREVERSIBLE_EXTERNAL"]      }    ]  },  "checksRun": 30,  "checksSkipped": 0,  "findings": []}

O hash da política identifica o artefato de regra criado. O bloco de evidências registra o estado observado do OpenClaw usado pelas verificações de política. O valor workspace.hash identifica esse payload de evidências para o escopo verificado. O hash das constatações identifica o conjunto exato de constatações retornado pela verificação. checkedAt registra quando a avaliação foi executada. O hash da attestação identifica a declaração estável: hash da política, hash das evidências, hash das constatações e se o resultado estava limpo. Intencionalmente, ele não inclui checkedAt, para que o mesmo estado de política produza a mesma attestação em verificações repetidas. Juntos, eles formam a tupla de auditoria para esta verificação de política.

Se um Gateway ou supervisor posterior usar a política para bloquear, aprovar ou anotar uma ação de runtime, ele deve registrar o hash da attestação da última verificação de política limpa. checkedAt permanece na saída JSON para logs de auditoria, mas não faz parte do hash de attestação estável.

Use este ciclo de vida ao aceitar o estado de política:

1. Crie ou revise policy.jsonc.
2. Execute openclaw policy check --json.
3. Se o resultado estiver limpo, registre attestation.policy.hash como expectedHash.
4. Registre attestation.attestationHash como expectedAttestationHash.
5. Execute novamente openclaw doctor --lint na CI ou em gates de lançamento.

Se as regras de política mudarem intencionalmente, atualize ambos os hashes aceitos a partir de uma verificação limpa. Se as configurações do workspace mudarem intencionalmente, mas a política permanecer a mesma, normalmente apenas expectedAttestationHash muda.

Habilitar ou atualizar regras de agents.workspace adiciona evidências agentWorkspace ao hash do workspace e ao hash da attestação. Os operadores devem revisar as novas evidências e atualizar os hashes de attestação aceitos após habilitar essas regras. Habilitar ou atualizar regras de postura de ferramentas adiciona evidências toolPosture da mesma forma.

openclaw policy watch executa a mesma verificação repetidamente e relata quando as evidências atuais não correspondem mais a expectedAttestationHash:

openclaw policy watch --json

Use --once em CI ou scripts que precisam de apenas uma avaliação de desvio. Sem --once, o comando consulta a cada dois segundos por padrão; use --interval-ms para escolher um intervalo diferente.

Constatações

Atualmente, a política verifica:

Achados de política podem incluir tanto target quanto requirement. target é a coisa observada no espaço de trabalho que não está em conformidade. requirement é a regra de política criada que fez disso um achado. Ambos os valores são endereços hoje, geralmente caminhos oc://, mas os nomes dos campos descrevem seu papel na política em vez do formato do endereço.

Exemplo de achado JSON:

{  "checkId": "policy/channels-denied-provider",  "severity": "error",  "message": "Channel 'telegram' uses denied provider 'telegram'.",  "source": "policy",  "path": "openclaw config",  "ocPath": "oc://openclaw.config/channels/telegram",  "target": "oc://openclaw.config/channels/telegram",  "requirement": "oc://policy.jsonc/channels/denyRules/#0",  "fixHint": "Telegram is not approved for this workspace."}

Exemplo de achado de ferramenta:

{  "checkId": "policy/tools-missing-risk-level",  "severity": "error",  "message": "TOOLS.md tool 'deploy' has no explicit risk classification.",  "source": "policy",  "path": "TOOLS.md",  "line": 12,  "ocPath": "oc://TOOLS.md/tools/deploy",  "target": "oc://TOOLS.md/tools/deploy",  "requirement": "oc://policy.jsonc/tools/requireMetadata"}

Exemplo de achado MCP:

{  "checkId": "policy/mcp-unapproved-server",  "severity": "error",  "message": "MCP server 'remote' is not in the policy allowlist.",  "source": "policy",  "path": "openclaw config",  "ocPath": "oc://openclaw.config/mcp/servers/remote",  "target": "oc://openclaw.config/mcp/servers/remote",  "requirement": "oc://policy.jsonc/mcp/servers/allow"}

Exemplo de achado de provedor de modelo:

{  "checkId": "policy/models-unapproved-provider",  "severity": "error",  "message": "Model ref 'anthropic/claude-sonnet-4.7' uses unapproved provider 'anthropic'.",  "source": "policy",  "path": "openclaw config",  "ocPath": "oc://openclaw.config/agents/defaults/model/fallbacks/#0",  "target": "oc://openclaw.config/agents/defaults/model/fallbacks/#0",  "requirement": "oc://policy.jsonc/models/providers/allow"}

Exemplo de achado de rede:

{  "checkId": "policy/network-private-access-enabled",  "severity": "error",  "message": "Network setting 'browser-private-network' allows private-network access.",  "source": "policy",  "path": "openclaw config",  "ocPath": "oc://openclaw.config/browser/ssrfPolicy/dangerouslyAllowPrivateNetwork",  "target": "oc://openclaw.config/browser/ssrfPolicy/dangerouslyAllowPrivateNetwork",  "requirement": "oc://policy.jsonc/network/privateNetwork/allow"}

Exemplo de constatação de exposição do Gateway:

{  "checkId": "policy/gateway-non-loopback-bind",  "severity": "error",  "message": "Gateway bind setting 'gateway-bind' permits non-loopback exposure.",  "source": "policy",  "path": "openclaw config",  "ocPath": "oc://openclaw.config/gateway/bind",  "target": "oc://openclaw.config/gateway/bind",  "requirement": "oc://policy.jsonc/gateway/exposure/allowNonLoopbackBind"}

Exemplo de achado de workspace de agente:

{  "checkId": "policy/agents-workspace-access-denied",  "severity": "error",  "message": "agents.defaults sandbox workspaceAccess 'rw' is not allowed by policy.",  "source": "policy",  "path": "openclaw config",  "ocPath": "oc://openclaw.config/agents/defaults/sandbox/workspaceAccess",  "target": "oc://openclaw.config/agents/defaults/sandbox/workspaceAccess",  "requirement": "oc://policy.jsonc/agents/workspace/allowedAccess"}

Reparo

doctor --lint e policy check são somente leitura.

doctor --fix só edita configurações de workspace gerenciadas por política quando workspaceRepairs está explicitamente habilitado. Sem essa adesão, as verificações de política relatam o que reparariam e deixam as configurações inalteradas.

Nesta versão, o reparo pode desabilitar canais que estão habilitados na configuração do OpenClaw mas negados por channels.denyRules. Habilite workspaceRepairs somente depois que o arquivo de política tiver sido revisado, porque uma regra de negação válida pode desativar um canal configurado:

{  "plugins": {    "entries": {      "policy": {        "config": {          "workspaceRepairs": true,        },      },    },  },}

Códigos de saída

Relacionado

• Modo de lint do Doctor
• CLI de caminho