openclaw policy

openclaw policy est fourni par le Plugin Policy intégré. Policy est une couche de conformité d’entreprise au-dessus des paramètres OpenClaw existants. Il n’ajoute pas un second système de configuration. policy.jsonc définit les exigences rédigées, OpenClaw observe l’espace de travail actif comme preuve, et les contrôles de santé de la politique signalent les dérives via doctor --lint. Le signal de conformité final est une exécution propre de doctor --lint ; la politique contribue des constats à cette surface de lint partagée au lieu de créer une porte de santé séparée.

Policy gère actuellement les canaux configurés, les serveurs MCP, les fournisseurs de modèles, la posture SSRF réseau, la posture d’accès entrant/canal, la posture d’exposition du Gateway, la posture de l’espace de travail des agents, la posture de traitement des données, la posture du fournisseur de secrets/profil d’authentification de la configuration OpenClaw, et les déclarations d’outils gouvernés. Par exemple, l’IT ou un opérateur d’espace de travail peut enregistrer que Telegram n’est pas un fournisseur de canal approuvé, restreindre les serveurs MCP et les références de modèles aux entrées approuvées, exiger que l’accès fetch/navigateur au réseau privé reste désactivé, exiger que l’isolation des sessions en messages directs et la posture d’entrée des canaux restent dans des limites examinées, exiger que l’exposition bind/auth/HTTP du Gateway reste dans des limites examinées, exiger que l’accès à l’espace de travail des agents et les refus d’outils restent dans une posture examinée, exiger que les SecretRefs de configuration OpenClaw utilisent des fournisseurs gérés, exiger que les profils d’authentification de configuration portent des métadonnées de fournisseur/mode, exiger que les outils gouvernés portent des métadonnées de risque et de sensibilité, exiger la rédaction des journaux sensibles, refuser la capture de contenu de télémétrie, exiger la maintenance de rétention des sessions, refuser l’indexation mémoire des transcriptions de session, puis utiliser doctor --lint comme porte de conformité partagée.

Utilisez la politique lorsqu’un espace de travail a besoin d’une déclaration durable telle que « ces canaux ne doivent pas être activés » ou « les outils gouvernés doivent déclarer des métadonnées d’approbation », ainsi que d’une méthode répétable pour prouver qu’OpenClaw reste conforme à cette déclaration. Utilisez uniquement la configuration normale et la documentation de l’espace de travail lorsque vous avez seulement besoin du comportement local et que vous n’avez pas besoin de constats de politique ni de sortie d’attestation.

Démarrage rapide

Activez le Plugin Policy intégré avant la première utilisation :

openclaw plugins enable policy

Lorsque la politique est activée, doctor peut charger les contrôles de santé de la politique sans activer de Plugins arbitraires. Le Plugin reste activé si policy.jsonc est absent, afin que doctor puisse signaler l’artefact manquant.

La politique est rédigée, et non générée à partir des paramètres actuels de l’utilisateur. Une politique minimale pour les canaux, les serveurs MCP, les fournisseurs de modèles, la posture réseau, l’accès entrant/canal, l’exposition du Gateway, la posture de l’espace de travail des agents, la posture du runtime sandbox configuré, la posture de traitement des données OpenClaw, la posture du fournisseur de secrets/profil d’authentification de configuration, la posture du fichier d’approbation d’exécution et les métadonnées d’outils ressemble à ceci :

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

Les règles font autorité. Un bloc de catégorie n’est qu’un espace de noms ; les contrôles s’exécutent lorsqu’une règle concrète est présente. OpenClaw lit les paramètres channels.* actuels, mcp.servers.*, models.providers.*, certaines références de modèles d’agent, les paramètres SSRF réseau, la portée des sessions en messages directs, la politique DM de canal, la politique de groupe de canal, les portes de mention canal/groupe, la posture bind/auth/Control UI/Tailscale/remote/HTTP du Gateway, la posture d’accès à l’espace de travail sandbox des agents dans la configuration OpenClaw et la posture de refus d’outils, la posture de configuration de traitement des données, la provenance du fournisseur de secrets de configuration et de SecretRef, les métadonnées de profil d’authentification de configuration, la posture d’outils globale/par agent configurée, et les déclarations TOOLS.md comme preuves, puis signale l’état observé qui n’est pas conforme. Si une politique refuse les binds du Gateway non-loopback, omettez gateway.bind uniquement lorsque vous acceptez d’examiner la valeur par défaut du runtime ; définissez gateway.bind=loopback pour une conformité stricte de la configuration. Pour une posture d’agent en lecture seule, configurez le mode sandbox sur les valeurs par défaut ou l’agent applicables et définissez workspaceAccess sur none ou ro ; un mode sandbox omis ou off ne satisfait pas une politique lecture seule/sans écriture. agents.workspace.denyTools prend en charge exec, process, write, edit et apply_patch ; la configuration OpenClaw group:fs couvre les outils de mutation de fichiers et group:runtime couvre les outils shell/processus. La politique de posture des outils observe tools.profile, tools.allow, tools.alsoAllow, tools.deny, tools.fs.workspaceOnly, tools.exec.security, tools.exec.ask, tools.exec.host, tools.elevated.enabled, ainsi que les mêmes remplacements par agent agents.list[].tools.*. La politique d’approbation d’exécution lit l’artefact produit nommé exec-approvals.json uniquement lorsqu’une règle execApprovals est présente ; les preuves enregistrent les valeurs par défaut, la posture par agent et les modèles de liste d’autorisation sans jetons de socket ni texte de dernière commande utilisée. La politique n’applique pas les appels d’outils au runtime. Les preuves de secrets enregistrent la posture fournisseur/source et les métadonnées SecretRef, jamais les valeurs brutes des secrets. La politique ne lit ni n’atteste les magasins d’identifiants par agent tels que auth-profiles.json ; ces magasins restent détenus par les flux d’authentification et d’identifiants existants. Les preuves de traitement des données concernent uniquement la posture au niveau de la configuration : elles vérifient le mode de rédaction configuré, les bascules de capture de contenu de télémétrie, le mode de maintenance des sessions, et les paramètres d’indexation mémoire des transcriptions de session. Elles n’inspectent pas les journaux bruts, les exports de télémétrie, le contenu des transcriptions, les fichiers mémoire, et ne prouvent pas qu’aucune donnée personnelle ni aucun secret n’existent.

Référence des règles de politique

Chaque champ de politique ci-dessous est facultatif. Un contrôle s’exécute uniquement lorsque la règle correspondante est présente dans policy.jsonc. L’état observé correspond à la configuration OpenClaw existante ou aux métadonnées de l’espace de travail ; la politique signale la dérive mais ne réécrit pas le comportement du runtime sauf si un chemin de réparation est explicitement disponible et activé. Les fichiers de politique sont stricts : les sections ou clés de règle non prises en charge sont signalées comme policy/policy-jsonc-invalid au lieu d’être ignorées.

Les superpositions de politique gardent les règles globales de premier niveau comme règles globales, puis permettent à des blocs de portée nommés d’ajouter des sections de politique normales plus strictes pour des sélecteurs explicites. Un nom de portée est seulement un compartiment descriptif ; la correspondance utilise les valeurs de sélecteur à l’intérieur de la portée. La superposition est additive : les revendications globales continuent de s’exécuter, et une revendication portée peut émettre son propre constat contre la même configuration observée.

Superpositions avec portée

Utilisez scopes.<scopeName> lorsqu’un ensemble d’agents ou de canaux a besoin d’une politique plus stricte que la base de référence de premier niveau. Les sections à portée d’agent utilisent agentIds, qui prend en charge tools.*, agents.workspace.*, sandbox.*, dataHandling.memory.*, et execApprovals.*. L’entrée à portée de canal utilise channelIds, qui prend en charge ingress.channels.*. Les sections non prises en charge sont rejetées au lieu d’être ignorées. Si une entrée agentIds n’est pas présente dans agents.list[], OpenClaw évalue la règle à portée contre la posture héritée globale/par défaut pour cet identifiant d’agent 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,        },      },    },  },}

Le même agent peut apparaître dans plusieurs portées lorsque chaque portée gouverne des champs différents, comme illustré ci-dessus. Un champ à portée répété pour le même agent doit être aussi restrictif ou plus restrictif selon les métadonnées de politique ; les revendications dupliquées plus faibles sont rejetées. Les métadonnées de rigueur traitent les listes d’autorisation comme des sous-ensembles, les listes de refus comme des sur-ensembles, et les booléens requis comme des exigences fixes.

La politique de posture de conteneur est évaluée uniquement contre les preuves qu’OpenClaw peut observer pour l’agent correspondant. Si une règle sandbox.containers.* activée s’applique à un agent dont le backend sandbox ne peut pas exposer ce champ, la politique signale policy/sandbox-container-posture-unobservable au lieu de considérer la revendication comme réussie. Utilisez des portées agentIds séparées pour les groupes d’agents qui utilisent différents backends sandbox, et laissez les règles de conteneur non prises en charge non définies ou à false pour les groupes où ces champs ne peuvent pas être observés.

ingress.session.requireDmScope de premier niveau reste global, car session.dmScope n’est pas une preuve attribuable à un canal.

Chaque portée présente dans policy.jsonc doit être valide et applicable.

Canaux

Serveurs MCP

Fournisseurs de modèles

Réseau

Ingress et accès aux canaux

Gateway

Espace de travail de l’agent

Posture du sandbox

La stratégie traite l’absence de sandbox.mode comme la valeur par défaut implicite off, donc sandbox.requireMode signale un sandbox neuf ou non configuré comme extérieur à une liste d’autorisation telle que ["all"].

Traitement des données

Secrets

Approbations exec

La stratégie d’approbations exec observe l’artefact d’exécution actif exec-approvals.json. Par défaut, il s’agit de ~/.openclaw/exec-approvals.json ; lorsque OPENCLAW_STATE_DIR est défini, Policy lit $OPENCLAW_STATE_DIR/exec-approvals.json. Les règles de posture réelles telles que execApprovals.defaults.* ou execApprovals.agents.* exigent une preuve d’artefact lisible ; un artefact manquant ou non valide est signalé comme preuve non observable au lieu de devenir une réussite au mieux contre des valeurs par défaut d’exécution synthétiques. Une fois l’artefact lisible, les champs d’approbation omis héritent des valeurs par défaut d’exécution : defaults.security manquant vaut full, et la sécurité d’agent manquante hérite de cette valeur par défaut. La preuve inclut defaults, agents.* et agents.*.allowlist[].pattern, ainsi que les éléments optionnels argPattern, la posture effective autoAllowSkills et la source de l’entrée. Elle n’inclut pas le chemin/token de socket, commandText, lastUsedCommand, les chemins résolus ni les horodatages.

Par exemple, exigez l’artéfact d’approbations, refusez les valeurs par défaut permissives et autorisez uniquement la posture d’approbation d’exécution relue pour les agents sélectionnés :

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

Profils d’authentification

Métadonnées des outils

Posture des outils

Exécutez les vérifications limitées aux politiques pendant la rédaction :

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

policy check exécute uniquement l’ensemble de vérifications de politique et émet les preuves, les constats et les hachages d’attestation. Les mêmes constats apparaissent également dans openclaw doctor --lint lorsque le Plugin Policy est activé.

Comparez un fichier de politique opérateur à un fichier de politique de référence rédigé :

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

policy compare compare la syntaxe d’un fichier de politique à celle d’un autre. Il n’inspecte pas l’état du runtime OpenClaw, les preuves, les identifiants d’authentification ni les secrets. La commande utilise les mêmes métadonnées de règles de politique que celles qui gouvernent les superpositions délimitées : les listes d’autorisation doivent rester identiques ou plus étroites, les listes de refus doivent rester identiques ou plus larges, les booléens requis doivent conserver leur valeur requise, les chaînes ordonnées doivent uniquement évoluer vers l’extrémité la plus restrictive de l’ordre configuré, et les listes exactes doivent correspondre.

Le fichier de référence peut être une politique rédigée par l’organisation. La politique vérifiée peut utiliser des valeurs plus strictes ou ajouter des règles de politique supplémentaires. Une règle vérifiée de niveau supérieur peut aussi satisfaire une règle de référence délimitée lorsqu’elle est aussi restrictive ou plus restrictive, car la politique de niveau supérieur s’applique largement. Les noms de périmètre n’ont pas besoin de correspondre ; la comparaison délimitée est indexée par valeur de sélecteur comme agentIds ou channelIds et par le champ de politique vérifié.

Exemple de sortie JSON de comparaison propre signalant uniquement l’état de comparaison des fichiers de politique :

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

Exemple de sortie propre policy check --json incluant des hachages stables qui peuvent être enregistrés par un opérateur ou un superviseur :

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

Configurer la politique

La configuration de politique se trouve sous plugins.entries.policy.config.

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

Définissez plugins.entries.policy.config.enabled sur false pour désactiver les vérifications de politique pour un espace de travail tout en laissant le plugin installé.

Les exigences de métadonnées d’outils sont rédigées dans policy.jsonc avec tools.requireMetadata, par exemple ["risk", "sensitivity", "owner"].

Accepter l’état de politique

Exemple de sortie 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": []}

Le hachage de politique identifie l’artefact de règles rédigé. Le bloc de preuves enregistre l’état OpenClaw observé utilisé par les vérifications de politique. La valeur workspace.hash identifie cette charge utile de preuves pour le périmètre vérifié. Le hachage des constats identifie l’ensemble exact de constats renvoyé par la vérification. checkedAt enregistre le moment où l’évaluation a été exécutée. Le hachage d’attestation identifie la revendication stable : hachage de politique, hachage des preuves, hachage des constats, et si le résultat était propre. Il n’inclut volontairement pas checkedAt, afin que le même état de politique produise la même attestation lors de vérifications répétées. Ensemble, ces éléments forment le tuple d’audit pour cette vérification de politique.

Si un Gateway ou un superviseur ultérieur utilise la politique pour bloquer, approuver ou annoter une action d’exécution, il doit enregistrer le hachage d’attestation de la dernière vérification de politique propre. checkedAt reste dans la sortie JSON pour les journaux d’audit, mais ne fait pas partie du hachage d’attestation stable.

Utilisez ce cycle de vie lors de l’acceptation de l’état de politique :

1. Rédigez ou révisez policy.jsonc.
2. Exécutez openclaw policy check --json.
3. Si le résultat est propre, enregistrez attestation.policy.hash comme expectedHash.
4. Enregistrez attestation.attestationHash comme expectedAttestationHash.
5. Réexécutez openclaw doctor --lint dans la CI ou les portes de publication.

Si les règles de politique changent intentionnellement, mettez à jour les deux hachages acceptés à partir d’une vérification propre. Si les paramètres de l’espace de travail changent intentionnellement mais que la politique reste la même, seul expectedAttestationHash change généralement.

L’activation ou la mise à niveau des règles agents.workspace ajoute des preuves agentWorkspace au hachage de l’espace de travail et au hachage d’attestation. Les opérateurs doivent examiner les nouvelles preuves et actualiser les hachages d’attestation acceptés après l’activation de ces règles. L’activation ou la mise à niveau des règles de posture des outils ajoute des preuves toolPosture de la même manière.

openclaw policy watch exécute la même vérification de manière répétée et signale lorsque les preuves actuelles ne correspondent plus à expectedAttestationHash :

openclaw policy watch --json

Utilisez --once dans la CI ou les scripts qui n’ont besoin que d’une seule évaluation de dérive. Sans --once, la commande interroge toutes les deux secondes par défaut ; utilisez --interval-ms pour choisir un intervalle différent.

Constats

La politique vérifie actuellement :

Les constats de politique peuvent inclure à la fois target et requirement. target est l’élément observé de l’espace de travail qui n’est pas conforme. requirement est la règle de politique rédigée qui en a fait un constat. Les deux valeurs sont aujourd’hui des adresses, généralement des chemins oc://, mais les noms de champs décrivent leur rôle dans la politique plutôt que le format d’adresse.

Exemple de constat 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."}

Exemple de constat d’outil :

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

Exemple de constat 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"}

Exemple de constat de fournisseur de modèles :

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

Exemple de constat réseau :

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

Exemple de résultat d’exposition du 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"}

Exemple de résultat d’espace de travail d’agent :

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

Réparation

doctor --lint et policy check sont en lecture seule.

doctor --fix ne modifie les paramètres d’espace de travail gérés par la politique que lorsque workspaceRepairs est explicitement activé. Sans cette activation explicite, les vérifications de politique signalent ce qu’elles répareraient et laissent les paramètres inchangés.

Dans cette version, la réparation peut désactiver des canaux activés dans la configuration OpenClaw mais refusés par channels.denyRules. N’activez workspaceRepairs qu’après avoir examiné le fichier de politique, car une règle de refus valide peut désactiver un canal configuré :

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

Codes de sortie

Connexe

• Mode lint de Doctor
• CLI Path