セキュリティ
Shell アクセスを持つ AI Gateway を運用するための脅威モデルと実践的なチェックリスト
クイックチェック：`openclaw security audit`
設定変更、ネットワーク公開、プラグイン追加の後は、まず監査を回すのがおすすめです：
openclaw security audit openclaw security audit --deep openclaw security audit --fix
主に、Gateway の認証/露出、ブラウザ制御の露出、elevated ツールの範囲、ローカル権限/機密ファイル、プラグインなどをチェックします。
関連：''形式化検証（セキュリティモデル）''
基本方針：賢さより先にアクセス制御
多くの失敗は高度な攻撃ではなく、「メッセージできる人がいて、AI が実行してしまう」パターンです。優先順位は：
- 入口（誰が話せるか）：DM の pairing/allowlist、グループの許可リスト、メンション必須など。
- 範囲（どこまでできるか）：ツール許可、サンドボックス、デバイス権限。
- モデル（最後）：モデルは操られる前提で、ハードな制約で被害を限定します。
修正の優先順（監査で警告が出たら）
監査の指摘は次の順で潰すと効果が出やすいです：
1. open + ツール有効：まず DM/グループを閉じ、次にツール/サンドボックスを締める。
2. ネットワーク露出（LAN bind、Funnel、auth 無し）：最優先で修正。
3. リモート操作系（ブラウザ/ノード）：運用者権限として扱い、tailnet-only を基本に。
4. ファイル権限：state/config/credentials が他ユーザーに読めないこと。
5. プラグイン：信頼したものだけを明示的に許可。
プロンプトインジェクション：DM 以外からも来る
あなただけがボットに DM できるとしても、ボットが信頼できないコンテンツ（ウェブページ、添付ファイル、メール、貼り付けられたログ/コード）を読む限り、プロンプトインジェクションは発生する可能性があります。
実務のポイント：
- 不信頼コンテンツは、ツール無し/読み取り専用の "reader agent" で要約してから主 agent に渡す。
- 高リスクツール（''exec''/''browser''/''web_fetch''/''web_search''）は最小限と許可リストで運用。
- サンドボックスを有効化し、機密は到達可能なファイルシステムから遠ざける。
インシデント対応（侵害を疑う場合）
「侵害」とは、bot をトリガーできる部屋に第三者が入った、token が漏れた、プラグイン/ツールが予期せぬ動作をした、などを含みます。
1) 止血：Gateway 停止または elevated ツール無効化、入口を即座に閉じる。
2) ''キー更新''：''gateway.auth'' token/password を更新；hooks token を更新；怪しいノードのペアリングを取り消し；モデルプロバイダーのキーを更新。
3) ''証拠確認''：Gateway ログと最近のセッション/記録を確認；''extensions/'' を確認・整理。
4) ''再監査''：''openclaw security audit --deep'' を再実行。