openclaw policy

openclaw policy wird vom gebündelten Policy-Plugin bereitgestellt. Es handelt sich um eine unternehmensweite Konformitätsschicht über vorhandenen OpenClaw-Einstellungen, nicht um ein zweites Konfigurationssystem. Sie verfassen Anforderungen in policy.jsonc; OpenClaw betrachtet den aktiven Workspace als Nachweis; Policy meldet Abweichungen über doctor --lint. Policy erzwingt keine Tool-Aufrufe und schreibt das Laufzeitverhalten nicht bei der Anfrageverarbeitung um. Außerdem attestiert es keine agentenspezifischen Anmeldedatenspeicher wie auth-profiles.json.

Policy prüft konfigurierte Kanäle, MCP-Server, Modell-Provider, die SSRF- Sicherheitslage des Netzwerks, Eingangs-/Kanalzugriff, Gateway-Exposition und die Befehlslage von Nodes, verfasste Nachrichten-Routing-Prüfungen, den Workspace-Zugriff von Agenten, die Sandbox-Sicherheitslage, die Datenverarbeitungslage, die Lage von Secret- Providern/Authentifizierungsprofilen und Metadaten verwalteter Tools (TOOLS.md). Verwenden Sie es, wenn ein Workspace eine dauerhafte, überprüfbare Festlegung benötigt, etwa „Telegram darf nicht aktiviert sein“ oder „verwaltete Tools müssen Risiko- und Eigentümermetadaten deklarieren“. Wenn Sie nur lokales Verhalten ohne Attestierung oder Abweichungserkennung benötigen, reicht die normale Konfiguration aus.

Schnellstart

openclaw plugins enable policy

Das Plugin bleibt auch dann aktiviert, wenn policy.jsonc fehlt, sodass doctor das fehlende Artefakt melden kann, statt Prüfungen stillschweigend zu überspringen.

Verfassen Sie policy.jsonc manuell; es wird nicht aus den aktuellen Einstellungen generiert. Jeder Abschnitt auf oberster Ebene ist ein Regel-Namespace: Eine Prüfung wird nur ausgeführt, wenn darunter eine konkrete Regel vorhanden ist (nicht unterstützte Abschnitte oder Schlüssel schlagen mit policy/policy-jsonc-invalid fehl, statt stillschweigend ignoriert zu werden). Minimales Beispiel, das jeden unterstützten Abschnitt abdeckt:

{  "channels": {    "denyRules": [      {        "id": "no-telegram",        "when": { "provider": "telegram" },        "reason": "Telegram ist für diesen Workspace nicht genehmigt.",      },    ],  },  "mcp": {    "servers": {      "allow": ["docs"],      "deny": ["untrusted"],    },  },  "models": {    "providers": {      "allow": ["openai", "anthropic"],      "deny": ["openrouter"],    },  },  "network": {    "privateNetwork": {      "allow": false,    },  },  "routing": {    "requireBindings": true,    "requireConfiguredChannels": true,    "probes": [      {        "id": "family-dm",        "route": {          "channel": "imessage",          "peer": { "kind": "direct", "id": "+15555550123" },        },        "expect": {          "agentId": "family",          "matchedBy": ["binding.peer"],        },      },    ],  },  "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,    },    "nodes": {      "denyCommands": ["system.run"],    },  },  "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"],  },}

Abschnittsübergreifende Hinweise, die aus den nachstehenden Regeltabellen nicht offensichtlich hervorgehen:

• Wenn Sie gateway.bind weglassen und gleichzeitig Nicht-Loopback-Bindungen verweigern, akzeptieren Sie den Laufzeitstandard; legen Sie gateway.bind: "loopback" für strikte Konformität fest.
• Legen Sie für einen schreibgeschützten Agenten den Sandbox-Wert mode bei den zutreffenden Standardwerten/dem zutreffenden Agenten auf all oder non-main und workspaceAccess auf none oder ro fest. Ein fehlender oder auf off gesetzter Sandbox-Modus erfüllt keine Richtlinie für schreibgeschützten Zugriff.
• agents.workspace.denyTools akzeptiert exec, process, write, edit, apply_patch. Die Tool-Verweigerungsgruppen der Konfiguration group:fs (Dateiveränderung) und group:runtime (Shell/Prozess) erfüllen die entsprechende Sicherheitslage.
• Prüfungen von Ausführungsgenehmigungen lesen das aktive Artefakt exec-approvals.json nur, wenn eine Regel execApprovals vorhanden ist; ein fehlendes oder ungültiges Artefakt ist nicht beobachtbarer Nachweis und kein synthetisch bestandener Test.
• Nachweise zu Secrets und Authentifizierungsprofilen zeichnen nur die Provider-/Quellenlage und SecretRef-Metadaten auf, niemals Rohwerte. Policy liest oder attestiert keine agentenspezifischen Anmeldedatenspeicher wie auth-profiles.json.
• Nachweise zur Datenverarbeitung betreffen ausschließlich die Konfigurationslage (Schwärzungsmodus, Umschalter für Telemetrieerfassung, Sitzungswartungsmodus, Einstellung zur Transkriptindizierung). Sie untersuchen keine Protokolle, Telemetrieexporte, Transkripte oder Speicherdateien, und ein fehlerfreies Ergebnis beweist nicht, dass darin keine personenbezogenen Daten oder Secrets vorhanden sind.
• Routing-Prüfungen verwenden den Laufzeit-Bindungsresolver von OpenClaw erneut. Routing-Nachweise zeichnen nur die Prüfungs-ID, den aufgelösten Agenten, die Übereinstimmungsart und geschwärzte Bindungsmetadaten auf. Sie zeichnen niemals Peer-, Konto-, Guild-, Team- oder Rollenkennungen auf. Das Hinzufügen eines Routing-Abschnitts ändert absichtlich die Policy- und Attestierungshashes; Richtlinien ohne Routing behalten ihre vorhandene Nachweisstruktur.

Referenz der Policy-Regeln

Jede nachstehende Regel ist optional; eine Prüfung wird nur ausgeführt, wenn die Regel vorhanden ist. Der beobachtete Zustand besteht aus der vorhandenen OpenClaw-Konfiguration oder den Workspace-Metadaten.

Bereichsbezogene Overlays

Verwenden Sie scopes.<scopeName>, wenn bestimmte Agenten oder Kanäle eine strengere Policy als die Baseline auf oberster Ebene benötigen. Der Bereichsname ist nur eine Bezeichnung; der Abgleich verwendet den Selektor innerhalb des Bereichs. Overlays sind additiv: Die globale Regel wird weiterhin ausgeführt, und die bereichsbezogene Regel kann einen eigenen Befund für denselben Nachweis hinzufügen.

Wenn ein Eintrag agentIds nicht in agents.entries.* vorhanden ist, wertet OpenClaw die bereichsbezogene Regel anhand der geerbten globalen/standardmäßigen Sicherheitslage für diese Laufzeitagenten-ID aus, statt sie zu überspringen.

{  "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 Bereichen vorkommen, wenn jeder Bereich ein anderes Feld verwaltet, wie oben dargestellt. Ein wiederholtes bereichsbezogenes Feld für denselben Agenten muss gleich oder stärker einschränkend sein; eine schwächere doppelte Festlegung wird abgelehnt (Zulassungslisten sind Teilmengen, Verweigerungslisten sind Obermengen, erforderliche boolesche Werte sind festgelegt).

Regeln zur Container-Sicherheitslage (sandbox.containers.*) werden nur anhand der Nachweise geprüft, die das Sandbox-Backend des übereinstimmenden Agenten offenlegen kann. Wenn ein Backend eine dafür aktivierte Regel nicht beobachten kann, meldet Policy policy/sandbox-container-posture-unobservable, statt die Prüfung als bestanden zu werten; beschränken Sie Container-Regeln auf die Agentengruppen, die ein Backend verwenden, das sie offenlegen kann.

ingress.session.requireDmScope auf oberster Ebene bleibt global; session.dmScope ist kein einem Kanal zuordenbarer Nachweis und kann daher nicht nach channelIds abgegrenzt werden.

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

Kanäle

MCP-Server

Modell-Provider

Netzwerk

Nachrichtenweiterleitung

Prüf-IDs müssen eindeutig sein. Eine Route unterstützt channel, optional accountId, peer, parentPeer, guildId, teamId und memberRoleIds. Peer-Arten sind direct, group und channel. matchedBy kann eine oder mehrere Laufzeit-Übereinstimmungsarten enthalten, darunter binding.peer, binding.account, binding.channel oder default.

Weiterleitungsprüfungen sind ausschließlich Konformitätsprüfungen. Sie ändern weder den Startvorgang noch die Nachrichtenzustellung, die Bindungspriorität oder das Fallback-Verhalten. Befunde erfordern eine Überprüfung durch den Betreiber, da die automatische Änderung einer Bindung private Nachrichten umleiten könnte.

Ingress- und Kanalzugriff

Gateway

gateway.nodes.denyCommands ist eine exakte, zwischen Groß- und Kleinschreibung unterscheidende Verweigerungs-Obermengenregel. Verwenden Sie sie, wenn die Richtlinie nachweisen muss, dass privilegierte Node-Befehle durch die OpenClaw-Konfiguration ausdrücklich verweigert werden. Eine Bereitstellung, die einen privilegierten Node-Befehl absichtlich zulässt, sollte nach der Überprüfung policy.jsonc aktualisieren, anstatt sich ausschließlich auf gateway.nodes.commands.allow zu verlassen.

Agenten-Arbeitsbereich

Sandbox-Sicherheitsstatus

Die Richtlinie behandelt ein fehlendes sandbox.mode als dessen impliziten Standardwert off, sodass sandbox.requireMode eine neue oder nicht konfigurierte Sandbox als außerhalb einer Zulassungsliste wie ["all"] meldet.

Datenverarbeitung

Geheimnisse

Ausführungsgenehmigungen

Prüfungen für Ausführungsgenehmigungen lesen das Laufzeitartefakt exec-approvals.json: standardmäßig ~/.openclaw/exec-approvals.json oder $OPENCLAW_STATE_DIR/exec-approvals.json, wenn OPENCLAW_STATE_DIR gesetzt ist. Sicherheitsstatusregeln unter execApprovals.defaults.* oder execApprovals.agents.* erfordern lesbare Artefaktnachweise; ein fehlendes oder ungültiges Artefakt wird als nicht beobachtbarer Nachweis statt als Best-Effort-Erfolg gemeldet. Sobald es lesbar ist, übernehmen ausgelassene Felder die Laufzeitstandardwerte: Ein fehlendes defaults.security entspricht full, und fehlende Agentensicherheit übernimmt diesen Standardwert. Der Nachweis umfasst defaults, agents.*, agents.*.allowlist[].pattern, optional argPattern, den effektiven autoAllowSkills-Sicherheitsstatus und die Eintragsquelle — niemals Socket-Pfad/-Token, commandText, lastUsedCommand, aufgelöste Pfade oder Zeitstempel.

Beispiel: Das Genehmigungsartefakt verlangen, großzügige Standardwerte verweigern und nur die geprüfte Ausführungsgenehmigungskonfiguration für ausgewählte Agenten zulassen.

{  "execApprovals": {    "requireFile": true,    "defaults": {      // Sicherheitsmodi: "deny", "allowlist" oder "full".      // Dieser Standardwert erlaubt nur die streng eingeschränkte Verweigerungskonfiguration.      "allowSecurity": ["deny"],    },  },  "scopes": {    "restricted-shell": {      "agentIds": ["family-agent", "groups-agent"],      "execApprovals": {        "agents": {          // Ausgewählte Agenten dürfen die geprüfte Positivlistenkonfiguration verwenden, aber nicht "full".          "allowSecurity": ["allowlist"],          // false bedeutet, dass Skill-CLIs in der geprüften Positivliste aufgeführt sein müssen, statt          // durch autoAllowSkills implizit genehmigt zu werden.          "allowAutoAllowSkills": false,          "allowlist": {            "expected": [              // Einfacher Eintrag: exakt geprüftes Muster der ausführbaren Datei ohne argPattern.              "travel-hub",              // Eingeschränkter Eintrag: Muster plus geprüfter regulärer Ausdruck für Argumente.              { "pattern": "calendar-cli", "argPattern": "^sync\\b" },              "/bin/date",            ],          },        },      },    },  },}

Authentifizierungsprofile

Tool-Metadaten

Tool-Konfiguration

Prüfungen ausführen

Während der Erstellung ausschließlich Richtlinienprüfungen ausführen:

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

policy check führt nur den Satz von Richtlinienprüfungen aus und gibt Nachweise, Feststellungen und Attestierungshashes aus. Dieselben Feststellungen erscheinen auch in openclaw doctor --lint, wenn das Richtlinien-Plugin aktiviert ist.

Eine Operator-Richtliniendatei mit einer erstellten Baseline vergleichen:

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

policy compare prüft die Syntax einer Richtliniendatei anhand der Syntax einer Richtliniendatei; dabei werden weder Laufzeitzustand noch Nachweise, Anmeldedaten oder Geheimnisse untersucht. Es werden dieselben Regelmetadaten verwendet, die bereichsbezogene Überlagerungen steuern: Positivlisten müssen gleich bleiben oder enger werden, Sperrlisten müssen gleich bleiben oder weiter werden, erforderliche boolesche Werte müssen ihren Wert beibehalten, geordnete Zeichenfolgen dürfen nur zum strengeren Ende der konfigurierten Reihenfolge verschoben werden und exakte Listen müssen übereinstimmen. Die Baseline kann eine von der Organisation erstellte Richtlinie sein; die geprüfte Richtlinie darf strengere Werte oder zusätzliche Regeln enthalten. Eine geprüfte Regel auf oberster Ebene kann eine bereichsbezogene Baseline-Regel erfüllen, wenn sie ebenso restriktiv oder restriktiver ist. Die Bereichsnamen müssen zwischen den Dateien nicht übereinstimmen; der Vergleich erfolgt anhand von Selektor (agentIds/channelIds) und Feld. Bei Routing-Prüfungen muss jede Baseline-Prüfungs-ID mit derselben Route und demselben erwarteten Agenten erhalten bleiben. Eine geprüfte Richtlinie darf Prüfungen hinzufügen oder matchedBy einschränken, aber das Entfernen einer Prüfung, das Ändern ihrer Route oder ihres Agenten oder das Erweitern ihrer akzeptierten Übereinstimmungsarten ist weniger streng.

Erfolgreicher Vergleich (--json):

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

Eine erfolgreiche policy check --json-Ausgabe enthält stabile Hashes, die ein Operator oder Supervisor aufzeichnen kann:

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

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

Richtlinienzustand akzeptieren

Beispiel für eine JSON-Ausgabe:

{  "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.6-sol",        "provider": "openai",        "model": "gpt-5.6-sol",        "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": []}

attestation.policy.hash identifiziert das erstellte Regelartefakt. evidence erfasst den beobachteten OpenClaw-Zustand, den die Prüfungen verwenden, und workspace.hash identifiziert diese Evidenznutzlast. findingsHash identifiziert die genaue Befundmenge. checkedAt erfasst, wann die Prüfung ausgeführt wurde. attestationHash identifiziert die stabile Aussage (Policy-Hash, Evidenz-Hash, Befund-Hash und sauberer/geänderter Zustand) und schließt checkedAt bewusst aus, sodass derselbe Policy-Zustand immer denselben Attestierungs-Hash erzeugt. Zusammen bilden diese vier Werte das Audit-Tupel für eine Policy-Prüfung.

Wenn ein Gateway oder Supervisor anhand einer Policy eine Laufzeitaktion blockiert, genehmigt oder mit Anmerkungen versieht, sollte er den Attestierungs-Hash der letzten sauberen Prüfung erfassen. checkedAt verbleibt für Audit-Protokolle in der JSON-Ausgabe, ist jedoch nicht Teil des stabilen Hashes.

Lebenszyklus zum Akzeptieren des Policy-Zustands:

1. Erstellen oder prüfen Sie policy.jsonc.
2. Führen Sie openclaw policy check --json aus.
3. Erfassen Sie bei einer sauberen Prüfung attestation.policy.hash als expectedHash.
4. Erfassen Sie attestation.attestationHash als expectedAttestationHash.
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 anhand einer sauberen Prüfung. Wenn sich nur Workspace-Einstellungen ändern (die Policy bleibt unverändert), ändert sich in der Regel nur expectedAttestationHash.

Das Aktivieren oder Aktualisieren von agents.workspace-Regeln fügt dem Workspace-Hash und dem Attestierungs-Hash agentWorkspace-Evidenz hinzu; prüfen Sie die neue Evidenz und aktualisieren Sie nach der Aktivierung die akzeptierten Attestierungs-Hashes. Das Aktivieren oder Aktualisieren von Regeln für die Tool-Sicherheitskonfiguration fügt auf dieselbe Weise toolPosture-Evidenz hinzu.

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

openclaw policy watch --json

Verwenden Sie --once in CI oder Skripten, die eine einzelne Driftbewertung benötigen. Ohne --once erfolgt die Abfrage standardmäßig alle zwei Sekunden; verwenden Sie --interval-ms, um das Intervall zu ändern.

Befunde

Eine Feststellung kann sowohl target (das beobachtete Element im Arbeitsbereich, das nicht konform ist) als auch requirement (die definierte Regel, durch die es zu einer Feststellung wurde) enthalten. Beide sind derzeit oc://-Adresszeichenfolgen, aber die Feldnamen beschreiben die Rolle in der Richtlinie und nicht das Adressformat.

Beispiele für Feststellungen:

{  "checkId": "policy/channels-denied-provider",  "severity": "error",  "message": "Der Kanal 'telegram' verwendet den abgelehnten 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 ist für diesen Arbeitsbereich nicht genehmigt."}

{  "checkId": "policy/tools-missing-risk-level",  "severity": "error",  "message": "Das Tool 'deploy' in TOOLS.md hat keine explizite Risikoklassifizierung.",  "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"}

{  "checkId": "policy/mcp-unapproved-server",  "severity": "error",  "message": "Der MCP-Server 'remote' befindet sich nicht auf der Richtlinien-Zulassungsliste.",  "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"}

{  "checkId": "policy/models-unapproved-provider",  "severity": "error",  "message": "Die Modellreferenz 'anthropic/claude-sonnet-4.7' verwendet den nicht genehmigten 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"}

{  "checkId": "policy/network-private-access-enabled",  "severity": "error",  "message": "Die Netzwerkeinstellung 'browser-private-network' erlaubt den Zugriff auf private Netzwerke.",  "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"}

{  "checkId": "policy/gateway-non-loopback-bind",  "severity": "error",  "message": "Die Gateway-Bindungseinstellung 'gateway-bind' erlaubt eine Offenlegung außerhalb der Loopback-Schnittstelle.",  "source": "policy",  "path": "openclaw config",  "ocPath": "oc://openclaw.config/gateway/bind",  "target": "oc://openclaw.config/gateway/bind",  "requirement": "oc://policy.jsonc/gateway/exposure/allowNonLoopbackBind"}

{  "checkId": "policy/gateway-node-command-denied",  "severity": "error",  "message": "Der Gateway-Node-Befehl 'system.run' ist durch die Richtlinie untersagt, aber nicht durch die OpenClaw-Konfiguration.",  "source": "policy",  "path": "openclaw config",  "ocPath": "oc://openclaw.config/gateway/nodes/commands/deny",  "target": "oc://openclaw.config/gateway/nodes/commands/deny",  "requirement": "oc://policy.jsonc/gateway/nodes/denyCommands",  "fixHint": "Fügen Sie 'system.run' zu gateway.nodes.commands.deny hinzu oder aktualisieren Sie die Richtlinie nach der Überprüfung."}

{  "checkId": "policy/agents-workspace-access-denied",  "severity": "error",  "message": "Der Sandbox-Arbeitsbereichszugriff 'rw' unter agents.defaults ist laut Richtlinie nicht zulässig.",  "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; andernfalls melden Prüfungen, was sie reparieren würden, und lassen die Einstellungen unverändert.

In dieser Version kann die Reparatur durch channels.denyRules untersagte Kanäle deaktivieren und die unten aufgeführten automatischen Einschränkungsreparaturen anwenden. Aktivieren Sie workspaceRepairs erst, nachdem die Richtliniendatei überprüft wurde, da eine gültige Regel die Arbeitsbereichskonfiguration ändern kann:

• tools.elevated.enabled=false festlegen, wenn eine globale Richtlinie Tools mit erweiterten Berechtigungen untersagt
• fehlende erforderliche Tool-IDs für die Sperrliste zu tools.deny oder agents.entries.*.tools.deny hinzufügen, wenn die Richtlinie verlangt, dass diese Tools untersagt werden
• unsichere gateway.controlUi.*-Schalter auf false setzen
• gateway.mode=local festlegen, wenn die Richtlinie den Remote-Gateway-Modus untersagt
• gemeldete gateway.http.endpoints.*.enabled-Pfade auf false setzen, wenn die Richtlinie Gateway-HTTP-API-Endpunkte untersagt
• gemeldete groupPolicy-Pfade für eingehenden Kanalverkehr auf allowlist setzen, wenn die Richtlinie offenen Gruppenzugriff untersagt
• gemeldete requireMention-Pfade für eingehenden Kanalverkehr auf true setzen, wenn die Richtlinie Gruppenerwähnungen verlangt
• logging.redactSensitive=tools festlegen, wenn die Richtlinie die Schwärzung sensibler Protokolldaten verlangt
• diagnostics.otel.captureContent=false oder diagnostics.otel.captureContent.enabled=false für Telemetrieerfassungseinstellungen in Objektform festlegen, wenn die Richtlinie die Erfassung von Telemetrieinhalten untersagt

Bereichsspezifische Reparaturen für Tools mit erweiterten Berechtigungen dienen nur der Erkennung. Bereichsspezifische Reparaturen der Datenverarbeitung werden ebenfalls übersprungen, wenn der Befund eine gemeinsam verwendete Protokollierungs- oder Telemetriekonfiguration meldet, da eine Änderung der gemeinsam verwendeten Einstellung mehr als das bereichsspezifische Richtlinienziel betreffen würde.

Bereichsspezifische Reparaturen erforderlicher Sperrlisten werden übersprungen, wenn der Befund eine geerbte Stammkonfiguration unter tools.deny meldet, da das Hinzufügen des erforderlichen Tools zur Stammkonfiguration mehr als das bereichsspezifische Richtlinienziel betreffen würde. Agent-lokale Reparaturen erforderlicher Sperrlisten können den gemeldeten agents.entries.*.tools.deny-Pfad aktualisieren.

Bereichsspezifische Reparaturen für eingehenden Kanalverkehr werden übersprungen, wenn der Befund geerbte channels.defaults.* meldet, da eine Änderung des gemeinsam verwendeten Kanalstandards mehr als das bereichsspezifische Richtlinienziel betreffen würde. Befunde zu Gateway-HTTP-URL-Abruf-Zulassungslisten müssen weiterhin manuell behoben werden, da die automatische Reparatur nicht die richtigen Zulassungslistenwerte für Endpunkt-URLs auswählen kann.

Befunde zu Gateway-Bindungen und Node-Befehlen erfordern weiterhin eine Überprüfung. Wenn policy/gateway-non-loopback-bind oder policy/gateway-node-command-denied einem Konfigurationspfad zugeordnet werden kann, meldet doctor --fix die vorgeschlagene Änderung an gateway.bind oder gateway.nodes.commands.deny als übersprungene Vorschauhinweise. Die Änderung wird nicht angewendet, und der Befund gilt erst dann als repariert, wenn ein Betreiber die Konfiguration oder Richtlinie überprüft und aktualisiert hat.

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

Exitcodes

Verwandte Themen

• Doctor-Lint-Modus
• Pfad-CLI