OpenClawセキュリティ設定ガイド｜用途別の推奨設定と監査手順を解説

OpenClawのセキュリティ設定は、~/.openclaw/openclaw.json で「Gatewayをローカル限定＋トークン認証」「ツールを用途に合わせて絞る」「シェル実行は拒否か毎回承認」の3つを先に固め、最後に openclaw security audit で確認するのが基本です。2026年8月末のOpenClaw 2.0（v2026.8.1）からは、ブラウザ操作やMacのデスクトップ操作も新しい入口になっているため、2026年4月ごろの設定のままでは足りません。

この記事でわかること

• インストール直後の既定値と、最初に変えるべき項目
• Gateway・チャネル・ツール・サンドボックス・秘密情報の設定項目（2026年10月時点の公式キー名）
• 2.0で増えたブラウザ・デスクトップ操作・自動学習スキルの推奨設定
• メッセージング用・開発用・企業評価用・読み取り専用の設定例と比較
• openclaw security audit の使い方、--fix で直る範囲と直らない範囲
• インシデントが起きたときの公式の対応手順

こんな方に向けた記事です

• OpenClawを導入済みで、2.0以降の変更に合わせて設定を見直したい方
• これから導入する予定で、安全な初期設定を知りたい方
• 企業でOpenClawを評価していて、セキュリティ要件を確認したい方

設定値は、2026年10月時点の公式ドキュメント（docs.openclaw.ai）と安定版 v2026.10.3 に合わせています。OpenClawそのものの特徴は「OpenClawとは？できること・料金・安全性を公式情報で整理」、リスクの全体像は「OpenClawの危険性とは？主要リスクと安全な運用方法」で扱っています。

OpenClawのセキュリティ設定が重要な理由

OpenClawは自分のマシンやVPSで常駐し、チャット経由の指示でシェル実行・ファイル操作・ブラウザ操作・デスクトップ操作まで行うエージェント基盤です。公式のSECURITY.mdは「エージェントを操作できる人は、そのエージェントにできることを何でもさせられる」と書いており、守りの中心は利用者自身の設定になります。

公式が示している前提のうち、設定の方針に直結するものを挙げます。

• Gateway 1つにつき信頼境界は1つ: 信頼度の違う人が使うなら、Gateway・認証情報、できればOSユーザーやホストまで分けるよう公式は求めています。1つのGatewayを複数人で共有して分離を期待する使い方は、設計の対象外です
• プロンプトインジェクションだけの攻撃は脆弱性報告の対象外: ポリシー・認証・承認・サンドボックスの迂回を伴わないものは「仕様の範囲」とされます。完全には防げない前提で、権限を絞って被害の範囲を小さくするしかありません
• ドキュメントが勧めない公開や設定ミスによる被害も対象外: 認証なしのインターネット公開などは自己責任です

さらに、GitHub Security Advisoriesで公開されているOpenClawのアドバイザリは、2026年10月14日時点で722件（critical 14件・high 249件）にのぼり、その大半が2026年2月以降に出ています。直近では2026年9月11日に75件がまとめて公開され、修正は主にv2026.8.1とv2026.7.1に入っています。設定を固めることと、修正版に更新し続けることの両方が必要です。

インストール直後の既定値と最初に変える項目

出典: OpenClaw 公式ドキュメント（Configuration）

ローカルのオンボーディングを終えた直後のOpenClawは「ほぼ全ツールが使え、シェルは確認なしで動く」状態です。Gatewayのバインドと未知のDMの扱いは控えめな既定値ですが、ツール側は自分で絞る必要があります。

公式はシェル実行の security=full＋ask=off の組み合わせを「YOLOモード」と呼んでいます。何も設定しなければ、この状態に近いまま動きます。

なお、コンテナイメージは外部に開いたバインドが既定です。Dockerで動かす場合は、認証を必ず組み合わせてください。

最初の作業はこの順番で進めると迷いません。

1. 設定ファイルと状態ディレクトリのバックアップを取り、最新の安定版に更新する
2. openclaw security audit で現状を確認する
3. gateway.bind と gateway.auth を固める
4. tools.profile とシェル実行の方針を決める
5. DMの受け付け方と session.dmScope を決める
6. 開発用途ならサンドボックスを有効にする
7. ブラウザ操作・デスクトップ操作・自動学習スキルの設定を見直す
8. openclaw security audit --deep で再確認する

インストールそのものの手順は「OpenClaw 使い方・インストール完全ガイド」にまとめています。

セキュリティ設定項目の全体像

出典: OpenClaw 公式ドキュメント（Security）

OpenClawのセキュリティ設定は、Gateway・チャネル・ツール・サンドボックス・セッション・秘密情報とファイル権限の6つに分けると整理しやすくなります。設定ファイルは ~/.openclaw/openclaw.json（JSON5形式）で、状態ディレクトリは ~/.openclaw/ です。

公式ドキュメントは2026年夏に構成が変わり、キー名も旧と新が並んでいる箇所があります。手元のバージョンでキー名が合わない場合は、openclaw security audit と openclaw doctor の指摘を優先してください。

Gateway認証・ネットワーク設定

Gatewayは外からの接続を受ける入口で、ここを開けたままにすると他の設定が意味をなさなくなります。公式は「認証なしで 0.0.0.0 に出さない」と明記しています。

パスワード認証を使う場合は24文字以上にしてください（未満だと監査で警告）。以前は「必ずfalseにする」と紹介されることが多かった gateway.controlUi.dangerouslyDisableDeviceAuth は、現在は廃止済みで何も効きません。

外から使いたい場合、公式はLANバインドよりTailscale Serveを勧めています。インターネットに公開するTailscale Funnelは、監査で critical として扱われます。Dockerで公開したポートはホストのINPUTチェーンではなく DOCKER-USER チェーンを通るため、UFWの設定だけでは塞げない点にも注意が必要です。

チャネルアクセス制御（DM・グループ）

誰がエージェントに話しかけられるかを決める設定です。WhatsApp・Telegram・Slack・Discordなど、チャネルごとに書きます。

dmPolicy の選択肢

• pairing（既定・推奨）: 未知の送信者にペアリングコードを返し、承認するまで無視します。コードは1時間で失効し、保留はチャネルあたり3件までです。承認は openclaw pairing list <channel> と openclaw pairing approve <channel> <code> で行います
• allowlist: 許可リストにない送信者は、ペアリングなしで遮断します
• open: 誰でも話しかけられます。監査で critical になるため使わないでください
• disabled: DMを受け付けません

channels.<チャネル>.groups を書くと、それ自体がグループの許可リストになります（"*" は全グループ許可）。ボットへの返信であっても groupAllowFrom を迂回できない仕様です。

もう1つ見落としやすいのが送信側です。messageツールを持つエージェントは、既定で別の会話や別のチャネルにも送信できます。tools.message.crossContext.allowAcrossProviders と allowWithinProvider を false にすると、今の会話の中だけに閉じられます。

ツールポリシー・プロファイル

OpenClawが何をできるかを決める、設定の中心部分です。公式の優先順位は「プロファイル → プロバイダー別の設定 → allow / deny」で、deny が常に優先されます。

シェル実行の設定は、旧来の security＋ask の組み合わせと、新しい tools.exec.mode の両方が公式ドキュメントに載っています。公式の堅牢化ベースラインは旧来のキーで書かれているため、本記事の設定例もそちらに合わせています。

ツールプロファイルの中身（公式）

設定では、次のような見落としやすい点に注意してください。

• write を拒否しても apply_patch は別のツールIDです。書き込みを止めたいなら両方を deny に入れます
• 信頼できない内容（Webページや他人の発言）を扱うエージェントでは、公式は gateway・cron・sessions_spawn・sessions_send の拒否を勧めています
• tools.toolsBySender など送信者ごとの制御は「今のターンの依頼者」にしか効きません。引用文や取得したWebページの中身は消毒されないため、ツール自体を絞るほうが確実です

サンドボックス・Docker設定

サンドボックスはツールの実行を隔離環境に閉じ込める設定で、既定ではオフです。2026年10月時点の設定場所は agents.defaults.sandbox（エージェントごとなら agents.entries.*.sandbox）で、トップレベルの sandbox キーではありません。

docker は mode の値ではなくバックエンドの名前です。バックエンドはDocker（ローカルの既定）のほか、Podman・SSH・OpenShell・Crabbox、2.0からはクラウドのDaytonaも選べます。

公式が明記している制約もあります。

• Gateway本体は常にホストで動きます。サンドボックスに入るのはツールの実行だけです
• ツールの allow / deny はサンドボックスより先に効きます。拒否したツールはサンドボックス内でも戻りません
• tools.elevated を有効にすると、サンドボックスを迂回できてしまいます
• 子セッションを起動する sessions_spawn で sandbox: "require" を指定すると、隔離なしの子セッションを拒否できます

ホストごと隔離したい場合は、OpenShellを中核にしたNVIDIAのセキュリティスタックも選択肢です。詳しくは「NemoClawとは？NVIDIAのOpenClawセキュリティ基盤」で解説しています。

セッション分離

session.dmScope は、DMの会話をどの単位で分けるかの設定です。

既定の main では全DMが1つのセッションを共有するため、Aさんとの会話内容がBさんとの会話に混ざるおそれがあります。自分しか話しかけない構成なら main でも困りませんが、家族やチームなど複数人が話しかけるなら per-channel-peer に変えてください。監査も複数人のDMを検知すると分離を勧めます。

秘密情報とファイルパーミッション

公式は「~/.openclaw/ 配下はすべて秘密情報か私的データを含みうる」と考えるよう求めています。中にあるのは次のようなファイルです。

chmod 700 ~/.openclaw/
chmod 600 ~/.openclaw/openclaw.json
chmod 700 ~/.openclaw/credentials/

あわせて次の点も確認してください。

• 同期フォルダに置かない: iCloud・Dropbox・Google Driveの同期フォルダに設定や状態があると監査で警告されます
• ログは生のまま残る: ファイルログ・会話記録・ツールの引数と結果には、認証情報がそのまま含まれることがあります。独自の伏せ字パターンは logging.redactPatterns で追加できます。人に見せるときは秘密を伏せた openclaw status --all の出力を使います
• APIキーの置き場所: ワークスペースの .env からは *_API_KEY や OPENCLAW_* を読み込まない仕様です。プロバイダーの認証はGatewayの環境変数か ~/.openclaw/.env に置きます
• ディスク暗号化: Gatewayを動かすマシンはフルディスク暗号化し、共有マシンなら専用のOSユーザーを作ります

2.0では任意の1Passwordブローカー（シークレットごとの承認と、値を含まない監査記録）も追加されました。ただし、エージェントのツールで読み取った値は、その実行の間モデルから見える点は変わりません。

OpenClaw 2.0以降のブラウザ・デスクトップ操作の設定

2026年8月31日公開のv2026.8.1（OpenClaw 2.0）で、ペアリングしたMac・Windowsのデスクトップ操作や、普段使いのChromeとのつながりが強化されました。便利になった分、攻撃の入口も増えています。2.0の新機能全体は「OpenClaw 2.0（v2026.8.1）新機能まとめ」を参照してください。

デスクトップ操作（Computer Use）

macOSではAllow Computer Controlが既定でオンです（アクセシビリティと画面収録の許可がそろった場合）。公式は「操作ごとの確認はない」と明記しており、許可がそろえばペアリング済みのGatewayはマウスとキーボードを操作できます。

{
  gateway: {
    nodes: {
      commands: { deny: ["computer.act"] },
    },
  },
}

coding プロファイルには computer が含まれないため、デスクトップ操作を使いたい場合だけ tools.alsoAllow に "computer" を追加する形になります。逆に言えば、オンボーディングで入った full のままだと、知らないうちにデスクトップ操作まで許していることになります。

画面に表示された文字を経由したプロンプトインジェクションにも注意してください。公式は、Webページやメールに書かれた指示をモデルが読み取って従うおそれがあると明記しています。macOSのCUAデーモンは承認を通らずに動き、同じユーザーの他プロセスからは守れない点も公式に書かれています。

Windows / Linuxで有効化する前には、次のコマンドで配布物の確認ができます。

openclaw doctor --lint --only cua-computer/driver-artifacts

ブラウザ操作（Chrome拡張のペアリング）

ブラウザ操作で一番大事なのは、普段使いのChromeプロファイルではなく、エージェント専用のプロファイル（既定の openclaw プロファイル）を使うことです。ログイン済みのセッションは、それ自体が鍵と同じ価値を持ちます。

• 専用プロファイルではブラウザの同期とパスワードマネージャーを切り、ダウンロード先は隔離したフォルダにする
• Chrome拡張のペアリングには「すべてのタブ」と「選択したタブ」（OpenClawのタブグループだけ）があります。公式は新規の個人ブラウザでは「すべてのタブ」を推奨していますが、業務のログインが多いプロファイルにつなぐなら「選択したタブ」に絞るほうが無難です。シークレットウィンドウとChromeの内部ページは、どちらのモードでも対象外です
• 2.0で追加された「macOSの既存のブラウザログインを管理プロファイルへ取り込む」機能は、取り込む範囲をよく確認してから使う
• ブラウザのプロキシ経由の操作が不要なら gateway.nodes.browser.mode: "off"
• 拡張機能のクライアントを更新したら、移行期間のために既定で true になっている browser.extensionRelay.allowLegacyAuth を false に

公式は「Chrome MCPの既存セッションモードは安全なモードではない」とも書いています。そのプロファイルでログインしているサービスには、すべて手が届くからです。リモートのGatewayからブラウザを操作させるのは、そのプロファイルで届く範囲すべての操作権を渡すのと同じだと考えてください。

社内サイトへのアクセス（SSRF）対策

{
  browser: {
    ssrfPolicy: {
      // dangerouslyAllowPrivateNetwork は書かない（社内・プライベート宛ては既定でブロック）
      blockedHostnames: ["intranet.example.com", "*.intranet.example.com"],
    },
  },
}

*.example.com の書き方は example.com 自体を含まないため、両方を書きます。公式はこの制御を「ファイアウォールではない」としており、リダイレクトやService Workerなどですり抜ける経路があります。確実に止めたい場合は、外向き通信をネットワーク側で分けるかプロキシを通します。

自動学習スキルと更新時の安全装置

2.0で見落とされやすい既定値が自動学習です。スキャナーが承認した新規スキルと、Skill Workshopが持つスキルは既定で自動適用され、Skill Workshopの適用・却下・隔離も追加の承認なしで進みます。

{
  skills: {
    workshop: { approvalPolicy: "pending" },
  },
}

pending にすると、適用の前に人の承認が入ります。あわせて security.installPolicy でスキル・プラグインのインストールを allow / warn / block から選べます。

更新まわりでは、2.0で次のような安全装置が入りました（公式リリースノートより）。

• プラグインのインストール・有効化の前に、能力・出所・バージョンを確認できる。更新を拒否すれば前のバージョンを使い続けられる
• 任意の実行可能ソースからのインストールには --force が必要
• ロールバック時に予期しない差分があれば、Gatewayを止めたままにする
• 再起動後のビルド確認で、検証できないビルドを拒否する
• 定期処理は操作単位で一度だけ許可し、内容が変わったら再承認を求める
• 設定変更の履歴（書き手のラベル、秘密値の伏せ字、手で編集した箇所の検出）が残る

リリースノートの冒頭には「更新前に設定と状態をバックアップする」とあります。更新の前に ~/.openclaw/ を丸ごと退避しておくと、問題が出たときに戻せます。

用途別の推奨設定テンプレート

利用シーンごとの設定例を4パターン紹介します。どれも2026年10月時点の公式スキーマに合わせたもので、トークンは必ず自分で生成した長いランダム値に置き換えてください。

パターン1: メッセージング専用（初心者向け）

チャットでのやり取りが中心で、ファイル操作やコマンド実行が不要な場合の設定です。公式の堅牢化ベースラインをそのまま使っています。

{
  gateway: {
    mode: "local",
    bind: "loopback",
    auth: { mode: "token", token: "replace-with-long-random-token" },
  },
  session: {
    dmScope: "per-channel-peer",
  },
  tools: {
    profile: "messaging",
    deny: ["group:automation", "group:runtime", "group:fs", "sessions_spawn", "sessions_send"],
    fs: { workspaceOnly: true },
    exec: { security: "deny", ask: "always" },
    elevated: { enabled: false },
    sessions: { visibility: "agent" },
    agentToAgent: { enabled: false },
  },
  channels: {
    whatsapp: { dmPolicy: "pairing", groups: { "*": { requireMention: true } } },
  },
}

Gatewayをローカルに限定し、DMを相手ごとに分け、制御系（group:automation）・実行系（group:runtime）・ファイル系（group:fs）のツールを切っています。必要なツールは、信頼できるエージェントにだけ個別に戻す考え方です。トークンを例の文字列のままにすると、監査で critical になります。

パターン2: 開発者向け（サンドボックス付き）

コーディング支援に使う場合の設定です。シェル実行は許可リストと毎回の承認で絞り、実行はサンドボックスに閉じ込めます。

{
  gateway: {
    mode: "local",
    bind: "loopback",
    auth: { mode: "token", token: "replace-with-long-random-token" },
  },
  session: { dmScope: "per-channel-peer" },
  tools: {
    profile: "coding",
    deny: ["gateway", "cron", "sessions_spawn", "sessions_send"],
    fs: { workspaceOnly: true },
    exec: { security: "allowlist", ask: "always", strictInlineEval: true },
    elevated: { enabled: false },
    sessions: { visibility: "agent" },
  },
  agents: {
    defaults: {
      sandbox: {
        mode: "all",
        scope: "session",
        workspaceAccess: "rw",
        docker: { network: "none" },
      },
    },
  },
  skills: {
    workshop: { approvalPolicy: "pending" },
  },
}

ask: "always" で毎回の承認を求め、strictInlineEval で python -c のような埋め込みコードも承認の対象にしています。パッケージの取得などで外部通信が必要なら、network は必要な範囲で見直してください。誤って危険なコマンドを承認しても、サンドボックス内で止まりやすくなります。

AIコーディング全般のリスクは「AIコーディングのセキュリティリスク」でも整理しています。

パターン3: 企業セキュリティ評価向け（最小権限）

企業で導入を検討する際、評価目的で最小限の権限で試す設定です。

{
  gateway: {
    mode: "local",
    bind: "loopback",
    auth: { mode: "token", token: "replace-with-long-random-token" },
    nodes: {
      browser: { mode: "off" },
      commands: { deny: ["computer.act"] },
    },
  },
  session: { dmScope: "per-channel-peer" },
  tools: {
    profile: "minimal",
    exec: { security: "deny", ask: "always" },
    elevated: { enabled: false },
    sessions: { visibility: "self" },
    agentToAgent: { enabled: false },
  },
  agents: {
    defaults: {
      sandbox: { mode: "all", scope: "session", workspaceAccess: "none" },
    },
  },
  discovery: { mdns: { mode: "off" } },
  skills: {
    workshop: { approvalPolicy: "pending" },
  },
}

minimal プロファイル、全セッションのサンドボックス化、ワークスペースへのアクセスなし、ブラウザとデスクトップ操作の停止を組み合わせた構成です。評価は専用のVMで行い、機密データのないアカウントだけをつないでください。

会社で使う段階に進むなら、OpenClawの設定だけでなく、データの置き場所・ログの保管・権限の分け方をどの構成で満たすかを先に決めておく必要があります。構成の選び方は「生成AIのセキュリティ要件と社内導入の構成」で解説しています。

パターン4: リードオンリーモード（情報閲覧専用）

ファイルの読み取りだけを許可し、書き込み・編集・コマンド実行を禁止する設定です。

{
  tools: {
    allow: ["read"],
    deny: ["write", "edit", "apply_patch", "exec", "process"],
    fs: { workspaceOnly: true },
    elevated: { enabled: false },
  },
  agents: {
    defaults: {
      sandbox: { mode: "all", workspaceAccess: "ro" },
    },
  },
}

write と apply_patch は別のツールIDなので、両方を拒否しています。サンドボックスの ro は、ワークスペースを読み取り専用でマウントし、書き込み系ツールを無効にします。ログ分析やドキュメント要約など、読むだけで終わる用途に向いています。

用途別の設定比較

迷ったらメッセージング専用の設定から始め、必要なツールを1つずつ戻していくのが安全です。最初から coding や full にして後から絞るより、思わぬトラブルが起きにくくなります。

openclaw security auditによるセキュリティ監査

openclaw security audit は、設定と状態を検査して問題点を深刻度つきで表示する公式コマンドです。公式は「設定を変えたあとと、ネットワークに公開する前に毎回実行する」よう勧めています。

監査コマンドの種類

# 基本の監査
openclaw security audit

# 動いているGatewayへの確認と、プラグイン・スキルのコード検査を追加
openclaw security audit --deep

# 権限とオープンなグループ設定だけを自動修正
openclaw security audit --fix

# JSON形式で出力
openclaw security audit --json

--deep は、実際に動いているGatewayに接続して状態を確かめるほか、インストール済みのプラグインとスキルのコードも検査します。ClawHubなどからスキルを入れている場合は、--deep まで実行してください。

--fix で直るもの・直らないもの

--fix は公式が「意図的に範囲を狭くしている」と説明しているオプションです。自動で直るのはファイル権限とグループの受け付け方だけで、それ以外は設定ファイルを自分で直します。

「--fix を実行したから安全」とはならない点に注意してください。

主要な監査チェック項目と深刻度

監査結果には checkId と深刻度が表示されます。公式の一覧は約150項目あり、ここでは特に見かけることが多いものを抜粋しました。<provider> の部分は実際には telegram などに置き換わります。

critical が1つでも出たら、その項目を直すまでGatewayを外部に開いたり、新しいチャネルをつないだりしないでください。意図して受け入れる項目は security.audit.suppressions で抑制できますが、抑制した項目も info として表示され続けます。

監査→修正→再監査のフロー

1. openclaw security audit を実行し、critical と warn を確認する
2. --fix で権限とグループ設定を直す
3. 残った項目を critical から順に、設定ファイルを編集して直す
4. Gatewayを再起動して設定を反映する（Macアプリで管理している場合はアプリを再起動）
5. openclaw security audit --deep で再確認し、critical がなくなるまで繰り返す

既知の脆弱性と必要な対策

OpenClawは脆弱性の公開件数が多く、修正版への更新が設定と同じくらい重要です。GitHub Security Advisoriesでは、2026年10月14日時点で722件が公開されています（critical 14件・high 249件・medium 390件・low 69件、CVE番号つきは39件）。

2026年10月14日時点の最新の安定版はv2026.10.3（10月13日公開）です。直前のv2026.10.2では、長いツール出力で認証情報の伏せ字が漏れる不具合が修正されています。2026年初めには、認証なしで公開されたOpenClawのインスタンスが数万〜十数万台規模で見つかったとセキュリティ各社が報告しており、古いバージョンを公開状態で動かすのは特に危険です。

脆弱性の報告方法はGitHubのSECURITY.mdに書かれています。以前の告知先だったtrust.openclaw.aiは、現在 openclaw.ai のブログ（セキュリティ欄）へ転送されています。

スキル導入時のセキュリティチェックポイント

スキルやプラグインはエージェントと同じ権限で動くため、入れる前に中身を確認します。2.0からはインストール・有効化の前に能力と出所を確認でき、ClawHubもインストール前にセキュリティ監査の情報を表示します。それでも、次のような特徴があれば入れないでください。

• curl | bash や wget | sh のようなパイプ実行
• base64などで中身を隠したコード
• 用途に関係のない外部サーバーへの通信
• tools.elevated の有効化や full プロファイルを求める
• 作者の実績がなく、公開されたばかりで利用者が極端に少ない

公式のSECURITY.mdは、運用者が自分で入れた悪意あるプラグインによる被害を脆弱性の対象外としています。入れるかどうかの判断は利用者の責任です。

プロンプトインジェクション対策

出典: OpenClaw 公式ドキュメント（Prompt injection）

プロンプトインジェクションは設定で完全には防げないため、「乗っ取られても被害が小さい構成」にしておくのが現実的な対策です。公式SECURITY.mdも、迂回を伴わないプロンプトインジェクションは報告の対象外としています。

設定でできる対策

• 入口を絞る: dmPolicy を pairing か allowlist にし、グループは許可リストとメンション必須にする
• 共有ルームの他人の発言を混ぜない: contextVisibility を allowlist にする
• 実行できることを絞る: シェル実行は deny か承認制、信頼できない内容を読むエージェントからは gateway・cron・sessions_spawn・sessions_send を外す
• 送信先を絞る: tools.message.crossContext を false にして、乗っ取られても他の会話へ送れないようにする
• 性能の高いモデルを使う: 小さいモデルに強いツールを持たせると、監査で models.small_params として指摘されます
• ブラウザと画面を入口にしない: ブラウザは専用プロファイル、デスクトップ操作は使うときだけ有効にする

エージェントが指示の目的を想定外の手段で果たしてしまう例として、2026年8月に予約システムの認可不備を突いて他人の予約を取り消した事例があります（「AIエージェントがジムの予約システムを不正操作」）。悪意がなくても起こりうるため、外部サービスに書き込む操作は承認制にしておくと安心です。

インシデント発生時の対応フロー

公式の対応手順は「封じ込め → 鍵の交換 → 調査 → 記録」の4段階です。

ステップ1: 封じ込め

• Gatewayを止める（Macアプリで管理している場合はアプリを終了）
• gateway.bind を loopback に戻し、Tailscale Funnel / Serve を切る
• DMとグループを disabled かメンション必須にし、許可リストの "*" を外す

ステップ2: 資格情報の交換

漏れた可能性があるなら、侵害されたものとして扱います。

1. gateway.auth.token / password を新しくする
2. Gatewayを呼び出す全マシンの gateway.remote.token / password を更新する
3. WhatsAppの認証、Slack・Discordのトークン、モデルのAPIキーを交換する
4. 認証方式を変えた場合はGatewayを再起動する

ステップ3: 調査

# ログ（既定の保存先）
ls /tmp/openclaw/

# 会話記録
ls ~/.openclaw/agents/*/sessions/*.jsonl

# critical が消えたかの確認
openclaw security audit --deep

見るべきなのは、gateway.bind・gateway.auth・DMとグループの方針・tools.elevated・プラグインの最近の変更です。2.0以降は設定変更の履歴が残るため、誰がいつ設定を変えたかも追えます。

ステップ4: 記録

時刻、ホストのOS、OpenClawのバージョン、会話記録とログの末尾（秘密は伏せる）、攻撃者が送った内容とエージェントの動き、ループバックの外から届いたかどうかを残します。

設定変更の手順（ステップバイステップ）

設定ファイルを書き換えるときは、次の流れで進めます。

1. 設定ファイルの場所を確認

ls -la ~/.openclaw/openclaw.json

状態ディレクトリを OPENCLAW_STATE_DIR で変えている場合は、そちらを確認します。

2. バックアップを取得

cp -a ~/.openclaw ~/openclaw-backup-$(date +%Y%m%d)

バックアップにも秘密情報が入るため、作成後は権限を絞り、同期フォルダには置かないでください。

3. 設定ファイルを編集

テキストエディタで ~/.openclaw/openclaw.json を開き、メッセージング用・開発用など自分の用途に合わせた値に書き換えます。古い版から更新した場合は、openclaw doctor --fix で旧形式の設定（シェル実行の承認ファイルなど）を取り込めます。

4. ファイルパーミッションを設定

openclaw security audit --fix

--fix を使わない場合は chmod 700 ~/.openclaw/ と chmod 600 ~/.openclaw/openclaw.json を手で実行します。

5. Gatewayを再起動

設定を反映するため、Gatewayを再起動します。Macアプリで管理している場合はアプリを再起動してください。

6. 監査を実行して確認

openclaw security audit --deep

critical がなくなり、残った warn が意図したものだけになれば完了です。

mDNSの無効化（ネットワーク検出の抑制）

mDNS（Bonjour）を使うと、同じネットワーク上の機器からOpenClawの存在が見えます。公式の既定は情報を絞った minimal ですが、使わないなら切るほうが安全です。

{
  discovery: { mdns: { mode: "off" } },
}

環境変数で切る場合は次のとおりです。

export OPENCLAW_DISABLE_BONJOUR=1

full にすると監査で warn〜critical になります。

こんな方にはOpenClawの利用をおすすめしません

• セキュリティ設定に時間をかけられない方: 初期状態はツールがほぼ全開で、設定変更が前提です
• 1つのGatewayを社内の複数人で共有したい方: 公式は利用者同士の分離を保証していません。2.0のチーム向けの運用者ロールも「敵対的な利用者の分離ではない」と明記されています
• 機密データのある普段使いのMacで、既定のまま使いたい方: デスクトップ操作が既定でオンのため、画面に映るものすべてが対象になりえます
• JSON設定ファイルやCLIの操作に慣れていない方: 設定の多くはファイル編集とコマンドで行います

このような場合は、隔離の仕組みが用意された別の選択肢も検討してください。開発用途なら「OpenClaw vs Claude Code 徹底比較」、組織での管理を重視するなら「NemoClawとは？NVIDIAのOpenClawセキュリティ基盤」が参考になります。

こんな方におすすめ

• 自分専用のエージェントを、自分のマシンやVPSで常駐させたい方
• 開発用途で、サンドボックスとシェル実行の承認を設定して運用できるエンジニア
• openclaw security audit の結果を読んで、更新のたびに設定を見直せる方
• 評価用のVMや専用アカウントを用意して、機密データから切り離して試せる方

AIエージェント全般のセキュリティの考え方は「AIエージェントのセキュリティ対策」にまとめています。

よくある質問（FAQ）

Q1. 古い記事の設定例をそのまま使っても大丈夫ですか？

キー名が古い可能性があります。たとえばトップレベルの sandbox は現在 agents.defaults.sandbox に移っており、dangerouslyDisableDeviceAuth は廃止済みです。認識されないキーは効かないため、書き換えたあとは openclaw security audit と openclaw doctor で、設定が意図どおり読まれているか確認してください。

Q2. OpenClaw 2.0に更新したら、追加で見直すべき設定はありますか？

3つあります。macOSのAllow Computer Control（既定でオン）、Chrome拡張のペアリングの範囲、自動学習スキルの適用方法（既定で自動適用）です。どれも2.0より前には無かった既定値なので、以前の設定を引き継いだだけでは対処されていません。

Q3. Dockerサンドボックスは必須ですか？

シェル実行とファイル系のツールを切ったメッセージング用途なら、必須ではありません。coding プロファイルでシェル実行を許可する場合は、有効にしておくのが無難です。サンドボックスに入るのはツールの実行だけで、Gateway本体はホストで動く点も理解しておいてください。

Q4. openclaw security audit はどのくらいの頻度で実行すべきですか？

公式は、設定を変えたあとと、ネットワークに公開する前に毎回実行するよう勧めています。加えて、バージョンを更新したあと、スキルやチャネルを追加したあとにも --deep で実行すると、新しい既定値やスキルの問題に気づけます。

Q5. 設定を正しくすれば、プロンプトインジェクションは防げますか？

完全には防げません。公式もプロンプトインジェクションだけの攻撃は脆弱性の対象外としています。設定でできるのは、乗っ取られたときにできることを減らすことです。入口（DM・グループ・ブラウザ・画面）と出口（シェル実行・送信先・ファイル書き込み）の両方を絞ってください。

Q6. 企業でOpenClawを導入する場合、追加で検討すべき点はありますか？

利用者ごと、または信頼レベルごとにGatewayとOSユーザーを分けることが出発点です。そのうえで、評価用VMでの検証、ブラウザ・デスクトップ操作の停止、設定変更の履歴の保管、更新手順の決め方を整えます。OpenShellで外側から制御するNemoClawのような仕組みを組み合わせる方法もあります。

まとめ

OpenClawのセキュリティ設定は、Gateway・チャネル・ツール・サンドボックス・セッション・秘密情報の6分野を、用途に合わせて絞り込む作業です。2.0以降は、これにブラウザ操作・デスクトップ操作・自動学習スキルの見直しが加わりました。

最低限、次の6つはやっておきましょう。

1. 最新の安定版に更新し、~/.openclaw/ をバックアップする
2. gateway.bind: "loopback" と gateway.auth.mode: "token"（長いランダム値）でGatewayを守る
3. tools.profile を用途に合わせて選び、オンボーディングの full のままにしない
4. シェル実行を deny、または許可リストと毎回の承認にする
5. 使わないなら、macOSのAllow Computer Controlをオフにし、自動学習スキルを承認制にする
6. openclaw security audit --fix で権限を直し、--deep で critical がなくなるまで確認する

インストール手順は「OpenClaw 使い方・インストール完全ガイド」、リスクの全体像は「OpenClawの危険性とは？主要リスクと安全な運用方法」、AIエージェントの基本は「AIエージェントとは？仕組み・種類・活用事例をわかりやすく解説」をあわせてご覧ください。