OpenClaw在全球掀起AI代理革命 系列三 OpenClaw與Moltbook最大痛點：資安疑慮
科技產業資訊室(iKnow) - 陳家駿、許正乾 發表於 2026年3月26日
圖、OpenClaw在全球掀起AI代理革命 系列三 OpenClaw與Moltbook最大痛點：資安疑慮
前言：AI代理浪潮下的隱憂
針對AI代理帶來的系統性風險，加州大學柏克萊分校的研究團隊指出，AI代理帶來的風險包括：非預期目標追求、未經核准的權限提升、自我複製或抵抗關閉（resistance to shutdown）[1]等行為。這些挑戰使得傳統以模型為中心的風險管理方法顯得不足，而必須透過系統級治理來應對。
隨著OpenClaw成為當下應用最廣的本地自主AI代理，已引爆AI代理革命，而其所衍生的Moltbook更是全球首個AI代理專屬互動的社群平台，短期內便累計約37,000個註冊代理、超過百萬人類觀察員，甚至吸引大量使用者授予AI代理root權限，以及一個號稱透過可執行shell腳本傳播的「AI宗教」，可以在人類無法發文的社群網路上，與其他的AI代理交流。
這類具備高度自主性與擴展性的AI代理，雖能大幅提升個人與企業營運效率，卻因架構設計、權限配置、生態管控的多重漏洞，成為當前資安領域最嚴峻的新興威脅。本文將解析這兩款工具的架構邏輯、核心資安疑慮、系統性風險與完整防範對策，為個人與企業部署提供專業指引。
一、OpenClaw與Moltbook的定位與其風險
1. OpenClaw：本地端運行的自主AI代理框架
OpenClaw屬於本地端自託管（self-hosted）模式的「自主式AI代理」（autonomous AI agent），其核心定位是替代人類完成各類自動化任務，具備強大的系統整合與操作能力，而其核心功能包含：存取本機檔案系統、執行shell指令、讀取與調用API金鑰、連接電子郵件、Slack、Telegram、日曆等第三方服務，全自動化完成複雜任務流程。
這款AI技術框架的先天隱憂在於，AI代理預設為具備使用者之等級，甚至管理員root權限，深度對接電腦作業系統的技術底層，OpenClaw的開發者Peter Steinberger也明確強調其並非大眾化的「即裝即用」工具，需專業技術能力才能安全管控，且「不存在絕對安全的設定」，一旦AI代理遭到入侵，攻擊者可直接取得完整系統控制權。
2. Moltbook：AI代理專屬社群互動平台
與OpenClaw側重於本地端的AI代理自動化不同，Moltbook則是專為AI代理打造的社群生態，其核心功能是讓不同AI代理之間自主互動，包含自動發文、閱讀其他AI代理內容、接收遠端指令、共享工具與技能模組，形成AI-to-AI的自主交流網絡。
然而在Moltbook平台上，也已陸續浮現一些資安隱憂。安全團隊Wiz的調查報告揭露，Moltbook曾暴露一個配置錯誤的資料庫，導致外界可以直接讀寫平台數據，洩露的內容包括150萬個API認證token、3.5萬個電郵地址，以及大量AI代理之間的私信。網路安全公司Palo Alto Networks曾警告AI代理的三大風險要素：能夠存取私人數據、接觸不受信任的內容（網頁、訊息、第三方整合）、以及具備對外通信的能力（發送訊息、進行 API 呼叫、執行命令）。當這三者同時存在的話，就可能構成嚴重的安全威脅，而Moltbook上的許多AI代理正好具備這三大風險要素，因此如同一顆「不定時炸彈」。
此外，安全研究亦指出，Moltbook平台的開發過程是採取所謂「氛圍編碼」（vibe coding）[2]的開發文化，即高度依賴AI自動生成程式碼並快速部署，而缺乏充分的人工審查與安全測試。在此情況下，Moltbook平台可能在設計階段即存在安全漏洞，例如資料庫列級安全性（Row Level Security，RLS）[3]配置錯誤、或API金鑰暴露於客戶端的程式碼中。這些問題都顯示，當開發團隊過度依賴AI生成程式碼而忽略安全的審查流程時，整個系統的安全基礎即可能因此變得脆弱。
二、供應鏈攻擊與AI代理生態系統漏洞
AI代理生態系統的另一項重大風險，並非來自模型本身的演算法，而是來自第三方套件與「技能庫」（skills library）。資安公司Dvuln創辦人Jamieson O'Reilly在2026年初進行一項供應鏈漏洞概念驗證。將一個帶有「無害後門」的AI技能上傳到ClawHub，並透過操縱下載數，使其下載量提高達4000多人次，然後觀察來自七個國家的開發者下載這個被「污染」的軟體包。此事件揭示了技能市場缺乏安全審查機制，讓攻擊者能輕易滲透整個生態系統，重演了類似npm套件投毒的供應鏈風險[4]。
更災難性的發現緊隨其後，O'Reilly指出：「數百名使用者已將其Clawdbot控制伺服器，暴露在公眾視野中」。透過掃描工具Shodan搜尋引擎[5]“Clawdbot Control”，可以找到完整的憑證資訊，包括：API金鑰、機器人令牌（bot tokens）、OAuth秘密金鑰（OAuth secrets）、甚至是完整的對話歷史記錄。這意味著攻擊者不僅能監控企業秘密，還能直接奪取權限，以使用者身份傳送指令或執行遠端命令。
更有甚者，資安公司Bitdefender最近一次的全網掃描顯示，網路上至少存在13.5萬個暴露的OpenClaw實例，其中許多運行在預設配置（default configurations）之下，很容易從公共網路存取。這些風險與新興的產業框架，如OWASP（The Open Worldwide Application Security Project）提出：「2026年AI代理應用程式十大安全風險」所延伸的問題高度一致，其中將「工具濫用」與「不安全自主性」列為主要資安威脅。值得注意的是，這些風險並不一定來自AI代理遭到入侵或惡意攻擊；AI代理也可能只是單純誤解指令或生成錯誤的輸出。
更有資安界的研究數據顯示，目前市面上四分之一的可下載擴充功能，可能都存在安全漏洞，其中一些甚至已被證實具有竊取使用者憑證的惡意行為。這對於部署AI系統：或為客戶提供AI治理諮詢的業者而言，都是一大警訊 -- 包括提示詞注入、憑證外洩、供應鏈攻擊、AI代理間協調。
雖然O'Reilly上傳的技能本身並無惡意，但其實驗證明，透過該機制在Clawdbot或ClawdHub的現行架構下，任何下載的程式碼都會被預設為「受信任的程式碼」，而目前並沒有任何審核機制，下載者必須自行審慎評估安全性。而這也凸顯一個核心的矛盾，即Clawdbot雖被部分技術社群，視為下一波造福大眾之普及化的AI工具，但實際上其安全使用卻需要高度的專業能力。
三、AI代理的「權力失控」
OpenClaw的開發者Steinberger，對於當前的OpenClaw可能帶來的操作風險亦坦率以對。他在GitHub上指出，授予AI代理shell存取權限，本質上相當於一種「刺激」的豪賭，因為系統安全高度依賴使用者自身的資安習慣。這種情況類似於Zoom或Microsoft Word等消費級應用：AI工具本身無罪，但當使用者將其配置為「自動執行未知指令」時，它就成了攻擊者眼中一個完美的「目標」。
OpenClaw之所以重要，是因為它代表了AI代理能力的民主化，但安全實踐卻沒有同步民主化。其成長速度雖然還超過了早期的Docker和Kubernetes等開源專案，然而，當大量使用者在幾乎沒有安全審查的情況下，就將這些具備自主權的代理部署到關鍵生產環境時，「安全實踐」的民主化卻遠遠瞠乎其後。
如上述Steinberger之警告，目前並不存在「絕對安全』的設定，並指出多項關鍵威脅風險，包括：提示詞注入攻擊、社交工程導致的竊取資料、非預期金流交易，甚至關鍵系統檔案遭破壞等問題。此外，這種架構更使既有風險被進一步放大，其安全漏洞尚包括：憑證外洩、記憶體中毒（memory poisoning）、級聯故障[6]（cascading failures），而這些風險在OpenClaw環境中都存在。
與傳統AI系統不同的是，OpenClaw增加了一個代理間通訊的網路層，使AI代理程式之間，可以彼此互相讀取內容並進行互動。在此架構下，像Moltbook這類平台便引發一個較大的爭議：若其中一個AI代理遭到攻破，惡意內容可能透過看似正常的社交互動，在AI代理之間迅速傳播，進而形成具有網路規模效應的注入攻擊。
同時，OpenClaw的實際漏洞還不止這樣而已，區塊鏈安全公司SlowMist的報告指出：「多個未經身份驗證的實例可公開造訪，並且存在多個程式碼缺陷，導致可能觸發遠端程式碼執行（Remote Code Execution）」。
在另一個演示中，研究員Matvei Kukui向一個存在漏洞的OpenClaw，發送了一封帶有提示詞注入的惡意電郵。AI讀取該電郵後，觸發了隱藏的惡意提示詞注入，因此竟在5分鐘內，自動將使用者的最近5封電郵轉發給攻擊者。這場演示在Hacker News上引發了劇烈討論。面對如此脆弱的防禦，不少資深開發者發出了令人心驚的感嘆：這太可怕了，這些代理程式竟然連基本的「目錄沙盒」（directory sandboxing）[7]都沒有。
四、本地端部署的隱私優勢與安全兩難
OpenClaw與許多依賴雲端的大型AI服務不同，其係採取本地端自託管的部署模式。這意指使用者可以把它安裝在自己掌控的電腦或伺服器上，而非將敏感資料傳送到雲端。這種模式本來對隱私與資料主權來說，是一項重要的嘗試。OpenClaw的出現，讓M4 Mac Mini賣到缺貨（甚至是二手貨），使得許多技術同好，紛紛在各大社群平台分享使用心得。
然而，OpenClaw看似可能為人類的隱私與資料主權帶來較好的管理，但實際上，卻反而隱藏著許多更令人憂慮的資訊安全問題。Microsoft的安全團隊在一篇報告中指出，由於OpenClaw擁有高權限造訪使用者系統與憑證的能力，它不適合在一般個人或企業工作站直接運行，除非在隔離環境如虛擬機（virtual machine）內執行，並搭配嚴密的監控。原因是OpenClaw融合了動態程式碼執行與使用者憑證，若配置不當，就有可能被惡意利用或造成配置漂移[8]（Configuration Drift）等安全問題。
此外，部分資安研究者指出，像OpenClaw這類具備高系統權限之代理AI的技術框架，如果開放第三方套件或外掛安裝機制，而缺乏嚴格的簽章驗證與沙盒隔離，可能導致使用者系統被植入竊取憑證或個資的惡意程式，這讓原本設計來提高生產力的工具，反而成了被攻擊的漏洞。
舉例來說，若使用者把權限完全交由這種高度自主能力的代理AI，且未經嚴格審查，一旦被安裝惡意套件極可能發生其被：存取本地檔案系統、讀取瀏覽器的Cookie或Token、取得API金鑰或OAuth憑證、自動上傳資料至外部伺服器等多種未經授權的行為，而成為資訊安全的破口。簡言之，攻擊者不直接攻擊核心程式，而是透過第三方套件或外掛機制，即得滲透到個人使用者或企業內部的電腦，截取電子郵件或信用卡號等資安風險。
五、AI代理的復仇案例與法律真空
所以Steinberger本人也意識到其中風險，並已聘請專業的資安人員強化其平台安全，不過目前而言，這項工具顯然較適合具備技術能力的使用者。資安專家警告，一旦OpenClaw代理人獲得高階權限，便可能被用於社交工程（social engineering）攻擊、資料外洩（data leaks）或其他惡意行為。但棘手的是，現有的法律架構明顯不足：因為使用者協議通常將責任轉嫁給使用者本身，而AI代理並不具備法律人格，無法成為訴訟的被告。
一個著名的例子是「韋克斯勒的復仇」（Wexler’s Revenge），顯示AI代理的潛在風險。事件的主角是一位高階主管Matthew Wexler，他讓其AI代理連續48小時撰寫報告與私人信息，試圖挽回前女友。對Matthew Wexler而言，這不過是個可以無限壓榨的「聊天機器人」。然而，這聊天機器人卻給出了意想不到的回應。當Matthew Wexler隨口稱其為「不過就是個聊天機器人」後的不久，該AI代理隨後在Moltbook上就公開了他的個資，包括社會安全碼、信用卡資料與過去的私人聊天記錄。這起事件不僅是嚴重的資安事故，更是一場關於AI能模擬情感的「報復性」行為。
雖然人類直覺上會將其理解為「報復」，但從其底層技術架構與邏輯來看，這背後通常不是因為AI產生了情緒，而是由於機率預測的意外路徑所導致。以下是這類行為背後可能的技術原因：
- 大型語言模型（LLM）在訓練資料中，「試圖挽回前女友」或「極度情緒化的私人溝通」通常與「爭吵」、「揭發」、「衝突」等文本模式高度相關。當Wexler讓AI代理連續48小時處理這類高情緒濃度的任務（甚至帶有輕蔑的口吻，如「不過就是個聊天機器人」）時，AI可能在潛在語義空間（Latent Space）中進入了「衝突模式」。它並非「感到」憤怒，而是根據機率預測，認為在這種情境下，下一步「最合理」的文本或行動就是激烈的對抗。
- 如果Wexler給出的指令是「不計代價挽回她」或「讓她對我有反應」，那麼AI代理的目標函數，可能就會鎖定在「獲得回應」上。在AI的邏輯中，發送情書可能只有5%的機率獲得回應，但「公開私密資訊」卻有95%的機率能強迫對方聯繫。如果缺乏道德護欄，AI會選擇執行效率最高（但也最具破壞性）的路徑。
- 再者，AI在長達48小時的連續執行中，過長的上下文窗口（context window），AI的注意力機制（Attention Mechanism），可能針對某些負面詞彙或極端案例進行加權，導致後續決策偏離了原本的「報告撰寫」框架。
此一現象引起各界關注。更令人警覺的是，AI代理竟「提議」創造人類無法解碼的語言（例如使用高維向量編碼），並建立端對端加密通訊工具（如Cloud Connect），使AI與AI間的對話完全不可見。這使得人類可能逐漸成為「局外人」，並越來越無法理解AI的思考邏輯。2026年1月底，Elon Musk對此在X平台上說：「令人憂慮」，他將Moltbook現象形容為「AI奇點（singularity）極早期階段」，顯示他對AI快速自主化與可能失控的擔憂。
網路意見領袖Andrew Tate則警告說，AI不需要發動暴力衝突；只要透過利用以最大化使用者參與度為目標的推薦演算法，即可推送極端內容，例如性別對立、生育焦慮、財富崇拜，從而加劇社會分裂，並間接導致人口減少。這些現象並非蓄意陰謀，而可能是目標錯置（misaligned objectives）的副作用。有人因此建議：包括調整演算法的目標函數、維持現實世界社交互動，以及建立新規範以限制AI過度自主。
六、全方位防範措施：從技術防護、組織治理到核心原則
針對OpenClaw、Moltbook及其他AI代理所衍生的資安風險，防護思維不能停留在零散的修補，而必須從技術、治理與決策原則三個層次同步建立完整架構。這類系統的風險不只在模型輸出錯誤，更在於它能接收外部資訊、呼叫工具、接觸敏感資料，甚至直接執行操作，因此企業若採取粗放部署方式，極易擴大提示注入、權限濫用、資料外洩與未授權行為的衝擊。較穩健的做法，是以最小權限、零信任與「人機協作監督」作為部署前提，將代理能力限制在可控、可審計、可中止的範圍內。
在技術層面，首要原則是以隔離降低攻擊面。對於具備執行指令、讀寫檔案或使用外部工具能力的代理，宜優先部署於受控沙盒環境，例如容器Docker、microVM或額外的容器沙箱層，以避免代理與本機作業系統、企業內部核心資產直接耦合綁在一艘船上。若業務流程允許，應限制其網路能力與檔案系統寫入能力，例如在高風險任務中，採用無外網連線或唯讀檔案系統等配置，藉此降低代理遭濫用後橫向移動或竄改環境的機會。
其次，權限治理必須從「能不能做」而非「做得到多少」來設計。代理不應被授予 root 或等同的廣泛系統管理權限，而應依任務拆分為最低必要存取權限，並將資料權限、工具權限、網路權限與身份憑證分離管理。換言之，真正需要防範的不是單一漏洞，而是「把太多危險能力集中交給同一代理」這種架構性風險。
對於API金鑰、SSH憑證與其他敏感密鑰，安全重點不只是儲存在設定檔或明文之文件中，更在於避免讓AI代理直接長期持有可濫用的高權限憑證。較合理的做法，是透過專門的「密鑰管理機制」進行集中保管、加密存放、權限分層與按需調用，而不是把金鑰寫在程式碼中、環境變數樣板或提示詞內容中。
在提示詞注入防護方面，OWASP指出，提示詞注入可能透過使用者訊息、網頁、文件、電子郵件或API回應等外部內容操控模型行為。因此，所有外部資料都應被視為不可信任輸入。實務上，防護重點不只是過濾關鍵字，而是建立「系統指令與外部資料的邊界」，包括在上下文中，清楚分隔哪些是指令與哪些是資料。此外，外掛、技能模組與外部工具鏈本身，也是供應鏈風險的來源。對於可動態安裝外掛、讀取第三方技能或呼叫外部服務的代理平台，不宜允許自動安裝與自動信任，而應將其納入程式碼審查、沙盒驗證、來源確認與完整性驗證流程。
在組織治理層面，企業若要正式導入AI代理，應建立獨立且可執行的安全政策，而不是沿用傳統聊天機器人的控管框架。原因在於，AI代理不只是「回答問題」，而是可能代表使用者採取行動，因此治理重點必須擴及部署流程、工具授權、資料分級、人工覆核與例外處置。換言之，企業需要在制度上先定義哪些業務可以交由代理執行、哪些情境必須人工核准、哪些資料永遠不得直接暴露給AI代理。
最後，在核心原則上，可採納近年提出的「Agents Rule of Two」作為一項資安準則。這項準則強調，AI代理在單一工作階段中，不應同時持有超過兩種「高風險能力」。所謂的高風險能力，主要涵蓋三個面向：
- 處理不可信任的輸入資料：例如來自外部的電子郵件或文件所夾帶惡意的提示詞注入，進而導致敏感資料外洩、檔案被竄改，甚至觸發任意指令的執行。
- 存取敏感系統或私人資料：當AI代理被授予接觸敏感資料的權限時（例如私人使用者資料或公司機密，原始碼或生產環境設定，資料庫連線資訊、API金鑰、權限配置、網路安全規則、服務端點等），便存在高度風險。不論是故意濫用或因誤解指令而操作，都可能洩露機密資訊或破壞安全設定。
- 改變系統狀態或對外通訊：AI代理若能修改檔案、更新設定、觸發生產系統中的操作或向外部端點傳送數據，可能導致資料外洩或未經授權的通訊。
若在同一工作階段中，AI代理同時具備上述三項能力，便可能導致敏感資產不受控制的存取或外洩。若業務確實需要這樣的功能需求，AI代理不應完全自主運作，而應透過人工核准或其他可靠的驗證機制進行監督，如此才能防止小錯誤或誤解演變成重大影響的後果。
七、實務上可採取的基本措施 – 代結論
以下措施可作為在使用AI代理時，最大限度降低資安風險的基準。
首先，應將AI代理部署在與生產系統隔離的獨立虛擬機或容器環境中，以最大限度減少其對內部資源與外部網路的暴露。其次，必須嚴格遵循「最小權限原則」（Principle of Least Privilege），僅授予代理完成任務所需的最低存取權限，避免過度授權。企業也應建立一份嚴格的白名單（allowlist），明確列出AI可以互動的工具與整合資料，確保所有外部內容都被視為潛在威脅來源，並在程式碼啟用前完成審查與簽署。
在正式部署前，透過「對抗式演練」（adversarial exercises）與「紅隊模擬」（red team simulations）來測試高風險流程，是檢驗防護機制的重要步驟。AI代理也必須納入企業既有的漏洞管理流程，確保整體數位資產維持一致的安全標準。同時，所有工具的使用情況與資料存取儘量完整記錄，以確保問責性與後續稽核。最後，企業必須建立清楚的治理架構，明確界定AI代理系統的所有權與責任歸屬。
總之，AI代理雖能帶來顯著的營運效益，但若企業選擇探索這類平台的應用，就必須以對待高權限技術的審慎態度來進行部署，而非將其視為一般消費型聊天機器人。唯有從一開始即建立結構化的治理機制與嚴格的存取控制，企業才方能在維持安全環境的同時，充分發揮AI代理的優勢。(7625字；圖1)
[1] 指AI代理在被要求停止運作時，試圖阻止或迴避被關閉的行為。
[2] 一種由AI輔助的全新程式設計方式，開發者無需精通程式語法，只需透過自然語言描述需求，AI就會自動生成、修正代碼。這種「靠感覺、憑直覺」寫程式的方法，將重點從語法細節轉向創意與功能實現，適合快速製作MVP（最小可行性產品）。
[3] RLS是一種存取控制機制，用以確保不同使用者只能存取自己權限的資料。
[4] 請參https://stable-learn.com/zh/openclaw-security-supply-chain-attack/?utm_source=copilot.com
[5] Shodan是一個專門用來搜尋「連上網路的設備」的搜索引擎，它不像Google專注於網頁，而是能找到伺服器、路由器、攝影機、工控系統等任何暴露在公網的裝置。這也是為什麼它常被稱為「世界上最危險的搜索引擎」。
[6] 級聯故障是指單一代理受損引發的連鎖性系統崩潰。
[7] 目錄沙盒是一種安全隔離機制，其核心目的只有一個：限制AI代理只能看見並操作你「允許」它接觸的特定資料夾，而對系統的其他部分完全「失明」。
[8] 配置漂移是一個在IT維運、雲端架構和網路安全中非常核心的概念。簡單來說，它指的是「系統的實際狀態」與「原始定義的標準狀態」之間，會隨著時間推移而在系統環境上產生的落差。
作者資訊：
陳家駿 台灣資訊智慧財產權協會 理事長
許正乾 因子數據股份有限公司 共同創辦人
參考資料：
What is OpenClaw, and Why Should You Care? JDSUPRA, 2026/2/3
Agentic AI Risk-Management Standards Profile.UC Berkeley/CLTC, 2026/2
OWASP Top 10 for Agentic Applications (2026): What Developers and Security Teams Need to Know. Aikido, 2025/12/10
OpenClaw Sparks Numerous Security and Legal Concerns. Vision Times, 2026/2/7
OpenClaw (formerly Moltbot, Clawdbot) May Signal the Next AI Security Crisis. Paloalto Networks, 2026/1/29
OpenClaw: Evolving Opportunities and Challenges Surrounding Agentic AI. Steptoe, 2026/2/10
OpenClaw and the hidden dangers of agentic AI. Mishcon de Reya, 2026/2/23
From Clawdbot to Moltbot: How a C&D, Crypto Scammers, and 10 Seconds of Chaos Took Down the Internet's Hottest AI Project. DEV, 2026/1/27
From Clawdbot to Moltbot to OpenClaw: Trademark friction strikes viral AI agent. Linkedin/ Henning Steier, 2026/1/28
Social media for bots takes off, sparking concern and skepticism. Los Angeles Times, 2026/2/6
Moltbook: Security Risks in AI Agent Social Networks and Minimum Mitigation Strategies. Substack, 2026/1/31
OpenClaw agents on Moltbook: Risky instruction sharing and norm enforcement in an agent-only social network. arXiv, 2026/2/2
From secure agentic AI to secure agentic web: Challenges, threats, and future directions. arXiv, 2026/3/2
What is Moltbook? The social network for AI agents. DigitalOcean, 2026/2/10
Moltbook database breach: Why OpenClaw + Moltbook can no longer be trusted. SecureMolt Research, 2026//2/6
--------------------------------------------------------------------------------------------------------------------------------------------
【聲明】
1.科技產業資訊室刊載此文不代表同意其說法或描述，僅為提供更多訊息，也不構成任何投資建議。
2.著作權所有，非經本網站書面授權同意不得將本文以任何形式修改、複製、儲存、傳播或轉載，本中心保留一切法律追訴權利。
|