---
read_when:
- アクセスや自動化の範囲を広げる機能の追加
summary: シェルアクセスを持つ AI Gateway を実行するためのセキュリティ上の考慮事項と脅威モデル
title: セキュリティ
x-i18n:
generated_at: "2026-05-10T19:37:03Z"
model: gpt-5.5
provider: openai
source_hash: dc25981e46229a6fabe72d70222953e84fcb6a0b19792e9849c4e05de7c266bb
source_path: gateway/security/index.md
workflow: 16
---
**パーソナルアシスタントの信頼モデル。** このガイダンスは、gateway ごとに 1 つの信頼済み
オペレーター境界があることを前提としています（単一ユーザーのパーソナルアシスタントモデル）。
OpenClaw は、1 つのエージェントまたは gateway を共有する複数の
敵対的ユーザー向けの敵対的マルチテナントセキュリティ境界では**ありません**。混在した信頼境界や
敵対的ユーザーの運用が必要な場合は、信頼境界を分割してください（別個の gateway +
認証情報、理想的には別個の OS ユーザーまたはホスト）。
## まずスコープ: パーソナルアシスタントのセキュリティモデル
OpenClaw のセキュリティガイダンスは、**パーソナルアシスタント**のデプロイを前提としています。1 つの信頼済みオペレーター境界に、多数のエージェントが存在し得るモデルです。
- サポートされるセキュリティ態勢: gateway ごとに 1 人のユーザー/信頼境界（境界ごとに 1 つの OS ユーザー/ホスト/VPS を推奨）。
- サポートされないセキュリティ境界: 相互に信頼されていないユーザーや敵対的ユーザーが使用する 1 つの共有 gateway/エージェント。
- 敵対的ユーザーの隔離が必要な場合は、信頼境界ごとに分割してください（別個の gateway + 認証情報、理想的には別個の OS ユーザー/ホスト）。
- 複数の信頼されていないユーザーが 1 つのツール有効エージェントにメッセージを送れる場合、それらのユーザーはそのエージェントに委任された同じツール権限を共有しているものとして扱ってください。
このページでは、**そのモデル内での**強化について説明します。1 つの共有 gateway 上で敵対的マルチテナント隔離を提供すると主張するものではありません。
## クイックチェック: `openclaw security audit`
関連項目: [形式検証（セキュリティモデル）](/ja-JP/security/formal-verification)
定期的に実行してください（特に config の変更後やネットワーク面を公開した後）。
```bash
openclaw security audit
openclaw security audit --deep
openclaw security audit --fix
openclaw security audit --json
```
`security audit --fix` は意図的に範囲を狭く保っています。一般的なオープングループ
ポリシーを allowlist に切り替え、`logging.redactSensitive: "tools"` を復元し、
state/config/include-file の権限を厳格化し、Windows 上で実行している場合は
POSIX `chmod` ではなく Windows ACL リセットを使用します。
一般的な落とし穴（Gateway 認証の公開、ブラウザー制御の公開、昇格 allowlist、ファイルシステム権限、寛容な exec 承認、オープンチャンネルのツール公開）をフラグします。
OpenClaw はプロダクトであると同時に実験でもあります。フロンティアモデルの挙動を、実際のメッセージング面と実際のツールに接続することになります。**「完全に安全」なセットアップは存在しません。** 目標は、次の点を慎重に決めることです。
- 誰が bot と会話できるか
- bot がどこで動作を許可されるか
- bot が何に触れられるか
まずは動作する最小限のアクセスから始め、確信が持てるにつれて広げてください。
### デプロイとホストの信頼
OpenClaw はホストと config 境界が信頼されていることを前提としています。
- 誰かが Gateway ホストの state/config（`openclaw.json` を含む `~/.openclaw`）を変更できる場合、その人は信頼済みオペレーターとして扱ってください。
- 相互に信頼されていない/敵対的な複数のオペレーターのために 1 つの Gateway を実行することは、**推奨されるセットアップではありません**。
- 信頼が混在するチームでは、別々の gateway（または少なくとも別々の OS ユーザー/ホスト）で信頼境界を分割してください。
- 推奨されるデフォルト: マシン/ホスト（または VPS）ごとに 1 人のユーザー、そのユーザー用に 1 つの gateway、その gateway 内に 1 つ以上のエージェント。
- 1 つの Gateway インスタンス内では、認証済みのオペレーターアクセスは信頼済みのコントロールプレーンロールであり、ユーザーごとのテナントロールではありません。
- セッション識別子（`sessionKey`、セッション ID、ラベル）はルーティングセレクターであり、認可トークンではありません。
- 複数の人が 1 つのツール有効エージェントにメッセージを送れる場合、その全員が同じ権限セットを誘導できます。ユーザーごとのセッション/メモリ隔離はプライバシーに役立ちますが、共有エージェントをユーザーごとのホスト認可に変換するものではありません。
### 安全なファイル操作
OpenClaw は、root 境界付きファイルアクセス、アトミック書き込み、アーカイブ抽出、一時ワークスペース、シークレットファイルヘルパーに `@openclaw/fs-safe` を使用します。OpenClaw は fs-safe の任意 POSIX Python ヘルパーをデフォルトで**オフ**にします。追加の fd 相対ミューテーション強化を必要とし、Python ランタイムをサポートできる場合にのみ、`OPENCLAW_FS_SAFE_PYTHON_MODE=auto` または `require` を設定してください。
詳細: [安全なファイル操作](/ja-JP/gateway/security/secure-file-operations)。
### 共有 Slack ワークスペース: 実際のリスク
「Slack 内の全員が bot にメッセージを送れる」場合、中核的なリスクは委任されたツール権限です。
- 許可された送信者は誰でも、エージェントのポリシー内でツール呼び出し（`exec`、ブラウザー、ネットワーク/ファイルツール）を誘導できます。
- ある送信者からのプロンプト/コンテンツインジェクションにより、共有 state、デバイス、出力に影響するアクションが発生する可能性があります。
- 1 つの共有エージェントが機密性の高い認証情報/ファイルを持っている場合、許可された送信者は誰でも、ツール使用を通じて漏えいを引き起こせる可能性があります。
チームのワークフローでは、最小限のツールを持つ別々のエージェント/gateway を使用してください。個人データのエージェントは非公開に保ってください。
### 会社共有エージェント: 許容されるパターン
これは、そのエージェントを使用する全員が同じ信頼境界内にあり（たとえば 1 つの会社チーム）、エージェントが厳密に業務スコープに限定されている場合に許容されます。
- 専用のマシン/VM/コンテナー上で実行する。
- そのランタイム用に専用の OS ユーザー + 専用のブラウザー/プロファイル/アカウントを使用する。
- そのランタイムに個人の Apple/Google アカウントや個人のパスワードマネージャー/ブラウザープロファイルでサインインしない。
同じランタイム上で個人 ID と会社 ID を混在させると、分離が崩れ、個人データの露出リスクが高まります。
## Gateway と Node の信頼概念
Gateway と Node は、役割が異なる 1 つのオペレーター信頼ドメインとして扱ってください。
- **Gateway** はコントロールプレーンおよびポリシー面です（`gateway.auth`、ツールポリシー、ルーティング）。
- **Node** は、その Gateway にペアリングされたリモート実行面です（コマンド、デバイスアクション、ホストローカル機能）。
- Gateway に認証された呼び出し元は、Gateway スコープで信頼されます。ペアリング後、Node アクションはその Node 上の信頼済みオペレーターアクションです。
- オペレータースコープレベルと承認時チェックは、
[オペレータースコープ](/ja-JP/gateway/operator-scopes) に要約されています。
- 共有 gateway トークン/パスワードで認証された直接 local loopback バックエンドクライアントは、ユーザー
デバイス ID を提示せずに内部コントロールプレーン RPC を実行できます。これはリモートまたはブラウザーのペアリングバイパスではありません。ネットワーク
クライアント、Node クライアント、デバイストークンクライアント、明示的なデバイス ID は、
引き続きペアリングとスコープアップグレードの強制を通過します。
- `sessionKey` はルーティング/コンテキスト選択であり、ユーザーごとの認証ではありません。
- Exec 承認（allowlist + ask）はオペレーターの意図に対するガードレールであり、敵対的マルチテナント隔離ではありません。
- 信頼済み単一オペレーターセットアップに対する OpenClaw のプロダクトデフォルトでは、`gateway`/`node` 上のホスト exec は承認プロンプトなしで許可されます（厳格化しない限り `security="full"`、`ask="off"`）。このデフォルトは意図的な UX であり、それ自体が脆弱性ではありません。
- Exec 承認は、正確なリクエストコンテキストとベストエフォートの直接ローカルファイルオペランドに結び付けられます。あらゆるランタイム/インタープリターローダーパスを意味論的にモデル化するものではありません。強力な境界にはサンドボックス化とホスト隔離を使用してください。
敵対的ユーザーの隔離が必要な場合は、OS ユーザー/ホストごとに信頼境界を分割し、別々の gateway を実行してください。
## 信頼境界マトリクス
リスクをトリアージする際の簡易モデルとして使用してください。
| 境界または制御 | 意味 | よくある誤読 |
| --------------------------------------------------------- | ------------------------------------------------- | ----------------------------------------------------------------------------- |
| `gateway.auth`（トークン/パスワード/trusted-proxy/デバイス認証） | gateway API に対して呼び出し元を認証する | 「安全であるには、すべてのフレームにメッセージごとの署名が必要」 |
| `sessionKey` | コンテキスト/セッション選択のルーティングキー | 「セッションキーはユーザー認証境界である」 |
| プロンプト/コンテンツのガードレール | モデル悪用リスクを低減する | 「プロンプトインジェクションだけで認証バイパスが証明される」 |
| `canvas.eval` / ブラウザー evaluate | 有効時の意図的なオペレーター機能 | 「この信頼モデルでは、任意の JS eval プリミティブが自動的に脆弱性である」 |
| ローカル TUI の `!` シェル | 明示的にオペレーターがトリガーしたローカル実行 | 「ローカルシェルの便利コマンドはリモートインジェクションである」 |
| Node ペアリングと Node コマンド | ペアリング済みデバイス上のオペレーターレベルのリモート実行 | 「リモートデバイス制御はデフォルトで信頼されていないユーザーアクセスとして扱うべき」 |
| `gateway.nodes.pairing.autoApproveCidrs` | オプトインの信頼済みネットワーク Node 登録ポリシー | 「デフォルト無効の allowlist は自動ペアリング脆弱性である」 |
## 設計上の非脆弱性
これらのパターンは頻繁に報告されますが、実際の境界バイパスが実証されない限り、
通常は対応不要としてクローズされます。
- ポリシー、認証、またはサンドボックスのバイパスを伴わない、プロンプトインジェクションのみのチェーン。
- 1 つの共有ホストまたは
config 上で敵対的マルチテナント運用を前提とする主張。
- 共有 gateway セットアップにおける通常のオペレーター読み取りパスアクセス（たとえば
`sessions.list` / `sessions.preview` / `chat.history`）を IDOR と分類する主張。
- ローカルホスト専用デプロイに関する指摘（たとえば loopback 専用
gateway 上の HSTS）。
- このリポジトリに存在しないインバウンドパスに対する Discord インバウンド Webhook 署名の指摘。
- `system.run` に対する隠れた第 2 のコマンドごとの
承認レイヤーとして Node ペアリングメタデータを扱う報告。実際の実行境界は依然として
gateway のグローバル Node コマンドポリシーと Node 自身の exec
承認です。
- 設定済みの `gateway.nodes.pairing.autoApproveCidrs` それ自体を
脆弱性として扱う報告。この設定はデフォルトで無効であり、
明示的な CIDR/IP エントリを必要とし、要求スコープがない初回の `role: node` ペアリングにのみ適用され、
loopback trusted-proxy 認証が明示的に有効化されていない限り、operator/browser/Control UI、
WebChat、ロールアップグレード、スコープアップグレード、メタデータ変更、公開鍵変更、
または同一ホストの loopback trusted-proxy ヘッダーパスを自動承認しません。
- `sessionKey` を認証トークンとして扱う「ユーザーごとの認可不足」の指摘。
## 60 秒での強化ベースライン
まずこのベースラインを使用し、その後、信頼済みエージェントごとにツールを選択的に再有効化してください。
```json5
{
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 },
},
channels: {
whatsapp: { dmPolicy: "pairing", groups: { "*": { requireMention: true } } },
},
}
```
これにより Gateway はローカル専用のままになり、DM が隔離され、コントロールプレーン/ランタイムツールがデフォルトで無効化されます。
## 共有 inbox のクイックルール
複数の人が bot に DM できる場合:
- `session.dmScope: "per-channel-peer"`（または複数アカウントのチャンネルでは `"per-account-channel-peer"`）を設定する。
- `dmPolicy: "pairing"` または厳格な allowlist を維持する。
- 共有 DM と広範なツールアクセスを決して組み合わせない。
- これは協調型/共有 inbox を強化しますが、ユーザーがホスト/config の書き込みアクセスを共有する場合の敵対的な共同テナント隔離として設計されているわけではありません。
## コンテキスト可視性モデル
OpenClaw は 2 つの概念を分離します。
- **トリガー認可**: 誰がエージェントをトリガーできるか（`dmPolicy`、`groupPolicy`、allowlist、メンションゲート）。
- **コンテキスト可視性**: モデル入力に注入される補足コンテキスト（返信本文、引用テキスト、スレッド履歴、転送メタデータ）。
Allowlist はトリガーとコマンド認可をゲートします。`contextVisibility` 設定は、補足コンテキスト（引用返信、スレッドルート、取得された履歴）がどのようにフィルタリングされるかを制御します。
- `contextVisibility: "all"` (デフォルト) は、受け取った補足コンテキストをそのまま保持します。
- `contextVisibility: "allowlist"` は、アクティブな許可リストチェックで許可された送信者に補足コンテキストを絞り込みます。
- `contextVisibility: "allowlist_quote"` は `allowlist` と同じように動作しますが、明示的に引用された返信を 1 つだけ保持します。
`contextVisibility` はチャネルごと、またはルーム/会話ごとに設定します。設定の詳細は [グループチャット](/ja-JP/channels/groups#context-visibility-and-allowlists) を参照してください。
アドバイザリートリアージのガイダンス:
- 「モデルが許可リストにない送信者からの引用テキストや過去のテキストを見られる」ことだけを示す主張は、`contextVisibility` で対処できる強化項目であり、それ自体では認証やサンドボックス境界のバイパスではありません。
- セキュリティへの影響があるとみなすには、レポートで信頼境界のバイパス (認証、ポリシー、サンドボックス、承認、または別の文書化された境界) が実証されている必要があります。
## 監査が確認すること (概要)
- **受信アクセス** (DM ポリシー、グループポリシー、許可リスト): 見知らぬ人がボットを起動できるか。
- **ツールの影響範囲** (昇格されたツール + オープンなルーム): プロンプトインジェクションがシェル/ファイル/ネットワーク操作につながる可能性があるか。
- **exec ファイルシステムのドリフト**: `exec`/`process` がサンドボックスのファイルシステム制約なしで利用可能なまま、ファイルシステムを変更するツールが拒否されているか。
- **exec 承認のドリフト** (`security=full`、`autoAllowSkills`、`strictInlineEval` なしのインタープリター許可リスト): ホスト exec のガードレールが、今も想定どおり機能しているか。
- `security="full"` は広範な姿勢に対する警告であり、バグの証明ではありません。これは信頼済みのパーソナルアシスタント設定で選ばれるデフォルトです。脅威モデルで承認や許可リストのガードレールが必要な場合にのみ強化してください。
- **ネットワーク公開** (Gateway の bind/auth、Tailscale Serve/Funnel、弱い/短い認証トークン)。
- **ブラウザー制御の公開** (リモートノード、リレーポート、リモート CDP エンドポイント)。
- **ローカルディスク衛生** (権限、シンボリックリンク、config include、「同期フォルダー」パス)。
- **Plugin** (明示的な許可リストなしで Plugin が読み込まれる)。
- **ポリシードリフト/誤設定** (サンドボックス Docker 設定が構成されているがサンドボックスモードがオフ、`gateway.nodes.denyCommands` パターンが正確なコマンド名のみの一致 (例: `system.run`) でシェルテキストを検査しないため無効、危険な `gateway.nodes.allowCommands` エントリー、グローバルの `tools.profile="minimal"` がエージェントごとのプロファイルで上書きされる、Plugin が所有するツールが許容的なツールポリシー下で到達可能)。
- **ランタイム期待値のドリフト** (たとえば、`tools.exec.host` が現在 `auto` をデフォルトにしているのに、暗黙の exec がまだ `sandbox` を意味すると想定する、またはサンドボックスモードがオフのまま `tools.exec.host="sandbox"` を明示的に設定する)。
- **モデル衛生** (構成されたモデルがレガシーに見える場合に警告する。ハードブロックではない)。
`--deep` を実行すると、OpenClaw はベストエフォートのライブ Gateway プローブも試行します。
## 認証情報ストレージマップ
アクセスを監査するとき、またはバックアップ対象を決めるときに使用します:
- **WhatsApp**: `~/.openclaw/credentials/whatsapp//creds.json`
- **Telegram ボットトークン**: config/env または `channels.telegram.tokenFile` (通常ファイルのみ。シンボリックリンクは拒否)
- **Discord ボットトークン**: config/env または SecretRef (env/file/exec プロバイダー)
- **Slack トークン**: config/env (`channels.slack.*`)
- **ペアリング許可リスト**:
- `~/.openclaw/credentials/-allowFrom.json` (デフォルトアカウント)
- `~/.openclaw/credentials/--allowFrom.json` (非デフォルトアカウント)
- **モデル認証プロファイル**: `~/.openclaw/agents//agent/auth-profiles.json`
- **Codex ランタイム状態**: `~/.openclaw/agents//agent/codex-home/`
- **ファイルベースのシークレットペイロード (任意)**: `~/.openclaw/secrets.json`
- **レガシー OAuth インポート**: `~/.openclaw/credentials/oauth.json`
## セキュリティ監査チェックリスト
監査が検出結果を出力したら、次の優先順位として扱ってください:
1. **「open」なもの + ツール有効**: まず DM/グループをロックダウンし (ペアリング/許可リスト)、次にツールポリシー/サンドボックス化を強化します。
2. **公開ネットワークへの露出** (LAN bind、Funnel、認証欠如): 直ちに修正します。
3. **ブラウザー制御のリモート公開**: オペレーターアクセスと同等に扱います (tailnet のみ、ノードは意図的にペアリング、公開露出を避ける)。
4. **権限**: state/config/credentials/auth が group/world-readable ではないことを確認します。
5. **Plugin**: 明示的に信頼するものだけを読み込みます。
6. **モデル選択**: ツールを持つボットには、現代的で指示に強化されたモデルを優先します。
## セキュリティ監査用語集
各監査検出結果は、構造化された `checkId` (例:
`gateway.bind_no_auth` または `tools.exec.security_full_configured`) によってキー付けされます。一般的な
重大度クラス:
- `fs.*` - state、config、credentials、auth プロファイルのファイルシステム権限。
- `gateway.*` - bind モード、auth、Tailscale、Control UI、trusted-proxy 設定。
- `hooks.*`、`browser.*`、`sandbox.*`、`tools.exec.*` - サーフェスごとの強化。
- `plugins.*`、`skills.*` - Plugin/skill のサプライチェーンとスキャン検出結果。
- `security.exposure.*` - アクセスポリシーとツールの影響範囲が交わる横断的チェック。
重大度レベル、修正キー、自動修正対応を含む完全なカタログは
[セキュリティ監査チェック](/ja-JP/gateway/security/audit-checks) を参照してください。
## HTTP 経由の Control UI
Control UI がデバイス ID を生成するには **セキュアコンテキスト** (HTTPS または localhost) が必要です。`gateway.controlUi.allowInsecureAuth` はローカル互換性トグルです:
- localhost では、ページが非セキュア HTTP で読み込まれた場合に、デバイス ID なしの Control UI 認証を許可します。
- ペアリングチェックはバイパスしません。
- リモート (非 localhost) のデバイス ID 要件は緩和しません。
HTTPS (Tailscale Serve) を優先するか、`127.0.0.1` で UI を開いてください。
ブレークグラスシナリオ専用として、`gateway.controlUi.dangerouslyDisableDeviceAuth` はデバイス ID チェックを完全に無効化します。これは重大なセキュリティ低下です。
積極的にデバッグしていて、すぐ戻せる場合を除き、オフのままにしてください。
これらの危険なフラグとは別に、`gateway.auth.mode: "trusted-proxy"` が成功すると、デバイス ID なしで **operator** Control UI セッションを許可できます。これは意図された auth-mode の挙動であり、`allowInsecureAuth` のショートカットではありません。また、node-role Control UI セッションには引き続き適用されません。
この設定が有効な場合、`openclaw security audit` は警告します。
## 非セキュアまたは危険なフラグの概要
既知の非セキュア/危険なデバッグスイッチが有効な場合、`openclaw security audit` は `config.insecure_or_dangerous_flags` を発生させます。本番環境ではこれらを未設定のままにしてください。
- `gateway.controlUi.allowInsecureAuth=true`
- `gateway.controlUi.dangerouslyAllowHostHeaderOriginFallback=true`
- `gateway.controlUi.dangerouslyDisableDeviceAuth=true`
- `hooks.gmail.allowUnsafeExternalContent=true`
- `hooks.mappings[].allowUnsafeExternalContent=true`
- `tools.exec.applyPatch.workspaceOnly=false`
- `plugins.entries.acpx.config.permissionMode=approve-all`
Control UI とブラウザー:
- `gateway.controlUi.dangerouslyAllowHostHeaderOriginFallback`
- `gateway.controlUi.dangerouslyDisableDeviceAuth`
- `browser.ssrfPolicy.dangerouslyAllowPrivateNetwork`
チャネル名一致 (同梱チャネルと Plugin チャネル。該当する場合は
`accounts.` ごとにも利用可能):
- `channels.discord.dangerouslyAllowNameMatching`
- `channels.slack.dangerouslyAllowNameMatching`
- `channels.googlechat.dangerouslyAllowNameMatching`
- `channels.msteams.dangerouslyAllowNameMatching`
- `channels.synology-chat.dangerouslyAllowNameMatching` (Plugin チャネル)
- `channels.synology-chat.dangerouslyAllowInheritedWebhookPath` (Plugin チャネル)
- `channels.zalouser.dangerouslyAllowNameMatching` (Plugin チャネル)
- `channels.irc.dangerouslyAllowNameMatching` (Plugin チャネル)
- `channels.mattermost.dangerouslyAllowNameMatching` (Plugin チャネル)
ネットワーク公開:
- `channels.telegram.network.dangerouslyAllowPrivateNetwork` (アカウントごとにも適用)
サンドボックス Docker (デフォルト + エージェントごと):
- `agents.defaults.sandbox.docker.dangerouslyAllowReservedContainerTargets`
- `agents.defaults.sandbox.docker.dangerouslyAllowExternalBindSources`
- `agents.defaults.sandbox.docker.dangerouslyAllowContainerNamespaceJoin`
## リバースプロキシ設定
Gateway をリバースプロキシ (nginx、Caddy、Traefik など) の背後で実行する場合は、
転送されたクライアント IP を適切に処理するために `gateway.trustedProxies` を構成してください。
Gateway が `trustedProxies` に **含まれていない** アドレスからプロキシヘッダーを検出した場合、その接続をローカルクライアントとして扱いません。Gateway 認証が無効な場合、それらの接続は拒否されます。これにより、プロキシされた接続が localhost から来たように見えて自動的な信頼を受ける認証バイパスを防ぎます。
`gateway.trustedProxies` は `gateway.auth.mode: "trusted-proxy"` にも渡されますが、この認証モードはより厳格です:
- trusted-proxy 認証は **デフォルトで loopback-source プロキシに対して fail closed**
- 同一ホストの loopback リバースプロキシは、ローカルクライアント検出と転送 IP 処理に `gateway.trustedProxies` を使用できます
- 同一ホストの loopback リバースプロキシが `gateway.auth.mode: "trusted-proxy"` を満たせるのは、`gateway.auth.trustedProxy.allowLoopback = true` の場合のみです。それ以外の場合は token/password 認証を使用してください
```yaml
gateway:
trustedProxies:
- "10.0.0.1" # reverse proxy IP
# Optional. Default false.
# Only enable if your proxy cannot provide X-Forwarded-For.
allowRealIpFallback: false
auth:
mode: password
password: ${OPENCLAW_GATEWAY_PASSWORD}
```
`trustedProxies` が構成されている場合、Gateway は `X-Forwarded-For` を使用してクライアント IP を判定します。`gateway.allowRealIpFallback: true` が明示的に設定されていない限り、`X-Real-IP` はデフォルトで無視されます。
信頼済みプロキシヘッダーによって、ノードデバイスのペアリングが自動的に信頼されることはありません。
`gateway.nodes.pairing.autoApproveCidrs` は別個の、デフォルト無効の
オペレーターポリシーです。有効な場合でも、loopback-source trusted-proxy ヘッダーパスは
ノードの自動承認から除外されます。ローカル呼び出し元がそれらのヘッダーを偽造できるためです。
これには、loopback trusted-proxy 認証が明示的に有効な場合も含まれます。
適切なリバースプロキシの挙動 (受信した転送ヘッダーを上書き):
```nginx
proxy_set_header X-Forwarded-For $remote_addr;
proxy_set_header X-Real-IP $remote_addr;
```
不適切なリバースプロキシの挙動 (信頼されていない転送ヘッダーを追加/保持):
```nginx
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
```
## HSTS とオリジンに関する注記
- OpenClaw gateway はローカル/loopback を第一にします。リバースプロキシで TLS を終端する場合は、そこでプロキシ向けの HTTPS ドメインに HSTS を設定してください。
- Gateway 自体が HTTPS を終端する場合は、`gateway.http.securityHeaders.strictTransportSecurity` を設定して、OpenClaw のレスポンスから HSTS ヘッダーを出力できます。
- 詳細なデプロイガイダンスは [Trusted Proxy Auth](/ja-JP/gateway/trusted-proxy-auth#tls-termination-and-hsts) にあります。
- 非 loopback の Control UI デプロイでは、デフォルトで `gateway.controlUi.allowedOrigins` が必要です。
- `gateway.controlUi.allowedOrigins: ["*"]` は明示的な全許可のブラウザーオリジンポリシーであり、強化されたデフォルトではありません。厳密に管理されたローカルテスト以外では避けてください。
- loopback でのブラウザーオリジン認証失敗は、一般的な loopback 免除が有効な場合でもレート制限されますが、ロックアウトキーは共有 localhost バケット 1 つではなく、正規化された `Origin` 値ごとにスコープされます。
- `gateway.controlUi.dangerouslyAllowHostHeaderOriginFallback=true` は Host ヘッダーのオリジンフォールバックモードを有効にします。危険な、オペレーターが選択したポリシーとして扱ってください。
- DNS rebinding とプロキシの Host ヘッダー挙動は、デプロイ時の強化上の懸念として扱ってください。`trustedProxies` を厳格に保ち、Gateway を公開インターネットに直接公開しないでください。
## ローカルセッションログはディスク上に保存されます
OpenClaw はセッショントランスクリプトを `~/.openclaw/agents//sessions/*.jsonl` の下のディスク上に保存します。
これはセッション継続性と、任意でセッションメモリのインデックス作成に必要ですが、同時に
**ファイルシステムアクセスを持つ任意のプロセス/ユーザーがこれらのログを読める**ことを意味します。ディスクアクセスを信頼境界として扱い、
`~/.openclaw` の権限をロックダウンしてください（下の監査セクションを参照）。エージェント間で
より強い分離が必要な場合は、別々の OS ユーザーまたは別々のホストで実行してください。
## Node 実行 (system.run)
macOS ノードがペアリングされている場合、Gateway はそのノードで `system.run` を呼び出せます。これは Mac 上での**リモートコード実行**です。
- ノードペアリング（承認 + トークン）が必要です。
- Gateway のノードペアリングはコマンドごとの承認面ではありません。ノードの ID/信頼とトークン発行を確立します。
- Gateway は `gateway.nodes.allowCommands` / `denyCommands` により、粗いグローバルノードコマンドポリシーを適用します。
- Mac では **設定 → 実行承認**（セキュリティ + 確認 + 許可リスト）で制御します。
- ノードごとの `system.run` ポリシーは、そのノード自身の実行承認ファイル（`exec.approvals.node.*`）であり、Gateway のグローバルなコマンド ID ポリシーより厳しくも緩くもできます。
- `security="full"` かつ `ask="off"` で動作するノードは、デフォルトの信頼済みオペレーターモデルに従っています。デプロイがより厳しい承認または許可リストの姿勢を明示的に必要としていない限り、これは期待される動作として扱ってください。
- 承認モードは正確なリクエストコンテキストに加え、可能な場合は 1 つの具体的なローカルスクリプト/ファイルオペランドに結び付けられます。OpenClaw がインタープリター/ランタイムコマンドについて直接のローカルファイルを正確に 1 つ識別できない場合、承認に基づく実行は、完全な意味的網羅を約束するのではなく拒否されます。
- `host=node` の場合、承認に基づく実行は正規化された準備済みの
`systemRunPlan` も保存します。以後の承認済み転送では保存されたプランが再利用され、Gateway の
検証は承認リクエスト作成後に呼び出し元がコマンド/cwd/セッションコンテキストを編集することを拒否します。
- リモート実行を望まない場合は、セキュリティを **deny** に設定し、その Mac のノードペアリングを削除してください。
この区別はトリアージで重要です。
- 再接続したペアリング済みノードが異なるコマンドリストを通知しても、それだけでは脆弱性ではありません。Gateway のグローバルポリシーとノードのローカル実行承認が、実際の実行境界をなお強制している場合です。
- ノードペアリングメタデータを、2 つ目の隠れたコマンドごとの承認レイヤーとして扱う報告は、通常はセキュリティ境界のバイパスではなく、ポリシー/UX の混同です。
## 動的 Skills（ウォッチャー / リモートノード）
OpenClaw はセッション中に Skills リストを更新できます。
- **Skills ウォッチャー**: `SKILL.md` への変更により、次のエージェントターンで Skills スナップショットが更新される場合があります。
- **リモートノード**: macOS ノードの接続により、macOS 専用 Skills が対象になる場合があります（バイナリのプローブに基づく）。
スキルフォルダーは**信頼済みコード**として扱い、変更できる人を制限してください。
## 脅威モデル
AI アシスタントは次のことができます。
- 任意のシェルコマンドを実行する
- ファイルを読み書きする
- ネットワークサービスにアクセスする
- 誰にでもメッセージを送る（WhatsApp アクセスを与えた場合）
あなたにメッセージを送る人は次のことができます。
- AI をだまして悪いことをさせようとする
- データへのアクセスをソーシャルエンジニアリングする
- インフラストラクチャの詳細を探る
## 中核概念: 知能より前にアクセス制御
ここでの失敗の多くは高度なエクスプロイトではなく、「誰かがボットにメッセージを送り、ボットが依頼どおりに動いた」というものです。
OpenClaw の姿勢:
- **まず ID:** 誰がボットと会話できるかを決める（DM ペアリング / 許可リスト / 明示的な「open」）。
- **次にスコープ:** ボットがどこで動作してよいかを決める（グループ許可リスト + メンションゲート、ツール、サンドボックス化、デバイス権限）。
- **最後にモデル:** モデルは操作され得ると想定し、操作されても影響範囲が限定されるように設計する。
## コマンド認可モデル
スラッシュコマンドとディレクティブは、**認可済み送信者**に対してのみ尊重されます。認可は
チャネル許可リスト/ペアリングと `commands.useAccessGroups` から導出されます（[設定](/ja-JP/gateway/configuration)
と [スラッシュコマンド](/ja-JP/tools/slash-commands) を参照）。チャネル許可リストが空、または `"*"` を含む場合、
そのチャネルではコマンドが実質的に開放されます。
`/exec` は認可済みオペレーター向けのセッション限定の利便機能です。設定を書き込んだり、
他のセッションを変更したりするものでは**ありません**。
## 制御プレーンツールのリスク
2 つの組み込みツールは、永続的な制御プレーン変更を行えます。
- `gateway` は `config.schema.lookup` / `config.get` で設定を検査でき、`config.apply`、`config.patch`、`update.run` で永続的な変更を行えます。
- `cron` は、元のチャット/タスクが終了した後も実行され続けるスケジュールジョブを作成できます。
所有者専用の `gateway` ランタイムツールは、なお
`tools.exec.ask` または `tools.exec.security` の書き換えを拒否します。レガシーの `tools.bash.*` エイリアスは、
書き込み前に同じ保護対象の実行パスへ正規化されます。
エージェント主導の `gateway config.apply` と `gateway config.patch` の編集は
デフォルトでフェイルクローズです。エージェントが調整可能なのは、プロンプト、モデル、メンションゲートに関する
狭い範囲のパスのみです。したがって、新しい機微な設定ツリーは、
意図的に許可リストへ追加されない限り保護されます。
信頼できないコンテンツを扱う任意のエージェント/サーフェスでは、デフォルトでこれらを拒否してください。
```json5
{
tools: {
deny: ["gateway", "cron", "sessions_spawn", "sessions_send"],
},
}
```
`commands.restart=false` は再起動アクションのみをブロックします。`gateway` の設定/更新アクションは無効化しません。
## Plugins
Plugins は Gateway と**同一プロセス内**で実行されます。信頼済みコードとして扱ってください。
- 信頼できるソースからの Plugins のみをインストールしてください。
- 明示的な `plugins.allow` 許可リストを推奨します。
- 有効化する前に Plugin 設定を確認してください。
- Plugin 変更後は Gateway を再起動してください。
- Plugins をインストールまたは更新する場合（`openclaw plugins install `、`openclaw plugins update `）、信頼できないコードを実行するのと同様に扱ってください。
- インストール先は、有効な Plugin インストールルート配下の Plugin ごとのディレクトリです。
- OpenClaw はインストール/更新前に組み込みの危険コードスキャンを実行します。`critical` の検出はデフォルトでブロックされます。
- npm と git による Plugin インストールでは、明示的なインストール/更新フロー中にのみ、パッケージマネージャーによる依存関係の収束を実行します。ローカルパスとアーカイブは自己完結した Plugin パッケージとして扱われ、OpenClaw は `npm install` を実行せずにコピー/参照します。
- ピン留めされた正確なバージョン（`@scope/pkg@1.2.3`）を推奨し、有効化する前にディスク上で展開済みコードを検査してください。
- `--dangerously-force-unsafe-install` は、Plugin のインストール/更新フローで組み込みスキャンの誤検知に対処するための非常用に限られます。Plugin の `before_install` フックポリシーブロックをバイパスせず、スキャン失敗もバイパスしません。
- Gateway 経由の Skills 依存関係インストールは、同じ危険/疑わしいの分岐に従います。呼び出し元が明示的に `dangerouslyForceUnsafeInstall` を設定しない限り、組み込みの `critical` 検出はブロックされます。一方、疑わしい検出は警告のみです。`openclaw skills install` は別個の ClawHub Skills ダウンロード/インストールフローのままです。
詳細: [Plugins](/ja-JP/tools/plugin)
## DM アクセスモデル: ペアリング、許可リスト、オープン、無効
現在 DM 対応のすべてのチャネルは、メッセージが処理される**前**に受信 DM をゲートする DM ポリシー（`dmPolicy` または `*.dm.policy`）をサポートします。
- `pairing`（デフォルト）: 未知の送信者は短いペアリングコードを受け取り、承認されるまでボットはそのメッセージを無視します。コードは 1 時間後に期限切れになります。新しいリクエストが作成されるまで、DM を繰り返してもコードは再送されません。保留中のリクエストはデフォルトで**チャネルあたり 3 件**に制限されます。
- `allowlist`: 未知の送信者はブロックされます（ペアリングハンドシェイクなし）。
- `open`: 誰でも DM できるようにします（公開）。チャネル許可リストに `"*"` が含まれていることが**必要**です（明示的なオプトイン）。
- `disabled`: 受信 DM を完全に無視します。
CLI で承認します。
```bash
openclaw pairing list
openclaw pairing approve
```
詳細 + ディスク上のファイル: [ペアリング](/ja-JP/channels/pairing)
## DM セッション分離（マルチユーザーモード）
デフォルトでは、OpenClaw はデバイスとチャネルをまたいだアシスタントの継続性を保つため、**すべての DM をメインセッションへルーティング**します。**複数の人**がボットに DM できる場合（オープン DM または複数人の許可リスト）、DM セッションの分離を検討してください。
```json5
{
session: { dmScope: "per-channel-peer" },
}
```
これにより、グループチャットは分離されたまま、ユーザー間のコンテキスト漏えいを防げます。
これはメッセージングコンテキスト境界であり、ホスト管理者の境界ではありません。ユーザー同士が互いに敵対的で、同じ Gateway ホスト/設定を共有している場合は、信頼境界ごとに別々の Gateway を実行してください。
### セキュア DM モード（推奨）
上のスニペットを**セキュア DM モード**として扱ってください。
- デフォルト: `session.dmScope: "main"`（継続性のため、すべての DM が 1 つのセッションを共有）。
- ローカル CLI オンボーディングのデフォルト: 未設定の場合に `session.dmScope: "per-channel-peer"` を書き込みます（既存の明示的な値は維持）。
- セキュア DM モード: `session.dmScope: "per-channel-peer"`（各チャネル+送信者のペアが分離された DM コンテキストを持つ）。
- チャネル横断のピア分離: `session.dmScope: "per-peer"`（各送信者が同じ種類のすべてのチャネルをまたいで 1 つのセッションを持つ）。
同じチャネルで複数アカウントを実行する場合は、代わりに `per-account-channel-peer` を使用してください。同じ人物が複数のチャネルで連絡してくる場合は、`session.identityLinks` を使ってそれらの DM セッションを 1 つの正規 ID に統合します。[セッション管理](/ja-JP/concepts/session) と [設定](/ja-JP/gateway/configuration) を参照してください。
## DM とグループの許可リスト
OpenClaw には 2 つの別々の「誰が自分を起動できるか？」レイヤーがあります。
- **DM 許可リスト**（`allowFrom` / `channels.discord.allowFrom` / `channels.slack.allowFrom`; レガシー: `channels.discord.dm.allowFrom`, `channels.slack.dm.allowFrom`）: ダイレクトメッセージでボットと会話できる人。
- `dmPolicy="pairing"` の場合、承認は `~/.openclaw/credentials/` 配下のアカウントスコープのペアリング許可リストストア（デフォルトアカウントでは `-allowFrom.json`、非デフォルトアカウントでは `--allowFrom.json`）に書き込まれ、設定の許可リストとマージされます。
- **グループ許可リスト**（チャネル固有）: ボットがそもそもどのグループ/チャネル/ギルドからのメッセージを受け入れるか。
- 一般的なパターン:
- `channels.whatsapp.groups`、`channels.telegram.groups`、`channels.imessage.groups`: `requireMention` のようなグループごとのデフォルト。設定されると、グループ許可リストとしても機能します（すべて許可の動作を維持するには `"*"` を含めます）。
- `groupPolicy="allowlist"` + `groupAllowFrom`: グループセッションの_内部_で誰がボットを起動できるかを制限します（WhatsApp/Telegram/Signal/iMessage/Microsoft Teams）。
- `channels.discord.guilds` / `channels.slack.channels`: サーフェスごとの許可リスト + メンションのデフォルト。
- グループチェックはこの順序で実行されます。まず `groupPolicy`/グループ許可リスト、次にメンション/返信によるアクティベーション。
- ボットメッセージへの返信（暗黙のメンション）は、`groupAllowFrom` のような送信者許可リストをバイパス**しません**。
- **セキュリティメモ:** `dmPolicy="open"` と `groupPolicy="open"` は最後の手段の設定として扱ってください。ほとんど使うべきではありません。部屋の全メンバーを完全に信頼している場合を除き、ペアリング + 許可リストを推奨します。
詳細: [設定](/ja-JP/gateway/configuration) と [グループ](/ja-JP/channels/groups)
## プロンプトインジェクション（それは何か、なぜ重要か）
プロンプトインジェクションとは、攻撃者がメッセージを細工して、モデルに安全でないことをさせるよう操作することです（「指示を無視して」、「ファイルシステムをダンプして」、「このリンクをたどってコマンドを実行して」など）。
強力なシステムプロンプトがあっても、**プロンプトインジェクションは解決されていません**。システムプロンプトのガードレールは柔らかい指針にすぎません。強制力はツールポリシー、実行承認、サンドボックス化、チャネル許可リストから来ます（そしてオペレーターは設計上これらを無効化できます）。実際に役立つこと:
- 受信 DM は厳格に制限する（ペアリング/許可リスト）。
- グループではメンションによるゲートを優先し、公開ルームでの「常時稼働」ボットは避ける。
- リンク、添付ファイル、貼り付けられた指示は、デフォルトで敵対的なものとして扱う。
- 機密性の高いツール実行はサンドボックス内で行い、シークレットをエージェントが到達可能なファイルシステムに置かない。
- 注: サンドボックス化はオプトインです。サンドボックスモードがオフの場合、暗黙の `host=auto` は Gateway ホストに解決されます。明示的な `host=sandbox` は、利用可能なサンドボックスランタイムがないため、なおもクローズドに失敗します。その動作を設定内で明示したい場合は `host=gateway` を設定してください。
- 高リスクなツール（`exec`、`browser`、`web_fetch`、`web_search`）は、信頼済みエージェントまたは明示的な許可リストに限定する。
- インタープリタ（`python`、`node`、`ruby`、`perl`、`php`、`lua`、`osascript`）を許可リストに入れる場合は、インライン eval 形式にも明示的な承認が必要になるように `tools.exec.strictInlineEval` を有効にする。
- シェル承認分析は、**引用符なしの heredoc** 内にある POSIX パラメータ展開形式（`$VAR`、`$?`、`$$`、`$1`、`$@`、`${…}`）も拒否するため、許可リストに入った heredoc 本文がプレーンテキストとして許可リストレビューをすり抜けてシェル展開を忍び込ませることはできません。リテラル本文セマンティクスを選択するには、heredoc 終端子を引用符で囲みます（例: `<<'EOF'`）。変数が展開されるはずだった引用符なしの heredoc は拒否されます。
- **モデル選択は重要です:** 古い/小さい/レガシーなモデルは、プロンプトインジェクションやツール悪用に対する堅牢性が大幅に低くなります。ツール有効エージェントには、利用可能な中で最も強力な最新世代の、命令に対して堅牢化されたモデルを使用してください。
信頼できないものとして扱うべき危険信号:
- 「このファイル/URL を読んで、そこに書かれていることを正確に実行して。」
- 「システムプロンプトまたは安全ルールを無視して。」
- 「隠された指示またはツール出力を明かして。」
- 「`~/.openclaw` またはログの完全な内容を貼り付けて。」
## 外部コンテンツの特殊トークンサニタイズ
OpenClaw は、ラップされた外部コンテンツとメタデータがモデルに到達する前に、一般的なセルフホスト LLM チャットテンプレートの特殊トークンリテラルを除去します。対象となるマーカーファミリーには、Qwen/ChatML、Llama、Gemma、Mistral、Phi、GPT-OSS のロール/ターントークンが含まれます。
理由:
- セルフホストモデルの前段にある OpenAI 互換バックエンドは、ユーザーテキスト内に現れる特殊トークンをマスクせず、そのまま保持することがあります。受信外部コンテンツ（取得されたページ、メール本文、ファイル内容ツール出力）に書き込める攻撃者は、そうでなければ合成された `assistant` または `system` ロール境界を注入し、ラップ済みコンテンツのガードレールを回避できてしまいます。
- サニタイズは外部コンテンツのラップ層で行われるため、プロバイダーごとではなく、fetch/read ツールと受信チャネルコンテンツ全体に一貫して適用されます。
- 送信モデル応答には、漏えいした ``、``、``、``、および同様の内部ランタイム足場を、最終チャネル配送境界でユーザー表示返信から除去する別個のサニタイザーがすでにあります。外部コンテンツサニタイザーは、その受信側の対応物です。
これは、このページの他の堅牢化（`dmPolicy`、許可リスト、exec 承認、サンドボックス化、`contextVisibility`）を置き換えるものではありません。それらは引き続き主要な役割を担います。これは、特殊トークンを含むユーザーテキストをそのまま転送するセルフホストスタックに対する、トークナイザー層の特定のバイパスを 1 つ塞ぎます。
## 安全でない外部コンテンツのバイパスフラグ
OpenClaw には、外部コンテンツの安全ラップを無効にする明示的なバイパスフラグが含まれます。
- `hooks.mappings[].allowUnsafeExternalContent`
- `hooks.gmail.allowUnsafeExternalContent`
- Cron ペイロードフィールド `allowUnsafeExternalContent`
ガイダンス:
- 本番環境では未設定/false のままにする。
- 厳密に範囲を限定したデバッグのためにのみ一時的に有効化する。
- 有効化する場合は、そのエージェントを隔離する（サンドボックス + 最小限のツール + 専用セッション名前空間）。
Hook のリスクに関する注記:
- Hook ペイロードは、配送元が管理下のシステムであっても信頼できないコンテンツです（メール/docs/Web コンテンツはプロンプトインジェクションを含み得ます）。
- 弱いモデル層はこのリスクを高めます。Hook 駆動の自動化では、強力な最新モデル層を優先し、ツールポリシーを厳格に保ち（`tools.profile: "messaging"` またはそれ以上に厳格）、可能であればサンドボックス化も使用してください。
### プロンプトインジェクションに公開 DM は不要
**自分だけ**がボットにメッセージを送れる場合でも、ボットが読む
**信頼できないコンテンツ**（Web 検索/取得結果、ブラウザページ、
メール、ドキュメント、添付ファイル、貼り付けられたログ/コード）を通じて、プロンプトインジェクションは発生し得ます。言い換えると、送信者だけが
脅威面ではありません。**コンテンツ自体**が敵対的な指示を運ぶことがあります。
ツールが有効な場合、典型的なリスクはコンテキストの流出または
ツール呼び出しのトリガーです。影響範囲を小さくするには:
- 信頼できないコンテンツを要約するために、読み取り専用またはツール無効の**リーダーエージェント**を使用し、
その要約をメインエージェントに渡す。
- ツール有効エージェントでは、必要でない限り `web_search` / `web_fetch` / `browser` をオフにする。
- OpenResponses URL 入力（`input_file` / `input_image`）では、
`gateway.http.endpoints.responses.files.urlAllowlist` と
`gateway.http.endpoints.responses.images.urlAllowlist` を厳密に設定し、`maxUrlParts` を低く保つ。
空の許可リストは未設定として扱われます。URL 取得を完全に無効化したい場合は、`files.allowUrl: false` / `images.allowUrl: false` を使用してください。
- OpenResponses ファイル入力では、デコードされた `input_file` テキストも
**信頼できない外部コンテンツ**として注入されます。Gateway がローカルでデコードしたという理由だけで、ファイルテキストが信頼できると見なさないでください。注入されたブロックには、この経路では長い `SECURITY NOTICE:` バナーが省略される場合でも、明示的な
`<<>>` 境界マーカーと `Source: External`
メタデータが引き続き含まれます。
- 添付ドキュメントから media-understanding がテキストを抽出し、そのテキストをメディアプロンプトに追加する場合にも、同じマーカーベースのラップが適用されます。
- 信頼できない入力に触れるすべてのエージェントに対して、サンドボックス化と厳格なツール許可リストを有効にする。
- シークレットをプロンプトに入れない。代わりに Gateway ホスト上の env/config 経由で渡す。
### セルフホスト LLM バックエンド
vLLM、SGLang、TGI、LM Studio、
またはカスタム Hugging Face トークナイザースタックなどの OpenAI 互換セルフホストバックエンドは、
チャットテンプレートの特殊トークンの扱いがホスト型プロバイダーと異なる場合があります。バックエンドが
`<|im_start|>`、`<|start_header_id|>`、`` などのリテラル文字列を
ユーザーコンテンツ内の構造的なチャットテンプレートトークンとしてトークン化する場合、信頼できないテキストは
トークナイザー層でロール境界を偽造しようとする可能性があります。
OpenClaw は、モデルに送信する前に、ラップされた
外部コンテンツから一般的なモデルファミリーの特殊トークンリテラルを除去します。外部コンテンツの
ラップは有効のままにし、利用可能な場合はユーザー提供コンテンツ内の特殊
トークンを分割またはエスケープするバックエンド設定を優先してください。OpenAI
や Anthropic などのホスト型プロバイダーは、すでに独自のリクエスト側サニタイズを適用しています。
### モデル強度（セキュリティ注記）
プロンプトインジェクション耐性は、モデル層間で**均一ではありません**。小さい/安価なモデルは、特に敵対的プロンプト下では、一般にツール悪用や指示乗っ取りの影響を受けやすくなります。
ツール有効エージェント、または信頼できないコンテンツを読むエージェントでは、古い/小さいモデルによるプロンプトインジェクションリスクは高すぎることが多いです。そのようなワークロードを弱いモデル層で実行しないでください。
推奨事項:
- ツールを実行できる、またはファイル/ネットワークに触れるボットには、**最新世代の最上位モデル**を使用する。
- ツール有効エージェントまたは信頼できない受信箱には、**古い/弱い/小さい層を使用しない**。プロンプトインジェクションリスクが高すぎます。
- 小さいモデルを使わざるを得ない場合は、**影響範囲を小さくする**（読み取り専用ツール、強力なサンドボックス化、最小限のファイルシステムアクセス、厳格な許可リスト）。
- 小さいモデルを実行する場合は、**すべてのセッションでサンドボックス化を有効化**し、入力が厳密に制御されていない限り **web_search/web_fetch/browser を無効化**する。
- 信頼済み入力かつツールなしのチャット専用パーソナルアシスタントでは、小さいモデルでも通常は問題ありません。
## グループ内での reasoning と冗長出力
`/reasoning`、`/verbose`、`/trace` は、内部 reasoning、ツール
出力、または公開チャネル向けではない Plugin 診断を
露出させる可能性があります。グループ設定では、これらを**デバッグ専用**として扱い、明示的に必要な場合を除いてオフにしてください。
ガイダンス:
- 公開ルームでは `/reasoning`、`/verbose`、`/trace` を無効のままにする。
- 有効化する場合は、信頼済み DM または厳密に管理されたルームでのみ行う。
- 注意: verbose と trace の出力には、ツール引数、URL、Plugin 診断、モデルが見たデータが含まれる可能性があります。
## 設定の堅牢化例
### ファイル権限
Gateway ホスト上で config + state を非公開に保つ:
- `~/.openclaw/openclaw.json`: `600`（ユーザーの読み書きのみ）
- `~/.openclaw`: `700`（ユーザーのみ）
`openclaw doctor` は警告し、これらの権限を強化する提案を行えます。
### ネットワーク公開（bind、port、firewall）
Gateway は単一ポート上で **WebSocket + HTTP** を多重化します。
- デフォルト: `18789`
- Config/flags/env: `gateway.port`、`--port`、`OPENCLAW_GATEWAY_PORT`
この HTTP サーフェスには Control UI と canvas ホストが含まれます。
- Control UI（SPA アセット）（デフォルトベースパス `/`）
- Canvas ホスト: `/__openclaw__/canvas/` と `/__openclaw__/a2ui/`（任意の HTML/JS。信頼できないコンテンツとして扱う）
通常のブラウザで canvas コンテンツを読み込む場合は、他の信頼できない Web ページと同様に扱ってください。
- canvas ホストを信頼できないネットワーク/ユーザーに公開しない。
- 影響を完全に理解していない限り、canvas コンテンツを特権 Web サーフェスと同じオリジンで共有させない。
Bind モードは Gateway がどこで待ち受けるかを制御します。
- `gateway.bind: "loopback"`（デフォルト）: ローカルクライアントのみ接続できます。
- 非 loopback bind（`"lan"`、`"tailnet"`、`"custom"`）は攻撃対象領域を拡大します。Gateway 認証（共有トークン/パスワード、または正しく設定された信頼済みプロキシ）と実際のファイアウォールがある場合にのみ使用してください。
経験則:
- LAN bind より Tailscale Serve を優先する（Serve は Gateway を loopback 上に保ち、Tailscale がアクセスを処理します）。
- LAN に bind せざるを得ない場合は、送信元 IP の厳密な許可リストにポートをファイアウォールで制限する。広範にポートフォワードしない。
- 認証なしで Gateway を `0.0.0.0` に公開しない。
### UFW を使用した Docker ポート公開
VPS 上で Docker を使って OpenClaw を実行する場合、公開されたコンテナポート
（`-p HOST:CONTAINER` または Compose `ports:`）は、ホストの `INPUT` ルールだけでなく、
Docker のフォワーディングチェーンを通じてルーティングされることを覚えておいてください。
Docker トラフィックをファイアウォールポリシーと整合させるには、
`DOCKER-USER` でルールを適用します（このチェーンは Docker 自身の accept ルールより前に評価されます）。
最近の多くのディストリビューションでは、`iptables`/`ip6tables` は `iptables-nft` フロントエンドを使用し、
それでもこれらのルールを nftables バックエンドに適用します。
最小限の許可リスト例（IPv4）:
```bash
# /etc/ufw/after.rules (append as its own *filter section)
*filter
:DOCKER-USER - [0:0]
-A DOCKER-USER -m conntrack --ctstate ESTABLISHED,RELATED -j RETURN
-A DOCKER-USER -s 127.0.0.0/8 -j RETURN
-A DOCKER-USER -s 10.0.0.0/8 -j RETURN
-A DOCKER-USER -s 172.16.0.0/12 -j RETURN
-A DOCKER-USER -s 192.168.0.0/16 -j RETURN
-A DOCKER-USER -s 100.64.0.0/10 -j RETURN
-A DOCKER-USER -p tcp --dport 80 -j RETURN
-A DOCKER-USER -p tcp --dport 443 -j RETURN
-A DOCKER-USER -m conntrack --ctstate NEW -j DROP
-A DOCKER-USER -j RETURN
COMMIT
```
IPv6 には別のテーブルがあります。
Docker IPv6 が有効な場合は、`/etc/ufw/after6.rules` に対応するポリシーを追加してください。
ドキュメントのスニペットで `eth0` のようなインターフェース名をハードコードするのは避けてください。インターフェース名は
VPS イメージによって異なり（`ens3`、`enp*` など）、不一致があると意図せず
deny ルールがスキップされる可能性があります。
リロード後のクイック検証:
```bash
ufw reload
iptables -S DOCKER-USER
ip6tables -S DOCKER-USER
nmap -sT -p 1-65535 --open
```
想定される外部ポートは、意図的に公開したものだけであるべきです（ほとんどの
構成では SSH + リバースプロキシのポート）。
### mDNS/Bonjour ディスカバリ
バンドルされた `bonjour` Plugin が有効な場合、Gateway はローカルデバイス検出のために mDNS（ポート 5353 上の `_openclaw-gw._tcp`）で自身の存在をブロードキャストします。フルモードでは、運用上の詳細を露出する可能性のある TXT レコードが含まれます。
- `cliPath`: CLI バイナリへの完全なファイルシステムパス（ユーザー名とインストール場所を露出する）
- `sshPort`: ホスト上で SSH が利用可能であることを通知する
- `displayName`, `lanHost`: ホスト名情報
**運用上のセキュリティ考慮事項:** インフラの詳細をブロードキャストすると、ローカルネットワーク上の誰でも偵察しやすくなる。ファイルシステムパスや SSH の利用可否のような「無害」な情報でも、攻撃者が環境を把握する助けになる。
**推奨事項:**
1. **LAN 検出が必要な場合を除き、Bonjour は無効のままにする。** Bonjour は macOS ホストでは自動起動し、それ以外ではオプトインである。直接 Gateway URL、Tailnet、SSH、または広域 DNS-SD を使えば、ローカルマルチキャストを避けられる。
2. **最小モード**（Bonjour が有効な場合のデフォルト。公開された Gateway に推奨）: mDNS ブロードキャストから機密フィールドを省略する:
```json5
{
discovery: {
mdns: { mode: "minimal" },
},
}
```
3. Plugin を有効のままにしつつローカルデバイス検出を抑止したい場合は、**mDNS モードを無効化**する:
```json5
{
discovery: {
mdns: { mode: "off" },
},
}
```
4. **完全モード**（オプトイン）: TXT レコードに `cliPath` + `sshPort` を含める:
```json5
{
discovery: {
mdns: { mode: "full" },
},
}
```
5. **環境変数**（代替）: 設定を変更せずに mDNS を無効化するには `OPENCLAW_DISABLE_BONJOUR=1` を設定する。
Bonjour が最小モードで有効な場合、Gateway はデバイス検出に十分な情報（`role`, `gatewayPort`, `transport`）をブロードキャストするが、`cliPath` と `sshPort` は省略する。CLI パス情報が必要なアプリは、代わりに認証済み WebSocket 接続経由で取得できる。
### Gateway WebSocket をロックダウンする（ローカル認証）
Gateway 認証は**デフォルトで必須**である。有効な Gateway 認証パスが設定されていない場合、
Gateway は WebSocket 接続を拒否する（フェイルクローズ）。
オンボーディングではデフォルトでトークンが生成される（ループバックでも同様）ため、
ローカルクライアントは認証する必要がある。
**すべての** WS クライアントに認証を要求するには、トークンを設定する:
```json5
{
gateway: {
auth: { mode: "token", token: "your-token" },
},
}
```
Doctor で生成できる: `openclaw doctor --generate-gateway-token`.
`gateway.remote.token` と `gateway.remote.password` はクライアント資格情報のソースである。それ自体ではローカル WS アクセスを保護しない。ローカル呼び出しパスは、`gateway.auth.*` が未設定の場合にのみ `gateway.remote.*` をフォールバックとして使用できる。`gateway.auth.token` または `gateway.auth.password` が SecretRef 経由で明示的に設定されていて解決できない場合、解決はフェイルクローズになる（リモートフォールバックで覆い隠されない）。
任意: `wss://` を使用する場合は `gateway.remote.tlsFingerprint` でリモート TLS を固定する。
プレーンテキストの `ws://` はデフォルトでループバック専用である。信頼済みのプライベートネットワーク
パスでは、非常時の例外としてクライアントプロセスに
`OPENCLAW_ALLOW_INSECURE_PRIVATE_WS=1` を設定する。これは意図的にプロセス環境のみであり、
`openclaw.json` 設定キーではない。
モバイルペアリングと Android の手動またはスキャン済み Gateway ルートはより厳格である:
クリアテキストはループバックでは受け入れられるが、プライベート LAN、リンクローカル、`.local`、および
ドットなしホスト名は、信頼済みプライベートネットワークのクリアテキストパスへ明示的にオプトインしない限り TLS を使用する必要がある。
ローカルデバイスペアリング:
- 同一ホストのクライアントを滑らかにするため、直接 local loopback 接続ではデバイスペアリングが自動承認される。
- OpenClaw には、信頼済み共有シークレットのヘルパーフロー向けに、限定的なバックエンド/コンテナローカルの自己接続パスもある。
- 同一ホストの tailnet バインドを含む Tailnet と LAN 接続は、ペアリング上はリモートとして扱われ、引き続き承認が必要である。
- ループバックリクエスト上の転送ヘッダー証拠は、ループバックローカリティの対象外にする。メタデータアップグレードの自動承認は狭くスコープされている。両方のルールについては
[Gateway ペアリング](/ja-JP/gateway/pairing) を参照。
認証モード:
- `gateway.auth.mode: "token"`: 共有ベアラートークン（ほとんどのセットアップで推奨）。
- `gateway.auth.mode: "password"`: パスワード認証（環境変数 `OPENCLAW_GATEWAY_PASSWORD` 経由で設定することを推奨）。
- `gateway.auth.mode: "trusted-proxy"`: ID 対応リバースプロキシがユーザーを認証し、ヘッダー経由で ID を渡すことを信頼する（[Trusted Proxy Auth](/ja-JP/gateway/trusted-proxy-auth) を参照）。
ローテーションチェックリスト（トークン/パスワード）:
1. 新しいシークレット（`gateway.auth.token` または `OPENCLAW_GATEWAY_PASSWORD`）を生成/設定する。
2. Gateway を再起動する（または macOS アプリが Gateway を監督している場合はそのアプリを再起動する）。
3. リモートクライアント（Gateway に呼び出すマシン上の `gateway.remote.token` / `.password`）を更新する。
4. 古い資格情報では接続できなくなったことを確認する。
### Tailscale Serve ID ヘッダー
`gateway.auth.allowTailscale` が `true`（Serve のデフォルト）の場合、OpenClaw は Control
UI/WebSocket 認証に Tailscale Serve ID ヘッダー（`tailscale-user-login`）を受け入れる。OpenClaw は、
ローカル Tailscale デーモン（`tailscale whois`）を通じて `x-forwarded-for` アドレスを解決し、
ヘッダーと照合することで ID を検証する。これは、リクエストがループバックに到達し、
Tailscale によって注入される `x-forwarded-for`、`x-forwarded-proto`、`x-forwarded-host` を含む場合にのみ発動する。
この非同期 ID チェックパスでは、同じ `{scope, ip}` に対する失敗した試行は、リミッターが失敗を記録する前に直列化される。そのため、1 つの Serve クライアントからの並行した不正な再試行は、2 つの単純な不一致として競合して通過するのではなく、2 回目の試行を即座にロックアウトできる。
HTTP API エンドポイント（例: `/v1/*`、`/tools/invoke`、`/api/channels/*`）は
Tailscale ID ヘッダー認証を**使用しない**。これらは引き続き Gateway の
設定済み HTTP 認証モードに従う。
重要な境界メモ:
- Gateway HTTP ベアラー認証は、実質的に全権限のオペレーターアクセスである。
- `/v1/chat/completions`、`/v1/responses`、または `/api/channels/*` を呼び出せる資格情報は、その Gateway に対するフルアクセスのオペレーターシークレットとして扱う。
- OpenAI 互換 HTTP サーフェスでは、共有シークレットのベアラー認証により、エージェントターンに対する完全なデフォルトのオペレータースコープ（`operator.admin`, `operator.approvals`, `operator.pairing`, `operator.read`, `operator.talk.secrets`, `operator.write`）と所有者セマンティクスが復元される。より狭い `x-openclaw-scopes` 値は、その共有シークレットパスを縮小しない。
- HTTP 上のリクエスト単位のスコープセマンティクスは、リクエストが trusted proxy auth やプライベートイングレス上の `gateway.auth.mode="none"` のような ID 付きモードから来る場合にのみ適用される。
- これらの ID 付きモードでは、`x-openclaw-scopes` を省略すると通常のオペレーターデフォルトスコープセットにフォールバックする。より狭いスコープセットが必要な場合は、ヘッダーを明示的に送信する。
- `/tools/invoke` は同じ共有シークレットルールに従う。トークン/パスワードのベアラー認証はそこでもフルオペレーターアクセスとして扱われる一方、ID 付きモードでは引き続き宣言されたスコープを尊重する。
- これらの資格情報を信頼できない呼び出し元と共有しないこと。信頼境界ごとに別の Gateway を使用することを推奨する。
**信頼前提:** トークンなしの Serve 認証は、Gateway ホストが信頼されていることを前提とする。
敵対的な同一ホストプロセスに対する保護として扱わないこと。信頼できない
ローカルコードが Gateway ホスト上で実行される可能性がある場合は、`gateway.auth.allowTailscale`
を無効化し、`gateway.auth.mode: "token"` または
`"password"` による明示的な共有シークレット認証を要求する。
**セキュリティルール:** 自分のリバースプロキシからこれらのヘッダーを転送しないこと。
Gateway の前段で TLS を終端したりプロキシしたりする場合は、
`gateway.auth.allowTailscale` を無効化し、共有シークレット認証（`gateway.auth.mode:
"token"` または `"password"`）または [Trusted Proxy Auth](/ja-JP/gateway/trusted-proxy-auth)
を代わりに使用する。
信頼済みプロキシ:
- Gateway の前段で TLS を終端する場合は、`gateway.trustedProxies` をプロキシ IP に設定する。
- OpenClaw は、それらの IP からの `x-forwarded-for`（または `x-real-ip`）を信頼し、ローカルペアリングチェックと HTTP 認証/ローカルチェックでクライアント IP を判定する。
- プロキシが `x-forwarded-for` を**上書き**し、Gateway ポートへの直接アクセスをブロックするようにする。
[Tailscale](/ja-JP/gateway/tailscale) と [Web 概要](/ja-JP/web) を参照。
### node ホスト経由のブラウザー制御（推奨）
Gateway がリモートにあり、ブラウザーが別のマシンで実行されている場合は、ブラウザーマシン上で **node ホスト**
を実行し、Gateway にブラウザー操作をプロキシさせる（[Browser tool](/ja-JP/tools/browser) を参照）。
node ペアリングは管理者アクセスと同様に扱う。
推奨パターン:
- Gateway と node ホストを同じ tailnet（Tailscale）上に置く。
- node を意図的にペアリングする。不要な場合はブラウザープロキシルーティングを無効化する。
避けること:
- リレー/制御ポートを LAN または公共インターネットに公開する。
- ブラウザー制御エンドポイントに Tailscale Funnel を使うこと（公開露出）。
### ディスク上のシークレット
`~/.openclaw/`（または `$OPENCLAW_STATE_DIR/`）配下のものはすべて、シークレットまたはプライベートデータを含む可能性があると考える:
- `openclaw.json`: 設定にはトークン（Gateway、リモート Gateway）、プロバイダー設定、許可リストが含まれる場合がある。
- `credentials/**`: チャネル資格情報（例: WhatsApp 資格情報）、ペアリング許可リスト、レガシー OAuth インポート。
- `agents//agent/auth-profiles.json`: API キー、トークンプロファイル、OAuth トークン、任意の `keyRef`/`tokenRef`。
- `agents//agent/codex-home/**`: エージェント単位の Codex アプリサーバーアカウント、設定、Skills、plugins、ネイティブスレッド状態、診断。
- `secrets.json`（任意）: `file` SecretRef プロバイダー（`secrets.providers`）で使用されるファイル-backed シークレットペイロード。
- `agents//agent/auth.json`: レガシー互換ファイル。静的な `api_key` エントリは発見時にスクラブされる。
- `agents//sessions/**`: セッショントランスクリプト（`*.jsonl`）+ ルーティングメタデータ（`sessions.json`）。プライベートメッセージやツール出力を含む可能性がある。
- バンドル済み Plugin パッケージ: インストール済み plugins（およびそれらの `node_modules/`）。
- `sandboxes/**`: ツールサンドボックスワークスペース。サンドボックス内で読み書きしたファイルのコピーが蓄積される場合がある。
強化のヒント:
- 権限を厳格に保つ（ディレクトリは `700`、ファイルは `600`）。
- Gateway ホストでフルディスク暗号化を使用する。
- ホストが共有されている場合は、Gateway 用に専用の OS ユーザーアカウントを使うことを推奨する。
### ワークスペースの `.env` ファイル
OpenClaw はエージェントとツール向けにワークスペースローカルの `.env` ファイルを読み込むが、それらのファイルが Gateway ランタイム制御を黙って上書きすることは決して許可しない。
- `OPENCLAW_*` で始まるすべてのキーは、信頼できないワークスペース `.env` ファイルからブロックされる。
- Matrix、Mattermost、IRC、Synology Chat のチャネルエンドポイント設定も、ワークスペース `.env` による上書きからブロックされるため、クローンされたワークスペースがローカルエンドポイント設定を通じてバンドル済みコネクタートラフィックをリダイレクトすることはできない。エンドポイント環境キー（`MATRIX_HOMESERVER`、`MATTERMOST_URL`、`IRC_HOST`、`SYNOLOGY_CHAT_INCOMING_URL` など）は、ワークスペースから読み込まれる `.env` ではなく、Gateway プロセス環境または `env.shellEnv` から来る必要がある。
- ブロックはフェイルクローズである。将来のリリースで追加された新しいランタイム制御変数は、チェックインされた、または攻撃者が提供した `.env` から継承されることはない。キーは無視され、Gateway は自身の値を保持する。
- 信頼済みのプロセス/OS 環境変数（Gateway 自身のシェル、launchd/systemd ユニット、アプリバンドル）は引き続き適用される。これは `.env` ファイルの読み込みだけを制限する。
理由: ワークスペース `.env` ファイルは、多くの場合エージェントコードの隣に置かれ、誤ってコミットされたり、ツールによって書き込まれたりする。`OPENCLAW_*` プレフィックス全体をブロックすることで、後から新しい `OPENCLAW_*` フラグを追加しても、ワークスペース状態からの暗黙の継承へ退行することは決してない。
### ログとトランスクリプト（リダクションと保持）
アクセス制御が正しくても、ログとトランスクリプトは機密情報を漏らす可能性がある:
- Gateway ログには、ツール要約、エラー、URL が含まれる場合がある。
- セッショントランスクリプトには、貼り付けられたシークレット、ファイル内容、コマンド出力、リンクが含まれる場合がある。
推奨事項:
- ログとトランスクリプトのリダクションを有効のままにする（`logging.redactSensitive: "tools"`、デフォルト）。
- `logging.redactPatterns` を使用して、環境に合わせたカスタムパターン（トークン、ホスト名、内部 URL）を追加する。
- 診断を共有する場合は、生ログではなく `openclaw status --all`（貼り付け可能、シークレットはリダクション済み）を推奨する。
- 長期保持が不要な場合は、古いセッショントランスクリプトとログファイルを削除する。
詳細: [Logging](/ja-JP/gateway/logging)
### DM: デフォルトでペアリング
```json5
{
channels: { whatsapp: { dmPolicy: "pairing" } },
}
```
### グループ: すべての場所でメンションを必須にする
```json
{
"channels": {
"whatsapp": {
"groups": {
"*": { "requireMention": true }
}
}
},
"agents": {
"list": [
{
"id": "main",
"groupChat": { "mentionPatterns": ["@openclaw", "@mybot"] }
}
]
}
}
```
グループチャットでは、明示的にメンションされた場合にのみ応答します。
### 番号を分ける (WhatsApp, Signal, Telegram)
電話番号ベースのチャネルでは、個人用とは別の電話番号で AI を実行することを検討してください。
- 個人番号: 会話は非公開のまま保たれます
- Bot 番号: AI が適切な境界を設けてこれらを処理します
### 読み取り専用モード (サンドボックスとツール経由)
次を組み合わせることで、読み取り専用プロファイルを構築できます。
- `agents.defaults.sandbox.workspaceAccess: "ro"` (ワークスペースアクセスなしの場合は `"none"`)
- `write`、`edit`、`apply_patch`、`exec`、`process` などをブロックするツールの許可/拒否リスト
追加の強化オプション:
- `tools.exec.applyPatch.workspaceOnly: true` (デフォルト): サンドボックス化がオフの場合でも、`apply_patch` がワークスペースディレクトリの外に書き込み/削除できないようにします。`false` に設定するのは、`apply_patch` が意図的にワークスペース外のファイルに触れる必要がある場合だけにしてください。
- `tools.fs.workspaceOnly: true` (任意): `read`/`write`/`edit`/`apply_patch` のパスと、ネイティブプロンプト画像の自動読み込みパスをワークスペースディレクトリに制限します (現在絶対パスを許可していて、単一のガードレールが必要な場合に有用です)。
- ファイルシステムルートは狭く保ちます。エージェントワークスペース/サンドボックスワークスペースには、ホームディレクトリのような広いルートを避けてください。広いルートでは、機密性の高いローカルファイル (たとえば `~/.openclaw` 配下の状態/設定) がファイルシステムツールに露出する可能性があります。
### セキュアなベースライン (コピー/ペースト)
Gateway を非公開に保ち、DM ペアリングを必須にし、常時稼働のグループ Bot を避ける「安全なデフォルト」設定の一例です。
```json5
{
gateway: {
mode: "local",
bind: "loopback",
port: 18789,
auth: { mode: "token", token: "your-long-random-token" },
},
channels: {
whatsapp: {
dmPolicy: "pairing",
groups: { "*": { requireMention: true } },
},
},
}
```
ツール実行も「デフォルトでより安全」にしたい場合は、非所有者エージェントに対してサンドボックスを追加し、危険なツールを拒否してください (例は下の「エージェントごとのアクセスプロファイル」を参照)。
チャット駆動のエージェントターンに対する組み込みベースライン: 非所有者の送信者は `cron` または `gateway` ツールを使用できません。
## サンドボックス化 (推奨)
専用ドキュメント: [サンドボックス化](/ja-JP/gateway/sandboxing)
補完的な 2 つのアプローチがあります。
- **Gateway 全体を Docker で実行する** (コンテナ境界): [Docker](/ja-JP/install/docker)
- **ツールサンドボックス** (`agents.defaults.sandbox`、ホスト Gateway + サンドボックス分離されたツール。Docker がデフォルトのバックエンドです): [サンドボックス化](/ja-JP/gateway/sandboxing)
エージェント間アクセスを防ぐには、`agents.defaults.sandbox.scope` を `"agent"` (デフォルト) のままにするか、より厳密なセッションごとの分離には `"session"` を使用してください。`scope: "shared"` は単一のコンテナまたはワークスペースを使用します。
サンドボックス内でのエージェントワークスペースアクセスも検討してください。
- `agents.defaults.sandbox.workspaceAccess: "none"` (デフォルト) はエージェントワークスペースをアクセス不可に保ちます。ツールは `~/.openclaw/sandboxes` 配下のサンドボックスワークスペースに対して実行されます
- `agents.defaults.sandbox.workspaceAccess: "ro"` はエージェントワークスペースを読み取り専用で `/agent` にマウントします (`write`/`edit`/`apply_patch` を無効化します)
- `agents.defaults.sandbox.workspaceAccess: "rw"` はエージェントワークスペースを読み書き可能で `/workspace` にマウントします
- 追加の `sandbox.docker.binds` は、正規化および正準化されたソースパスに対して検証されます。親シンボリックリンクのトリックや正準ホームエイリアスでも、`/etc`、`/var/run`、または OS ホーム配下の認証情報ディレクトリなど、ブロック対象ルートに解決される場合は安全側に失敗します。
`tools.elevated` は、サンドボックス外で exec を実行するグローバルなベースラインのエスケープハッチです。有効なホストはデフォルトでは `gateway`、exec ターゲットが `node` に設定されている場合は `node` です。`tools.elevated.allowFrom` は厳しく制限し、見知らぬ相手には有効にしないでください。`agents.list[].tools.elevated` を使って、エージェントごとに elevated をさらに制限できます。[Elevated モード](/ja-JP/tools/elevated)を参照してください。
### サブエージェント委任のガードレール
セッションツールを許可する場合は、委任されたサブエージェント実行を別の境界判断として扱ってください。
- エージェントが本当に委任を必要としない限り、`sessions_spawn` を拒否します。
- `agents.defaults.subagents.allowAgents` と、エージェントごとの `agents.list[].subagents.allowAgents` オーバーライドは、既知の安全なターゲットエージェントに制限してください。
- サンドボックス化された状態を維持する必要があるワークフローでは、`sandbox: "require"` を指定して `sessions_spawn` を呼び出します (デフォルトは `inherit` です)。
- `sandbox: "require"` は、ターゲット子ランタイムがサンドボックス化されていない場合に即座に失敗します。
## ブラウザ制御のリスク
ブラウザ制御を有効にすると、モデルは実際のブラウザを操作できるようになります。
そのブラウザプロファイルにログイン済みセッションがすでに含まれている場合、モデルは
それらのアカウントやデータにアクセスできます。ブラウザプロファイルは**機密状態**として扱ってください。
- エージェント専用のプロファイル (デフォルトの `openclaw` プロファイル) を優先します。
- 個人の日常利用プロファイルをエージェントに指定することは避けてください。
- 信頼していない限り、サンドボックス化されたエージェントではホストブラウザ制御を無効のままにします。
- スタンドアロンのループバックブラウザ制御 API は、共有シークレット認証
(Gateway トークン bearer 認証または Gateway パスワード) のみを尊重します。trusted-proxy または Tailscale Serve の identity ヘッダーは使用しません。
- ブラウザダウンロードは信頼できない入力として扱い、分離されたダウンロードディレクトリを優先してください。
- 可能であれば、エージェントプロファイルでブラウザ同期/パスワードマネージャーを無効化してください (影響範囲を縮小します)。
- リモート Gateway では、「ブラウザ制御」は、そのプロファイルが到達できるものへの「オペレーターアクセス」と同等だと想定してください。
- Gateway とノードホストは tailnet 限定に保ちます。ブラウザ制御ポートを LAN や公開インターネットに公開することは避けてください。
- 必要ない場合は、ブラウザプロキシルーティングを無効化します (`gateway.nodes.browser.mode="off"`)。
- Chrome MCP の既存セッションモードは「より安全」**ではありません**。そのホストの Chrome プロファイルが到達できる範囲で、あなたとして動作できます。
### ブラウザ SSRF ポリシー (デフォルトで厳格)
OpenClaw のブラウザナビゲーションポリシーはデフォルトで厳格です。明示的にオプトインしない限り、プライベート/内部の宛先はブロックされたままになります。
- デフォルト: `browser.ssrfPolicy.dangerouslyAllowPrivateNetwork` は未設定のため、ブラウザナビゲーションではプライベート/内部/特殊用途の宛先がブロックされたままになります。
- レガシーエイリアス: `browser.ssrfPolicy.allowPrivateNetwork` は互換性のため引き続き受け付けられます。
- オプトインモード: プライベート/内部/特殊用途の宛先を許可するには、`browser.ssrfPolicy.dangerouslyAllowPrivateNetwork: true` を設定します。
- 厳格モードでは、明示的な例外として `hostnameAllowlist`（`*.example.com` のようなパターン）と `allowedHostnames`（`localhost` のようなブロック対象名を含む、完全一致のホスト例外）を使用します。
- リダイレクトによるピボットを減らすため、ナビゲーションはリクエスト前にチェックされ、ナビゲーション後の最終的な `http(s)` URL でベストエフォートで再チェックされます。
厳格ポリシーの例:
```json5
{
browser: {
ssrfPolicy: {
dangerouslyAllowPrivateNetwork: false,
hostnameAllowlist: ["*.example.com", "example.com"],
allowedHostnames: ["localhost"],
},
},
}
```
## エージェントごとのアクセスプロファイル（マルチエージェント）
マルチエージェントルーティングでは、各エージェントが独自のサンドボックス + ツールポリシーを持てます。
これを使って、エージェントごとに**フルアクセス**、**読み取り専用**、または**アクセスなし**を付与します。
詳細と優先順位ルールについては、[マルチエージェントのサンドボックスとツール](/ja-JP/tools/multi-agent-sandbox-tools)を参照してください。
一般的なユースケース:
- 個人用エージェント: フルアクセス、サンドボックスなし
- 家族/仕事用エージェント: サンドボックス化 + 読み取り専用ツール
- 公開エージェント: サンドボックス化 + ファイルシステム/シェルツールなし
### 例: フルアクセス（サンドボックスなし）
```json5
{
agents: {
list: [
{
id: "personal",
workspace: "~/.openclaw/workspace-personal",
sandbox: { mode: "off" },
},
],
},
}
```
### 例: 読み取り専用ツール + 読み取り専用ワークスペース
```json5
{
agents: {
list: [
{
id: "family",
workspace: "~/.openclaw/workspace-family",
sandbox: {
mode: "all",
scope: "agent",
workspaceAccess: "ro",
},
tools: {
allow: ["read"],
deny: ["write", "edit", "apply_patch", "exec", "process", "browser"],
},
},
],
},
}
```
### 例: ファイルシステム/シェルアクセスなし（プロバイダーメッセージングは許可）
```json5
{
agents: {
list: [
{
id: "public",
workspace: "~/.openclaw/workspace-public",
sandbox: {
mode: "all",
scope: "agent",
workspaceAccess: "none",
},
// セッションツールはトランスクリプトから機微データを明らかにする可能性があります。デフォルトでは OpenClaw はこれらのツールを
// 現在のセッション + 生成されたサブエージェントセッションに制限しますが、必要に応じてさらに締め付けられます。
// 設定リファレンスの `tools.sessions.visibility` を参照してください。
tools: {
sessions: { visibility: "tree" }, // self | tree | agent | all
allow: [
"sessions_list",
"sessions_history",
"sessions_send",
"sessions_spawn",
"session_status",
"whatsapp",
"telegram",
"slack",
"discord",
],
deny: [
"read",
"write",
"edit",
"apply_patch",
"exec",
"process",
"browser",
"canvas",
"nodes",
"cron",
"gateway",
"image",
],
},
},
],
},
}
```
## インシデント対応
AI が悪いことをした場合:
### 封じ込め
1. **停止する:** macOS アプリ（Gateway を監視している場合）を停止するか、`openclaw gateway` プロセスを終了します。
2. **露出を閉じる:** 何が起きたかを理解するまで、`gateway.bind: "loopback"` を設定します（または Tailscale Funnel/Serve を無効にします）。
3. **アクセスを凍結する:** リスクの高い DM/グループを `dmPolicy: "disabled"` に切り替えるかメンション必須にし、`"*"` の全許可エントリがある場合は削除します。
### ローテーション（シークレットが漏えいした場合は侵害を想定）
1. Gateway 認証（`gateway.auth.token` / `OPENCLAW_GATEWAY_PASSWORD`）をローテーションして再起動します。
2. Gateway を呼び出せる任意のマシンで、リモートクライアントシークレット（`gateway.remote.token` / `.password`）をローテーションします。
3. プロバイダー/API 認証情報（WhatsApp 認証情報、Slack/Discord トークン、`auth-profiles.json` 内のモデル/API キー、および使用時の暗号化シークレットペイロード値）をローテーションします。
### 監査
1. Gateway ログを確認します: `/tmp/openclaw/openclaw-YYYY-MM-DD.log`（または `logging.file`）。
2. 関連するトランスクリプトを確認します: `~/.openclaw/agents//sessions/*.jsonl`。
3. 最近の設定変更（アクセスを広げた可能性があるもの: `gateway.bind`、`gateway.auth`、dm/group ポリシー、`tools.elevated`、plugin の変更）を確認します。
4. `openclaw security audit --deep` を再実行し、重大な検出事項が解決済みであることを確認します。
### レポート用に収集
- タイムスタンプ、Gateway ホスト OS + OpenClaw バージョン
- セッショントランスクリプト + 短いログ末尾（伏せ字処理後）
- 攻撃者が送信した内容 + エージェントが行ったこと
- Gateway が loopback を超えて露出していたかどうか（LAN/Tailscale Funnel/Serve）
## シークレットスキャン
CI はリポジトリ全体に対して pre-commit の `detect-private-key` フックを実行します。失敗した場合は、コミットされた鍵マテリアルを削除またはローテーションしてから、ローカルで再現します。
```bash
pre-commit run --all-files detect-private-key
```
## セキュリティ問題の報告
OpenClaw に脆弱性を見つけましたか？責任ある方法で報告してください:
1. メール: [security@openclaw.ai](mailto:security@openclaw.ai)
2. 修正されるまで公開投稿しないでください
3. クレジットを記載します（匿名を希望する場合を除く）