OpenClawの便利な機能そのものが、セキュリティモデルを重視すべき理由です。ゲートウェイは、メッセージングチャネルを、シェルコマンドの実行、ファイルの読み書き、ブラウザの操作、メッセージの送信が可能なエージェントにつなぎます。単純でも影響の大きい障害経路の1つは、信頼できない送信者や、アカウントを侵害された送信者が、過剰な権限を持つエージェントに到達することです。以下の対策は、通常のホスト、依存関係、認証情報、ネットワークのセキュリティ対策と併せて、このリスクを減らします。
OpenClaw自身が示す順序は妥当です（セキュリティ文書）：
- まず利用者を確認：誰がボットと対話できるかを制御する（DMのペアリング／許可リスト／明示的な公開設定）。
- 次にスコープ：どこで何を実行できるかを制御する（グループ、ツール、サンドボックス、デバイス権限）。
- モデルは最後：モデルは操作され得ると想定し、被害範囲を限定する。
この記事では、ゲートウェイがすでにインストールされていることを前提とします（個人用ゲートウェイのセットアップ）。
dmPolicy="open"とgroupPolicy="open"は最後の手段です。ボットに到達できるすべての参加者を完全に信頼できる場合を除き、ペアリングと許可リストを優先してください。ツールを有効にした公開DMは、誰でも到達できるリモート操作面になります。
承認した送信者は全員、エージェントが読めるものへの経路になり得ます。対象には、メール、ファイル、ブラウザセッション、ツール内の顧客データなどがあります。人を承認するときは、SSHキーを許可するときと同じように慎重に扱ってください。対象を絞り、取り消せるようにし、承認理由を明記します。
信頼モデルを一段落で説明する
OpenClawが文書化しているのは、ゲートウェイごとに信頼できる運用者1人を境界とする個人アシスタント向けの信頼モデルです。敵対的なマルチテナント環境の境界ではありません。互いに信頼していないユーザーが、ツールを有効にした同じエージェントにメッセージを送れる場合、そのエージェントに委任された権限も共有することになります。信頼境界が異なる場合はゲートウェイを分け、可能ならOSユーザーやホストも分離してください。
認証済みのゲートウェイアクセスは運用者レベルです。sessionKeyはルーティング用のセレクターであり、認可トークンではありません。共有の個人用ゲートウェイに、実際には存在しないユーザー単位のテナント分離があると思い込まないでください。
DMアクセス：pairing、allowlist、open、disabled
DMに対応する各チャネルはDMポリシーをサポートしています。名称はチャネルによって多少異なるため、最新の文書を確認してください。
| ポリシー | 動作 |
|---|---|
pairing | デフォルト。未知の送信者にはペアリングコードが発行され、承認されるまでメッセージは無視される。文書上、コードは1時間で失効する。 |
allowlist | 未知の送信者をブロックし、ペアリングの手続きは行わない。 |
open | 誰でもDMできる。"*"を含む許可リストで明示的にオプトインする必要がある。 |
disabled | 受信DMを無視する。 |
内容を確認してから承認します。
openclaw pairing list <channel>
openclaw pairing approve <channel> <code>
詳細はペアリングを参照してください。
個人利用での実務的な原則： pairingまたは厳格なallowlistを維持します。承認するのは自分のアカウントと、多くても同じ信頼境界を共有するごく少数の共同運用者に限ります。
2層の許可リスト
1. DM許可リスト（allowFrom／チャネル固有の同等設定）
ボットにDMできる送信者を定めます。現在のOpenClawでは、保留中および承認済みの送信者レコードは、チャネルとアカウントをキーとして~/.openclaw/state/openclaw.sqliteに保存されます。以前の認証情報JSONファイルは、現在の認可情報源ではなく、移行時の入力としてのみ使われます（ペアリング状態に関する文書）。このSQLiteファイルは機密性の高い認可状態として扱い、ゲートウェイの状態と一貫した方法でバックアップしてください。
2. グループ許可リスト
ボットが受け付けるグループ／チャネル／ギルドと、グループ内でボットを起動できる人を定めます。対応するチャネルでは、groupPolicy="allowlist"とgroupAllowFromを組み合わせます。
確認の順序も重要です。最初にグループポリシーと許可リストが適用され、その後にメンションや返信による起動条件が確認されます。ボットのメッセージに返信しても、groupAllowFromを回避することはできません。
設定例を示します。安定した送信者IDとエージェント名を、現在のチャネルスキーマに合わせて変更してください。
{
channels: {
whatsapp: {
dmPolicy: 'allowlist',
allowFrom: ['+15555550123'],
groupPolicy: 'allowlist',
groupAllowFrom: ['+15555550123'],
groups: { '<approved-group-id>': { requireMention: true } },
},
},
agents: {
list: [{ id: 'main', groupChat: { mentionPatterns: ['@openclaw'] } }],
},
}
requireMentionが、誰もが誤って入力しそうな汎用文字列ではなく、_自分の_ボット名に一致するようにメンションパターンを調整してください。
グループメンションは安全対策になる
会話量の多いグループでエージェントが常にすべての発言を受け付けると、次の問題が起こります。
- ノイズの処理にトークンを消費する
- 冗談、貼り付けられたログ、リンク先のページに埋め込まれたプロンプトインジェクションに反応する
- 同じチャットルームに参加していても信頼境界を共有していない人の間で、コンテキストが漏れる
メンバーを厳格に管理した専用のエージェントチャネルでない限り、メンションまたは同等の起動操作を必須にしてください。
メンションで起動を制限していても、ボットが取得する信頼できないコンテンツには指示が含まれる可能性があります。Webページ、添付ファイル、メールなどが該当します。システムプロンプトだけではプロンプトインジェクションを解決できません。実効性のある制御は、ツールポリシー、承認、サンドボックス、そして誰がボットと対話できるかというアクセス制御です。
プロンプトインジェクションは、DMを公開していなくても発生します。ボットにメッセージを送れるのが自分だけでも、ボットが公開Webや共有受信箱を読むなら、敵対的なテキストがツールの結果に入り込む可能性があります。
複数人からのDMをセッションで分離する
継続性を保つため、デフォルトではDMがメインセッションへルーティングされることがあります。ボットにDMできる人が複数いる場合は、セッションを分離してください。
{ session: { dmScope: 'per-channel-peer' } }
分離しないと、ある人のコンテキストが別の人との会話に漏れる可能性があります。これはプライバシー上の不具合であり、プロンプトインジェクションの影響を増幅する要因でもあります。
ネットワークへの公開
リモートチャットの利用を始める前に、次を確認します。
- 個人用のインストールでは
gateway.bind: "loopback"を優先する - ループバック以外からアクセスする場合は、ゲートウェイ認証トークンを必須にする
- Tailscale Serve／Funnelとリバースプロキシの利用は公開範囲の変更として扱い、使用する場合は公開時のランブックに従う
- Control UI（
:18789）やモデルのポートを、認証なしで公開インターネットからアクセスできる状態にしない
次のコマンドを実行します。
openclaw security audit
openclaw security audit --deep
openclaw security audit --fix # narrow safe remediations only
文書が示すトリアージの順序は、まずツールを有効にした公開DM／グループを閉じ、次に公開ネットワークへの露出、ブラウザ制御用リモート接続、ファイル権限、プラグインの順に確認するというものです。
堅牢化した基準構成（出発点）
OpenClawは、簡潔な堅牢化の例を公開しています。内容は、ローカルバインド、トークン認証、メッセージング向けのツールプロファイル、automation／runtime／fsグループの拒否リスト、ask: "always"を指定したexecの拒否、昇格ツールの無効化、WhatsApp形式のペアリングとメンション要件です。古い設定例を貼り付けたまま固定するのではなく、公開中のセキュリティページから_意図_を読み取り、自分の設定に反映してから再監査してください。
信頼できる運用者が1人だけの環境では、デフォルト設定によって確認なしのホストexecが許可される場合があります（security="full"、ask="off"）。これは個人アシスタント向けに意図されたUXであり、チャネルの利用者を増やした後も有効のままでよいという根拠ではありません。自分以外から届くメッセージを脅威モデルに含める場合は、制限を強化してください。
四半期ごとのレビュー項目
四半期ごと、またはチャネルの公開範囲を広げた後に、次を確認します。
- 各許可リストに誰が登録されていて、その理由は何か？
- どのグループにまだボットが参加していて、メンションは引き続き必須か？
- 誰かが「一時的に」
openのDM／グループポリシーを有効にしていないか？ - exec／ブラウザツールの権限は、前四半期の脅威モデルより広くなっていないか？
- 最後に設定を変更してから
openclaw security auditを実行したか？
回答は記録してください。誰かの頭の中にしか存在しないセキュリティ体制は、その人が最初に休暇を取った時点で機能しなくなります。
Discord／Slack／Teamsに関する注意（原則は同じ）
チャネルのUIは異なっても、確認すべきセキュリティ上の問いは同じです。
- どのギルド／ワークスペース／チームを許可しているか？
- どのユーザーがDMできるか？
- チャネル内でボットへの@メンションを必須にしているか？
- ボットトークンをゲートウェイのホストだけに保存しているか？
DiscordとSlackについて、OpenClawは操作面ごとの許可リストを文書化しています。対象にはguilds、channels、関連する設定キーなどがあります。現在のスキーマを確認してください。WhatsApp／Telegramの例と同じく、デフォルトでは閉じる方針を適用します。誰でも利用できるSlackワークスペースで、公開設定のエージェントにexecツールを持たせれば、好奇心を持った同僚が試すのを待つだけの状態になります。
職場のチャットには、従業員や顧客の個人データが含まれることがあります。OpenClawをSlack／Teamsへ接続することはデータ処理行為です。適法な根拠、ボットを呼び出せる人、
~/.openclawに保持されるツール出力を把握してください。
具体的な障害例（逸話ではなくパターン）
インシデントは、次のような形で発生します。
公開したDMポリシーを元に戻し忘れる
ボットトークンが公開リポジトリへ漏れるか、友人がボットのハンドルを共有します。見知らぬ人が「~/Documentsを要約して」のようなプロンプトをDMで送ります。ツールが有効なら、モデルは実行を試みる可能性があります。
メンションを必須にしていないグループ
ボットがすべてのスレッドに反応します。誰かが悪意のあるREADMEを貼り付けると、エージェントがそれを取得して指示に従います。
家族で共有するWhatsApp
十代の家族と請負業者が参加するグループで、どちらもボットを@メンションできます。継続中のセッションでコンテキストが混ざり、冗談がシェルコマンドの実行要求になります。
認証のないリモートUI
「スマートフォンからアクセスできるようにする」ため、:18789をLANにバインドします。その結果、ゲストWi-Fiの利用者がコントロールプレーンへアクセスできるようになります。
各例への対策は、ペアリング／許可リスト、メンション規則、セッション分離、バインド／認証です。システムプロンプトを厳しく書くだけでは防げません。
取り消しとオフボーディング
簡潔なランブックを用意します。
allowFromから対象のIDを削除するか、現行のCLIまたはUIを使ってペアリングの承認を取り消します。データベースを直接編集せず、サポートされているツールで正規のSQLite認可レコードが削除されたことを確認します。- 対象者がチャネルのボットトークンを見た可能性がある場合は、そのトークンをローテーションします。
~/.openclawにあるセッションを確認し、機密情報が残っていないか調べます。openclaw security auditを再実行します。- 対象者がノードをペアリングしていた場合は、そのデバイスのペアリングを解除します。
ボットのフォローを解除するような軽い作業ではなく、SSHキーを回収する手続きとして扱ってください。
運用者向けチェックリスト
- DMポリシーが
pairingまたは厳格なallowlistになっている -
allowFromに信頼できるIDだけが登録されている - グループでメンションを必須にし、グループ許可リストを設定している
- DMを送る人が複数いる場合、
dmScopeでセッションを分離している - ゲートウェイがループバックにバインドされている（リモートなら認証済みアクセスだけを許可している）
-
openclaw security auditの結果を確認し、容認できる状態になっている - IDによるアクセス制御が完了するまで、高リスクのツールを無効にしている
- 状態ディレクトリを誰でも読み取れる権限にしていない
- 利用チャネルごとのオフボーディング手順を文書化している
電話番号、Slackユーザー、請負契約が無効になったら、ペアリングと許可リストの登録を取り消してください。忘れられた許可リストの行は、常に有効な招待状です。適法な根拠がなくなったら、他者の個人データを含むセッション履歴をエクスポートまたは削除してください。
許可リストとペアリングは、単なる官僚的な手続きではありません。個人用ゲートウェイと、自分のシェルにつながった未認証のエージェントAPIを分ける境界です。スキル、heartbeat、利便性のための自動化より先に設定してください。次の記事ではスキル、heartbeat、承認を扱います。
