Policy Plugin: Doctor Checks for Workspace Conformance
Learn how the Policy plugin adds policy-backed doctor checks for workspace conformance, covering channels, tools, MCP servers, and more. Operators use it to audit drift and record attestation hashes.
Read this when
- You are installing, configuring, or auditing the policy plugin
Policy plugin
Adds policy-backed doctor checks for workspace conformance.
Distribution
- Package:
@openclaw/policy - Install route: included in OpenClaw
Surface
plugin
Behavior
Doctor health checks for policy-managed OpenClaw settings and governed workspace declarations are contributed by the Policy plugin. Policy coverage extends to channel conformance, governed tool metadata, MCP server posture, model-provider posture, private-network access posture, Gateway exposure posture, agent workspace/tool posture, configured global/per-agent tool posture, configured sandbox runtime posture, ingress/channel access posture, data-handling posture, and OpenClaw config secret provider/auth profile posture.
Authored requirements are stored in policy.jsonc, while existing OpenClaw settings and workspace declarations serve as observed evidence. Drift is reported through openclaw policy check and openclaw doctor --lint. When a policy check passes cleanly, it emits policy, evidence, findings, and attestation hashes that operators can record for audit purposes.
openclaw policy check, watch, and workspace-relative compare all take --agent <id>. For explicit multi-agent fleets, the workspace owner must be selected; the plugin never deduces this from roster order.
openclaw policy compare --baseline <file> performs a comparison between one policy file and another. This is purely config-level conformance: policy rule metadata is used to confirm that the checked policy is neither missing nor weaker than the authored baseline, and runtime state, credentials, or secret values are not inspected.
Tool posture rules may mandate approved profiles, workspace-only filesystem tools, bounded exec security/ask/host settings, disabled elevated mode, exact alsoAllow entries, and required tool deny entries. Additive alsoAllow entries appear in the evidence because they can broaden effective tool posture. These checks only observe config conformance; runtime approval state is not read, and no runtime enforcement is added.
Sandbox posture rules can require approved sandbox modes/backends, deny host container networking, deny container namespace joins, require read-only container mounts, deny container runtime socket mounts and unconfined container profiles, and require sandbox browser CDP source ranges. Only config conformance is observed here; runtime approval state, live containers, and runtime enforcement are all outside the scope of these checks.
Data-handling rules can require sensitive logging redaction, deny telemetry content capture, require session retention maintenance, and deny session transcript memory indexing. These checks observe config conformance only; raw logs, telemetry exports, transcripts, memory files, secrets, and personal data are not inspected.
Named policy scopes under scopes.<scopeName> can add stricter normal policy sections for the selector they list. agentIds supports tools, agents.workspace, sandbox, and dataHandling.memory; channelIds supports ingress.channels. Runtime agent ids absent from agents.entries.* are checked against inherited global/default posture rather than silently passing with no evidence. Every scope present in policy.jsonc must be valid and enforceable for its selector. Overlay rules are additional claims, so they do not weaken top-level policy and can produce their own findings when the same observed config violates both scopes.