OpenClaw是一個開源、可自託管的代理型AI運行時（agentic AI runtime）。截至2026年3月下旬，在Github官網（世界上最大的代碼託管平臺）上約有340k的關注，可通過WhatsApp、Telegram、Slack等平臺與用戶交互，並接入工具、記憶和多代理路由能力[2]。

1.據SecurityScorecard STRIKE 團隊於2026年2月披露並被多家媒體轉述，其對OpenClaw暴露面的網絡測繪曾識別出28,663個承載公開暴露控制面板的唯一IP地址，其中12,812個被標記爲存在遠程代碼執行風險，約63%的被觀測部署被歸類爲可利用狀態；相關declawed看板爲即時更新數據，約每15分鐘刷新一次，故上述數字應理解爲特定時間窗口內的動態快照，而非恆定總量[3]。

2.Microsoft明確建議，就OpenClaw當前形態而言，應預設其運行時可能受不受信任輸入影響、其持久狀態可能被篡改，且宿主環境可能經由代理而暴露；因此，其不宜運行於標準個人或企業工作站，而應僅在隔離環境中，以專用、低權限憑證和非敏感數據進行評估[5]。

3.Bitdefender於2026年2月5日披露，其在2026年2月第一週分析的OpenClaw skills 中，約17%表現出惡意行爲[8]。

TapTap(点点)官方网站

圖 1 代理系統六層執行鏈 / Figure 1: Six-Layer Execution Chain

在代理系統中，權限配置決定潛在損害的作用半徑，上下文輸入決定指令污染的進入路徑，外部組件決定供應鏈風險的暴露方式，持久狀態則決定風險是否會跨任務累積並持續放大。圖1所示六層執行鏈揭示的，是代理系統“如何運行”的技術邏輯；但法律分析並不需要對六個層面逐層機械對應具體義務，而是應從中識別出足以改變處理活動性質、範圍、目的與風險邊界的關鍵控制點。就此而言，六層執行鏈可進一步收束爲四類具有直接法律意義的技術節點：其一，執行層的身份與憑證問題，即誰授權代理以何種身份行動；其二，輸入層至模型層的上下文污染問題，即不可信外部內容如何進入控制上下文並影響決策；其三，工具層的第三方組件問題，即誰對skills及外部API的安全性、權限邊界與數據流向承擔審查責任；其四，狀態層的持久記憶問題，即一次寫入爲何可能在後續任務中被持續調用並放大影響。

這一分析框架並非任何單一監管文件的逐字表述，而是對公開安全研究和監管指引的綜合歸納。但值得注意的是，AEPD（Agencia Española de Protección de Datos，西班牙數據保護局）在其2026年2月發佈的代理式AI指南（Agentic Artificial Intelligence from the Perspective of Data Protection）中，爲這一框架提供了直接的監管呼應：該指南明確指出，組織不能僅以“使用者”視角理解代理系統，而應理解其技術基礎、能力邊界、侷限及具體實現方式；代理式AI作爲處理活動的實現手段，會改變處理活動的性質，並可能進一步改變其場景、範圍、目的與內生風險[9]。AEPD還以“Accept the possibility of failure”爲專門標題，要求組織按安全失敗原則預先設計控制結構——這恰好對應本文四個節點中每一個的治理邏輯：不是假定代理不會犯錯，而是在每個風險凝聚點預設約束、留痕與回滾能力[9]。

前述執行鏈所呈現的，不僅是代理系統的技術運行結構，也是其風險生成、傳導與擴張的基本路徑。進入法律評價後，分析重心不再停留於模型輸出是否準確，而應轉向系統在具體部署中的四個關鍵技術節點。由此，合規審查的核心亦相應轉化爲：企業是否已圍繞上述關鍵技術節點建立起與風險相適應的權限控制、流程約束、第三方治理及事件響應機制。

1、權限配置義務，防止未經授權的身份複用與過度授權

對OpenClaw而言，並不是單純的“模型可能出錯”，而是該類自託管代理會在同一運行環境中同時處理不受信任輸入、加載外部skills，並以有效憑證持續執行操作。這意味着，一旦代理被賦予郵箱、文件系統、終端、代碼倉庫、SaaS API或內部控制面的訪問權，風險的重心就從“回答是否正確”轉向“權限是否被過度放大、邊界是否被錯誤繼承”。Microsoft進一步指出，代理運行時的安全邊界至少包括identity、execution與 persistence三個組成部分：它使用什麼身份、能夠執行哪些改變狀態的動作、以及能夠以何種方式將影響持續保留下來[5]。

在中國法下，首先對應的是“權限設計與安全控制義務”，而不是抽象的AI特別義務。《中華人民共和國個人信息保護法》（以下簡稱“個保法”或“PIPL”）第51條要求個人信息處理者根據處理目的、處理方式、個人信息種類、對個人權益的影響以及可能存在的安全風險，採取相應措施確保處理活動合規，並防止未經授權的訪問以及個人信息泄露、篡改、丟失；其中，第（四）項特別要求“合理確定個人信息處理的操作權限”。《中華人民共和國網絡數據安全管理條例》（以下簡稱“網絡數據安全管理條例”）第9條則進一步要求網絡數據處理者在等級保護基礎上，加強網絡數據安全防護，建立管理制度，並採取加密、備份、訪問控制、安全認證等技術措施，對所處理網絡數據的安全承擔主體責任。由此可見，在企業部署代理系統的場景下，若仍以共享賬號、長期令牌、默認全盤訪問或無隔離運行環境的方式讓代理接觸個人信息或其他網絡數據，法律上的核心問題在於企業是否已經在權限治理、訪問控制和運行邊界上違反了與風險相適應的基本安全要求[13][14]。

在歐盟法下，GDPR第25條（Data protection by design and by default）要求控制者在確定處理手段和實際處理過程中，將數據保護原則和必要保障嵌入系統設計，並確保默認情況下僅處理實現特定目的所必需的數據；第32條（Security of processing）則要求控制者和處理者採取適當的技術和組織措施，以確保與風險相適應的安全水平，並特別考慮未經授權訪問、泄露、篡改、丟失等風險。就代理系統而言，如果企業明知其會讀取郵件、文件、終端或其他高敏感業務系統，卻仍採用共享身份、過寬權限、長期令牌和普通工作站直連運行的方式部署，則其將面臨較大的舉證壓力：很難證明其在系統設計、默認訪問範圍和運行控制上，已經滿足GDPR關於 by design、by default 以及 security appropriate to the risk 的要求[9][15]。

2、目的限制義務，防止不可信內容進入控制上下文

當系統提示、用戶指令、外部網頁、郵件文本、附件內容以及工具返回值進入同一上下文，而系統又未能在架構上強制區分“數據”與“指令”時，模型就可能把外部內容中的隱藏要求誤當作應當執行的操作邏輯。Liu等在USENIX Security 2024 中已將提示詞注入(prompt injection)形式化爲：攻擊者通過修改目標任務的數據，使大語言模型集成應用(LLM-integrated application)轉而完成攻擊者選擇的注入式任務(injected task)，而非用戶原本的目標任務(target task)[10]；OWASP 亦將間接提示詞注入(indirect prompt injection)明確定義爲來自網站、文件等外部來源的內容改變模型行爲[11]；對 OpenClaw這類代理而言，Microsoft指出，攻擊者可將惡意指令嵌入代理讀取的內容中，從而引導工具調用，甚至修改其持久狀態；因此，組織應按“運行時可能受到不受信任輸入影響”的前提配置防護邊界[12]。

在中國法下，《個保法》第5條要求處理個人信息遵循合法、正當、必要和誠信原則；第6條要求處理應具有明確、合理的目的，與處理目的直接相關，並採取對個人權益影響最小的方式。若企業部署的代理因爲外部郵件、網頁或文檔中的隱藏內容而誤將內部文件外發、誤調用工具或誤變更處理路徑，則問題不宜僅表述爲“模型受攻擊”，而應表述爲，企業未在系統設計中將外部數據與內部控制指令有效隔離，致使處理活動偏離原定目的並超出最小必要範圍。進一步地，若該類代理對個人權益產生重大影響，或者事實上構成利用個人信息進行自動化決策，還應考慮《個保法》第55條、第56條下的事前個人信息保護影響評估義務。

在歐盟法下，只要代理處理個人數據，且外部內容可能改變其處理路徑，控制者就需要首先面對GDPR第5條所要求的目的限制與數據最小化原則，以及第25條、第32條關於by design/by default 和與風險相適應安全水平的要求。AI Act Service Desk 進一步確認，AI agents 並非獨立法類，是否進入高風險軌道取決於具體用途；因此，只有當代理被用於招聘、篩選候選人、分析申請材料或評價候選人等 Annex III 第4(a) 項場景，或用於信用評估等Annex III 第5(b) 項場景時，纔會在 GDPR 之外疊加《人工智能法案》（AI Act ）的高風險義務。換言之，《人工智能法案》不是第二節點的一般法基礎，而是用途特定的強化義務[16][17]。

3、數據提供安全保障義務，防止第三方組件治理失控

ClawHub官方將其定位爲OpenClaw的公開技能與插件註冊表；其GitHub倉庫亦明確說明，平臺既提供text-based skills，也提供代碼插件( code plugins) 與打包插件( bundle plugins)的目錄與分發能力。就企業治理而言，這些skills/plugins不宜僅被視爲“功能增強項”，而應被視爲能夠擴展代理執行面、引入外部依賴並可能改變數據流向的第三方能力包[7]。

在中國法下，若第三方組件、其開發者或其後端服務實際接收、存儲、傳輸或代表企業處理個人信息或重要數據，則網數安全管理條例第12條直接要求企業通過合同等約定處理目的、方式、範圍和安全保護義務，並對接收方履約情況進行監督，相關處理記錄至少保存3年；如進一步涉及個人信息或重要數據跨境流動，還需分別判斷個保法第38條及網數安全管理條例第35-38條項下的數據出境路徑與範圍控制要求。反之，若企業只是本地安裝某個組件，尚未形成向外部主體“提供數據”或“委託處理數據”的關係，則網數安全管理條例第12條未必直接適用，但企業仍需承擔一般性的組件準入、權限控制、審計留痕和運行安全責任。對於像ClawHub這類平臺/分發場景，網數安全管理條例第40條、第41條還要求平臺通過規則或合同明確第三方產品與服務提供者的數據安全義務，並建立覈驗與處置機制[13][14]。

此外，如果企業後續通過代理系統向境內公衆提供生成式AI服務，則需疊加《生成式人工智能服務管理暫行辦法》的特別要求，包括算法備案、內容標識、安全評估等義務。但對純內部部署且未向公衆提供服務的場景，該辦法第2條第3款已明確排除適用[18]。

在歐盟法下，第三方組件治理同樣應區分“處理者安排”與“供應鏈安全”。若某一 skill/plugin的開發者、託管方或其後端服務代表企業處理個人數據，則GDPR第28條關於processor / sub-processor的選擇、授權和合同安排將直接適用；第32條則要求 controller 與processor 採取與風險相適應的安全措施。若尚未形成 processor關係，企業也不能因此免於治理義務，因爲第三方組件仍可能通過外部API、日誌、遙測、雲調用或動態安裝機制重塑系統的風險暴露面。至於《人工智能法案》，罰則必須分層理解：Article 99下3500萬歐元或7%全球營業額的上限（選取較高者）主要針對Article 5的禁止性實踐，而對其他多數運營者義務的違反，通常適用1500萬歐元或3%的上限（選取較高者）；因此，“AI Act 最高 7%”並不能被泛化爲一切代理式AI合規問題的統一罰則[16]。

4、應急保障義務，防止持久狀態與持續性風險

本節點特殊性在於，代理風險並不一定以一次性事件的形式爆發，而可能以“狀態被污染—後續持續執行—影響逐步擴散”的方式展開。OpenClaw的memory以workspace中的Markdown文件保存，其中MEMORY.md構成長週期記憶，日記式memory文件則承載運行上下文；官方文檔明確指出，這些文件本身即爲agent的 “source of truth”。因此，持久狀態不是附屬緩存，而是後續任務得以延續和放大影響的結構性載體[5]。

從安全結構看，持久狀態的法律意義，不在於其“存儲了什麼”，而在於它能夠把一次成功注入轉化爲跨會話、跨任務的持續性控制。Microsoft指出，在無防護部署中，agent的persistent state/memory可能被修改，進而在後續長期遵循攻擊者提供的指令；Kaspersky亦指出，單次成功注入即可污染agent的memory，並在長期內持續影響其行爲。換言之，這裏的風險不只是一次性泄露或一次性誤操作，而是一次污染可以在之後多個任務中不斷複用和放大[22]。

在中國法下，個保法第57條規定，發生或者可能發生個人信息泄露、篡改、丟失的，個人信息處理者應當立即採取補救措施，並通知履行個人信息保護職責的部門和個人；網數安全管理條例第11條則要求網絡數據處理者建立網絡數據安全事件應急預案，事件發生時立即啓動，並在對個人、組織合法權益造成危害時及時通知利害關係人。對於代理系統而言，難點在於：memory poisoning往往並不以一個邊界清晰的“單點事故”出現，而可能表現爲靜默、漸進、跨任務的異常執行。也正因如此，企業是否建立了state review、異常檢測、快速回滾、證據保全和通知判斷機制，將直接影響其能否證明自己已盡到法定義務。[13][14]。

在歐盟法下，第四節點首先落入GDPR第33條與第34條的數據泄露通知框架，並由AEPD的agentic AI指南進一步細化。GDPR第33條要求控制者（controller）在知悉個人數據泄漏後履行“不當延誤”地通知義務，原則上不遲於72小時；第34條則要求在個人數據泄露事件可能對自然人權利和自由造成高風險時通知數據主體。AEPD進一步以專門的“Memory control”章節指出，代理系統的memory與日誌本身可能形成對用戶的持續性畫像，因而應採取memory management、memory compartmentalization、strict retention periods、disabling persistent memory以及sanitization等控制措施，並特彆強調對persistent memory中信息的過濾與校驗，以防惡意注入持續存在。[9][15]。

1.中國：內部部署先回到通用義務框架

中國法下最常見的誤區，是將企業內部部署AI代理直接等同於《生成式人工智能服務管理暫行辦法》下的面向公衆服務。該辦法第2條明確規定，其適用對象是“利用生成式人工智能技術向中華人民共和國境內公衆提供”相關服務；第2條第3款進一步排除了“行業組織、企業、教育和科研機構……研發、應用生成式人工智能技術，未向境內公衆提供生成式人工智能服務的”情形[18]。因此，對多數企業內部代理場景而言，首要法律框架仍是《網絡安全法》《個人信息保護法》《數據安全法》和《網絡數據安全管理條例》，而非先行討論生成式AI備案或登記。

但這並不意味着內部部署“監管更輕”。只要代理接觸員工、客戶、患者、供應商或合作方信息，個人信息保護、網絡數據安全、自動化決策、第三方管理、事件響應和跨境傳輸等全套通用義務，不因“僅爲內部工具”而消失。如果代理後續向境內公衆提供服務，或疊加具有輿論屬性或社會動員能力的功能，再進一步討論備案、標識、算法管理等特別規則，纔是更穩妥的分析路徑[13][14][18]。

2.歐盟：GDPR與AI Act並行，而非二選一

AI Act Service Desk已明確確認，在《人工智能法案》下，AI agents不是單獨的一類——它們通常落入AI system與/或GPAI model的既有定義[17]。穩妥的分析路徑是先問用途，再問分類：代理被用於招聘篩選自然人，可能進入Annex III第4(a)項高風險用途；一般辦公自動化則通常不會自動進入高風險軌道[16][17]。

與此同時，只要代理處理個人數據，GDPR框架就不會因其“屬於AI”而退出適用。AEPD指南已明確把agentic AI納入數據保護治理視野[9]。因而對歐盟業務，最穩妥的路徑不是在GDPR與AI Act之間“二選一”，而是把二者視爲並行層級：GDPR解決個人數據處理問題，AI Act解決特定用途與角色責任問題；同一事實下兩套義務完全可能同時觸發[9][15][16]。

3.美國：分散規制，場景依賴

與數據保護立法一樣，美國目前不存在統一的聯邦AI綜合立法框架，但這不等於監管風險較低。企業需依業務場景分別審視以下並行義務。

（1）FTC Section 5義務。FTC對不正當/ unfair 或欺騙/deceptive的行爲擁有廣泛執法權。當代理因配置不當導致消費者數據泄露，或企業對代理能力的宣傳與實際安全水平不符時，均可能構成 FTC執法的觸發條件。FTC近年已多次就AI相關的不公平和欺騙性行爲發出執法警告[19]。

（2）HIPAA。若代理接入醫療信息系統並接觸ePHI（electronic Protected Health Information），則HIPAA Privacy Rule 與 Security Rule 關於confidentiality, integrity and availability的要求將直接適用。代理以高權限讀取患者記錄卻缺乏審計日誌和訪問控制，與HIPAA Security Rule 的access control 和 audit controls標準存在直接衝突[20]。

（3）DOJ Data Security Program。該規則自2025年4月8日起生效，對美國政府相關數據和美國人大宗敏感個人數據向“countries of concern”的流動建立了類似出口管制的限制框架。若代理系統的skills、插件或API調用涉及向上述國家的數據傳輸，企業須判斷是否構成DSP下的prohibited或restricted交易[21]。

美國法的特點是規則分散、執法分流、場景依賴更強。對企業而言，最危險的認知不是“不知道有AI法”，而是誤以爲“不是AI特別法就不重要”。代理一旦接入消費者數據、健康數據、員工數據或跨境數據流，可能迅速落入多個並行義務之中。

圖 3 四個技術節點與三法域法律義務映射 / Figure 3: Four Nodes → Three-Jurisdiction Mapping

注1：本圖將《中華人民共和國個人信息保護法》縮寫爲“PIPL”；《網絡數據安全管理條例》縮寫爲“條例”。注2：本圖展示的法律義務（如“72h breach 報告”、“風險導向安全義務”等）系作者基於代理型AI的技術特性對相關法律核心條款的合規提煉與實務映射，旨在揭示風險邏輯，而非法律條文的逐字引用。

鑑於上述分析，我們提出如下合規建議。

（1）影子代理盤點。“企業未採購”不等於“內部不存在代理”，應先識別哪些團隊、賬號和流程已將模型輸出接入可執行控制面[8]。

（2）權限重構。代理應被視爲高權限非人身份，禁止共享賬號、長期令牌和默認全盤訪問，改用最小必要、短期、可撤銷授權[5]。

（3）上下文隔離。外部輸入、系統策略、用戶指令和工具返回值應分層處理；對外發、刪除、付款、配置變更等關鍵動作設置二次確認和人機門控[10][11][12]。

（4）第三方準入。skills、plugins及外部API不只是功能擴展，更是新的執行面和數據流入口，應納入盡調、代碼審查、合同約束和持續審計[7][8][14]。

（5）持久狀態保護。對memory、日誌和歷史任務記錄建立完整性校驗、留存期限、分艙管理和異常檢測，防止單次污染跨會話持續放大[6][9]。

（6）事件響應預案。預先設計停機、隔離、回滾、取證和通知路徑，使組織能夠證明其已預見失敗並具備應對能力[9][13][14]。

代理式AI系統（agentic AI system）並不是單純的信息生成工具，而是可能進入企業控制面的新型執行主體。對這類系統的法律評價，也因此不能停留在“生成內容是否準確”這一傳統問題上，而應回到更根本的治理命題：企業是否在引入自動化能力的同時，仍然保有對權限、邊界、狀態與責任的最終控制。真正的合規需要在系統必然可能失誤的前提下，仍然能夠證明組織已預先設計了足夠的約束、留痕與糾偏機制。

免責聲明：本文僅供信息參考之用，文中分析基於截至2026年3月30日的公開信息，相關法律法規和監管指引可能發生變化。如需針對具體業務場景的合規評估，請聯繫本所相關業務團隊。

參考文獻:

[1] OpenAI, "Function calling," https://platform.openai.com/docs/guides/function-calling

[2] OpenClaw GitHub Repository, https://github.com/openclaw/openclaw

[3] SecurityScorecard STRIKE Team, "Beyond the Hype: Moltbot’s Real Risk Is Exposed Infrastructure" (Feb. 9, 2026), 

https://securityscorecard.com/blog/beyond-the-hype-moltbots-real-risk-is-exposed-infrastructure-not-ai-superintelligence/

[4] GitHub Advisory GHSA-g8p2-7wf7-98mq, CVE-2026-25253, https://github.com/advisories/GHSA-g8p2-7wf7-98mq

[5] Microsoft Security Blog, "Running OpenClaw safely: identity, isolation, and runtime risk" (Feb. 19, 2026), 

https://www.microsoft.com/en-us/security/blog/2026/02/19/running-openclaw-safely-identity-isolation-runtime-risk/

[6] OpenClaw Docs, "Memory," https://docs.openclaw.ai/concepts/memory

[7] GitHub, openclaw/clawhub (public skill registry), https://github.com/openclaw/clawhub

[8] Bitdefender, "Technical Advisory: OpenClaw Exploitation in Enterprise Networks," https://businessinsights.bitdefender.com/technical-advisory-openclaw-exploitation-enterprise-networks

[9] AEPD, Agentic Artificial Intelligence from the Perspective of Data Protection (V1.1, Feb. 18, 2026), https://www.aepd.es/en/guides/agentic-artificial-intelligence.pdf

[10] Y. Liu et al., "Formalizing and Benchmarking Prompt Injection Attacks and Defenses," USENIX Security Symposium 2024 ，

https://doi.org/10.48550/arXiv.2310.12815

[11] OWASP, "2025 Top 10 for LLM Applications: LLM01 Prompt Injection," https://genai.owasp.org/llmrisk/llm01-prompt-injection/

[12] Microsoft Learn, "Defend against indirect prompt injection attacks," https://learn.microsoft.com/en-us/security/zero-trust/sfi/defend-indirect-prompt-injection

[13] 《中華人民共和國個人信息保護法》 (PIPL),https://www.cac.gov.cn/2021-08/20/c_1631050028355286.htm

[14] 《網絡數據安全管理條例》, https://www.gov.cn/zhengce/content/202409/content_6977766.htm

[15] GDPR, Regulation (EU) 2016/679, EUR-Lex, https://eur-lex.europa.eu/eli/reg/2016/679/oj/eng

[16] Regulation (EU) 2024/1689 (AI Act), EUR-Lex, https://eur-lex.europa.eu/eli/reg/2024/1689/oj/eng 

[17] AI Act Service Desk, FAQ, https://ai-act-service-desk.ec.europa.eu/en/faq

[18] 《生成式人工智能服務管理暫行辦法》 , https://www.cac.gov.cn/2023-07/13/c_1690898327029107.htm

[19] FTC, Privacy & Security Enforcement, https://www.ftc.gov/news-events/topics/protecting-consumer-privacy-security/privacy-security-enforcement

[20] HHS, HIPAA for Professionals, https://www.hhs.gov/hipaa/for-professionals/index.html

[21] DOJ NSD, Data Security Program, https://www.justice.gov/nsd/data-security

[22] Kaspersky, "AI agents in your organization: managing the risks," https://me-en.kaspersky.com/blog/top-agentic-ai-risks-2026/25171/

[23] Conscia, "The OpenClaw security crisis," https://conscia.com/blog/the-openclaw-security-crisis/