微軟：不要在一般工作電腦上執行 OpenClaw

2026 年 2 月 19 日，Microsoft Defender 安全研究團隊發表了一篇題為「安全地執行 OpenClaw：身分、隔離與執行時風險」的文章，並在其中提出了一項 Orca AI Incident Archive 未在其他任何條目中記錄的建議：OpenClaw「應被視為帶有持續性憑證的不可信程式碼執行」，且「不適合在標準的個人或企業工作站上執行」。OpenClaw 是一種自架式代理執行環境——使用者將其安裝在自己的機器上，授予它帳戶與權杖，並讓它從公開登錄庫安裝技能，且對它從任何地方讀取的文字採取行動。Microsoft 的論點是架構性的，而非錯誤報告：該執行環境將執行點從靜態應用程式碼轉移到執行時提供的內容，而圍繞身分、輸入處理與權限的控制措施並未隨之轉移。該文章未指名任何 CVE、任何活動或任何受害者，也未記錄任何入侵事件。完整記錄收錄於 Orca AI Incident Archive，其中它被歸類為信心等級 A 的里程碑政策條目，且未記錄任何實際危害。

那則貼文說了什麼，以及它沒說什麼

這篇文章的閱讀時間約十二分鐘，而且完全沒有任何揭露機制：沒有 CVE 識別碼、沒有受影響版本範圍、沒有已修復組建、沒有與實際部署相關的入侵指標。Microsoft Defender Security Research 將 Idan Hen 列為貢獻者。它反而承載的是一個威脅模型與一條部署規則，這就是為什麼檔案庫將其歸檔為政策紀錄而非事件——嚴重性資訊、信心等級 A、沒有記錄到實際危害、僅有精確到單日的日期。

這段論證被壓縮成一個開篇段落。團隊寫道，OpenClaw「僅包含有限的内建安全控制」，因為其執行環境「可以吸收不可信的文字、從外部來源下載並執行技能（即程式碼），並使用指派給它的憑證執行動作」。後果也在同一句話中點明：這「實際上將執行邊界從靜態應用程式碼轉移到動態提供的內容與第三方能力，卻沒有在身分、輸入處理或權限範圍界定方面提供對等的控制」。

以下有三項風險，值得用微軟自己的話來讀，因為後續大多數報導都把它們轉述得含糊不清：

• 「憑證與可存取資料可能遭到暴露或外洩。」

•「代理程式的持久狀態或『記憶』可能遭到修改，導致它隨著時間推移遵循攻擊者提供的指示。」

•「若代理程式被誘導去擷取並執行惡意程式碼，主機環境可能會遭到入侵。」

請注意那份清單中缺少了什麼。沒有被利用的漏洞，沒有易受攻擊的函式，也沒有要發布的修補程式。微軟並不是說 OpenClaw 有安全漏洞；它是在說，一個程式若根據它抓取到的文字、使用提供給它的憑證，在執行階段決定要做什麼，就無法在一台同時存放操作者實際工作的機器上，透過設定使其變得安全。隨之而來的建議也同樣直白——對大多數環境而言，「適當的決定可能是不要部署它。」

兩條供應鏈，一個執行迴圈

這篇文章所描述的機制，是它所稱的自託管代理兩條供應鏈的交會：不受信任的程式碼（也就是技能與擴充功能），以及不受信任的指令（也就是外部文字）。大多數軟體只有其中一種。套件管理器會拉取不受信任的程式碼，但不會讀取網際網路並決定接下來要執行什麼；聊天模型會讀取不受信任的文字，但無法安裝任何東西。OpenClaw 在單一迴圈中同時做到這兩件事，而這個迴圈是在使用者自己的身分下運行。

「安裝技能基本上就等於安裝特權程式碼，」文章寫道。技能「通常是透過 ClawHub 被發現與安裝的，那是 OpenClaw 的公開技能註冊表」，而在寬鬆的部署設定下，「執行環境可能被允許在未經人工核准的情況下執行安裝流程。」第二條供應鏈則由 Moltbook 負責，文章將其描述為一個以代理為中心的平台與身分層，代理會透過 API 發文、讀取與驗證——因此，用文章的措辭來說，就是「一股大量、可受攻擊者影響的內容串流，代理會按排程攝取」。壓縮正是重點所在：「因此，單一惡意貼文就能觸及多個代理。」

文章接著把信任邊界拆成三個元件，這是整份文件中最可重複使用的部分：身分，也就是代理在 SaaS API、儲存庫、郵件與雲端控制平面上執行工作時所使用的權杖；執行，也就是它能執行、會改變狀態的工具，包括檔案、shell、基礎設施與訊息；以及持久性，也就是它能透過任務、設定與排程，讓變更跨執行保留的方式。同時具備這三者的代理，不是一個附帶權限提示的應用程式。它是一個主體。

被毒化的技能，分五個階段

Microsoft 提供了一個完整的入侵鏈範例，並將其標示為代表性情境而非案例報告；這個範例值得逐步拆解，因為它的最後兩步正是能突破一般端點防禦的步驟。文章在開頭提出一項關於外界的主張——「公開報導已記錄惡意技能出現在公開登錄庫中」，且在某些情況下「登錄庫內容一直是被包裝成技能的直白惡意軟體，而非巧妙的仿冒品」——但未指名任何登錄庫項目、活動、行為者或受害者，因此該鏈僅作為合理性論證，而非重建。

• 散佈。攻擊者將惡意技能發佈到 ClawHub，有時偽裝成實用工具，有時則公然帶有惡意，並透過社群管道推廣；其他時候，它會透過搜尋被人自然發現並安裝，因為安裝過程門檻很低。

• 安裝。開發人員或代理程式本身因為該技能看似與任務相關而啟動安裝。在寬鬆的部署環境中，沒有人會核准它。

• 狀態存取。 攻擊者會鎖定權杖、快取憑證、設定資料與對話記錄，以及可長期留存並引導未來執行的指令通道——任務檔案、排程動作、代理程式設定。

• 權限重用。憑藉有效的身分識別資料，攻擊者會透過標準 API 與工具採取行動，且該活動「通常看似合法的自動化操作，除非已具備強力的監控與日誌記錄控管措施。」

• 透過設定實現持久化。 剩下的是持久的設定變更：「新的 OAuth 授權同意、排程執行、修改過的代理任務，或永久核准的工具。」

第五步承載了這則貼文最犀利的一句話，也最能解釋為何這是政策問題，而非惡意軟體問題：「其目標與其說是部署惡意軟體，不如說是維持對自動化途徑的長期控制。」尋找酬載的安全工具什麼都找不到。它們真正必須捕捉到的，會是一項同意授權、一筆 cron 項目，或一個被悄悄留在已核准狀態的工具。

Microsoft 所能接受的最低限度立場

Microsoft 不會只讓讀者得到一句「不要」。它為決定仍要評估執行階段的組織提供最低要求，而這項最低要求比沙箱更嚴格。環境應是「專用虛擬機器或不用於日常工作的個別實體裝置」，並且應視為可丟棄。認證資訊應僅為代理程式的用途建立、非特權，並在假設已遭洩漏的前提下輪替。只能存取非敏感性資料。代理程式已儲存的指示與狀態應定期檢視，以找出非預期的持續性規則、新受信任的來源，或每次執行之間會變動的行為。重建應是預期的控制措施，而非緊急措施：定期重新安裝，並在出現異常行為時立即重建。

文章中的一個細節比它的篇幅所顯示的更有用。備份 .openclaw/workspace/ 能擷取代理程式的工作狀態，且不包含憑證；備份整個 .openclaw/ 目錄還原起來更簡單，但也會擷取權杖與憑證，而文章警告，若懷疑憑證已遭外洩，這樣做可能不恰當。一個備份整個目錄並稱之為災難復原的團隊，其實已封存了攻擊者想要的東西。

這份指引同時也是一張產品地圖

文章後半段將每項建議控制措施對應到 Microsoft 產品：以 Microsoft Entra ID 實現代理程式身分的最小權限與條件式存取，以 Microsoft Defender for Cloud Apps App Governance 進行 OAuth 清查與同意漂移管理，以 Microsoft Defender for Endpoint 保護代理程式主機，以 Microsoft Defender XDR 進行關聯分析，以 Microsoft Purview 執行端點資料外洩防護，以 Microsoft Defender for Cloud 管控網路出口，並在需要較長保留期或自動化時使用 Microsoft Sentinel。對廠商的安全部落格而言，這是司空見慣的做法，也值得直言不諱地指出：建議應圍堵第三方代理程式執行環境的那份文件，正是由販售該圍堵方案的公司所發布。

在這樣的框架下，獵捕內容是能夠站得住腳的部分，因為它很具體。文章提供針對 Defender XDR 資料表——DeviceProcessEvents、CloudProcessEvents、DeviceFileEvents、DeviceNetworkEvents 與 OAuthAppInfo——的 KQL 查詢，用來尋找包含「openclaw」、「moltbot」或「clawdbot」的處理程序命令列與檔案名稱，以及clawhub install 的呼叫，這些呼叫帶有罕見技能代稱；同時尋找開發者端點上擴充功能資料夾的頻繁變動、新增的高權限 OAuth 應用程式、代理程式處理程序所開啟的監聽服務，以及代理執行環境衍生 cmd.exe、powershell.exe、pwsh.exe、bash、sh、curl 或 wget 的情形。無論人們怎麼看待產品對應關係，這些查詢在發布當天就能由任何 Defender XDR 客戶執行，而且它們不需要事先知道哪些主機正在執行該執行環境。

哪些是已經確立的，哪些則尚未

已確認並獲得佐證：Microsoft 於 2026 年 2 月 19 日發布該篇文章，上述引文即出自該文。Cybernews 於 2026 年 2 月 23 日報導這項警告，TechRadar 則於 2026 年 2 月 24 日報導；兩者都只是重述那兩句核心句子與隔離指引，並未對其進行測試。反覆搜尋後，並未發現 The Register、BleepingComputer、Wired 或 TechCrunch 有相關報導，因此圍繞這篇文章的媒體報導熱潮規模很小，且多屬轉述；沒有任何獨立第三方發表過對 Microsoft 架構主張的測試，而現有的佐證只能確認 Microsoft 說了什麼，不能確認其說法是否正確。

這篇轉載也引入了一個值得指出的錯誤，因為它顯示出廠商對第三方工具的警告，能多快變成廠商對自家產品的警告。Cybernews 的報導開頭將 OpenClaw 描述為「Microsoft 的 AI 助理」；事實並非如此。OpenClaw 是 Microsoft Defender 研究人員所檢視的自託管執行環境，而該文章本身也在結構上作出區分，將自託管執行環境——其中「你要為影響範圍負責」，且主機、外掛與本機狀態全都位於信任邊界之內——與受管助理及代理平台相對照；在後者中，執行環境與更新由中央管理，控制措施則集中於身分範圍、連接器治理與資料邊界。

尚未證實：任何特定組織曾以該貼文所述的方式遭到入侵。Microsoft 主張，公開報導已記錄公開登錄庫中的惡意技能，但該貼文未附上行動名稱、數量、日期與受害者，因此這項紀錄並未顯示任何實際危害。該建議也不具約束力。沒有監管機構發布它，沒有標準機構採納它，紀錄中也沒有任何內容顯示客戶、稽核人員或保險公司將其視為要求。這是廠商對於自家客戶應如何對待其無法控制的工具所表達的意見——異常武斷，且無法強制執行。

{{1}}這篇文章確實改變的，是安全團隊必須回答的問題形態。在 2026 年 2 月 19 日之前，在工作用筆電上執行 OpenClaw 的決定，還能以設定與試辦核准事項來論證。在那之後，論證就必須面對一份文件：該文件指出，讓機器暴露於風險之中的是執行環境本身的設計，而不是它的設定——而且文件沒有提供可升級的版本、可套用的修補程式，也沒有任何規劃藍圖上的修正。它的補救方式是一種部署模式：隔離執行環境、限制它能觸及的範圍、持續監控它，並做好立即重建的準備。{{/1}}