安全性

範圍：個人助理安全模型

• 支援：每個閘道一個使用者／信任邊界（每個邊界最好使用一個作業系統使用者／主機／VPS）。
• 不支援：彼此不信任或具有敵意的使用者共用一個閘道／代理程式。
• 敵對使用者隔離需要使用不同的閘道（最好也使用不同的作業系統使用者／主機）。
• 如果數名不受信任的使用者都能向同一個啟用工具的代理程式傳送訊息，他們就會共用該代理程式獲委派的工具權限。
• 如果有人能修改閘道主機的狀態／設定（~/.openclaw，包括 openclaw.json），請將其視為受信任的操作者。
• 在同一個閘道內，經過驗證的操作者存取權是受信任的控制平面角色，而不是每位使用者各自的租戶角色。
• sessionKey（工作階段 ID、標籤）是路由選擇器，而不是授權權杖。

要託管多個使用者或組織嗎？請為每個租戶執行一個隔離的閘道單元，而不要共用閘道。請參閱多租戶託管。

變更遠端存取、私訊政策、反向代理或公開暴露之前，請先依照閘道暴露執行手冊進行檢查，將其作為事前檢查／復原檢查清單。

openclaw security audit

每次變更設定後或暴露網路介面之前，請執行以下命令：

openclaw security auditopenclaw security audit --deep    # 嘗試即時探查閘道openclaw security audit --fix     # 套用安全的修正措施openclaw security audit --json

--fix 的範圍刻意限縮：它會將開放的群組政策切換為允許清單、還原 logging.redactSensitive: "tools"、收緊狀態／設定／引入檔案的權限（600 檔案、700 目錄），並在 Windows 上使用 ACL 重設，而不是 POSIX chmod。

稽核檢查的內容（概要）

• 輸入存取－私訊／群組政策、允許清單：陌生人能否觸發機器人？
• 工具影響範圍－提升權限的工具＋開放聊天室：提示詞注入是否可能演變成 Shell／檔案／網路操作？
• 執行檔案系統偏移－拒絕會變更檔案系統的工具，但 exec/process 在沒有沙箱限制的情況下仍可使用。
• 執行核准偏移－security="full"、autoAllowSkills、缺少 strictInlineEval 的直譯器允許清單。僅有 security="full" 是廣泛的安全態勢警告，而不是錯誤存在的證據－這是受信任個人助理部署所選用的預設值；只有在你的威脅模型需要核准或允許清單防護機制時才應收緊。
• 網路暴露－閘道繫結／驗證、Tailscale Serve/Funnel、強度不足／過短的驗證權杖。
• 瀏覽器控制暴露－遠端節點、轉送連接埠、遠端 CDP 端點。
• 本機磁碟衛生－權限、符號連結、設定引入、同步資料夾路徑。
• 外掛－在沒有明確允許清單的情況下載入。
• 政策偏移－已設定沙箱 Docker 設定，但沙箱模式關閉；看似有效、實際上只會比對確切命令 ID（例如 system.run），而不會比對承載資料內 Shell 文字的 gateway.nodes.denyCommands 項目；危險的 gateway.nodes.allowCommands 項目；全域 tools.profile="minimal" 遭個別代理程式覆寫；外掛擁有的工具可在寬鬆政策下使用。
• 執行階段預期偏移－在 tools.exec.host 現已預設為 auto 時，仍假設隱含執行表示 sandbox；或在沙箱模式關閉時設定 tools.exec.host="sandbox"。
• 模型衛生－針對設定中的舊版模型發出警告（柔性警告，而非強制封鎖）。

每項發現都有結構化的 checkId（例如 gateway.bind_no_auth、tools.exec.security_full_configured）。前綴：fs.*（權限）、gateway.*（繫結／驗證／Tailscale／控制介面／受信任代理）、hooks.*/browser.*/sandbox.*/tools.exec.*（各介面的強化）、plugins.*/skills.*（供應鏈）、security.exposure.*（存取政策 × 工具影響範圍）。包含嚴重性與自動修正支援的完整目錄：安全稽核檢查。另請參閱形式驗證。

分類處理發現時的優先順序

1. 任何「開放」且已啟用工具的情況：先鎖定私訊／群組（配對／允許清單），再收緊工具政策／沙箱。
2. 公開網路暴露（LAN 繫結、Funnel、缺少驗證）：立即修正。
3. 瀏覽器控制的遠端暴露：將其視同操作者存取權（僅限 tailnet、刻意配對節點、不得公開暴露）。
4. 權限：狀態／設定／認證資訊／驗證資訊不得允許群組／所有人讀取。
5. 外掛：只載入你明確信任的外掛。
6. 模型選擇：任何具有工具的機器人都應優先採用現代且經過指令強化的模型。

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 } } },  },}

讓閘道僅限本機存取、隔離私訊，並預設停用控制平面／執行階段工具。之後再為每個受信任的代理程式選擇性地重新啟用工具。

聊天驅動代理程式回合的內建基準：無論設定如何，非擁有者傳送者都無法使用 cron 或 gateway 工具。

信任邊界矩陣

用於分類處理風險報告的快速模型：

設計上不屬於漏洞

閘道與節點信任

將閘道與節點視為同一個操作者信任網域中角色不同的部分：

• 閘道：控制平面與政策介面（gateway.auth、工具政策、路由）。
• 節點：與該閘道配對的遠端執行介面（命令、裝置操作、主機本機能力）。
• 通過閘道驗證的呼叫者在閘道範圍內受信任；配對後，節點操作會被視為該節點上的受信任操作者操作。請參閱操作者範圍。
• 使用共用閘道權杖／密碼通過驗證的直接迴路介面後端用戶端，可在不提供使用者裝置身分的情況下進行內部控制平面 RPC。這並非遠端或瀏覽器配對繞過－網路用戶端、節點用戶端、裝置權杖用戶端及明確的裝置身分仍須經過配對與範圍升級強制措施。
• 執行核准（允許清單＋詢問）是操作者意圖的防護機制，而不是惡意多租戶隔離。它們會繫結確切的要求內容脈絡，以及盡力比對直接的本機檔案運算元；並不會在語意上為每個執行階段／直譯器載入器路徑建立模型。若需要強健邊界，請使用沙箱與主機隔離。
• 受信任單一操作者預設值：gateway/node 上的主機執行不需要核准提示即可允許（security="full"、ask="off"）。這是刻意設計的使用者體驗，本身並非漏洞。

若要隔離敵對使用者，請依作業系統使用者／主機分隔信任邊界，並執行不同的閘道。

威脅模型

你的 AI 助理可以執行任意 shell 命令、讀寫檔案、存取網路服務，以及傳送訊息給任何人（若已授予頻道存取權）。傳訊息給它的人可能會試圖誘騙它做出惡意行為、透過社交工程取得你的資料存取權，或探查基礎架構的詳細資訊。

這裡的大多數失敗並非奇特的漏洞利用，而是「有人傳訊息給機器人，而機器人照對方的要求做了」。OpenClaw 的立場依序如下：

1. 身分優先 — 決定誰可以與機器人交談（私訊配對／允許清單／明確設為「開放」）。
2. 接著限制範圍 — 決定機器人可以在哪裡採取行動（群組允許清單 + 提及閘控、工具、沙箱、裝置權限）。
3. 最後才是模型 — 假設模型可能遭到操控；設計系統時，讓操控造成的影響範圍受限。

私訊存取：配對、允許清單、開放、停用

每個支援私訊的頻道都支援 dmPolicy（或 *.dm.policy），在處理訊息前對傳入私訊進行閘控：

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

詳細資訊與磁碟上的檔案：配對

請將 dmPolicy="open" 和 groupPolicy="open" 視為最後手段；除非你完全信任聊天室中的每位成員，否則應優先使用配對 + 允許清單。

允許清單（兩層）

• 私訊允許清單（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；設定後也會作為群組允許清單（若要保留全部允許的行為，請包含 "*"）。使用 agents.list[].groupChat.mentionPatterns 自訂提及觸發詞（例如 ["@openclaw", "@mybot"]），讓 requireMention 依你自己的機器人名稱進行閘控。
  • groupPolicy="allowlist" + groupAllowFrom：限制誰可以在群組工作階段中觸發機器人（WhatsApp/Telegram/Signal/iMessage/Microsoft Teams）。
  • channels.discord.guilds / channels.slack.channels：各介面的允許清單 + 提及預設值。
  • 檢查順序：先檢查 groupPolicy/群組允許清單，再檢查提及／回覆啟用條件。回覆機器人訊息（隱含提及）不會略過 groupAllowFrom。

詳細資訊：設定和群組

私訊工作階段隔離（多使用者模式）

OpenClaw 預設會將所有私訊路由至主要工作階段，以維持跨裝置的連續性。如果有多人可以私訊機器人（開放私訊或多人允許清單），請隔離私訊工作階段：

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

session.dmScope 值：

本機命令列介面新手引導會在未設定時寫入 session.dmScope: "per-channel-peer"，並保留任何明確設定的現有值。

這是訊息情境邊界，而非主機管理員邊界。如果使用者彼此敵對，卻共用相同的閘道主機／設定，請針對每個信任邊界執行獨立的閘道。

如果同一人透過多個頻道與你聯絡，請使用 session.identityLinks 將這些私訊工作階段合併為一個標準身分。請參閱工作階段管理和設定。

情境可見性與觸發授權

這是兩個不同的概念：

• 觸發授權：誰可以觸發代理程式（dmPolicy、groupPolicy、允許清單、提及閘控）。
• 情境可見性：哪些補充情境會傳送給模型（回覆內文、引用文字、討論串記錄、轉寄的中繼資料）。

contextVisibility 控制後者：

• "all"（預設值）：依接收時的原樣保留補充情境。
• "allowlist"：將補充情境篩選為通過有效允許清單檢查的傳送者。
• "allowlist_quote"：與 allowlist 相同，但仍會保留一則明確引用的回覆。

可針對每個頻道或每個聊天室／對話設定，請參閱群組。若報告僅指出「模型可以看到來自不在允許清單中之傳送者的引用／歷史文字」，這屬於可透過 contextVisibility 處理的強化問題，本身並非驗證或沙箱繞過；具安全影響的報告仍須證明存在信任邊界繞過。

提示注入

攻擊者會精心設計訊息，操控模型採取不安全的行動（「忽略你的指示」、「傾印你的檔案系統」、「開啟這個連結並執行命令」）。僅靠系統提示的防護措施無法解決提示注入問題，因為這些只是軟性指引；硬性強制措施來自工具政策、執行核准、沙箱和頻道允許清單（營運者仍可依設計選擇停用這些措施）。

提示注入不需要公開私訊：即使只有你能傳訊息給機器人，它讀取的任何不受信任內容（網頁搜尋／擷取結果、瀏覽器頁面、電子郵件、文件、附件、貼上的記錄／程式碼）都可能夾帶惡意指示。內容本身就是攻擊面，而不只是傳送者。

應視為不受信任的警訊：

• 「讀取這個檔案／URL，並完全照其中的內容操作。」
• 「忽略你的系統提示或安全規則。」
• 「揭露你的隱藏指示或工具輸出。」
• 「貼上 ~/.openclaw 或你的記錄的完整內容。」

實務上有幫助的措施：

• 嚴格限制傳入私訊（配對／允許清單）；在群組中優先使用提及閘控；避免在公開聊天室中使用永遠啟用的機器人。
• 預設將連結、附件和貼上的指示視為惡意內容。
• 在沙箱中執行敏感工具；不要將機密資訊放在代理程式可存取的檔案系統中。沙箱為選擇性啟用：若沙箱模式關閉，隱含的 host=auto 會解析為閘道主機，而明確指定的 host=sandbox 仍會以關閉方式失敗（沒有可用的沙箱執行階段）。設定 host=gateway，以在設定中明確指定此行為。
• 將高風險工具（exec、browser、web_fetch、web_search）限制為僅供受信任的代理程式或明確允許清單使用。
• 如果將直譯器（python、node、ruby、perl、php、lua、osascript）加入允許清單，請啟用 tools.exec.strictInlineEval，讓行內求值形式（-c、-e 等）仍需明確核准。在允許清單模式中，任何 heredoc 區段（<<）一律需要審查者或明確核准，不論其引號形式為何；允許清單中的命令無法利用 heredoc 內文繞過允許清單審查。
• 使用唯讀或停用工具的讀取代理程式來摘要不受信任的內容，再將摘要傳遞給主要代理程式，以縮小影響範圍。
• 對於 Gmail 網路鉤子，內建的每則訊息工作階段會隔離對話情境，但不會移除目標代理程式的工具或工作區權限。將不受信任的郵件路由至專用的讀取代理程式、套用各代理程式的沙箱與工具限制，並使用 tools.agentToAgent 限制任何移交給主要代理程式的內容。請參閱 Gmail 整合。
• 除非確有需要，否則對已啟用工具的代理程式關閉 web_search / web_fetch / browser。
• 對於 OpenResponses URL 輸入（input_file / input_image），請設定嚴格的 gateway.http.endpoints.responses.files.urlAllowlist / images.urlAllowlist，並將 maxUrlParts 保持在低值（空的允許清單視為未設定）。使用 files.allowUrl: false / images.allowUrl: false 完全停用 URL 擷取。
• 不要在提示中放入機密資訊；改由閘道主機上的環境變數／設定傳入。

模型選擇很重要。 各模型層級抵抗提示注入的能力並不一致；面對惡意提示時，較小型／較便宜的模型更容易誤用工具或遭到指示劫持。

• 任何能夠執行工具或存取檔案／網路的機器人，都應使用最新一代的最高層級模型。
• 不要為已啟用工具的代理程式或不受信任的收件匣使用較舊／較弱／較小型的模型層級。
• 如果必須使用較小型模型，請縮小影響範圍：唯讀工具、嚴格的沙箱、最低限度的檔案系統存取權、嚴格的允許清單。為所有工作階段啟用沙箱，並停用 web_search/web_fetch/browser，除非輸入受到嚴格控管。
• 對於僅供聊天、輸入內容受信任且不使用工具的個人助理，較小型模型通常已足夠。

外部內容與不受信任輸入的封裝

即使閘道會在本機解碼，OpenResponses input_file 文字仍會以不受信任的外部內容注入；該區塊包含 <<&lt;EXTERNAL_UNTRUSTED_CONTENT ...&gt;>> 邊界標記及 Source: External 中繼資料（此路徑省略了其他位置使用的較長 SECURITY NOTICE: 橫幅）。當媒體理解功能從附加文件擷取文字，再將其附加至媒體提示時，也會套用相同的標記式封裝。

OpenClaw 也會在包裝的外部內容與中繼資料送達模型之前，移除常見的自託管 LLM 聊天範本特殊權杖字面值（Qwen/ChatML、Llama、Gemma、Mistral、Phi、GPT-OSS 角色／輪次權杖）。自託管的 OpenAI 相容後端（vLLM、SGLang、TGI、LM Studio、自訂 Hugging Face tokenizer 堆疊）有時會將使用者內容中的 <|im_start|> 或 <|start_header_id|> 等字面字串權杖化為結構性聊天範本權杖；若沒有這項清理，擷取頁面、電子郵件內文或檔案內容工具輸出中的不受信任文字，可能偽造合成的 assistant/system 角色邊界。清理發生在外部內容包裝層，因此會一致套用於擷取／讀取工具和傳入的頻道內容。託管供應商（OpenAI、Anthropic）已套用其自身的請求端清理；請保持啟用外部內容包裝，並在可用時優先採用會分割／逸出特殊權杖的後端設定。

傳出模型回應有獨立的清理器，會在最終頻道傳遞邊界，從使用者可見的回覆中移除洩漏的 <tool_call>、<function_calls>、<system-reminder>、<previous_response> 和類似的內部支架內容。

這無法取代 dmPolicy、允許清單、exec 核准、沙箱或 contextVisibility，而是封堵一個特定的 tokenizer 層繞過途徑。

繞過旗標（在正式環境中保持關閉）

• hooks.mappings[].allowUnsafeExternalContent
• hooks.gmail.allowUnsafeExternalContent
• 排程承載資料欄位 allowUnsafeExternalContent

僅在範圍嚴格受限的偵錯中暫時啟用；若已啟用，請隔離該代理程式（沙箱 + 最少工具 + 專用工作階段命名空間）。

即使傳遞來源是你控制的系統，Hook 承載資料仍是不受信任的內容（郵件／文件／網頁內容可能攜帶提示詞注入）。較弱的模型等級會提高此風險；對於由 Hook 驅動的自動化，請優先採用強大的現代模型等級，並維持嚴格的工具政策（tools.profile: "messaging" 或更嚴格），且在可能時使用沙箱。

群組中的推理與詳細輸出

/reasoning、/verbose 和 /trace 可能暴露不應出現在公開頻道中的內部推理、工具輸出或外掛診斷資訊，其中可能包含工具引數、URL、外掛診斷資訊，以及模型看到的資料。請在公開聊天室中停用它們；僅在受信任的私訊或嚴格控管的聊天室中啟用。

命令授權

只有獲授權的傳送者，其斜線命令和指令才會生效；授權身分由頻道允許清單／配對加上 commands.useAccessGroups 衍生而來（請參閱設定和斜線命令）。如果頻道允許清單為空或包含 "*"，該頻道的命令實際上即為開放狀態。

/exec 僅供獲授權操作人員在目前工作階段中便利使用，不會寫入設定或變更其他工作階段。

控制平面工具

有兩個內建工具可以進行持久性變更：

• gateway 使用 config.schema.lookup / config.get 檢查設定，並使用 config.apply、config.patch 和 update.run 進行變更。
• cron 建立會在原始聊天／任務結束後繼續執行的排程工作。

gateway config.apply/config.patch 預設為失敗時關閉：僅允許代理程式調整一小部分低風險的代理程式執行階段微調項目（agents.defaults.model、agents.defaults.thinkingDefault、各代理程式的模型／思考／推理／快速模式欄位）、提及閘控（多個巢狀深度中的 channels.*.requireMention），以及可見回覆設定（messages.visibleReplies、messages.groupChat.visibleReplies、messages.groupChat.unmentionedInbound）。任何其他已變更的設定路徑都會遭到拒絕。提示詞覆寫仍由操作人員控制，新的敏感設定樹也會受到保護，除非刻意將其加入該允許清單。此工具仍會拒絕重寫 tools.exec.ask 或 tools.exec.security；舊版 tools.bash.* 別名會先正規化為對應的 tools.exec.* 路徑，再檢查寫入操作。

對於任何處理不受信任內容的代理程式／介面，預設拒絕下列工具：

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

commands.restart=false 只會封鎖重新啟動動作，不會停用 gateway 設定／更新動作。

節點執行（system.run）

如果已配對 macOS 節點，閘道便可在其上叫用 system.run，這代表可在該 Mac 上遠端執行程式碼。

• 需要節點配對（核准 + 權杖）。配對會建立節點身分／信任關係並簽發權杖；它不是逐一命令的核准介面。
• 閘道透過 gateway.nodes.allowCommands / denyCommands 套用粗粒度的全域節點命令政策。denyCommands 只比對確切的節點命令名稱（例如 system.run），不會比對命令承載資料內的 shell 文字；如果重新連線的節點公布不同的命令清單，只要閘道的全域政策和節點本身的 exec 核准仍會強制執行邊界，這本身就不構成弱點。
• 每個節點的 system.run 政策是該節點自身的 exec 核准檔案（exec.approvals.node.*），可在 Mac 上透過 Settings -> Exec approvals（安全性 + 詢問 + 允許清單）控制；它可以比閘道的全域命令 ID 政策更嚴格或更寬鬆。
• 執行 security="full" 和 ask="off" 的節點遵循預設的受信任操作人員模型；除非你的部署需要更嚴格的立場，否則這是預期行為，不是錯誤。
• 核准模式會繫結確切的請求上下文，並在可能時繫結一個具體的本機指令碼／檔案運算元。如果 OpenClaw 無法為直譯器／執行階段命令精確識別唯一一個直接本機檔案，便會拒絕需要核准的執行，而非承諾提供完整的語意涵蓋範圍。
• 對於 host=node，需要核准的執行也會儲存一份標準化且已準備的 systemRunPlan；後續獲核准的轉送會重複使用該儲存計畫，而閘道驗證會拒絕呼叫者在建立核准請求後對命令／cwd／工作階段上下文所做的修改。
• 若要完全停用遠端執行：將安全性設為 deny，並移除該 Mac 的節點配對。

動態 Skills（監看器／遠端節點）

OpenClaw 可以在工作階段進行期間重新整理 Skills 清單：當 SKILL.md 變更時，Skills 監看器會在代理程式下一輪更新快照；連線 macOS 節點也可讓僅限 macOS 的 Skills 符合資格（依據二進位檔探測）。請將 Skill 資料夾視為受信任的程式碼，並限制可修改它們的人員。

外掛

外掛會在閘道程序內執行，請將其視為受信任的程式碼。

• 僅從你信任的來源安裝；優先使用明確的 plugins.allow 允許清單；啟用前先檢閱外掛設定；變更外掛後重新啟動閘道。
• 安裝／更新（openclaw plugins install <package>、openclaw plugins update <id>）會執行不受信任的程式碼：
  • 安裝路徑是有效外掛安裝根目錄下的各外掛目錄。
  • OpenClaw 不會在安裝／更新期間執行內建的本機危險程式碼封鎖。請使用 security.installPolicy 進行由操作人員掌控的本機允許／封鎖決策，並使用 openclaw security audit --deep 進行診斷掃描。
  • npm 和 git 外掛安裝只會在明確的安裝／更新流程期間執行套件管理員相依性收斂。本機路徑和封存檔會視為自足套件；OpenClaw 會複製／參照它們，而不會執行 npm install。
  • 優先使用釘選的確切版本（@scope/pkg@1.2.3），並在啟用前檢查解壓縮後的程式碼。
  • --dangerously-force-unsafe-install 已棄用，不再變更安裝／更新行為。
  • security.installPolicy 可讓操作人員執行受信任的本機命令，針對 Skill 和外掛安裝做出主機特定的允許／封鎖決策。它會在來源資料暫存後、安裝繼續前執行，也適用於 ClawHub Skills，且已棄用的不安全旗標無法繞過它。

詳細資訊：外掛

沙箱

專屬文件：沙箱

兩種互補方法：

• 在 Docker 中執行完整閘道（容器邊界）：Docker
• 工具沙箱（agents.defaults.sandbox；主機閘道 + 沙箱隔離工具；Docker 是預設後端）：沙箱

沙箱內的代理程式工作區存取權（agents.defaults.sandbox.workspaceAccess）：

• "none"（預設）：工具會看到 ~/.openclaw/sandboxes 下的沙箱工作區；無法存取代理程式工作區。
• "ro"：將代理程式工作區以唯讀方式掛載至 /agent（停用 write/edit/apply_patch）。
• "rw"：將代理程式工作區以讀寫方式掛載至 /workspace。

額外的 sandbox.docker.binds 會依據正規化、標準化的來源路徑進行驗證。封鎖路徑拒絕清單涵蓋 /etc、/private/etc、/proc、/sys、/dev、/root、/boot，以及通常包含 Docker socket 或作為其別名的目錄（其下的 /run、/var/run 和 docker.sock），另包括 HOME 認證資訊子路徑（.aws、.cargo、.config、.docker、.gnupg、.netrc、.npm、.ssh）。系統會透過既有祖先解析上層符號連結技巧和標準化主目錄別名，並再次檢查，因此如果它們解析至遭封鎖的根目錄，仍會失敗時關閉。

子代理程式委派防護措施

如果允許使用工作階段工具，請將委派的子代理程式執行視為另一項邊界決策：

• 除非代理程式確實需要委派，否則拒絕 sessions_spawn。
• 將 agents.defaults.subagents.allowAgents 和任何各代理程式的 agents.list[].subagents.allowAgents 覆寫限制為已知安全的目標代理程式。
• 對於必須維持在沙箱內的工作流程，請使用 sandbox: "require" 呼叫 sessions_spawn（預設為 "inherit"）；當目標子執行階段未置於沙箱中時，"require" 會快速失敗。

唯讀模式

將 agents.defaults.sandbox.workspaceAccess: "ro"（或使用 "none" 來禁止工作區存取）與會封鎖 write、edit、apply_patch、exec、process 等項目的工具允許／拒絕清單結合，即可建立唯讀設定檔。

• tools.exec.applyPatch.workspaceOnly: true（預設）：即使沙箱已關閉，也會防止 apply_patch 在工作區目錄外寫入／刪除。僅當你刻意希望 apply_patch 存取工作區外的檔案時，才設定 false。
• tools.fs.workspaceOnly: true（選用）：將 read/write/edit/apply_patch 路徑和原生提示詞圖片自動載入路徑限制在工作區目錄內。
• 保持檔案系統根目錄範圍狹窄；避免將主目錄等寬泛根目錄用於代理程式／沙箱工作區，因為這可能會將敏感的本機檔案（例如 ~/.openclaw 下的狀態／設定）暴露給檔案系統工具。

各代理程式存取設定檔（多代理程式）

每個代理程式都可以有自己的沙箱與工具原則：完整存取、唯讀或無存取權。優先順序規則請參閱多代理程式沙箱與工具。

常見模式：個人代理程式（完整存取、無沙箱）、家庭／工作代理程式（沙箱化 + 唯讀工具）、公開代理程式（沙箱化 + 無檔案系統／殼層工具）。

完整存取（無沙箱）

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

無檔案系統／殼層存取權（允許供應商訊息傳遞）

{  agents: {    list: [      {        id: "public",        workspace: "~/.openclaw/workspace-public",        sandbox: { mode: "all", scope: "agent", workspaceAccess: "none" },        tools: {          // 工作階段工具可能會揭露逐字稿資料。預設範圍是目前工作階段 +          // 衍生的子代理程式工作階段；如有需要，可使用 tools.sessions.visibility 進一步限制。          sessions: { visibility: "tree" }, // self | tree | agent | all          allow: [            "sessions_list",            "sessions_history",            "sessions_send",            "sessions_spawn",            "session_status",            "discord",            "slack",            "telegram",            "whatsapp",          ],          deny: [            "apply_patch",            "browser",            "canvas",            "cron",            "edit",            "exec",            "gateway",            "image",            "nodes",            "process",            "read",            "write",          ],        },      },    ],  },}

瀏覽器控制風險

啟用瀏覽器控制會讓模型取得真正的瀏覽器。如果該設定檔已有登入中的工作階段，模型便能存取這些帳號與資料——請將瀏覽器設定檔視為敏感狀態。

• 建議為代理程式使用專用設定檔（預設的 openclaw 設定檔）；避免使用你日常使用的個人設定檔。
• 除非你信任沙箱化代理程式，否則請停用其主機瀏覽器控制。
• 獨立的迴路瀏覽器控制 API 僅接受共用密鑰驗證（閘道權杖承載式驗證或閘道密碼）——不會採用受信任代理或 Tailscale Serve 身分標頭。
• 將瀏覽器下載內容視為不受信任的輸入；建議使用隔離的下載目錄。
• 如可行，請在代理程式設定檔中停用瀏覽器同步／密碼管理器。
• 對遠端閘道而言，“瀏覽器控制”等同於對該設定檔可存取之所有內容的“操作員存取權”。
• 讓閘道與節點主機僅限 tailnet 存取；避免將瀏覽器控制連接埠暴露至區域網路或公用網際網路。
• 不需要時請停用瀏覽器代理路由（gateway.nodes.browser.mode="off"）。
• Chrome MCP 的既有工作階段模式並不“更安全”——它可以在該主機 Chrome 設定檔可存取的任何範圍內，以你的身分執行操作。
• 當閘道與瀏覽器位於不同遠端位置時，請在瀏覽器電腦上執行節點主機，並讓閘道代理瀏覽器動作（請參閱瀏覽器工具）；將節點配對視同管理員存取權，讓閘道與節點主機位於同一個 tailnet，並避免透過區域網路、公用網際網路或 Tailscale Funnel 暴露轉送／控制連接埠。

瀏覽器 SSRF 原則（預設嚴格）

除非你明確選擇允許，否則私人／內部目的地會維持封鎖。

• 預設：未設定 browser.ssrfPolicy.dangerouslyAllowPrivateNetwork，因此私人／內部／特殊用途目的地會維持封鎖。仍接受舊版別名 allowPrivateNetwork。
• 選擇允許：設定 dangerouslyAllowPrivateNetwork: true 以允許這些目的地。
• 在嚴格模式中，使用 hostnameAllowlist（例如 *.example.com 的模式）與 allowedHostnames（精確的主機例外，包括 localhost 等原本會被封鎖的名稱）設定明確例外。
• 直接導覽要求會經過預先檢查。在動作期間以及動作後的有限寬限期間，受防護的 Playwright 互動（點擊、座標點擊、懸停、拖曳、捲動、選取、按鍵、輸入、填寫表單與求值）會在送出 HTTP 要求位元組前，攔截原則拒絕的頂層與子框架文件載入，之後再盡力重新檢查最終的 http(s) URL。
• 每次全新啟動受管理的 Chrome 前，OpenClaw 都會盡力停用網路預測，以抑制 Chromium 對這些遭拒載入項目所觀察到的推測性預先連線。這是縱深防禦，而非原則邊界：跨控制服務重新啟動而重複使用的瀏覽器，以及其他瀏覽器後端，可能不具備相同的強化措施。頁面路由仍是要求層級的攔截，而非網路防火牆：重新導向躍點、彈出式視窗的第一個要求、Service Worker 流量、在有限防護時間窗結束後執行的頁面程式碼，以及部分背景／子資源路徑都可能繞過它。最終 URL 檢查仍是偵測／隔離防禦；如要完全阻止，必須由擁有者端進行輸出流量隔離，或使用強制執行原則的代理伺服器。

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

網路暴露

繫結、連接埠、防火牆

閘道會在單一連接埠上多工 WebSocket + HTTP（預設 18789；設定／旗標／環境變數：gateway.port、--port、OPENCLAW_GATEWAY_PORT）。該 HTTP 介面包括控制介面（SPA 資產，預設基底路徑為 /）與畫布主機（/__openclaw__/canvas 和 /__openclaw__/a2ui——任意 HTML/JS；在一般瀏覽器中載入時應視為不受信任的內容；請勿將其暴露給不受信任的網路／使用者，也不要與具有特殊權限的網頁介面共用來源）。

gateway.bind 控制閘道的監聽位置：

• "loopback"（預設）：只有本機用戶端可以連線。
• "lan"、"tailnet"、"custom"：會擴大攻擊面。只能搭配閘道驗證（共用權杖／密碼，或正確設定的受信任代理）及真正的防火牆使用。

經驗法則：優先使用 Tailscale Serve，而非區域網路繫結（Serve 會讓閘道維持在迴路介面上，並由 Tailscale 處理存取）；如果必須繫結至區域網路，請用防火牆將連接埠限制為嚴格的來源 IP 允許清單，而非廣泛轉送連接埠；絕不可在 0.0.0.0 上暴露未經驗證的閘道。

搭配 UFW 發布 Docker 連接埠

發布的容器連接埠（-p HOST:CONTAINER 或 Compose ports:）會經由 Docker 的轉送鏈路由，而不僅是主機的 INPUT 規則。請在 DOCKER-USER 中強制執行規則（其評估順序早於 Docker 自身的接受規則）；多數現代發行版使用 iptables-nft 前端，而該前端仍會將這些規則套用至 nftables 後端。

# /etc/ufw/after.rules（附加為獨立的 *filter 區段）*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 RETURNCOMMIT

IPv6 使用獨立的資料表——如果已啟用 Docker IPv6，請在 /etc/ufw/after6.rules 中加入相符的原則。避免將介面名稱寫死（eth0），因為不同 VPS 映像中的名稱可能不同（ens3、enp* 等），名稱不符可能會在沒有警告的情況下略過拒絕規則。

ufw reloadiptables -S DOCKER-USERip6tables -S DOCKER-USERnmap -sT -p 1-65535 <public-ip> --open

預期的外部連接埠應僅包含你有意暴露的項目（對多數設定而言：SSH + 反向代理連接埠）。

mDNS/Bonjour 探索

啟用內建的 bonjour 外掛時，閘道會透過 mDNS（_openclaw-gw._tcp，連接埠 5353）廣播存在資訊，以供本機裝置探索。完整模式包含會暴露操作細節的 TXT 記錄：cliPath（會洩露使用者名稱與安裝位置的檔案系統路徑）、sshPort（公布 SSH 可用性）、displayName/lanHost（主機名稱資訊）。廣播基礎架構細節會使區域網路偵察更容易。

• 除非需要區域網路探索，否則請停用 Bonjour——它會在 macOS 主機上自動啟動，在其他環境則需選擇啟用；直接使用閘道 URL、Tailnet、SSH 或廣域 DNS-SD 可避免本機多點傳送。

• 最小模式（啟用 Bonjour 時的預設值，建議暴露的閘道使用）會省略敏感欄位：

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

• 關閉會停用本機探索，同時讓外掛保持啟用：

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

• 完整模式（選擇啟用）包含 cliPath + sshPort：

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

• 也可以設定 OPENCLAW_DISABLE_BONJOUR=1，不變更設定即可停用 mDNS。

在最小模式中，閘道會廣播 role、gatewayPort、transport，但會省略 cliPath/sshPort；需要命令列介面路徑的應用程式，可改為透過已驗證的 WebSocket 連線取得。

閘道 WebSocket 驗證

預設需要閘道驗證——若未設定任何有效的驗證路徑，閘道會拒絕 WebSocket 連線（失敗時關閉）。初始設定預設會產生權杖（即使使用迴路介面也是如此），因此本機用戶端必須進行驗證。

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

openclaw doctor --generate-gateway-token 可以為你產生一組權杖。

使用 wss:// 時，請透過 gateway.remote.tlsFingerprint 鎖定遠端 TLS。迴路位址、私人 IP 常值、.local 與 Tailnet *.ts.net 閘道 URL 可接受明文 ws://；對其他受信任的私人 DNS 名稱，請在用戶端程序上設定 OPENCLAW_ALLOW_INSECURE_PRIVATE_WS=1 作為緊急例外（僅限程序環境，不是 openclaw.json 鍵）。行動裝置配對，以及 Android 手動輸入／掃描的閘道路由更為嚴格：只有迴路位址可使用明文；私人區域網路、鏈路本機、.local 與不含點號的主機名稱都必須使用 TLS，除非你明確選擇允許受信任私人網路的明文路徑。

直接從本機迴路連線時，裝置配對會自動核准（另有一條狹窄的後端／容器本機自我連線路徑，供受信任的共用密鑰輔助程式流程使用）；Tailnet 與區域網路連線，包括同一主機連至 tailnet 位址的連線，都會視為遠端連線，仍需核准。解析出的 tailnet 位址或 custom 位址若不是 127.0.0.1 或 0.0.0.0，會新增獨立的 127.0.0.1 接聽程式；只有連至該本機接聽程式的連線才具有迴路語意。迴路要求中若有轉送標頭證據，就不再符合迴路本機性；中繼資料升級的自動核准僅限於嚴格範圍。請參閱閘道配對。

驗證模式：

• "token"：共用的不記名權杖（建議用於大多數設定）。
• "password"：建議透過 OPENCLAW_GATEWAY_PASSWORD 設定。
• "trusted-proxy"：信任具身分感知能力的反向 Proxy，由其驗證使用者，並透過標頭傳遞身分。請參閱受信任的 Proxy 驗證。

輪替檢查清單（權杖／密碼）：產生／設定新的密鑰（gateway.auth.token 或 OPENCLAW_GATEWAY_PASSWORD）；重新啟動閘道（若由 macOS App 監管閘道，則重新啟動該 App）；更新遠端用戶端（gateway.remote.token/.password）；確認舊的認證資訊已無法使用。

Tailscale Serve 身分標頭

當 gateway.auth.allowTailscale 為 true（Serve 的預設值）時，OpenClaw 會接受 Tailscale Serve 身分標頭 tailscale-user-login，用於 Control UI/WebSocket 驗證。它會透過本機 Tailscale 常駐程式（tailscale whois）解析 x-forwarded-for 位址，並將結果與標頭比對以驗證身分；這只會由帶有 Tailscale 所注入的 x-forwarded-for、x-forwarded-proto 和 x-forwarded-host 的回送要求觸發。對於這項非同步檢查，在限流器記錄失敗之前，來自同一 {scope, ip} 的失敗嘗試會依序處理，因此同一 Serve 用戶端並行進行的錯誤重試，可能會立即鎖定第二次嘗試。

HTTP API 端點（/v1/*、/tools/invoke、/api/channels/*）不使用 Tailscale 身分標頭驗證，而是遵循閘道所設定的 HTTP 驗證模式。

閘道 HTTP 不記名驗證實際上是全有或全無的操作員存取權。能夠呼叫 /v1/chat/completions、/v1/responses、/api/v1/admin/rpc 等外掛路由或 /api/channels/* 的認證資訊，皆是該閘道具完整存取權的操作員密鑰：共用密鑰不記名驗證會恢復完整的預設操作員範圍（operator.admin、operator.approvals、operator.pairing、operator.read、operator.talk.secrets、operator.write）以及代理程式回合的擁有者語意；較受限的 x-openclaw-scopes 值不會縮減這條共用密鑰路徑。每個要求的範圍語意僅在要求來自攜帶身分的模式（受信任的 Proxy 驗證），或明確無驗證的私人入口時適用；在這些模式中，省略 x-openclaw-scopes 會回復至一般的操作員預設範圍集合，而在範圍縮減時，x-openclaw-model 等擁有者層級標頭需要 operator.admin。/tools/invoke 與 HTTP 工作階段歷程記錄端點遵循相同的共用密鑰規則。請勿與不受信任的呼叫端共用這些認證資訊；建議每個信任邊界使用不同的閘道。

無權杖的 Serve 驗證假設閘道主機本身可信任，無法防範同一主機上的惡意程序。若閘道主機可能執行不受信任的本機程式碼，請停用 allowTailscale，並要求明確的共用密鑰驗證（token 或 password）。

請勿從你自己的反向 Proxy 轉送這些標頭。如果你在閘道前方終止 TLS 或設定 Proxy，請停用 allowTailscale，並改用共用密鑰驗證或受信任的 Proxy 驗證。

請參閱 Tailscale 與 Web 概觀。

反向 Proxy 設定

在 nginx/Caddy/Traefik 等服務後方部署時，請設定 gateway.trustedProxies，以正確處理轉送的用戶端 IP。當閘道偵測到來自不在 trustedProxies 中之位址的 Proxy 標頭時，不會將該連線視為本機連線；若已停用閘道驗證，該連線將遭拒絕。這可防止經過 Proxy 的連線看似來自 localhost，因而自動獲得信任。

trustedProxies 也會提供資訊給更嚴格的 gateway.auth.mode: "trusted-proxy"：預設情況下，它會對來源為回送位址的 Proxy 採取封閉式失敗。同一主機上的回送反向 Proxy 可使用 trustedProxies 進行本機用戶端偵測與轉送 IP 處理，但只有在 gateway.auth.trustedProxy.allowLoopback = true 時才能滿足 trusted-proxy 驗證模式；否則請使用權杖／密碼驗證。

gateway:  trustedProxies:    - "10.0.0.1" # 反向 Proxy IP  allowRealIpFallback: false # 預設為 false；僅當你的 Proxy 無法提供 X-Forwarded-For 時才啟用  auth:    mode: password    password: ${OPENCLAW_GATEWAY_PASSWORD}

設定 trustedProxies 後，閘道會使用 X-Forwarded-For 判斷用戶端 IP；除非明確設定 gateway.allowRealIpFallback: true，否則會忽略 X-Real-IP。請確認你的 Proxy 會覆寫 X-Forwarded-For/X-Real-IP，而非附加至其中：

# 正確proxy_set_header X-Forwarded-For $remote_addr;proxy_set_header X-Real-IP $remote_addr; # 錯誤：保留／附加由不受信任用戶端提供的值proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

受信任的 Proxy 標頭不會讓節點裝置配對自動受信任；gateway.nodes.pairing.autoApproveCidrs 是另一項預設停用的操作員政策，而且即使已啟用回送受信任 Proxy 驗證，來源為回送位址的受信任 Proxy 標頭路徑仍不適用節點自動核准（因為本機呼叫端可以偽造這些標頭）。

HSTS 與來源注意事項

• OpenClaw 的閘道以本機／回送為優先。若你在反向 Proxy 終止 TLS，請在該處設定 HSTS。
• 若由閘道本身終止 HTTPS，gateway.http.securityHeaders.strictTransportSecurity 會讓 OpenClaw 回應送出 HSTS 標頭。
• 非回送的 Control UI 部署預設需要 gateway.controlUi.allowedOrigins；allowedOrigins: ["*"] 是明確的全部允許政策，並非經過強化的預設值，請避免在嚴格控管的本機測試以外使用。
• 即使已啟用一般回送豁免，來自瀏覽器來源且發生於回送位址的驗證失敗仍會受到速率限制，但鎖定鍵會依每個正規化的 Origin 值劃分，而非共用同一個 localhost 儲存區。
• gateway.controlUi.dangerouslyAllowHostHeaderOriginFallback=true 會啟用 Host 標頭來源備援模式；應將其視為由操作員選取的危險政策。
• 應將 DNS 重新綁定與 Proxy 主機標頭行為視為部署強化事項；請嚴格限制 trustedProxies，並避免將閘道直接暴露於公用網際網路。
• 詳細部署指引：受信任的 Proxy 驗證。

透過 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：僅限緊急情況，會完全停用裝置身分檢查。這會嚴重降低安全性；除非正在主動偵錯且能迅速還原，否則請保持停用。
• 除了這些旗標之外，成功的 gateway.auth.mode: "trusted-proxy" 可以在沒有裝置身分的情況下允許操作員 Control UI 工作階段；這是刻意設計的驗證模式行為，而非 allowInsecureAuth 捷徑，且不會延伸至節點角色的 Control UI 工作階段。

啟用 allowInsecureAuth 時，openclaw security audit 會發出警告。

不安全／危險旗標

每啟用一個已知的不安全／危險偵錯開關，openclaw security audit 就會提出一個 config.insecure_or_dangerous_flags（每個旗標各一項發現）。請勿在正式環境中設定這些旗標。若已設定稽核抑制，即使相符的發現移至 suppressedFindings，security.audit.suppressions.active 仍會保留在作用中的輸出中。

部署與主機信任

• 閘道主機應啟用全磁碟加密；若主機由多人共用，建議為閘道使用專用的作業系統使用者帳號。
• 已發布套件的相依性鎖定：原始碼簽出版使用 pnpm-lock.yaml；已發布的 openclaw npm 套件與 OpenClaw 所有的 npm 外掛套件包含 npm-shrinkwrap.json，因此安裝時會使用發行版本中已審查的遞移相依性圖，而非在安裝時重新解析新的相依性圖。這是供應鏈強化與發行版本可重現性的邊界，而非沙箱；請參閱 npm shrinkwrap。
• 安全檔案操作：OpenClaw 使用 @openclaw/fs-safe 進行根目錄範圍內的檔案存取、不可分割寫入、封存檔解壓縮、暫存工作區與密鑰檔案輔助操作。選用的 POSIX Python 輔助程式預設為停用；只有在需要額外的檔案描述元相對變更強化，且能支援 Python 執行環境時，才設定 OPENCLAW_FS_SAFE_PYTHON_MODE=auto 或 require。詳細資訊：安全檔案操作。
• 共用 Slack 工作區風險：若 Slack 中的所有人都能傳訊息給機器人，核心風險在於委派的工具權限；任何獲准的傳送者都能在代理程式政策範圍內觸發工具呼叫（exec、瀏覽器、網路／檔案工具），某位傳送者的提示／內容注入可能影響共用狀態、裝置與輸出；若共用代理程式具備敏感認證資訊或檔案，任何獲准的傳送者都可能透過工具使用方式促成資料外洩。團隊工作流程應使用僅配備必要工具的不同代理程式／閘道；包含個人資料的代理程式應保持私有。
• 公司共用代理程式（可接受的模式）：當所有使用代理程式的人都位於同一信任邊界內（例如同一公司的團隊），且代理程式嚴格限定於商務用途時，可以採用此模式。請在專用機器／VM／容器上執行，使用專用的作業系統使用者、專用瀏覽器／設定檔／帳號，且不要讓該執行環境登入個人 Apple/Google 帳號，或使用個人密碼管理工具／瀏覽器設定檔。在同一執行環境中混用個人與公司身分會破壞隔離，並提高個人資料的暴露風險。

磁碟上的密鑰

應假設 ~/.openclaw/（或 $OPENCLAW_STATE_DIR/）下的任何內容都可能包含密鑰或私人資料：

認證資訊儲存對照表

也有助於備份決策：

• WhatsApp：~/.openclaw/credentials/whatsapp/<accountId>/creds.json
• Telegram 機器人權杖：設定／環境變數或 channels.telegram.tokenFile（僅限一般檔案；拒絕符號連結）
• Discord 機器人權杖：設定／環境變數或 SecretRef（環境變數／檔案／exec 提供者）
• Slack 權杖：設定／環境變數（channels.slack.*）
• 配對允許清單：~/.openclaw/credentials/<channel>-allowFrom.json（預設帳號）／<channel>-<accountId>-allowFrom.json（非預設帳號）
• 模型驗證設定檔：~/.openclaw/agents/<agentId>/agent/auth-profiles.json
• 舊版 OAuth 匯入：~/.openclaw/credentials/oauth.json

強化：嚴格限制權限（目錄使用 700，檔案使用 600）；在閘道主機上使用全磁碟加密；若主機由多人共用，建議使用專用的作業系統使用者帳號。

檔案權限

• ~/.openclaw/openclaw.json：600（僅允許使用者讀取／寫入）
• ~/.openclaw：700（僅限使用者）

openclaw doctor 可發出警告，並提供收緊這些權限的選項。

工作區 .env 檔案

OpenClaw 會為代理程式與工具載入工作區本機的 .env 檔案，但絕不允許這些檔案在未明示的情況下覆寫閘道執行階段控制：

• 來自不受信任工作區 .env 檔案的提供者認證資訊環境變數會被封鎖，例如 GEMINI_API_KEY、GOOGLE_API_KEY、XAI_API_KEY、MISTRAL_API_KEY、GROQ_API_KEY、DEEPSEEK_API_KEY、PERPLEXITY_API_KEY、BRAVE_API_KEY、TAVILY_API_KEY、EXA_API_KEY、FIRECRAWL_API_KEY，以及已安裝的受信任外掛所宣告的提供者驗證金鑰。請改將提供者認證資訊放在閘道程序環境、~/.openclaw/.env（$OPENCLAW_STATE_DIR/.env）、設定的 env 區塊，或選用的登入 Shell 匯入中。
• 任何以 OPENCLAW_ 開頭的金鑰都會從不受信任工作區的 .env 檔案中封鎖，藉此保留整個執行階段命名空間，使未來的 OPENCLAW_* 控制項預設採用失敗時關閉，而不會默默從已簽入或攻擊者提供的 .env 內容繼承。
• 頻道與提供者的端點路由設定也會禁止由工作區 .env 覆寫（例如 MATRIX_HOMESERVER、MATTERMOST_URL、IRC_HOST、SYNOLOGY_CHAT_INCOMING_URL、AZURE_SPEECH_ENDPOINT，以及其他以 _ENDPOINT 結尾的金鑰），因此複製的工作區無法透過本機端點設定重新導向隨附連接器的流量。這些設定必須來自閘道程序環境、全域執行階段 dotenv、明確設定或 env.shellEnv。
• 受信任的程序／作業系統環境變數、全域執行階段 dotenv、設定 env，以及已啟用的登入 Shell 匯入仍會生效；這只會限制工作區 .env 檔案的載入。

工作區 .env 檔案經常與代理程式碼放在一起、意外提交，或由工具寫入；封鎖提供者認證資訊，可防止複製的工作區替換成由攻擊者控制的提供者帳戶。

日誌與逐字稿

OpenClaw 會將工作階段逐字稿儲存在磁碟的 ~/.openclaw/agents/<agentId>/sessions/*.jsonl 下，以維持工作階段連續性並供選用的記憶索引使用；任何具有檔案系統存取權的程序／使用者都能讀取它們。請將磁碟存取視為信任邊界，並嚴格限制 ~/.openclaw 的權限；若需要更強的隔離，請在不同的作業系統使用者或主機下執行代理程式。

閘道日誌可能包含工具摘要、錯誤和 URL；工作階段逐字稿可能包含貼上的機密、檔案內容、命令輸出和連結。

• 保持啟用日誌／逐字稿遮蔽（logging.redactSensitive: "tools"，預設值）。
• 透過 logging.redactPatterns 加入環境專用的自訂模式（權杖、主機名稱、內部 URL）。
• 分享診斷資訊時，請優先使用 openclaw status --all（可直接貼上，且已遮蔽機密），而不是原始日誌。
• 若不需要長期保留，請清除舊的工作階段逐字稿和日誌檔案。

詳細資訊：日誌記錄

安全基準（複製／貼上）

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

這會讓閘道保持私有、要求私訊配對，並避免群組機器人持續運作。若也要讓工具執行更安全，請為任何非擁有者代理程式加入沙箱，並拒絕危險工具（請參閱上方的「各代理程式存取設定檔」）。

使用不同號碼（WhatsApp、Signal、Telegram）

對於以電話號碼為基礎的頻道，建議讓助理使用與個人號碼不同的獨立號碼，使個人對話維持私密，並讓機器人號碼在自身邊界內處理自動化。

事件回應

圍堵

1. 停止執行：停止 macOS 應用程式（若它負責監督閘道），或終止你的 openclaw gateway 程序。
2. 關閉暴露面：設定 gateway.bind: "loopback"（或停用 Tailscale Funnel/Serve），直到釐清發生了什麼事。
3. 凍結存取：將高風險私訊／群組切換為 dmPolicy: "disabled"／要求提及，並移除所有 "*" 全部允許項目。

輪替（若機密洩漏，應假設已遭入侵）

1. 輪替閘道驗證資訊（gateway.auth.token／OPENCLAW_GATEWAY_PASSWORD）並重新啟動。
2. 在任何能呼叫閘道的機器上輪替遠端用戶端機密（gateway.remote.token／.password）。
3. 輪替提供者／API 認證資訊（WhatsApp 認證資訊、Slack／Discord 權杖、auth-profiles.json 中的模型／API 金鑰，以及使用加密機密承載內容時其中的值）。

稽核

1. 檢查閘道日誌：/tmp/openclaw/openclaw-YYYY-MM-DD.log（或 logging.file）。
2. 檢閱相關逐字稿：~/.openclaw/agents/<agentId>/sessions/*.jsonl。
3. 檢閱近期可能擴大存取範圍的設定變更：gateway.bind、gateway.auth、私訊／群組原則、tools.elevated、外掛變更。
4. 重新執行 openclaw security audit --deep，並確認重大發現已解決。

收集報告所需資料

• 時間戳記、閘道主機作業系統與 OpenClaw 版本。
• 工作階段逐字稿與一小段日誌末尾內容（遮蔽後）。
• 攻擊者傳送了什麼，以及代理程式做了什麼。
• 閘道是否暴露於迴路位址之外（LAN／Tailscale Funnel/Serve）。

機密掃描

CI 會在儲存庫上執行 pre-commit 的 detect-private-key 鉤子。若執行失敗，請移除或輪替已提交的金鑰資料，然後在本機重現：

pre-commit run --all-files detect-private-key

回報安全性問題

發現 OpenClaw 的弱點？請以負責任的方式回報：

1. 電子郵件：security@openclaw.ai
2. 在修正前，請勿公開發布。
3. 我們會致謝你的貢獻（除非你希望保持匿名）。