openclaw policy

openclaw policy è fornito dal Plugin Policy incluso. Policy è un livello di conformità enterprise sopra le impostazioni OpenClaw esistenti. Non aggiunge un secondo sistema di configurazione. policy.jsonc definisce i requisiti redatti, OpenClaw osserva l'area di lavoro attiva come evidenza e i controlli di integrità delle policy segnalano le deviazioni tramite doctor --lint. Il segnale finale di conformità è un'esecuzione pulita di doctor --lint; policy contribuisce con rilevamenti a quella superficie di lint condivisa invece di creare un gate di integrità separato.

Policy attualmente gestisce canali configurati, server MCP, provider di modelli, postura SSRF di rete, postura di accesso ingress/canale, postura di esposizione del Gateway, postura dell'area di lavoro dell'agente, postura di gestione dei dati, postura del provider di segreti/profilo auth della configurazione OpenClaw e dichiarazioni degli strumenti governati. Per esempio, l'IT o un operatore dell'area di lavoro può registrare che Telegram non è un provider di canale approvato, limitare server MCP e riferimenti di modello alle voci approvate, richiedere che l'accesso fetch/browser a reti private rimanga disabilitato, richiedere che l'isolamento delle sessioni di messaggi diretti e la postura di ingress del canale restino entro limiti revisionati, richiedere che bind/auth/esposizione HTTP del Gateway restino entro limiti revisionati, richiedere che l'accesso all'area di lavoro dell'agente e i deny degli strumenti restino in una postura revisionata, richiedere che i SecretRef della configurazione OpenClaw usino provider gestiti, richiedere che i profili auth di configurazione portino metadati di provider/modalità, richiedere che gli strumenti governati portino metadati di rischio e sensibilità, richiedere la redazione del logging sensibile, negare l'acquisizione dei contenuti di telemetria, richiedere la manutenzione della conservazione delle sessioni, negare l'indicizzazione in memoria delle trascrizioni di sessione, quindi usare doctor --lint come gate di conformità condiviso.

Usa policy quando un'area di lavoro richiede una dichiarazione durevole come "questi canali non devono essere abilitati" o "gli strumenti governati devono dichiarare metadati di approvazione" e un modo ripetibile per dimostrare che OpenClaw è ancora conforme a quella dichiarazione. Usa solo la configurazione regolare e la documentazione dell'area di lavoro quando ti serve soltanto il comportamento locale e non ti servono rilevamenti di policy o output di attestazione.

Avvio rapido

Abilita il Plugin Policy incluso prima del primo utilizzo:

openclaw plugins enable policy

Quando policy è abilitato, doctor può caricare i controlli di integrità delle policy senza attivare Plugin arbitrari. Il Plugin resta abilitato se policy.jsonc manca, così doctor può segnalare l'artefatto mancante.

Policy è redatto, non generato dalle impostazioni correnti dell'utente. Una policy minima per canali, server MCP, provider di modelli, postura di rete, accesso ingress/canale, esposizione Gateway, postura dell'area di lavoro dell'agente, postura del runtime sandbox configurato, postura di gestione dei dati OpenClaw, postura del provider di segreti/profilo auth della configurazione, postura del file di approvazione exec e metadati degli strumenti ha questo aspetto:

{  "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"],  },}

Le regole sono l'autorità. Un blocco di categoria è solo uno spazio dei nomi; i controlli vengono eseguiti quando è presente una regola concreta. OpenClaw legge le impostazioni correnti channels.*, mcp.servers.*, models.providers.*, i riferimenti di modello agente selezionati, le impostazioni SSRF di rete, l'ambito delle sessioni di messaggi diretti, la policy DM del canale, la policy di gruppo del canale, i gate di menzione canale/gruppo, la postura bind/auth/Control UI/Tailscale/remote/HTTP del Gateway, la postura di accesso all'area di lavoro sandbox agente della configurazione OpenClaw e di deny degli strumenti, la postura della configurazione di gestione dei dati, la provenienza del provider di segreti e dei SecretRef della configurazione, i metadati dei profili auth di configurazione, la postura degli strumenti globali/per agente configurata e le dichiarazioni TOOLS.md come evidenza, quindi segnala lo stato osservato che non è conforme. Se una policy nega i bind Gateway non-loopback, ometti gateway.bind solo quando sei disposto a revisionare il valore predefinito del runtime; imposta gateway.bind=loopback per una conformità di configurazione rigorosa. Per la postura agente in sola lettura, configura la modalità sandbox sui default applicabili o sull'agente e imposta workspaceAccess a none o ro; una modalità sandbox omessa o off non soddisfa una policy in sola lettura/no-write. agents.workspace.denyTools supporta exec, process, write, edit e apply_patch; la configurazione OpenClaw group:fs copre gli strumenti di mutazione dei file e group:runtime copre gli strumenti shell/processo. La policy di postura degli strumenti osserva tools.profile, tools.allow, tools.alsoAllow, tools.deny, tools.fs.workspaceOnly, tools.exec.security, tools.exec.ask, tools.exec.host, tools.elevated.enabled e gli stessi override per agente agents.list[].tools.*. La policy di approvazione exec legge l'artefatto di prodotto denominato exec-approvals.json solo quando è presente una regola execApprovals; l'evidenza registra default, postura per agente e pattern allowlist senza token socket o testo dell'ultimo comando usato. Policy non applica le chiamate agli strumenti a runtime. L'evidenza dei segreti registra la postura provider/source e i metadati SecretRef, mai i valori grezzi dei segreti. Policy non legge né attesta archivi di credenziali per agente come auth-profiles.json; questi archivi restano di proprietà dei flussi auth e credenziali esistenti. L'evidenza di gestione dei dati è solo postura a livello di configurazione: controlla la modalità di redazione configurata, i toggle di acquisizione contenuti di telemetria, la modalità di manutenzione delle sessioni e le impostazioni di indicizzazione in memoria delle trascrizioni di sessione. Non ispeziona log grezzi, export di telemetria, contenuti di trascrizioni, file di memoria, né dimostra che non esistano dati personali o segreti.

Riferimento alle regole di policy

Ogni campo di policy qui sotto è facoltativo. Un controllo viene eseguito solo quando la regola corrispondente è presente in policy.jsonc. Lo stato osservato è la configurazione OpenClaw esistente o i metadati dell'area di lavoro; policy segnala le deviazioni ma non riscrive il comportamento del runtime a meno che un percorso di riparazione sia esplicitamente disponibile e abilitato. I file di policy sono rigorosi: sezioni o chiavi di regola non supportate vengono segnalate come policy/policy-jsonc-invalid invece di essere ignorate.

Gli overlay di policy mantengono globali le regole ampie di primo livello, poi consentono ai blocchi di ambito denominati di aggiungere sezioni di policy normali più rigorose per selettori espliciti. Il nome di un ambito è solo un contenitore descrittivo; la corrispondenza usa i valori dei selettori dentro l'ambito. L'overlay è additivo: le dichiarazioni globali vengono comunque eseguite e una dichiarazione con ambito può emettere il proprio rilevamento sulla stessa configurazione osservata.

Overlay con ambito

Usa scopes.<scopeName> quando un insieme di agenti o canali richiede una policy più rigorosa rispetto alla baseline di primo livello. Le sezioni con ambito agente usano agentIds, che supporta tools.*, agents.workspace.*, sandbox.*, dataHandling.memory.* e execApprovals.*. L'ingress con ambito canale usa channelIds, che supporta ingress.channels.*. Le sezioni non supportate vengono rifiutate invece di essere ignorate. Se una voce agentIds non è presente in agents.list[], OpenClaw valuta la regola con ambito rispetto alla postura globale/default ereditata per quell'id agente 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,        },      },    },  },}

Lo stesso agente può apparire in più ambiti quando ogni ambito governa campi diversi, come mostrato sopra. Un campo con ambito ripetuto per lo stesso agente deve essere ugualmente o più restrittivo secondo i metadati di policy; le dichiarazioni duplicate più deboli vengono rifiutate. I metadati di rigore trattano le allow-list come sottoinsiemi, le deny-list come sovrainsiemi e i booleani richiesti come requisiti fissi.

La policy di postura dei container viene valutata solo rispetto all'evidenza che OpenClaw può osservare per l'agente corrispondente. Se una regola sandbox.containers.* abilitata si applica a un agente il cui backend sandbox non può esporre quel campo, policy segnala policy/sandbox-container-posture-unobservable invece di trattare la dichiarazione come superata. Usa ambiti agentIds separati per gruppi di agenti che usano backend sandbox diversi e lascia le regole container non supportate non impostate o false per i gruppi in cui quei campi non possono essere osservati.

ingress.session.requireDmScope di primo livello resta globale perché session.dmScope non è evidenza attribuibile a un canale.

Ogni ambito presente in policy.jsonc deve essere valido e applicabile.

Canali

Server MCP

Provider di modelli

Rete

Ingress e accesso ai canali

Gateway

Workspace agente

Postura sandbox

La policy tratta sandbox.mode mancante come default implicito off, quindi sandbox.requireMode segnala un sandbox nuovo o non configurato come fuori da un'allowlist come ["all"].

Gestione dei dati

Segreti

Approvazioni exec

La policy delle approvazioni exec osserva l'artefatto runtime attivo exec-approvals.json. Per default è ~/.openclaw/exec-approvals.json; quando OPENCLAW_STATE_DIR è impostato, Policy legge $OPENCLAW_STATE_DIR/exec-approvals.json. Le regole di postura effettive come execApprovals.defaults.* o execApprovals.agents.* richiedono evidenza leggibile dall'artefatto; un artefatto mancante o non valido viene segnalato come evidenza non osservabile invece di diventare un pass best-effort contro default runtime sintetici. Una volta che l'artefatto è leggibile, i campi di approvazione omessi ereditano i default runtime: defaults.security mancante è full, e la sicurezza agente mancante eredita quel default. L'evidenza include defaults, agents.* e agents.*.allowlist[].pattern più argPattern opzionale, postura effettiva autoAllowSkills e origine della voce. Non include percorso/token del socket, commandText, lastUsedCommand, percorsi risolti o timestamp.

Ad esempio, richiedere l'artefatto delle approvazioni, negare valori predefiniti permissivi e consentire solo la postura di approvazione exec revisionata per agenti selezionati:

{  "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",            ],          },        },      },    },  },}

Profili di autenticazione

Metadati degli strumenti

Postura degli strumenti

Eseguire controlli solo policy durante la creazione:

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

policy check esegue solo l'insieme dei controlli policy ed emette evidenze, findings e hash di attestazione. Gli stessi findings compaiono anche in openclaw doctor --lint quando il Plugin Policy e abilitato.

Confrontare un file policy operatore con un file policy baseline creato:

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

policy compare confronta la sintassi di un file policy con la sintassi di un file policy. Non ispeziona lo stato del runtime OpenClaw, evidenze, credenziali o segreti. Il comando usa gli stessi metadati delle regole policy che governano gli overlay con scope: le allowlist devono rimanere uguali o piu ristrette, le denylist devono rimanere uguali o piu ampie, i booleani richiesti devono mantenere il loro valore richiesto, le stringhe ordinate devono spostarsi solo verso l'estremita piu restrittiva dell'ordine configurato e gli elenchi esatti devono corrispondere.

Il file baseline puo essere una policy creata dall'organizzazione. La policy controllata puo usare valori piu rigorosi o aggiungere regole policy extra. Una regola controllata di livello superiore puo anche soddisfare una regola baseline con scope quando e ugualmente o piu restrittiva, perche la policy di livello superiore si applica in modo ampio. I nomi degli scope non devono corrispondere; il confronto con scope e indicizzato per valore del selettore, come agentIds o channelIds, e per il campo policy controllato.

Esempio di output JSON di confronto pulito che riporta solo lo stato del confronto dei file policy:

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

Esempio di output pulito di policy check --json che include hash stabili che possono essere registrati da un operatore o supervisore:

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

Configurare la policy

La configurazione della policy si trova sotto plugins.entries.policy.config.

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

Impostare plugins.entries.policy.config.enabled su false per disabilitare i controlli policy per un workspace lasciando installato il plugin.

I requisiti dei metadati degli strumenti vengono creati in policy.jsonc con tools.requireMetadata, ad esempio ["risk", "sensitivity", "owner"].

Accettare lo stato policy

Esempio di output 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": []}

L’hash della policy identifica l’artefatto della regola redatto. Il blocco evidence registra lo stato OpenClaw osservato usato dai controlli della policy. Il valore workspace.hash identifica quel payload di evidenza per l’ambito controllato. L’hash dei finding identifica l’esatto insieme di finding restituito dal controllo. checkedAt registra quando è stata eseguita la valutazione. L’hash di attestazione identifica la dichiarazione stabile: hash della policy, hash dell’evidenza, hash dei finding e se il risultato era pulito. Intenzionalmente non include checkedAt, quindi lo stesso stato della policy produce la stessa attestazione in controlli ripetuti. Insieme, questi formano la tupla di audit per questo controllo della policy.

Se un Gateway o un supervisore successivo usa la policy per bloccare, approvare o annotare un’azione runtime, deve registrare l’hash di attestazione dell’ultimo controllo della policy pulito. checkedAt rimane nell’output JSON per i log di audit, ma non fa parte dell’hash di attestazione stabile.

Usa questo ciclo di vita quando accetti lo stato della policy:

1. Redigi o rivedi policy.jsonc.
2. Esegui openclaw policy check --json.
3. Se il risultato è pulito, registra attestation.policy.hash come expectedHash.
4. Registra attestation.attestationHash come expectedAttestationHash.
5. Riesegui openclaw doctor --lint in CI o nei gate di rilascio.

Se le regole della policy cambiano intenzionalmente, aggiorna entrambi gli hash accettati da un controllo pulito. Se le impostazioni del workspace cambiano intenzionalmente ma la policy rimane la stessa, di solito cambia solo expectedAttestationHash.

L’abilitazione o l’aggiornamento delle regole agents.workspace aggiunge evidenze agentWorkspace all’hash del workspace e all’hash di attestazione. Gli operatori devono rivedere le nuove evidenze e aggiornare gli hash di attestazione accettati dopo aver abilitato queste regole. L’abilitazione o l’aggiornamento delle regole di postura degli strumenti aggiunge evidenze toolPosture nello stesso modo.

openclaw policy watch esegue ripetutamente lo stesso controllo e segnala quando l’evidenza corrente non corrisponde più a expectedAttestationHash:

openclaw policy watch --json

Usa --once in CI o negli script che richiedono una sola valutazione della deriva. Senza --once, il comando esegue il polling ogni due secondi per impostazione predefinita; usa --interval-ms per scegliere un intervallo diverso.

Finding

La policy attualmente verifica:

I riscontri della policy possono includere sia target sia requirement. target è l’elemento osservato nel workspace che non è conforme. requirement è la regola di policy scritta che lo ha reso un riscontro. Entrambi i valori oggi sono indirizzi, di solito percorsi oc://, ma i nomi dei campi descrivono il loro ruolo nella policy anziché il formato dell’indirizzo.

Esempio di riscontro 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."}

Esempio di riscontro strumento:

{  "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"}

Esempio di riscontro 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"}

Esempio di riscontro provider di modelli:

{  "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"}

Esempio di riscontro rete:

{  "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"}

Esempio di rilevamento dell'esposizione del 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"}

Esempio di rilevamento dell'area di lavoro dell'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"}

Riparazione

doctor --lint e policy check sono in sola lettura.

doctor --fix modifica solo le impostazioni dell'area di lavoro gestite dalla policy quando workspaceRepairs è abilitato esplicitamente. Senza questa adesione esplicita, i controlli delle policy segnalano ciò che riparerebbero e lasciano le impostazioni invariate.

In questa versione, la riparazione può disabilitare i canali che sono abilitati nella configurazione OpenClaw ma negati da channels.denyRules. Abilita workspaceRepairs solo dopo che il file delle policy è stato revisionato, perché una regola di negazione valida può disattivare un canale configurato:

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

Codici di uscita

Correlati

• Modalità lint di Doctor
• CLI path