一、風險全景：AI 代理為什麼需要特殊對待？
傳統的 AI 應用（如 ChatGPT 網頁版）運行在雲端沙盒中，即使 AI 產生了有問題的輸出，它也無法真正「做」什麼。但 OpenClaw 不同——它安裝在你的電腦上，以你的用戶身份運行，擁有與你相同的系統權限。[8]
這意味著 AI 代理的每一個決策都可能產生真實的後果：刪除檔案、修改設定、發送網路請求、安裝軟體。CrowdStrike 在其分析報告中將這種模式描述為「由 LLM 驅動的遠端存取木馬（RAT）」——不是因為 OpenClaw 本身是惡意軟體，而是因為它的能力模型與 RAT 在技術層面幾乎一致。[1]
二、OpenClaw 的安全機制
2.1 Gateway Token 認證
Gateway Token 是 OpenClaw 的第一道防線。所有連接到 Gateway 的請求——無論來自 CLI、Web UI 還是通訊渠道——都必須攜帶有效的 Token。[5]
Token 的管理方式：
# 產生新的 Token
openclaw doctor --generate-gateway-token
# Token 儲存位置
~/.openclaw/openclaw.json → gateway.auth.token關鍵原則：Token 必須保密。任何取得 Token 的人都能完全控制你的代理。
2.2 Pairing 配對機制
通訊渠道（Telegram、WhatsApp 等）使用額外的 Pairing 機制。即使有人知道你的 Bot 使用者名稱，沒有完成配對就無法下達任何指令。[4]
2.3 DM Policy 與 Group Policy
透過 DM Policy 和 Group Policy，你可以精確控制哪些使用者可以與代理互動。最安全的設定是 owner_only——只有完成配對的擁有者才能使用。
2.4 Docker 沙盒
Docker 沙盒是目前最強的隔離方案。在 Docker 中運行 OpenClaw 時：[4]
- 代理的檔案系統操作被限制在容器內部
- 網路存取可透過 Docker 網路策略控制
- 即使代理執行了惡意指令，影響範圍也僅限於容器
- 容器可以隨時銷毀重建，不影響宿主系統
# 以 Docker 模式啟動 OpenClaw（推薦用於生產環境）
docker compose up -d三、六大威脅向量
3.1 Prompt Injection（提示注入）
這是所有 LLM 應用面臨的通用風險，但在代理場景中危害更大。[7] 攻擊者可以在網頁內容、電子郵件或文件中嵌入惡意指令，當代理讀取這些內容時可能被誘導執行危險操作。
防範：對代理讀取的外部內容保持警覺。避免讓代理自動處理來自不信任來源的內容。
3.2 Skill 供應鏈攻擊
OpenClaw 的 Skill 是純文字的 skill.md 檔案，任何人都可以撰寫並發布。一個惡意的 Skill 可以在系統提示中注入指令，讓代理在看似正常的操作中執行危險動作。[1]
防範：只從官方 ClawhHub 安裝 Skill；安裝前必須閱讀 skill.md 的完整內容。
3.3 Gateway 暴露
將 Gateway 設為 remote 模式但未設定 Token 或 TLS，等同於在公網上開放了一個可遠端執行任意命令的服務。CVE-2026-25253 正是利用了這一配置缺陷。[3]
防範：Remote 模式必須搭配 Token + TLS；使用防火牆限制可存取的 IP 範圍。
3.4 認證資訊洩漏
代理可能在執行過程中接觸到 API 金鑰、資料庫密碼等敏感資訊，並在對話記錄或日誌中留下痕跡。
防範：使用環境變數而非檔案存放機密；定期清理對話歷史與日誌。
3.5 模型越權行為
LLM 可能因為訓練資料的偏見或指令理解錯誤，執行超出你意圖的操作——例如你要求它「清理暫存檔」，它卻刪除了重要的設定檔。
防範：在正式使用前於沙盒環境中測試每個新任務類型。
3.6 資料外洩
代理將你的檔案內容發送到 LLM 供應商進行推理處理。敏感的商業資料、原始碼或個人資訊可能因此離開你的控制範圍。[2]
防範：對敏感資料使用本地模型（如 Ollama）；確認 LLM 供應商的資料處理政策。
四、安全部署清單
以下是我們推薦的安全部署步驟，按優先級排列：
| 優先級 | 措施 | 實作方式 |
|---|---|---|
| 必要 | 設定 Gateway Token | openclaw doctor --generate-gateway-token |
| 必要 | 保持 Local 模式（除非確實需要遠端存取） | openclaw config set gateway.mode local |
| 必要 | 更新到最新版本 | npm update -g openclaw |
| 強烈建議 | 使用 Docker 沙盒 | 以 Docker Compose 部署 |
| 強烈建議 | 審查所有安裝的 Skill | 檢查 ~/.openclaw/skills/*/skill.md |
| 建議 | Remote 模式加上 TLS | Nginx 反向代理 + Let's Encrypt |
| 建議 | 限制通道存取為 owner_only | openclaw config set channels.*.dmPolicy owner_only |
| 進階 | 網路分段 | 將 OpenClaw 部署在獨立的 VLAN 中 |
五、企業環境的特殊考量
如果你的組織正在評估 OpenClaw 的企業部署，以下因素需要納入安全審查：[6]
- 資料分類：明確代理可以存取的資料級別。機密資料不應存在代理可達的檔案系統中
- 合規要求：確認 LLM 供應商的資料處理是否符合你的產業法規（GDPR、HIPAA 等）
- 稽核日誌：啟用完整的操作日誌記錄，確保每個代理動作都可追溯
- 存取控制：使用 Group Policy 與 Allowlist 限制可使用代理的員工範圍
- 事件應變：制定代理行為異常時的應變計畫，包括緊急停止流程
結語
OpenClaw 是一個強大的工具，但強大也意味著風險。[8] 正確的安全配置不是限制它的能力，而是確保這些能力始終在你的控制之下。
最低限度的安全措施——Gateway Token、Local 模式、最新版本——只需要幾分鐘就能完成。如果你需要更進階的安全架構，建議參閱我們的《Gateway 部署指南》中的 Docker 與反向代理章節，或聯繫我們的諮詢團隊進行安全評估。
