Skip to main content

openclaw policy

openclaw policy は、バンドルされた Policy Plugin によって提供されます。これは既存の OpenClaw 設定上に構築されたエンタープライズ向けの 適合性レイヤーであり、2つ目の設定システムではありません。要件は policy.jsonc に記述します。OpenClaw はアクティブな ワークスペースを証拠として観測し、Policy は doctor --lint を通じて逸脱を報告します。Policy は ツール呼び出しを強制したり、リクエスト時にランタイムの動作を書き換えたりせず、 auth-profiles.json などのエージェント別認証情報ストアを証明することもありません。 Policy は、設定済みチャンネル、MCP サーバー、モデルプロバイダー、ネットワークの SSRF 態勢、イングレスおよびチャンネルアクセス、Gateway の公開範囲と Node コマンド態勢、 記述済みのメッセージルーティングプローブ、 エージェントのワークスペースアクセス、サンドボックス態勢、データ処理態勢、シークレット プロバイダーおよび認証プロファイルの態勢、ならびに管理対象ツールのメタデータ(TOOLS.md)を検査します。 ワークスペースに「Telegram を有効にしてはならない」や「管理対象ツールはリスクと所有者の メタデータを宣言しなければならない」といった、永続的で検査可能な宣言が必要な場合に使用します。 証明や逸脱検出を伴わないローカル動作だけが必要な場合は、通常の 設定で十分です。

クイックスタート

policy.jsonc が存在しない場合でも Plugin は有効なままなので、doctor は 検査を暗黙にスキップするのではなく、不足している成果物を報告できます。 policy.jsonc は手動で記述します。現在の設定から生成されるものではありません。各 トップレベルセクションはルールの名前空間です。具体的なルールがその配下に存在する場合にのみ 検査が実行されます(未対応のセクションやキーは暗黙に無視されず、 policy/policy-jsonc-invalid として失敗します)。サポートされるすべてのセクションを網羅する 最小限の例を次に示します。
以下のルール表からは明確でない、複数領域にまたがる注意事項を示します。
  • local loopback 以外へのバインドを拒否しながら gateway.bind を省略すると、ランタイムの デフォルトを受け入れることになります。厳密な適合性を確保するには gateway.bind: "loopback" を設定してください。
  • 読み取り専用エージェントの場合、該当するデフォルトまたはエージェントでサンドボックスの modeall または non-main に、workspaceAccessnone または ro に設定してください。サンドボックスモードが未指定または off の場合、読み取り専用ポリシーを満たしません。
  • agents.workspace.denyToolsexecprocesswriteeditapply_patch を受け入れます。設定のツール拒否グループ group:fs(ファイル変更)と group:runtime(シェル/プロセス)は、同等の態勢を満たします。
  • 実行承認の検査は、execApprovals ルールが存在する場合にのみ、 稼働中の exec-approvals.json 成果物を読み取ります。成果物が存在しないか無効な場合、それは 観測不能な証拠であり、合格として合成されるものではありません。
  • シークレットおよび認証プロファイルの証拠には、プロバイダー/ソースの態勢と SecretRef メタデータのみが記録され、生の値は一切記録されません。Policy は auth-profiles.json などのエージェント別認証情報ストアを読み取ったり証明したりしません。
  • データ処理の証拠は、設定レベルの態勢(秘匿化モード、 テレメトリ取得の切り替え、セッション保守モード、トランスクリプトのインデックス設定)のみです。 ログ、テレメトリエクスポート、トランスクリプト、メモリファイルは検査されず、 検査結果に問題がなくても、それらに個人データやシークレットが存在しないことは証明されません。
  • ルーティングプローブは、OpenClaw のランタイムバインディングリゾルバーを再利用します。ルーティングの証拠には、 プローブ ID、解決されたエージェント、照合種別、秘匿化されたバインディング メタデータのみが記録されます。ピア、アカウント、ギルド、チーム、ロールの識別子は一切記録されません。 ルーティングセクションを追加すると、ポリシーと証明の ハッシュが意図的に変更されます。ルーティングのないポリシーでは、既存の証拠形式が維持されます。

Policy ルールリファレンス

以下のすべてのルールは任意です。ルールが存在する場合にのみ検査が実行されます。 観測される状態は、既存の OpenClaw 設定またはワークスペースのメタデータです。

スコープ付きオーバーレイ

特定のエージェントまたはチャンネルで、トップレベルのベースラインより厳格なポリシーが必要な場合は、 scopes.<scopeName> を使用します。スコープ名は単なるラベルです。照合には スコープ内のセレクターが使用されます。オーバーレイは加算的です。グローバルルールは引き続き実行され、 スコープ付きルールは同じ証拠に対して独自の検出結果を追加できます。 agentIds エントリが agents.entries.* に存在しない場合、OpenClaw は スコープ付きルールをスキップせず、そのランタイムエージェント ID に継承された グローバル/デフォルトの態勢に対して評価します。
上記のように、各スコープが異なるフィールドを管理する場合、同じエージェントを複数のスコープに含めることができます。 同じエージェントに対してスコープ付きフィールドを繰り返す場合は、同等以上に 厳格でなければなりません。より緩い重複宣言は拒否されます(許可リストは 部分集合、拒否リストは上位集合、必須の真偽値は固定です)。 コンテナ態勢ルール(sandbox.containers.*)は、 照合されたエージェントのサンドボックスバックエンドが公開できる証拠に対してのみ検査されます。バックエンドが 有効化されたルールを観測できない場合、Policy は合格とする代わりに policy/sandbox-container-posture-unobservable を報告します。コンテナルールは、 そのルールを公開できるバックエンドを使用するエージェントグループに限定してください。 トップレベルの ingress.session.requireDmScope はグローバルなままです。session.dmScope は チャンネルに帰属可能な証拠ではないため、channelIds でスコープを限定できません。 policy.jsonc に存在するすべてのスコープは、有効かつ適用可能でなければなりません。

チャンネル

MCP サーバー

モデルプロバイダー

ネットワーク

メッセージルーティング

プローブ ID は一意でなければなりません。ルートは channel、任意の accountIdpeerparentPeerguildIdteamId、および memberRoleIds をサポートします。ピア種別は directgroup、および channel です。matchedBy には、 binding.peerbinding.accountbinding.channeldefault など、1 つ以上のランタイム一致種別を含めることができます。 ルーティングチェックは適合性チェックにすぎません。起動、 メッセージ配信、バインディングの優先順位、フォールバック動作は変更しません。バインディングを自動的に変更すると プライベートメッセージが別の宛先に転送される可能性があるため、検出事項には オペレーターによるレビューが必要です。

イングレスとチャネルアクセス

Gateway

gateway.nodes.denyCommands は、大文字と小文字を区別する完全一致のポリシー拒否スーパーセットルールです。 特権 Node コマンドが OpenClaw 設定で明示的に 拒否されていることをポリシーで証明する必要がある場合に使用します。特権 Node コマンドを意図的に許可するデプロイでは、gateway.nodes.commands.allow のみに依存せず、 レビュー後に policy.jsonc を更新する必要があります。

エージェントワークスペース

サンドボックスポスチャー

ポリシーでは、欠落した sandbox.mode を暗黙のデフォルト値 off として扱うため、 sandbox.requireMode は、新規または未設定のサンドボックスを ["all"] などの許可リスト外として報告します。

データ処理

シークレット

Exec 承認

Exec 承認チェックは、ランタイムの exec-approvals.json アーティファクトを読み取ります。 デフォルトでは ~/.openclaw/exec-approvals.jsonOPENCLAW_STATE_DIR が設定されている場合は $OPENCLAW_STATE_DIR/exec-approvals.json です。 execApprovals.defaults.* または execApprovals.agents.* 配下の ポスチャールールでは、読み取り可能なアーティファクトの証拠が必要です。アーティファクトが欠落または無効な場合、 ベストエフォートで合格とするのではなく、観測不能な証拠として報告されます。読み取り可能になると、省略された フィールドはランタイムのデフォルト値を継承します。欠落した defaults.securityfull となり、 欠落したエージェントセキュリティもそのデフォルト値を継承します。証拠には defaultsagents.*agents.*.allowlist[].pattern、任意の argPattern、有効な autoAllowSkills ポスチャー、およびエントリソースが含まれます。ソケットパス/トークン、 commandTextlastUsedCommand、解決済みパス、タイムスタンプは決して含まれません。 例: 承認アーティファクトを必須にし、制限の緩いデフォルトを拒否して、選択したエージェントに対して レビュー済みの exec 承認態勢のみを許可します。

認証プロファイル

ツールメタデータ

ツール態勢

チェックの実行

作成中にポリシーのみのチェックを実行します。
policy check はポリシーチェックセットのみを実行し、証拠、検出事項、 およびアテステーションハッシュを出力します。Policy Plugin が有効な場合は、 同じ検出事項が openclaw doctor --lint にも表示されます。 オペレーターのポリシーファイルを作成済みのベースラインと比較します。
policy compare はポリシーファイルの構文をポリシーファイルの構文と照合します。 ランタイムの状態、証拠、認証情報、またはシークレットは検査しません。スコープ付きオーバーレイを 管理するものと同じルールメタデータを使用します。許可リストは同等かより狭く、 拒否リストは同等かより広く、必須のブール値はその値を維持する必要があります。 順序付き文字列は設定された順序のより厳格な側にのみ移動でき、完全一致リストは一致する必要があります。 ベースラインには組織が作成したポリシーを使用でき、チェック対象のポリシーには、より厳格な値や 追加のルールを含めることができます。トップレベルのチェック対象ルールは、同等以上に制限的であれば、 スコープ付きのベースラインルールを満たすことができます。ファイル間でスコープ名を一致させる必要はありません。 比較はセレクター(agentIds/channelIds)とフィールドをキーとして行われます。 ルーティングプローブでは、すべてのベースラインプローブ ID が、同じルートおよび想定エージェントとともに 維持される必要があります。チェック対象ポリシーでは、プローブの追加や matchedBy の範囲縮小は可能ですが、 プローブの削除、ルートやエージェントの変更、または許容される一致種別の拡大は、より弱い設定です。 正常な比較(--json):
正常な policy check --json の出力には、オペレーターまたは 監督者が記録できる安定したハッシュが含まれます。

ポリシーの設定

ポリシー設定は plugins.entries.policy.config の下にあります。
Plugin をインストールしたままワークスペースのポリシーチェックを無効にするには、 plugins.entries.policy.config.enabledfalse に設定します。

ポリシー状態の受け入れ

JSON 出力の例:
attestation.policy.hash は作成されたルール成果物を識別します。evidence は チェックで使用された、観測時点の OpenClaw の状態を記録し、 workspace.hash はその証拠ペイロードを識別します。findingsHash は 正確な検出事項の集合を識別します。checkedAt はチェックの実行日時を記録します。 attestationHash は安定したクレーム(ポリシーハッシュ、証拠ハッシュ、 検出事項ハッシュ、およびクリーン/ダーティ状態)を識別し、意図的に checkedAt を 除外するため、同じポリシー状態からは常に同じアテステーションハッシュが生成されます。 これら4つの値が、1回のポリシーチェックの監査タプルを構成します。 Gateway またはスーパーバイザーがポリシーを使用してランタイムアクションをブロック、 承認、または注釈付けする場合、直近のクリーンなチェックのアテステーションハッシュを 記録する必要があります。checkedAt は監査ログ用に JSON 出力へ残りますが、 安定したハッシュには含まれません。 ポリシー状態を受け入れるためのライフサイクル:
  1. policy.jsonc を作成またはレビューします。
  2. openclaw policy check --json を実行します。
  3. クリーンな場合、attestation.policy.hashexpectedHash として記録します。
  4. attestation.attestationHashexpectedAttestationHash として記録します。
  5. CI またはリリースゲートで openclaw doctor --lint を再実行します。
ポリシールールを意図的に変更した場合は、クリーンなチェックから受け入れ済みの 両方のハッシュを更新します。ワークスペース設定のみを変更した場合(ポリシーは同じ)、 通常は expectedAttestationHash のみが変更されます。 agents.workspace ルールを有効化またはアップグレードすると、agentWorkspace の証拠が ワークスペースハッシュとアテステーションハッシュに追加されます。有効化後に新しい証拠を レビューし、受け入れ済みのアテステーションハッシュを更新してください。ツール態勢ルールを 有効化またはアップグレードした場合も、同様に toolPosture の証拠が追加されます。 openclaw policy watch はチェックを再実行し、現在の証拠が expectedAttestationHash と一致しなくなった場合に報告します:
単一のドリフト評価が必要な CI またはスクリプトでは、--once を使用します。 --once を指定しない場合、デフォルトでは2秒ごとにポーリングします。 間隔を変更するには --interval-ms を使用します。

検出事項

検出事項には、target(準拠していない、観測されたワークスペース内の対象)と requirement(その対象を検出事項とした、記述済みのルール)の両方を含めることができます。 現在、どちらも oc:// アドレス文字列ですが、フィールド名はアドレス形式ではなく ポリシー上の役割を表します。 検出事項の例:

修復

doctor --lintpolicy check は読み取り専用です。 doctor --fix は、workspaceRepairs が明示的に有効になっている場合にのみ、ポリシーで管理されるワークスペース設定を編集します。それ以外の場合、チェックでは修復対象を報告し、設定は変更しません。 このバージョンでは、修復によって channels.denyRules で拒否されたチャンネルを無効化し、以下に示す自動的な制限強化の修復を適用できます。有効なルールによってワークスペース設定が変更される可能性があるため、ポリシーファイルをレビューした後にのみ workspaceRepairs を有効にしてください。
  • グローバルポリシーで昇格ツールが禁止されている場合、tools.elevated.enabled=false を設定する
  • ポリシーで対象ツールの拒否が必須とされている場合、不足している必須拒否ツール ID を tools.deny または agents.entries.*.tools.deny に追加する
  • 安全でない gateway.controlUi.* の切り替え設定を false に設定する
  • ポリシーでリモート Gateway モードが拒否されている場合、gateway.mode=local を設定する
  • ポリシーで Gateway HTTP API エンドポイントが拒否されている場合、報告された gateway.http.endpoints.*.enabled パスを false に設定する
  • ポリシーでオープングループからの受信が拒否されている場合、報告されたチャンネル受信 groupPolicy パスを allowlist に設定する
  • ポリシーでグループメンションが必須とされている場合、報告されたチャンネル受信 requireMention パスを true に設定する
  • ポリシーで機密ログの秘匿化が必須とされている場合、logging.redactSensitive=tools を設定する
  • ポリシーでテレメトリ内容のキャプチャが拒否されている場合、diagnostics.otel.captureContent=false、または オブジェクト形式のテレメトリキャプチャ設定では diagnostics.otel.captureContent.enabled=false を設定する
スコープ指定された昇格ツールの修復は検出のみです。検出結果で共有のログ設定またはテレメトリ設定が報告されている場合も、スコープ指定されたデータ処理の修復はスキップされます。共有設定を変更すると、スコープ指定されたポリシー対象以外にも影響が及ぶためです。 検出結果で継承されたルート tools.deny が報告されている場合、スコープ指定された必須拒否の修復はスキップされます。必須ツールをルート設定に追加すると、スコープ指定されたポリシー対象以外にも影響が及ぶためです。エージェントローカルの必須拒否の修復では、報告された agents.entries.*.tools.deny パスを更新できます。 検出結果で継承された channels.defaults.* が報告されている場合、スコープ指定されたチャンネル受信の修復はスキップされます。共有チャンネルのデフォルトを変更すると、スコープ指定されたポリシー対象以外にも影響が及ぶためです。自動修復では正しいエンドポイント URL の許可リスト値を選択できないため、Gateway HTTP URL 取得の許可リストに関する検出結果は手動対応のままです。 Gateway のバインドと Node コマンドに関する検出結果には、引き続きレビューが必要です。policy/gateway-non-loopback-bind または policy/gateway-node-command-denied を設定パスにマッピングできる場合、doctor --fix は提案された gateway.bind または gateway.nodes.commands.deny の変更を、スキップされたプレビューガイダンスとして報告します。変更は適用されず、オペレーターがレビューして設定またはポリシーを更新するまで、検出結果は修復済みとしてカウントされません。

終了コード

関連項目