openclaw policy

openclaw policy wird vom gebündelten Policy-Plugin bereitgestellt. Policy ist eine Enterprise-Konformitätsschicht über bestehenden OpenClaw-Einstellungen. Sie fügt kein zweites Konfigurationssystem hinzu. policy.jsonc definiert verfasste Anforderungen, OpenClaw beobachtet den aktiven Arbeitsbereich als Nachweis, und Policy-Integritätsprüfungen melden Abweichungen über doctor --lint. Das abschließende Konformitätssignal ist ein sauberer doctor --lint-Lauf; Policy trägt Befunde zu dieser gemeinsamen Lint-Oberfläche bei, statt ein separates Integritäts-Gate zu erstellen.

Policy verwaltet derzeit konfigurierte Kanäle, MCP-Server, Modell-Provider, Netzwerk-SSRF-Haltung, Ingress-/Kanalzugriffshaltung, Gateway-Expositionshaltung, Agent-Arbeitsbereichshaltung, Datenverarbeitungshaltung, OpenClaw-Konfigurationshaltung für Secret-Provider/Auth-Profile sowie verwaltete Tool-Deklarationen. Beispielsweise können IT oder ein Arbeitsbereichsbetreiber festhalten, dass Telegram kein genehmigter Kanal-Provider ist, MCP-Server und Modellreferenzen auf genehmigte Einträge beschränken, verlangen, dass Fetch-/Browser-Zugriff auf private Netzwerke deaktiviert bleibt, verlangen, dass Direct-Message-Sitzungsisolierung und Kanal-Ingress-Haltung innerhalb geprüfter Grenzen bleiben, verlangen, dass Gateway-Bind/Auth/HTTP-Exposition innerhalb geprüfter Grenzen bleibt, verlangen, dass Agent-Arbeitsbereichszugriff und Tool-Verweigerungen in einer geprüften Haltung bleiben, verlangen, dass OpenClaw-Konfigurations-SecretRefs verwaltete Provider verwenden, verlangen, dass Konfigurations-Auth-Profile Provider-/Modus-Metadaten tragen, verlangen, dass verwaltete Tools Risiko- und Sensitivitätsmetadaten tragen, sensible Logging-Redaktion verlangen, Telemetrie-Inhaltserfassung verweigern, Sitzungsaufbewahrungswartung verlangen, Sitzungs-Transkript-Memory-Indexierung verweigern und dann doctor --lint als gemeinsames Konformitäts-Gate verwenden.

Verwenden Sie Policy, wenn ein Arbeitsbereich eine dauerhafte Aussage benötigt, etwa „diese Kanäle dürfen nicht aktiviert sein“ oder „verwaltete Tools müssen Genehmigungsmetadaten deklarieren“, sowie eine wiederholbare Möglichkeit, zu belegen, dass OpenClaw weiterhin dieser Aussage entspricht. Verwenden Sie nur reguläre Konfiguration und Arbeitsbereichsdokumentation, wenn Sie lediglich lokales Verhalten benötigen und keine Policy-Befunde oder Attestierungs-Ausgaben brauchen.

Schnellstart

Aktivieren Sie das gebündelte Policy-Plugin vor der ersten Verwendung:

openclaw plugins enable policy

Wenn Policy aktiviert ist, kann doctor Policy-Integritätsprüfungen laden, ohne beliebige Plugins zu aktivieren. Das Plugin bleibt aktiviert, wenn policy.jsonc fehlt, sodass doctor das fehlende Artefakt melden kann.

Policy wird verfasst und nicht aus den aktuellen Einstellungen des Benutzers generiert. Eine minimale Policy für Kanäle, MCP-Server, Modell-Provider, Netzwerkhaltung, Ingress-/Kanalzugriff, Gateway-Exposition, Agent-Arbeitsbereichshaltung, konfigurierte Sandbox-Runtime-Haltung, OpenClaw-Datenverarbeitungshaltung, Konfigurations-Secret-Provider-/Auth-Profil-Haltung, Exec-Genehmigungsdatei-Haltung und Tool-Metadaten sieht so aus:

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

Die Regeln sind maßgeblich. Ein Kategorieblock ist nur ein Namespace; Prüfungen laufen, wenn eine konkrete Regel vorhanden ist. OpenClaw liest die aktuellen channels.*-Einstellungen, mcp.servers.*, models.providers.*, ausgewählte Agent-Modellreferenzen, Netzwerk-SSRF-Einstellungen, Direct-Message-Sitzungsscope, Kanal-DM-Policy, Kanalgruppen-Policy, Kanal-/Gruppen-Erwähnungs-Gates, Gateway-Bind/Auth/Control UI/Tailscale/Remote/HTTP-Haltung, OpenClaw-Konfigurationshaltung für Agent-Sandbox-Arbeitsbereichszugriff und Tool-Verweigerung, Konfigurationshaltung zur Datenverarbeitung, Secret-Provider- und SecretRef-Herkunft der Konfiguration, Metadaten von Konfigurations-Auth-Profilen, konfigurierte globale/pro-Agent-Tool-Haltung und TOOLS.md-Deklarationen als Nachweise und meldet dann beobachteten Zustand, der nicht konform ist. Wenn eine Policy Nicht-Loopback-Gateway-Binds verweigert, lassen Sie gateway.bind nur weg, wenn Sie bereit sind, den Runtime-Standard zu prüfen; setzen Sie gateway.bind=loopback für strikte Konfigurationskonformität. Für eine schreibgeschützte Agent-Haltung konfigurieren Sie den Sandbox-Modus für die jeweiligen Standards oder den Agent und setzen workspaceAccess auf none oder ro; ein ausgelassener oder off-Sandbox-Modus erfüllt keine schreibgeschützte/No-Write-Policy. agents.workspace.denyTools unterstützt exec, process, write, edit und apply_patch; die OpenClaw-Konfiguration group:fs deckt dateimutierende Tools ab, und group:runtime deckt Shell-/Prozess-Tools ab. Tool-Haltungs-Policy beobachtet tools.profile, tools.allow, tools.alsoAllow, tools.deny, tools.fs.workspaceOnly, tools.exec.security, tools.exec.ask, tools.exec.host, tools.elevated.enabled und dieselben pro-Agent-Overrides agents.list[].tools.*. Exec-Genehmigungs-Policy liest das benannte Produktartefakt exec-approvals.json nur, wenn eine execApprovals-Regel vorhanden ist; Nachweise erfassen Standards, pro-Agent-Haltung und Allowlist-Muster ohne Socket-Token oder zuletzt verwendeten Befehlstext. Policy erzwingt Tool-Aufrufe nicht zur Laufzeit. Secret-Nachweise erfassen Provider-/Quellenhaltung und SecretRef-Metadaten, niemals rohe Secret-Werte. Policy liest oder attestiert keine pro-Agent-Anmeldeinformationsspeicher wie auth-profiles.json; diese Speicher bleiben Eigentum der bestehenden Auth- und Anmeldeinformationsflüsse. Datenverarbeitungsnachweise sind ausschließlich Konfigurationshaltung: Geprüft werden der konfigurierte Redaktionsmodus, Umschalter für Telemetrie-Inhaltserfassung, Sitzungswartungsmodus und Einstellungen für Sitzungs-Transkript-Memory-Indexierung. Rohlogs, Telemetrie-Exporte, Transkriptinhalte oder Memory-Dateien werden nicht inspiziert, und es wird nicht bewiesen, dass keine personenbezogenen Daten oder Secrets existieren.

Policy-Regelreferenz

Jedes der folgenden Policy-Felder ist optional. Eine Prüfung läuft nur, wenn die passende Regel in policy.jsonc vorhanden ist. Der beobachtete Zustand ist bestehende OpenClaw-Konfiguration oder Arbeitsbereichsmetadaten; Policy meldet Abweichungen, schreibt aber das Runtime-Verhalten nicht um, außer wenn ein Reparaturpfad ausdrücklich verfügbar und aktiviert ist. Policy-Dateien sind strikt: Nicht unterstützte Abschnitte oder Regelschlüssel werden als policy/policy-jsonc-invalid gemeldet, statt ignoriert zu werden.

Policy-Overlays halten breite Regeln auf oberster Ebene global und lassen dann benannte Scope-Blöcke strengere normale Policy-Abschnitte für explizite Selektoren hinzufügen. Ein Scope-Name ist nur ein beschreibender Bucket; der Abgleich verwendet die Selektorwerte innerhalb des Scopes. Das Overlay ist additiv: Globale Ansprüche laufen weiterhin, und ein scoped Anspruch kann einen eigenen Befund gegen dieselbe beobachtete Konfiguration ausgeben.

Scoped Overlays

Verwenden Sie scopes.<scopeName>, wenn eine Gruppe von Agents oder Kanälen eine strengere Policy als die Baseline auf oberster Ebene benötigt. Agent-scoped Abschnitte verwenden agentIds; dies unterstützt tools.*, agents.workspace.*, sandbox.*, dataHandling.memory.* und execApprovals.*. Channel-scoped Ingress verwendet channelIds; dies unterstützt ingress.channels.*. Nicht unterstützte Abschnitte werden abgelehnt, statt ignoriert zu werden. Wenn ein agentIds-Eintrag nicht in agents.list[] vorhanden ist, bewertet OpenClaw die scoped Regel gegen die geerbte globale/Standardhaltung für diese Runtime-Agent-ID.

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

Derselbe Agent kann in mehreren Scopes erscheinen, wenn jeder Scope unterschiedliche Felder verwaltet, wie oben gezeigt. Ein wiederholtes scoped Feld für denselben Agent muss gemäß Policy-Metadaten gleich streng oder strenger sein; schwächere doppelte Ansprüche werden abgelehnt. Striktheitsmetadaten behandeln Allow-Listen als Teilmengen, Deny-Listen als Obermengen und erforderliche boolesche Werte als feste Anforderungen.

Container-Haltungs-Policy wird nur gegen Nachweise ausgewertet, die OpenClaw für den passenden Agent beobachten kann. Wenn eine aktivierte sandbox.containers.*-Regel auf einen Agent angewendet wird, dessen Sandbox-Backend dieses Feld nicht offenlegen kann, meldet Policy policy/sandbox-container-posture-unobservable, statt den Anspruch als bestanden zu behandeln. Verwenden Sie separate agentIds-Scopes für Agent-Gruppen, die unterschiedliche Sandbox-Backends verwenden, und lassen Sie nicht unterstützte Container-Regeln für die Gruppen, bei denen diese Felder nicht beobachtet werden können, unset oder false.

ingress.session.requireDmScope auf oberster Ebene bleibt global, weil session.dmScope kein kanalzuordenbarer Nachweis ist.

Jeder in policy.jsonc vorhandene Scope muss gültig und durchsetzbar sein.

Kanäle

MCP-Server

Modell-Provider

Netzwerk

Ingress und Kanalzugriff

Gateway

Agent-Arbeitsbereich

Sandbox-Posture

Policy behandelt fehlendes sandbox.mode als impliziten Standardwert off, sodass sandbox.requireMode eine frische oder nicht konfigurierte Sandbox als außerhalb einer Allowlist wie ["all"] meldet.

Datenverarbeitung

Secrets

Exec-Genehmigungen

Die Exec-Genehmigungs-Policy beobachtet das aktive Laufzeit-Artefakt exec-approvals.json. Standardmäßig ist dies ~/.openclaw/exec-approvals.json; wenn OPENCLAW_STATE_DIR gesetzt ist, liest Policy $OPENCLAW_STATE_DIR/exec-approvals.json. Tatsächliche Posture-Regeln wie execApprovals.defaults.* oder execApprovals.agents.* benötigen lesbare Artefakt-Evidence; ein fehlendes oder ungültiges Artefakt wird als nicht beobachtbare Evidence gemeldet, statt als Best-Effort-Pass gegen synthetische Laufzeit-Defaults zu gelten. Sobald das Artefakt lesbar ist, erben ausgelassene Genehmigungsfelder Laufzeit-Defaults: fehlendes defaults.security ist full, und fehlende Agent-Sicherheit erbt diesen Standardwert. Evidence umfasst defaults, agents.* und agents.*.allowlist[].pattern plus optionales argPattern, effektive autoAllowSkills-Posture und Eintragsquelle. Sie enthält nicht Socket-Pfad/-Token, commandText, lastUsedCommand, aufgelöste Pfade oder Zeitstempel.

Verlangen Sie beispielsweise das Genehmigungsartefakt, verweigern Sie permissive Standards und lassen Sie nur die geprüfte Exec-Genehmigungshaltung für ausgewählte Agenten zu:

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

Auth-Profile

Tool-Metadaten

Tool-Haltung

Führen Sie während der Erstellung nur Richtlinienprüfungen aus:

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

policy check führt nur den Richtlinienprüfsatz aus und gibt Nachweise, Befunde und Attestierungs-Hashes aus. Dieselben Befunde erscheinen auch in openclaw doctor --lint, wenn das Policy-Plugin aktiviert ist.

Vergleichen Sie eine Operator-Richtliniendatei mit einer erstellten Baseline-Richtliniendatei:

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

policy compare vergleicht Richtliniendateisyntax mit Richtliniendateisyntax. Es prüft keinen OpenClaw-Laufzeitzustand, keine Nachweise, Zugangsdaten oder Geheimnisse. Der Befehl verwendet dieselben Richtlinienregel-Metadaten, die bereichsbezogene Overlays steuern: Allowlisten müssen gleich bleiben oder enger werden, Denylisten müssen gleich bleiben oder breiter werden, erforderliche boolesche Werte müssen ihren erforderlichen Wert behalten, geordnete Zeichenfolgen dürfen sich nur zum restriktiveren Ende der konfigurierten Reihenfolge bewegen, und exakte Listen müssen übereinstimmen.

Die Baseline-Datei kann eine von der Organisation erstellte Richtlinie sein. Die geprüfte Richtlinie kann strengere Werte verwenden oder zusätzliche Richtlinienregeln hinzufügen. Eine geprüfte Regel auf oberster Ebene kann auch eine bereichsbezogene Baseline-Regel erfüllen, wenn sie gleich restriktiv oder restriktiver ist, da Richtlinien auf oberster Ebene breit gelten. Bereichsnamen müssen nicht übereinstimmen; der bereichsbezogene Vergleich wird nach Selektorwert wie agentIds oder channelIds und nach dem geprüften Richtlinienfeld geschlüsselt.

Beispielausgabe eines sauberen Vergleichs im JSON-Format meldet nur den Vergleichszustand der Richtliniendateien:

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

Beispielausgabe von sauberem policy check --json enthält stabile Hashes, die von einem Operator oder Supervisor aufgezeichnet werden können:

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

Richtlinie konfigurieren

Die Richtlinienkonfiguration befindet sich unter plugins.entries.policy.config.

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

Setzen Sie plugins.entries.policy.config.enabled auf false, um Richtlinienprüfungen für einen Workspace zu deaktivieren, während das Plugin installiert bleibt.

Tool-Metadatenanforderungen werden in policy.jsonc mit tools.requireMetadata erstellt, zum Beispiel ["risk", "sensitivity", "owner"].

Richtlinienzustand akzeptieren

Beispielausgabe im JSON-Format:

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

Der Policy-Hash identifiziert das verfasste Regelartefakt. Der Evidence-Block zeichnet den beobachteten OpenClaw-Zustand auf, der von den Policy-Prüfungen verwendet wird. Der Wert workspace.hash identifiziert diese Evidence-Nutzlast für den geprüften Scope. Der Findings-Hash identifiziert die genaue Findings-Menge, die von der Prüfung zurückgegeben wurde. checkedAt zeichnet auf, wann die Auswertung ausgeführt wurde. Der Attestation-Hash identifiziert die stabile Aussage: Policy-Hash, Evidence-Hash, Findings-Hash und ob das Ergebnis sauber war. Er enthält absichtlich nicht checkedAt, sodass derselbe Policy-Zustand bei wiederholten Prüfungen dieselbe Attestation erzeugt. Zusammen bilden diese das Audit-Tupel für diese Policy-Prüfung.

Wenn ein späterer Gateway oder Supervisor Policy verwendet, um eine Runtime-Aktion zu blockieren, zu genehmigen oder zu annotieren, sollte er den Attestation-Hash der letzten sauberen Policy-Prüfung aufzeichnen. checkedAt bleibt für Audit-Logs in der JSON-Ausgabe, ist aber nicht Teil des stabilen Attestation-Hashs.

Verwenden Sie diesen Lebenszyklus beim Akzeptieren von Policy-Zustand:

1. Verfassen oder prüfen Sie policy.jsonc.
2. Führen Sie openclaw policy check --json aus.
3. Wenn das Ergebnis sauber ist, zeichnen Sie attestation.policy.hash als expectedHash auf.
4. Zeichnen Sie attestation.attestationHash als expectedAttestationHash auf.
5. Führen Sie openclaw doctor --lint in CI- oder Release-Gates erneut aus.

Wenn Policy-Regeln absichtlich geändert werden, aktualisieren Sie beide akzeptierten Hashes aus einer sauberen Prüfung. Wenn Workspace-Einstellungen absichtlich geändert werden, die Policy aber gleich bleibt, ändert sich normalerweise nur expectedAttestationHash.

Das Aktivieren oder Aktualisieren von agents.workspace-Regeln fügt dem Workspace-Hash und dem Attestation-Hash agentWorkspace-Evidence hinzu. Operators sollten die neue Evidence prüfen und akzeptierte Attestation-Hashes nach dem Aktivieren dieser Regeln aktualisieren. Das Aktivieren oder Aktualisieren von Tool-Posture-Regeln fügt auf dieselbe Weise toolPosture-Evidence hinzu.

openclaw policy watch führt dieselbe Prüfung wiederholt aus und meldet, wenn die aktuelle Evidence nicht mehr mit expectedAttestationHash übereinstimmt:

openclaw policy watch --json

Verwenden Sie --once in CI oder Skripten, die nur eine Drift-Auswertung benötigen. Ohne --once pollt der Befehl standardmäßig alle zwei Sekunden; verwenden Sie --interval-ms, um ein anderes Intervall auszuwählen.

Findings

Policy prüft derzeit:

Richtlinienbefunde können sowohl target als auch requirement enthalten. target ist das beobachtete Workspace-Objekt, das nicht konform ist. requirement ist die verfasste Richtlinienregel, die daraus einen Befund gemacht hat. Beide Werte sind heute Adressen, üblicherweise oc://-Pfade, aber die Feldnamen beschreiben ihre Richtlinienrolle und nicht das Adressformat.

Beispiel für einen JSON-Befund:

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

Beispiel für einen Tool-Befund:

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

Beispiel für einen MCP-Befund:

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

Beispiel für einen Modell-Provider-Befund:

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

Beispiel für einen Netzwerkbefund:

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

Beispielbefund zur Gateway-Exposition:

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

Beispielbefund zum Agent-Arbeitsbereich:

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

Reparatur

doctor --lint und policy check sind schreibgeschützt.

doctor --fix bearbeitet richtlinienverwaltete Arbeitsbereichseinstellungen nur, wenn workspaceRepairs ausdrücklich aktiviert ist. Ohne diese Opt-in-Einstellung melden Richtlinienprüfungen, was sie reparieren würden, und lassen die Einstellungen unverändert.

In dieser Version kann die Reparatur Kanäle deaktivieren, die in der OpenClaw-Konfiguration aktiviert sind, aber durch channels.denyRules verweigert werden. Aktivieren Sie workspaceRepairs erst, nachdem die Richtliniendatei geprüft wurde, da eine gültige Verweigerungsregel einen konfigurierten Kanal deaktivieren kann:

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

Exit-Codes

Verwandte Themen

• Doctor-Lint-Modus
• Path-CLI