OpenClaw のセキュリティ設定入門 — pairing・sandbox・exec approvals の安全運用

OpenClawとセキュリティで、最初に捨てるべき幻想

OpenClawとセキュリティを語るとき、まず捨てるべき幻想があります。
「AIが危ない」のではなく、「AIに何を触らせるか」が危ないということです。

OpenClawは、リアルなメッセージング面に、リアルなファイル、リアルなコマンド実行、リアルな外部ツールをつなぎます。だからこそ便利です。逆に言えば、境界設計を雑にすると、便利さがそのまま事故の入口になります。

OpenClaw 自体の機能や向いている用途を先に整理したい場合は「OpenClawで何ができるのか」を、Claude 系エージェントとどう使い分けるかを見たい場合は「OpenClaw vs Claude 徹底比較」も先に読むと、このセキュリティ設計の前提が掴みやすいです。

私の結論ははっきりしています。**OpenClawは“安全な自動化”ではなく、“安全に設計しないと危険な自動化”**です。

OpenClaw の全体像や何ができるかをまだ掴めていないなら、先に OpenClaw の使い方入門を読むと、この後の境界設計が理解しやすくなります。導入判断まで含めて比較したい場合は、OpenClaw vs Claude 徹底比較も合わせて見ると位置づけがはっきりします。

まず前提: これはマルチテナントの境界ではない

OpenClaw の公式セキュリティ文書は、かなり明確です。
1つの Gateway を複数の敵対的ユーザーで共有する前提ではありません。

つまり、OpenClaw の安全モデルは次の考え方です。

Gateway は制御面
Node は実行面
それらは同じ信頼ドメインとして扱う
必要なら OS ユーザーやホストごと切る

この整理を無視して「これならチーム全員で共用できる」と考えると、期待値がずれます。OpenClaw は、権限分離を魔法で解決する製品ではありません。

DMのデフォルトは「pairing」にしておく

OpenClaw の DM 受信は、デフォルトで pairing ベースです。知らない送信者には短いコードを返し、承認されるまで処理しません。

これが重要なのは、AIの脅威がモデル内部よりも入力面にあるからです。
見知らぬ DM、貼られたリンク、添付ファイル、雑にコピーされた指示文。こうしたものを素通しにすると、AI は簡単に誘導されます。

OpenClaw の安全運用で最低限やるべきことは次です。

{
  "session": {
    "dmScope": "per-channel-peer"
  },
  "channels": {
    "telegram": {
      "dmPolicy": "pairing"
    },
    "discord": {
      "dmPolicy": "pairing"
    }
  }
}

この設定で得られるのは、単なるアクセス制限ではありません。ユーザーごとの文脈分離です。複数人が同じボットに触れるなら、これは必須に近いです。

`allow` より `ask`、`ask` より sandbox

OpenClaw の危険度を決めるのは、モデルの賢さではなく、実行面の制御です。

特に見るべきは次の3つです。

1. Exec approvals

OpenClaw は exec approvals で、allowlist と ask を組み合わせてコマンド実行を絞れます。
ここで大事なのは、承認はホスト分離の代わりではないことです。

2. Sandbox

Sandbox を使えば、実行できる範囲を狭められます。
ただし、sandbox を切った瞬間に、実行は一気に危険になります。便利だからこそ、ここは妥協しない方がいいです。

3. Doctor と Security audit

openclaw doctor と openclaw security audit は、設定の危険箇所を見つけるための最低限のチェックです。
これを「最初の1回だけ」ではなく、設定変更のたびに回すべきです。

openclaw security audit
openclaw doctor
openclaw pairing list telegram
openclaw pairing approve telegram ABCD-EFGH

Skills と plugins は「便利な拡張」ではなく「コード実行面」

OpenClaw の Skills は、Markdown だけの説明文ではありません。
実際には、スクリプトや設定を含む versioned bundle です。

そして ClawHub は公開レジストリです。検索や配布が簡単なのは強みですが、裏返せば導入時の審査責任は自分にあるということです。

ここでよくある失敗は、「README が丁寧だから安全だろう」と思うことです。違います。
安全かどうかは、配布文書ではなく、展開後に何が実行されるかで決まります。

この感覚は、AIコーディングで存在しない依存パッケージをそのまま入れてしまう問題と同じです。サプライチェーン面の具体例は「パッケージハルシネーション攻撃（Slopsquatting）解説」でも扱っています。

私なら、少なくとも次を徹底します。

使う前に unpack された中身を見る
pinned version 以外は入れない
拡張を有効化する前に openclaw doctor を通す
秘密情報を workspace に置かない

安全に使うための初期値

OpenClaw を安全寄りで始めるなら、初期値はかなり保守的でいいです。

DM は pairing をデフォルトにする
グループは mention gating を使う
open は最後の手段にする
allowlist を明示する
session.dmScope を共有前提にしない
1つの Gateway を複数の敵対的ユーザーで共有しない
重要な exec は sandbox の外に出さない

これは「機能を削る」話ではありません。
最初から広く開けないことが、結局いちばん速いです。後から事故対応する方がずっと高くつきます。

よくある誤解

誤解1: pairing しているから安全

安全ではありません。pairing は入口の認証です。実行面の隔離ではありません。

誤解2: exec approvals があるから大丈夫

大丈夫ではありません。承認は補助輪であって、ホスト隔離ではありません。

誤解3: Skills はただの説明書

違います。実体はコードと設定の塊です。便利なだけに、取り扱いは厳しめでいいです。

まとめ

OpenClaw とセキュリティの関係は、要するにこうです。
OpenClaw は危険だから避けるのではなく、危険になりやすい構造を前提に境界を設計して使うべきです。

便利さを捨てる必要はありません。
ただし、DM、セッション、exec、sandbox、Skills のそれぞれに境界を引かないまま本番運用するのは、かなり雑です。

私は、OpenClaw を「安全なAI」ではなく、安全設計を要求する強い道具として扱う方が現実的だと思います。

組織導入でルールや責任分界まで含めて設計したい場合は、「AIの組織利用をどう進めるか」も合わせて読むと、技術設定と運用ルールを分けて考えやすくなります。導入判断の比較軸を整理したいなら OpenClaw vs Claude 徹底比較、OpenClaw 自体の全体像を押さえたいなら OpenClaw の使い方入門を続けて読むのがおすすめです。