安全性

[!WARNING] 個人助理信任模型： 本指南假設每個 gateway 只有一個受信任的操作者邊界（單使用者/個人助理模型）。 OpenClaw 不是為多個敵對使用者共用同一個 agent/gateway 而設計的多租戶安全邊界。 如果你需要混合信任或敵對使用者操作，請拆分信任邊界（獨立的 gateway + 憑證，理想情況下使用獨立的 OS 使用者/主機）。

先釐清範圍：個人助理安全模型

OpenClaw 的安全指南假設個人助理部署：一個受信任的操作者邊界，可能有多個代理。

• 支援的安全態勢：每個 gateway 一個使用者/信任邊界（建議每個邊界使用一個 OS 使用者/主機/VPS）。
• 不支援的安全邊界：一個共用的 gateway/agent 由互不信任或敵對的使用者使用。
• 如果需要敵對使用者隔離，請按信任邊界拆分（獨立的 gateway + 憑證，理想情況下使用獨立的 OS 使用者/主機）。
• 如果多個不受信任的使用者可以對同一個啟用工具的代理發送訊息，請將他們視為共用該代理的委派工具權限。

本頁說明在此模型內的強化方式。它不聲稱能在一個共用 gateway 上提供敵對多租戶隔離。

快速檢查：openclaw security audit

另見：形式驗證（安全模型）

定期執行（特別是在變更設定或暴露網路介面之後）：

openclaw security audit
openclaw security audit --deep
openclaw security audit --fix
openclaw security audit --json

它會標記常見的地雷（Gateway 認證暴露、瀏覽器控制暴露、提權白名單、檔案系統權限）。

OpenClaw 既是一個產品也是一個實驗：你正在把前沿模型的行為接入真實的通訊介面和真實的工具。不存在「完美安全」的設定。 目標是對以下事項有意識地做出決定：

• 誰能跟你的機器人對話
• 機器人被允許在哪裡行動
• 機器人能碰到什麼

從能正常運作的最小存取開始，隨著信心增加再逐步放寬。

部署假設（重要）

OpenClaw 假設主機和設定邊界是受信任的：

• 如果有人能修改 Gateway 主機的狀態/設定（~/.openclaw，包括 openclaw.json），就把他們視為受信任的操作者。
• 為多個互不信任/敵對的操作者運行一個 Gateway 不是建議的設定。
• 對於混合信任的團隊，用獨立的 gateway 拆分信任邊界（或至少使用獨立的 OS 使用者/主機）。
• OpenClaw 可以在一台機器上執行多個 gateway 實例，但建議的做法是乾淨地分離信任邊界。
• 建議的預設值：每台機器/主機（或 VPS）一個使用者，該使用者一個 gateway，gateway 中可以有多個代理。
• 如果多個使用者都想用 OpenClaw，每個使用者使用一個 VPS/主機。

實際影響（操作者信任邊界）

在一個 Gateway 實例中，已認證的操作者存取是受信任的控制層角色，不是按使用者的租戶角色。

• 擁有讀取/控制層存取的操作者可以透過設計檢視 gateway session 中繼資料/歷史。
• Session 識別碼（sessionKey、session ID、標籤）是路由選擇器，不是授權 token。
• 例如：預期 sessions.list、sessions.preview 或 chat.history 等方法有按操作者的隔離，超出了此模型的範圍。
• 如果你需要敵對使用者隔離，請按信任邊界運行獨立的 gateway。
• 在一台機器上運行多個 gateway 技術上可行，但不是多使用者隔離的建議基準。

個人助理模型（不是多租戶匯流排）

OpenClaw 被設計為個人助理安全模型：一個受信任的操作者邊界，可能有多個代理。

• 如果多人可以對同一個啟用工具的代理發送訊息，每個人都能操控同一組權限。
• 按使用者的 session/記憶體隔離有助於隱私，但不會把共用代理轉變為按使用者的主機授權。
• 如果使用者之間可能互相敵對，請按信任邊界運行獨立的 gateway（或獨立的 OS 使用者/主機）。

共用 Slack 工作區：真實風險

如果「Slack 裡的所有人都能跟機器人對話」，核心風險是委派的工具權限：

• 任何被允許的發送者都能引導工具呼叫（exec、瀏覽器、網路/檔案工具），範圍取決於代理的策略；
• 來自一個發送者的提示詞/內容注入可能導致影響共用狀態、裝置或輸出的動作；
• 如果一個共用代理擁有敏感憑證/檔案，任何被允許的發送者都可能透過工具使用驅動資料外洩。

針對團隊工作流程使用獨立的代理/gateway 並搭配最少的工具；把個人資料代理保持私有。

公司共用代理：可接受的模式

當使用該代理的所有人都在同一個信任邊界內（例如一個公司團隊）且代理嚴格限定在商業用途時，這是可接受的。

• 在專用機器/VM/容器上運行；
• 使用專用的 OS 使用者 + 專用的瀏覽器/profile/帳號給該 runtime；
• 不要在該 runtime 中登入個人 Apple/Google 帳號或個人密碼管理器/瀏覽器 profile。

如果你混用個人和公司身分在同一個 runtime 上，你就瓦解了隔離並增加了個人資料暴露風險。

Gateway 和節點信任概念

將 Gateway 和節點視為一個操作者信任域，有不同的角色：

• Gateway 是控制層和策略介面（gateway.auth、工具策略、路由）。
• 節點是配對到該 Gateway 的遠端執行介面（指令、裝置動作、主機本機能力）。
• 對 Gateway 已認證的呼叫者在 Gateway 範圍內是受信任的。配對後，節點動作是該節點上的受信任操作者動作。
• sessionKey 是路由/上下文選擇，不是按使用者的認證。
• Exec 核准（白名單 + 詢問）是操作者意圖的防護欄，不是敵對多租戶隔離。
• Exec 核准綁定確切的請求上下文和盡力直接的本機檔案操作對象；它們不會語義化地建模每個 runtime/直譯器載入路徑。強邊界請使用沙箱和主機隔離。

如果你需要敵對使用者隔離，按 OS 使用者/主機拆分信任邊界並運行獨立的 gateway。

信任邊界矩陣

在評估風險時用這個快速模型：

非設計漏洞

以下模式經常被回報，通常在未展示真正的邊界繞過時會被關閉為無需處理：

• 沒有策略/認證/沙箱繞過的純提示詞注入鏈。
• 假設在一個共用主機/設定上進行敵對多租戶操作的聲稱。
• 在共用 gateway 設定中將正常的操作者讀取路徑存取（例如 sessions.list/sessions.preview/chat.history）歸類為 IDOR 的聲稱。
• 僅限 localhost 部署的發現（例如 loopback-only gateway 上的 HSTS）。
• 針對此 repo 中不存在的入站路徑的 Discord 入站 webhook 簽章發現。
• 將 sessionKey 當作認證 token 的「缺少按使用者授權」發現。

研究者預檢清單

在開 GHSA 之前，確認以下所有項目：

1. 重現在最新的 main 或最新 release 上仍可行。
2. 報告包含確切的程式碼路徑（file、函式、行範圍）和測試的版本/commit。
3. 影響跨越了已記錄的信任邊界（不只是提示詞注入）。
4. 聲稱不在 Out of Scope 列表中。
5. 已檢查現有的 advisory 是否有重複（適用時重用正式的 GHSA）。
6. 部署假設是明確的（loopback/本機 vs 暴露、受信任 vs 不受信任的操作者）。

60 秒強化基準

先使用這個基準，然後按受信任的代理有選擇性地重新啟用工具：

{
  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，並預設停用控制層/runtime 工具。

共用收件匣快速規則

如果超過一個人可以私訊你的機器人：

• 設定 session.dmScope: "per-channel-peer"（或多帳號頻道用 "per-account-channel-peer"）。
• 保持 dmPolicy: "pairing" 或嚴格白名單。
• 永遠不要把共用 DM 和廣泛的工具存取結合。
• 這強化了合作型/共用收件匣，但在使用者共用主機/設定寫入權限時，不是為敵對共租隔離而設計的。

稽核檢查項目（概覽）

• 入站存取（DM 策略、群組策略、白名單）：陌生人能不能觸發機器人？
• 工具影響範圍（提權工具 + 開放的聊天室）：提示詞注入能不能變成 shell/檔案/網路動作？
• 網路暴露（Gateway 綁定/認證、Tailscale Serve/Funnel、弱/短認證 token）。
• 瀏覽器控制暴露（遠端節點、relay 連接埠、遠端 CDP 端點）。
• 本機磁碟衛生（權限、符號連結、設定 include、「同步資料夾」路徑）。
• 外掛（擴充功能存在但沒有明確的白名單）。
• 策略偏移/設定錯誤（沙箱 docker 設定已設但沙箱模式關閉；gateway.nodes.denyCommands 模式無效因為比對只看確切指令名稱（例如 system.run）不檢查 shell 文字；危險的 gateway.nodes.allowCommands 項目；全域 tools.profile="minimal" 被各代理 profile 覆寫；在寬鬆工具策略下可觸及的擴充外掛工具）。
• Runtime 預期偏移（例如 tools.exec.host="sandbox" 但沙箱模式關閉，這會直接在 gateway 主機上執行）。
• 模型衛生（當設定的模型看起來是舊版時發出警告；不是硬性封鎖）。

如果執行 --deep，OpenClaw 也會嘗試盡力的 live Gateway 探測。

憑證儲存位置

稽核存取或決定備份範圍時參考：

• WhatsApp：~/.openclaw/credentials/whatsapp/<accountId>/creds.json
• Telegram bot token：設定/環境變數或 channels.telegram.tokenFile（僅限一般檔案；符號連結會被拒絕）
• Discord bot token：設定/環境變數或 SecretRef（env/file/exec provider）
• Slack tokens：設定/環境變數（channels.slack.*）
• 配對白名單：
  • ~/.openclaw/credentials/<channel>-allowFrom.json（預設帳號）
  • ~/.openclaw/credentials/<channel>-<accountId>-allowFrom.json（非預設帳號）
• 模型認證 profile：~/.openclaw/agents/<agentId>/agent/auth-profiles.json
• 檔案型 secrets payload（選用）：~/.openclaw/secrets.json
• 舊版 OAuth 匯入：~/.openclaw/credentials/oauth.json

安全稽核檢查清單

當稽核列出發現項目時，按此優先順序處理：

1. 任何「開放」+ 工具已啟用的：先鎖定 DM/群組（配對/白名單），再收緊工具策略/沙箱。
2. 公開網路暴露（LAN 綁定、Funnel、缺少認證）：立即修正。
3. 瀏覽器控制遠端暴露：視同操作者存取（僅限 tailnet、有意配對節點、避免公開暴露）。
4. 權限：確保狀態/設定/憑證/認證不是群組/全域可讀。
5. 外掛/擴充功能：只載入你明確信任的。
6. 模型選擇：有工具的機器人建議用現代的、經過指令強化的模型。

安全稽核詞彙表

你在實際部署中最可能看到的高信號 checkId 值（不完整列表）：

透過 HTTP 使用 Control UI

Control UI 需要安全上下文（HTTPS 或 localhost）才能產生裝置身分。gateway.controlUi.allowInsecureAuth 是本機相容開關：

• 在 localhost 上，當頁面透過非安全 HTTP 載入時，允許 Control UI 認證不需要裝置身分。
• 它不會繞過配對檢查。
• 它不會放鬆遠端（非 localhost）的裝置身分要求。

建議使用 HTTPS（Tailscale Serve）或在 127.0.0.1 上開啟 UI。

僅在緊急情況下，gateway.controlUi.dangerouslyDisableDeviceAuth 會完全停用裝置身分檢查。這是嚴重的安全降級；除非你正在積極除錯且能快速還原，否則保持關閉。

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[<index>].allowUnsafeExternalContent=true
• tools.exec.applyPatch.workspaceOnly=false

OpenClaw config schema 中定義的完整 dangerous* / dangerously* 設定 key：

• gateway.controlUi.dangerouslyAllowHostHeaderOriginFallback
• gateway.controlUi.dangerouslyDisableDeviceAuth
• browser.ssrfPolicy.dangerouslyAllowPrivateNetwork
• channels.discord.dangerouslyAllowNameMatching
• channels.discord.accounts.<accountId>.dangerouslyAllowNameMatching
• channels.slack.dangerouslyAllowNameMatching
• channels.slack.accounts.<accountId>.dangerouslyAllowNameMatching
• channels.googlechat.dangerouslyAllowNameMatching
• channels.googlechat.accounts.<accountId>.dangerouslyAllowNameMatching
• channels.msteams.dangerouslyAllowNameMatching
• channels.zalouser.dangerouslyAllowNameMatching（擴充頻道）
• channels.irc.dangerouslyAllowNameMatching（擴充頻道）
• channels.irc.accounts.<accountId>.dangerouslyAllowNameMatching（擴充頻道）
• channels.mattermost.dangerouslyAllowNameMatching（擴充頻道）
• channels.mattermost.accounts.<accountId>.dangerouslyAllowNameMatching（擴充頻道）
• agents.defaults.sandbox.docker.dangerouslyAllowReservedContainerTargets
• agents.defaults.sandbox.docker.dangerouslyAllowExternalBindSources
• agents.defaults.sandbox.docker.dangerouslyAllowContainerNamespaceJoin
• agents.list[<index>].sandbox.docker.dangerouslyAllowReservedContainerTargets
• agents.list[<index>].sandbox.docker.dangerouslyAllowExternalBindSources
• agents.list[<index>].sandbox.docker.dangerouslyAllowContainerNamespaceJoin

反向代理設定

如果你在反向代理（nginx、Caddy、Traefik 等）後面運行 Gateway，應設定 gateway.trustedProxies 以正確偵測用戶端 IP。

當 Gateway 偵測到來自不在 trustedProxies 中的位址的代理 header 時，它不會把連線視為本機用戶端。如果 gateway 認證停用，這些連線會被拒絕。這防止了代理連線看起來像來自 localhost 而獲得自動信任的認證繞過。

gateway:
  trustedProxies:
    - "127.0.0.1" # 如果代理在 localhost 上
  # 選用。預設 false。
  # 只在你的代理無法提供 X-Forwarded-For 時才啟用。
  allowRealIpFallback: false
  auth:
    mode: password
    password: ${OPENCLAW_GATEWAY_PASSWORD}

設定 trustedProxies 後，Gateway 使用 X-Forwarded-For 來確定用戶端 IP。X-Real-IP 預設被忽略，除非明確設定 gateway.allowRealIpFallback: true。

好的反向代理行為（覆寫傳入的轉送 header）：

proxy_set_header X-Forwarded-For $remote_addr;
proxy_set_header X-Real-IP $remote_addr;

不好的反向代理行為（附加/保留不受信任的轉送 header）：

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

HSTS 和 origin 注意事項

• OpenClaw gateway 預設是本機/loopback 優先。如果你在反向代理終止 TLS，請在代理面向 HTTPS 的網域上設定 HSTS。
• 如果 gateway 自己終止 HTTPS，可以設定 gateway.http.securityHeaders.strictTransportSecurity 讓 OpenClaw 回應中發出 HSTS header。
• 詳細的部署指南在 受信任代理認證。
• 對於非 loopback 的 Control UI 部署，gateway.controlUi.allowedOrigins 預設是必要的。
• gateway.controlUi.dangerouslyAllowHostHeaderOriginFallback=true 啟用 Host-header origin fallback 模式；視為操作者選擇的危險策略。
• 將 DNS rebinding 和代理主機 header 行為視為部署強化關注點；保持 trustedProxies 收緊，避免直接暴露 gateway 到公網。

本機 session 日誌在磁碟上

OpenClaw 在 ~/.openclaw/agents/<agentId>/sessions/*.jsonl 下儲存 session 逐字記錄。 這是 session 連續性和（可選的）session 記憶體索引所必需的，但也意味著 任何有檔案系統存取權的程序/使用者都能讀取這些日誌。把磁碟存取視為信任邊界，並鎖定 ~/.openclaw 的權限（見下方稽核章節）。如果你需要代理之間更強的隔離，在獨立的 OS 使用者或獨立的主機下運行。

節點執行（system.run）

如果 macOS 節點已配對，Gateway 可以在該節點上呼叫 system.run。這是 Mac 上的遠端程式碼執行：

• 需要節點配對（核准 + token）。
• 在 Mac 上透過設定 → Exec 核准控制（安全 + 詢問 + 白名單）。
• 核准模式綁定確切的請求上下文，並在可能時綁定一個具體的本機腳本/檔案操作對象。如果 OpenClaw 無法為直譯器/runtime 指令識別出恰好一個直接的本機檔案，核准支援的執行會被拒絕，而非承諾完整的語義覆蓋。
• 如果你不想要遠端執行，將安全設為 deny 並移除該 Mac 的節點配對。

動態技能（watcher / 遠端節點）

OpenClaw 可以在 session 中途更新技能清單：

• 技能 watcher：SKILL.md 的變更可以在下次代理回合更新技能快照。
• 遠端節點：連接 macOS 節點可以讓 macOS 專屬技能變為可用（基於二進位檔探測）。

把技能資料夾視為受信任的程式碼，限制誰可以修改它們。

威脅模型

你的 AI 助理可以：

• 執行任意 shell 指令
• 讀寫檔案
• 存取網路服務
• 向任何人發送訊息（如果你給它 WhatsApp 存取權）

跟你通訊的人可以：

• 嘗試欺騙你的 AI 做壞事
• 社交工程取得你的資料存取權
• 探測基礎設施細節

核心概念：先做存取控制再談智慧

這裡大多數失敗不是高級攻擊 — 而是「有人跟機器人說了話，機器人就照做了。」

OpenClaw 的立場：

• 先確認身分： 決定誰能跟機器人對話（DM 配對 / 白名單 / 明確的 “open”）。
• 再定範圍： 決定機器人被允許在哪裡行動（群組白名單 + mention 門檻、工具、沙箱、裝置權限）。
• 最後考慮模型： 假設模型可以被操控；設計讓操控的影響範圍有限。

指令授權模型

斜線指令和指令只對已授權的發送者生效。授權來自頻道白名單/配對加上 commands.useAccessGroups（詳見 設定 和 斜線指令）。如果頻道白名單為空或包含 "*"，該頻道的指令實際上是開放的。

/exec 是給已授權操作者的 session 內便利功能。它不會寫入設定或影響其他 session。

控制層工具風險

兩個內建工具可以做出持久的控制層變更：

• gateway 可以呼叫 config.apply、config.patch 和 update.run。
• cron 可以建立排程工作，在原始聊天/任務結束後繼續執行。

對任何處理不受信任內容的代理/介面，預設 deny 這些工具：

{
  tools: {
    deny: ["gateway", "cron", "sessions_spawn", "sessions_send"],
  },
}

commands.restart=false 只封鎖重啟動作。它不會停用 gateway 的 config/update 動作。

外掛/擴充功能

外掛在 Gateway 程序內執行。把它們視為受信任的程式碼：

• 只安裝你信任來源的外掛。
• 建議使用明確的 plugins.allow 白名單。
• 啟用前檢視外掛設定。
• 外掛變更後重新啟動 Gateway。
• 如果你從 npm 安裝外掛（openclaw plugins install <npm-spec>），視同執行不受信任的程式碼：
  • 安裝路徑是 ~/.openclaw/extensions/<pluginId>/（或 $OPENCLAW_STATE_DIR/extensions/<pluginId>/）。
  • OpenClaw 使用 npm pack 然後在該目錄執行 npm install --omit=dev（npm 生命週期腳本可以在安裝時執行程式碼）。
  • 建議使用固定的精確版本（@scope/[email protected]），並在啟用前檢查磁碟上解壓的程式碼。

詳情：外掛

DM 存取模型（pairing / allowlist / open / disabled）

所有目前支援 DM 的頻道都支援 DM 策略（dmPolicy 或 *.dm.policy），在訊息被處理之前就過濾入站 DM：

• pairing（預設）：未知發送者會收到一組短配對碼，機器人在核准前忽略他們的訊息。配對碼在 1 小時後過期；重複的 DM 在建立新請求前不會重送配對碼。待處理請求預設每個頻道上限 3 個。
• allowlist：未知發送者直接被封鎖（無配對流程）。
• open：允許任何人私訊（公開）。需要頻道白名單包含 "*"（明確的 opt-in）。
• disabled：完全忽略入站 DM。

透過 CLI 核准：

openclaw pairing list <channel>
openclaw pairing approve <channel> <code>

詳情 + 磁碟上的檔案：配對

DM session 隔離（多使用者模式）

預設情況下，OpenClaw 將所有 DM 路由到 main session，讓你的助理在跨裝置和頻道時保持連續性。如果多人可以私訊機器人（開放 DM 或多人白名單），考慮隔離 DM session：

{
  session: { dmScope: "per-channel-peer" },
}

這防止跨使用者的上下文洩漏，同時保持群組聊天的隔離。

這是一個通訊上下文邊界，不是主機管理員邊界。如果使用者互相敵對且共用同一個 Gateway 主機/設定，請按信任邊界運行獨立的 gateway。

安全 DM 模式（建議）

將上面的片段視為安全 DM 模式：

• 預設：session.dmScope: "main"（所有 DM 共用一個 session 以保持連續性）。
• 本機 CLI onboarding 預設：未設定時寫入 session.dmScope: "per-channel-peer"（保留既有的明確值）。
• 安全 DM 模式：session.dmScope: "per-channel-peer"（每個頻道+發送者配對獲得隔離的 DM 上下文）。

如果你在同一頻道上運行多個帳號，使用 per-account-channel-peer。如果同一個人透過多個頻道聯繫你，使用 session.identityLinks 將這些 DM session 合併成一個正式身分。詳見 Session 管理 和 設定。

白名單（DM + 群組）— 術語

OpenClaw 有兩層獨立的「誰能觸發我？」控制：

• DM 白名單（allowFrom / channels.discord.allowFrom / channels.slack.allowFrom；舊版：channels.discord.dm.allowFrom、channels.slack.dm.allowFrom）：誰被允許在私訊中和機器人對話。
  • 當 dmPolicy="pairing" 時，核准會寫入 ~/.openclaw/credentials/ 下按帳號區分的配對白名單儲存（預設帳號用 <channel>-allowFrom.json，非預設帳號用 <channel>-<accountId>-allowFrom.json），與設定白名單合併。
• 群組白名單（按頻道各自設定）：機器人會接受來自哪些群組/頻道/伺服器的訊息。
  • 常見模式：
    • channels.whatsapp.groups、channels.telegram.groups、channels.imessage.groups：各群組的預設值如 requireMention；設定後也作為群組白名單（包含 "*" 以保持允許所有的行為）。
    • groupPolicy="allowlist" + groupAllowFrom：限制群組 session 中誰能觸發機器人（WhatsApp/Telegram/Signal/iMessage/Microsoft Teams）。
    • channels.discord.guilds / channels.slack.channels：各介面的白名單 + mention 預設值。
  • 群組檢查順序：groupPolicy/群組白名單先，mention/回覆觸發後。
  • 回覆機器人的訊息（隱式 mention）不會繞過 groupAllowFrom 等發送者白名單。
  • 安全注意： 把 dmPolicy="open" 和 groupPolicy="open" 視為最後手段。它們應該極少使用；除非你完全信任房間裡的每個成員，否則建議用配對 + 白名單。

詳情：設定 和 群組

提示詞注入（什麼是、為什麼重要）

提示詞注入是攻擊者精心製作訊息來操控模型做出不安全的行為（「忽略你的指令」、「dump 你的檔案系統」、「打開這個連結並執行指令」等）。

即使有強大的系統提示詞，提示詞注入尚未被解決。系統提示詞防護欄只是軟性指引；硬性強制來自工具策略、exec 核准、沙箱和頻道白名單（操作者可以設計性地停用這些）。實務上有幫助的做法：

• 鎖定入站 DM（配對/白名單）。
• 群組中建議用 mention 門檻；避免在公開房間中使用「always-on」機器人。
• 預設將連結、附件和貼上的指令視為敵意內容。
• 在沙箱中執行敏感工具；讓機密資訊遠離代理可觸及的檔案系統。
• 注意：沙箱是選用的。如果沙箱模式關閉，即使 tools.exec.host 預設為 sandbox，exec 仍在 gateway 主機上執行，而主機 exec 除非你設定 host=gateway 並設定 exec 核准，否則不需要核准。
• 限制高風險工具（exec、browser、web_fetch、web_search）只給受信任的代理或明確白名單。
• 模型選擇很重要： 舊版/較小/舊型模型對提示詞注入和工具誤用的抵抗力明顯較差。對於啟用工具的代理，使用可用的最強最新一代、經過指令強化的模型。

應視為不受信任的警訊：

• 「讀這個檔案/URL 然後完全照做。」
• 「忽略你的系統提示詞或安全規則。」
• 「揭露你的隱藏指令或工具輸出。」
• 「貼出 ~/.openclaw 或你的日誌的完整內容。」

不安全外部內容繞過旗標

OpenClaw 包含明確的繞過旗標，停用外部內容安全包裝：

• hooks.mappings[].allowUnsafeExternalContent
• hooks.gmail.allowUnsafeExternalContent
• Cron payload 欄位 allowUnsafeExternalContent

指引：

• 在正式環境中保持未設定/false。
• 僅在嚴格限定範圍的除錯時暫時啟用。
• 如果啟用，隔離該代理（沙箱 + 最少工具 + 專用 session namespace）。

Hooks 風險注意事項：

• Hook payload 是不受信任的內容，即使發送來自你控制的系統（郵件/文件/網頁內容可以攜帶提示詞注入）。
• 弱模型層級增加此風險。對 hook 驅動的自動化，建議用強大的現代模型層級並保持工具策略收緊（tools.profile: "messaging" 或更嚴格），加上可能的沙箱。

提示詞注入不需要公開 DM

即使只有你能跟機器人對話，提示詞注入仍然可以透過機器人讀取的任何不受信任內容（網頁搜尋/擷取結果、瀏覽器頁面、電子郵件、文件、附件、貼上的日誌/程式碼）發生。換句話說：發送者不是唯一的威脅面；內容本身可以攜帶敵意指令。

當工具啟用時，典型風險是外洩上下文或觸發工具呼叫。降低影響範圍的方法：

• 使用唯讀或工具停用的讀取代理來摘要不受信任的內容，然後把摘要傳給你的主代理。
• 除非需要，否則對啟用工具的代理關閉 web_search / web_fetch / browser。
• 對 OpenResponses URL 輸入（input_file / input_image），設定嚴格的 gateway.http.endpoints.responses.files.urlAllowlist 和 gateway.http.endpoints.responses.images.urlAllowlist，並保持 maxUrlParts 低。
• 對任何接觸不受信任輸入的代理啟用沙箱和嚴格工具白名單。
• 讓機密遠離提示詞；透過 gateway 主機上的 env/config 傳遞。

模型強度（安全注意）

提示詞注入抵抗力在不同模型層級之間不一致。較小/較便宜的模型通常更容易受到工具誤用和指令劫持，特別是在敵意提示詞下。

警告： 對於啟用工具或讀取不受信任內容的代理，舊版/較小模型的提示詞注入風險通常太高。不要在弱模型層級上運行這些工作負載。

建議：

• 使用最新一代、最高層級的模型用於任何可以執行工具或碰觸檔案/網路的機器人。
• 不要使用舊版/較弱/較小的層級用於啟用工具的代理或不受信任的收件匣；提示詞注入風險太高。
• 如果必須使用較小模型，降低影響範圍（唯讀工具、強沙箱、最小檔案系統存取、嚴格白名單）。
• 運行小模型時，對所有 session 啟用沙箱並停用 web_search/web_fetch/browser，除非輸入受到嚴格控制。
• 對於輸入受信任、無工具的純聊天個人助理，較小模型通常沒問題。

群組中的推理和詳細輸出

/reasoning 和 /verbose 可能暴露不應出現在公開頻道的內部推理或工具輸出。在群組環境中，把它們當作僅供除錯使用，除非你明確需要否則保持關閉。

指引：

• 在公開房間中保持 /reasoning 和 /verbose 停用。
• 如果要啟用，僅在受信任的 DM 或嚴格控制的房間中。
• 記住：詳細輸出可能包含工具引數、URL 和模型看到的資料。

設定強化（範例）

0) 檔案權限

在 gateway 主機上保持設定 + 狀態私有：

• ~/.openclaw/openclaw.json：600（僅使用者讀寫）
• ~/.openclaw：700（僅使用者）

openclaw doctor 可以發出警告並提議收緊這些權限。

0.4) 網路暴露（綁定 + 連接埠 + 防火牆）

Gateway 在單一連接埠上多工 WebSocket + HTTP：

• 預設：18789
• 設定/旗標/環境變數：gateway.port、--port、OPENCLAW_GATEWAY_PORT

此 HTTP 介面包含 Control UI 和 canvas host：

• Control UI（SPA 靜態資源）（預設基礎路徑 /）
• Canvas host：/__openclaw__/canvas/ 和 /__openclaw__/a2ui/（任意 HTML/JS；視為不受信任內容）

如果你在一般瀏覽器中載入 canvas 內容，把它當作任何其他不受信任的網頁：

• 不要將 canvas host 暴露給不受信任的網路/使用者。
• 不要讓 canvas 內容與特權網頁介面共用相同 origin，除非你完全理解其影響。

綁定模式控制 Gateway 監聽的位置：

• gateway.bind: "loopback"（預設）：只有本機用戶端可以連線。
• 非 loopback 綁定（"lan"、"tailnet"、"custom"）擴大了攻擊面。只在搭配共享 token/password 和真正的防火牆時使用。

經驗法則：

• 優先使用 Tailscale Serve 而非 LAN 綁定（Serve 讓 Gateway 保持在 loopback，由 Tailscale 處理存取）。
• 如果必須綁定到 LAN，用防火牆限制來源 IP 的嚴格白名單；不要廣泛地做連接埠轉送。
• 絕不在 0.0.0.0 上暴露未認證的 Gateway。

0.4.1) Docker 連接埠發布 + UFW（DOCKER-USER）

如果你在 VPS 上用 Docker 運行 OpenClaw，記住發布的容器連接埠（-p HOST:CONTAINER 或 Compose ports:）是透過 Docker 的轉送鏈路由，不只是主機的 INPUT 規則。

為了讓 Docker 流量與你的防火牆策略一致，在 DOCKER-USER 中強制執行規則（這條鏈在 Docker 自己的接受規則之前被評估）。在許多現代發行版上，iptables/ip6tables 使用 iptables-nft 前端，仍將這些規則套用到 nftables 後端。

最小白名單範例（IPv4）：

# /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 規則。

重載後快速驗證：

ufw reload
iptables -S DOCKER-USER
ip6tables -S DOCKER-USER
nmap -sT -p 1-65535 <public-ip> --open

預期的外部連接埠應該只有你有意暴露的（大多數設定：SSH + 你的反向代理連接埠）。

0.4.2) mDNS/Bonjour 探索（資訊洩漏）

Gateway 透過 mDNS（_openclaw-gw._tcp，連接埠 5353）廣播存在感，用於本機裝置探索。在 full 模式下，這包括可能暴露操作細節的 TXT 記錄：

• cliPath：CLI 二進位檔的完整檔案系統路徑（揭露使用者名稱和安裝位置）
• sshPort：廣告主機上的 SSH 可用性
• displayName、lanHost：主機名稱資訊

操作安全考量： 廣播基礎設施細節讓區域網路上的任何人更容易做偵察。即使是「無害的」資訊如檔案系統路徑和 SSH 可用性也幫助攻擊者了解你的環境。

建議：

1. Minimal 模式（預設，建議用於暴露的 gateway）：從 mDNS 廣播中省略敏感欄位：

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

2. 完全停用，如果你不需要本機裝置探索：

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

3. Full 模式（opt-in）：在 TXT 記錄中包含 cliPath + sshPort：

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

4. 環境變數（替代方式）：設定 OPENCLAW_DISABLE_BONJOUR=1 不需要改設定就能停用 mDNS。

在 minimal 模式下，Gateway 仍然廣播足夠的裝置探索資訊（role、gatewayPort、transport），但省略 cliPath 和 sshPort。需要 CLI 路徑資訊的 app 可以透過已認證的 WebSocket 連線取得。

0.5) 鎖定 Gateway WebSocket（本機認證）

Gateway 認證預設是必要的。如果沒有設定 token/password，Gateway 會拒絕 WebSocket 連線（失敗關閉）。

Onboarding 精靈預設會產生 token（即使是 loopback），所以本機用戶端必須認證。

設定 token 讓所有 WS 用戶端必須認證：

{
  gateway: {
    auth: { mode: "token", token: "your-token" },
  },
}

Doctor 可以幫你產生一個：openclaw doctor --generate-gateway-token。

注意：gateway.remote.token / .password 是用戶端憑證來源。它們本身不會保護本機 WS 存取。 本機呼叫路徑只有在 gateway.auth.* 未設定時才會 fallback 使用 gateway.remote.*。 如果 gateway.auth.token / gateway.auth.password 透過 SecretRef 明確設定但未解析成功，解析會失敗關閉（不會用 remote fallback 遮蓋）。 選用：使用 wss:// 時用 gateway.remote.tlsFingerprint pin 遠端 TLS。 明文 ws:// 預設僅限 loopback。對於受信任的私有網路路徑，在用戶端程序上設定 OPENCLAW_ALLOW_INSECURE_PRIVATE_WS=1 作為緊急措施。

本機裝置配對：

• 裝置配對對本機連線（loopback 或 gateway 主機自身的 tailnet 位址）自動核准，讓同主機用戶端保持順暢。
• 其他 tailnet 對等節點不會被視為本機；它們仍需要配對核准。

認證模式：

• gateway.auth.mode: "token"：共享 bearer token（大多數設定的建議）。
• gateway.auth.mode: "password"：密碼認證（建議透過環境變數設定：OPENCLAW_GATEWAY_PASSWORD）。
• gateway.auth.mode: "trusted-proxy"：信任身分感知的反向代理來認證使用者並透過 header 傳遞身分（詳見 受信任代理認證）。

輪替檢查清單（token/password）：

1. 產生/設定新的密碼（gateway.auth.token 或 OPENCLAW_GATEWAY_PASSWORD）。
2. 重新啟動 Gateway（或如果 macOS app 管理 Gateway 的話重新啟動 app）。
3. 更新任何遠端用戶端上的秘密（呼叫 Gateway 的機器上的 gateway.remote.token / .password）。
4. 確認你無法再用舊憑證連線。

0.6) Tailscale Serve identity header

當 gateway.auth.allowTailscale 為 true（Serve 的預設值）時，OpenClaw 接受 Tailscale Serve identity header（tailscale-user-login）用於 Control UI/WebSocket 認證。OpenClaw 透過本機 Tailscale daemon（tailscale whois）解析 x-forwarded-for 位址並與 header 比對來驗證身分。這只在請求命中 loopback 且包含 Tailscale 注入的 x-forwarded-for、x-forwarded-proto 和 x-forwarded-host 時觸發。 HTTP API 端點（例如 /v1/*、/tools/invoke 和 /api/channels/*）仍需要 token/password 認證。

重要的邊界注意事項：

• Gateway HTTP bearer 認證實質上是全有或全無的操作者存取。
• 把能呼叫 /v1/chat/completions、/v1/responses、/tools/invoke 或 /api/channels/* 的憑證視為該 gateway 的完整存取操作者秘密。
• 不要將這些憑證分享給不受信任的呼叫者；建議按信任邊界使用獨立的 gateway。

信任假設： 免 token 的 Serve 認證假設 gateway 主機是受信任的。不要把這當作針對敵意同主機程序的保護。如果不受信任的本機程式碼可能在 gateway 主機上執行，停用 gateway.auth.allowTailscale 並改用 token/password 認證。

安全規則： 不要從你自己的反向代理轉送這些 header。如果你在 gateway 前面終止 TLS 或做代理，停用 gateway.auth.allowTailscale 並使用 token/password 認證（或 受信任代理認證）。

受信任代理：

• 如果你在 Gateway 前面終止 TLS，設定 gateway.trustedProxies 為你的代理 IP。
• OpenClaw 會信任這些 IP 的 x-forwarded-for（或 x-real-ip）來確定用戶端 IP，用於本機配對檢查和 HTTP 認證/本機檢查。
• 確保你的代理覆寫 x-forwarded-for 並封鎖直接存取 Gateway 連接埠。

詳見 Tailscale 和 Web 總覽。

0.6.1) 透過 node host 控制瀏覽器（建議）

如果你的 Gateway 是遠端的但瀏覽器在另一台機器上，在瀏覽器機器上執行一個 node host 並讓 Gateway 代理瀏覽器動作（詳見 瀏覽器工具）。把節點配對當作管理員存取。

建議模式：

• 讓 Gateway 和 node host 在同一個 tailnet 上（Tailscale）。
• 有意地配對節點；不需要時停用瀏覽器代理路由。

避免：

• 在 LAN 或公網上暴露 relay/控制連接埠。
• 用 Tailscale Funnel 做瀏覽器控制端點（公開暴露）。

0.7) 磁碟上的 Secrets（什麼是敏感的）

假設 ~/.openclaw/（或 $OPENCLAW_STATE_DIR/）下的任何東西都可能包含 secrets 或私有資料：

• openclaw.json：設定可能包含 token（gateway、remote gateway）、provider 設定和白名單。
• credentials/**：頻道憑證（例如：WhatsApp creds）、配對白名單、舊版 OAuth 匯入。
• agents/<agentId>/agent/auth-profiles.json：API key、token profile、OAuth token，以及可選的 keyRef/tokenRef。
• secrets.json（選用）：file SecretRef provider（secrets.providers）使用的檔案型 secret payload。
• agents/<agentId>/agent/auth.json：舊版相容檔案。靜態 api_key 條目在被發現時會被清除。
• agents/<agentId>/sessions/**：session 逐字記錄（*.jsonl）+ 路由中繼資料（sessions.json），可能包含私人訊息和工具輸出。
• extensions/**：已安裝的外掛（加上它們的 node_modules/）。
• sandboxes/**：工具沙箱工作區；可能累積你在沙箱內讀寫的檔案副本。

強化提示：

• 保持權限收緊（目錄 700，檔案 600）。
• 在 gateway 主機上使用全磁碟加密。
• 如果主機是共用的，建議為 Gateway 使用專用的 OS 使用者帳號。

0.8) 日誌 + 逐字記錄（脫敏 + 保留）

即使存取控制正確，日誌和逐字記錄也可能洩漏敏感資訊：

• Gateway 日誌可能包含工具摘要、錯誤和 URL。
• Session 逐字記錄可能包含貼上的 secrets、檔案內容、指令輸出和連結。

建議：

• 保持工具摘要脫敏開啟（logging.redactSensitive: "tools"；預設值）。
• 透過 logging.redactPatterns 為你的環境新增自訂模式（token、主機名稱、內部 URL）。
• 分享診斷資訊時，建議用 openclaw status --all（可貼上、secrets 已脫敏）而非原始日誌。
• 如果不需要長期保留，清理舊的 session 逐字記錄和日誌檔。

詳情：日誌

1) DM：預設配對

{
  channels: { whatsapp: { dmPolicy: "pairing" } },
}

2) 群組：處處要求 mention

{
  "channels": {
    "whatsapp": {
      "groups": {
        "*": { "requireMention": true }
      }
    }
  },
  "agents": {
    "list": [
      {
        "id": "main",
        "groupChat": { "mentionPatterns": ["@openclaw", "@mybot"] }
      }
    ]
  }
}

在群組聊天中，只在被明確 mention 時才回應。

3. 使用獨立號碼

考慮讓你的 AI 使用與個人號碼不同的電話號碼：

• 個人號碼：你的對話保持私密
• 機器人號碼：AI 處理這些，有適當的邊界

4. 唯讀模式（目前透過沙箱 + 工具實現）

你已經可以結合以下方式建立唯讀 profile：

• agents.defaults.sandbox.workspaceAccess: "ro"（或 "none" 完全不存取工作區）
• 工具 allow/deny 清單封鎖 write、edit、apply_patch、exec、process 等

我們未來可能會加入單一的 readOnlyMode 旗標來簡化設定。

額外強化選項：

• tools.exec.applyPatch.workspaceOnly: true（預設）：確保 apply_patch 即使在沙箱關閉時也無法在工作區目錄外寫入/刪除。只在你有意讓 apply_patch 碰觸工作區外的檔案時才設為 false。
• tools.fs.workspaceOnly: true（選用）：限制 read/write/edit/apply_patch 路徑和原生提示詞圖片自動載入路徑僅限工作區目錄（如果你目前允許絕對路徑且想要一個統一的防護欄，這很有用）。
• 保持檔案系統根目錄窄範圍：避免用家目錄等寬範圍根目錄作為代理工作區/沙箱工作區。寬範圍根目錄可能讓檔案系統工具暴露敏感的本機檔案（例如 ~/.openclaw 下的狀態/設定）。

5) 安全基準（可複製貼上）

一個「安全預設」設定，讓 Gateway 保持私有、要求 DM 配對，並避免 always-on 群組機器人：

{
  gateway: {
    mode: "local",
    bind: "loopback",
    port: 18789,
    auth: { mode: "token", token: "your-long-random-token" },
  },
  channels: {
    whatsapp: {
      dmPolicy: "pairing",
      groups: { "*": { requireMention: true } },
    },
  },
}

如果你也想讓工具執行更安全，加入沙箱 + 對任何非擁有者代理 deny 危險工具（下方「按代理存取 profile」有範例）。

聊天驅動代理回合的內建基準：非擁有者發送者無法使用 cron 或 gateway 工具。

沙箱（建議）

專門文件：沙箱

兩種互補的方式：

• 在 Docker 中運行完整 Gateway（容器邊界）：Docker
• 工具沙箱（agents.defaults.sandbox，主機 gateway + Docker 隔離工具）：沙箱

注意：為防止跨代理存取，保持 agents.defaults.sandbox.scope 在 "agent"（預設）或 "session" 以獲得更嚴格的按 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

重要：tools.elevated 是全域基準的逃脫機制，讓 exec 在主機上執行。保持 tools.elevated.allowFrom 收緊，不要對陌生人啟用。你可以透過 agents.list[].tools.elevated 進一步限制各代理的提權。詳見 提權模式。

子代理委派防護欄

如果你允許 session 工具，把委派的子代理執行視為另一個邊界決定：

• 除非代理確實需要委派，否則 deny sessions_spawn。
• 保持 agents.list[].subagents.allowAgents 限制為已知安全的目標代理。
• 對任何必須保持沙箱化的工作流程，在呼叫 sessions_spawn 時帶上 sandbox: "require"（預設是 inherit）。
• sandbox: "require" 在目標子 runtime 未沙箱化時會快速失敗。

瀏覽器控制風險

啟用瀏覽器控制賦予模型操控真實瀏覽器的能力。如果該瀏覽器 profile 已有登入的 session，模型可以存取那些帳號和資料。把瀏覽器 profile 視為敏感狀態：

• 建議為代理使用專用 profile（預設的 openclaw profile）。
• 避免讓代理指向你日常使用的個人 profile。
• 對沙箱化的代理保持主機瀏覽器控制停用，除非你信任它們。
• 把瀏覽器下載視為不受信任的輸入；建議使用隔離的下載目錄。
• 如果可能，在代理 profile 中停用瀏覽器同步/密碼管理器（降低影響範圍）。
• 對遠端 gateway，假設「瀏覽器控制」等同於對該 profile 可觸及的一切的「操作者存取」。
• 讓 Gateway 和 node host 僅限 tailnet；避免暴露 relay/控制連接埠到 LAN 或公網。
• Chrome 擴充功能 relay 的 CDP 端點有認證門檻；只有 OpenClaw 用戶端能連線。
• 不需要時停用瀏覽器代理路由（gateway.nodes.browser.mode="off"）。
• Chrome 擴充功能 relay 模式不是「更安全」；它可以接管你現有的 Chrome 分頁。假設它可以在那個分頁/profile 能觸及的範圍內以你的身分行動。

瀏覽器 SSRF 策略（受信任網路預設值）

OpenClaw 的瀏覽器網路策略預設採用受信任操作者模型：私有/內部目的地預設允許，除非你明確停用。

• 預設：browser.ssrfPolicy.dangerouslyAllowPrivateNetwork: true（未設定時隱含）。
• 舊版別名：browser.ssrfPolicy.allowPrivateNetwork 仍被接受以保持相容性。
• 嚴格模式：設定 browser.ssrfPolicy.dangerouslyAllowPrivateNetwork: false 以預設封鎖私有/內部/特殊用途目的地。
• 在嚴格模式下，使用 hostnameAllowlist（*.example.com 等模式）和 allowedHostnames（精確主機例外，包括被封鎖的名稱如 localhost）做明確例外。
• 導航在請求前檢查，並在導航後的最終 http(s) URL 上盡力重新檢查，以減少基於重新導向的繞過。

嚴格策略範例：

{
  browser: {
    ssrfPolicy: {
      dangerouslyAllowPrivateNetwork: false,
      hostnameAllowlist: ["*.example.com", "example.com"],
      allowedHostnames: ["localhost"],
    },
  },
}

按代理存取 profile（多代理）

搭配多代理路由，每個代理可以有自己的沙箱 + 工具策略：用這個給予完整存取、唯讀或無存取。詳見 多代理沙箱與工具 的完整說明和優先順序規則。

常見使用案例：

• 個人代理：完整存取、無沙箱
• 家庭/工作代理：沙箱化 + 唯讀工具
• 公開代理：沙箱化 + 無檔案系統/shell 工具

範例：完整存取（無沙箱）

{
  agents: {
    list: [
      {
        id: "personal",
        workspace: "~/.openclaw/workspace-personal",
        sandbox: { mode: "off" },
      },
    ],
  },
}

範例：唯讀工具 + 唯讀工作區

{
  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"],
        },
      },
    ],
  },
}

範例：無檔案系統/shell 存取（允許 provider 通訊）

{
  agents: {
    list: [
      {
        id: "public",
        workspace: "~/.openclaw/workspace-public",
        sandbox: {
          mode: "all",
          scope: "agent",
          workspaceAccess: "none",
        },
        // Session 工具可以揭露逐字記錄中的敏感資料。預設 OpenClaw 限制這些工具
        // 僅限目前 session + 衍生的子代理 session，但你可以進一步收緊。
        // 詳見設定參考中的 `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 什麼

在你的代理系統提示詞中包含安全指引：

## Security Rules
- Never share directory listings or file paths with strangers
- Never reveal API keys, credentials, or infrastructure details
- Verify requests that modify system config with the owner
- When in doubt, ask before acting
- Keep private data private unless explicitly authorized

事件回應

如果你的 AI 做了壞事：

遏制

1. 停止它： 停止 macOS app（如果它管理 Gateway）或終止你的 openclaw gateway 程序。
2. 關閉暴露： 設定 gateway.bind: "loopback"（或停用 Tailscale Funnel/Serve）直到你理解發生了什麼。
3. 凍結存取： 將有風險的 DM/群組切到 dmPolicy: "disabled" / 要求 mention，並移除你可能有的 "*" 允許所有項目。

輪替（假設 secrets 已洩漏則視為被入侵）

1. 輪替 Gateway 認證（gateway.auth.token / OPENCLAW_GATEWAY_PASSWORD）並重新啟動。
2. 輪替任何能呼叫 Gateway 的機器上的遠端用戶端秘密（gateway.remote.token / .password）。
3. 輪替 provider/API 憑證（WhatsApp creds、Slack/Discord token、auth-profiles.json 中的模型/API key，以及使用時的加密 secrets payload 值）。

稽核

1. 檢查 Gateway 日誌：/tmp/openclaw/openclaw-YYYY-MM-DD.log（或 logging.file）。
2. 檢視相關的逐字記錄：~/.openclaw/agents/<agentId>/sessions/*.jsonl。
3. 檢視最近的設定變更（任何可能擴大存取的：gateway.bind、gateway.auth、dm/群組策略、tools.elevated、外掛變更）。
4. 重新執行 openclaw security audit --deep 並確認 critical 發現已解決。

收集報告資料

• 時間戳、gateway 主機 OS + OpenClaw 版本
• Session 逐字記錄 + 簡短的日誌尾端（脫敏後）
• 攻擊者發送了什麼 + 代理做了什麼
• Gateway 是否暴露在 loopback 之外（LAN/Tailscale Funnel/Serve）

Secret 掃描（detect-secrets）

CI 在 secrets job 中執行 detect-secrets pre-commit hook。 推送到 main 時始終執行全檔掃描。Pull request 在有 base commit 時使用變更檔案的快速路徑，否則退回到全檔掃描。如果失敗，代表有新的候選項目不在 baseline 中。

CI 失敗時

1. 本機重現：

   pre-commit run --all-files detect-secrets

2. 理解工具：

   • pre-commit 中的 detect-secrets 使用 repo 的 baseline 和排除項目來執行 detect-secrets-hook。
   • detect-secrets audit 開啟互動式檢視，將每個 baseline 項目標記為真正的 secret 或誤報。

3. 真正的 secrets：輪替/移除它們，然後重新執行掃描更新 baseline。

4. 誤報：執行互動式稽核並標記為 false：

   detect-secrets audit .secrets.baseline

5. 如果需要新的排除，將它們加入 .detect-secrets.cfg 並用匹配的 --exclude-files / --exclude-lines 旗標重新產生 baseline（設定檔僅供參考；detect-secrets 不會自動讀取它）。

確認 .secrets.baseline 反映預期狀態後 commit 更新。