来源：天驰君泰法律评论
发布日期：2026年03月31日
2026年第一季度，以OpenClaw为代表的自托管代理型AI运行时（self-hosted agentic AI runtime）在企业环境中快速扩散。与传统“只生成内容”的大模型应用不同，这类系统把语言模型、工具调用（tool call）、真实凭证、外部执行与持久状态整合为一个连续执行闭环。OpenAI的函数调用文档明确区分了“模型提出 tool call”与“应用侧执行”的角色分工 [1] ——这意味着企业需治理的不仅是模型输出，更是权限边界、工具准入、状态管理与异常中止能力。本文以OpenClaw为例，围绕身份/权限、上下文、第三方skills、持久状态四个技术节点，分析其如何映射到日常合规义务中。
一、从“生成”到“执行”：代理式AI系统的范式转变
OpenClaw 是一个开源、可自托管的代理型 AI 运行时 （ agentic AI runtime ） 。截至 2026 年3 月下旬，在 Github 官网（世界上最大的代码托管平台）上约有340k 的关注，可通过WhatsApp 、 Telegram 、 Slack 等平台与用户交互，并接入工具、记忆和多代理路由能力 [2] 。
OpenAI官方文档把 tool/function calling的机制描述得很清楚：模型提出工具调用，应用侧执行，结果再送回模型，形成多轮闭环 [1] 。一旦邮件、文件、终端、SaaS API 被接入这个闭环，法律分析的重心就必须从内容风险前移到控制结构风险。
这类系统之所以受到各界关注，在于它把模型推断直接接入了真实系统的控制面：
-
据SecurityScorecard STRIKE 团队于2026 年2 月披露并被多家媒体转述，其对 OpenClaw 暴露面的网络测绘曾识别出28,663 个承载公开暴露控制面板的唯一IP 地址，其中12,812 个被标记为存在远程代码执行风险，约63% 的被观测部署被归类为可利用状态；相关declawed 看板为实时更新数据，约每15 分钟刷新一次，故上述数字应理解为特定时间窗口内的动态快照，而非恒定总量 [3] 。 -
Microsoft 明确建议，就 OpenClaw 当前形态而言，应预设其运行时可能受不受信任输入影响、其持久状态可能被篡改，且宿主环境可能经由代理而暴露；因此，其不宜运行于标准个人或企业工作站，而应仅在隔离环境中，以专用、低权限凭证和非敏感数据进行评估 [5] 。 -
Bitdefender 于 2026 年2 月 5 日披露，其在 2026 年2 月第一周分析的 OpenClaw skills 中，约17% 表现出恶意行为 [8] 。
二、执行链解析与法律评价的转向
图 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 、目的限制义务，防止不可信内容进入控制上下文
图 2 间接提示注入攻击路径 / Figure 2: Indirect Prompt Injection Attack Pa t h
当系统提示、用户指令、外部网页、邮件文本、附件内容以及工具返回值进入同一上下文，而系统又未能在架构上强制区分 “ 数据 ” 与 “ 指令 ” 时，模型就可能把外部内容中的隐藏要求误当作应当执行的操作逻辑。 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] 。
四、三法域规则落地：先看业务，再看法源
-
中国：内部部署先回到通用义务框架
=======================
中国法下最常见的误区，是将企业内部部署AI 代理直接等同于《生成式人工智能服务管理暂行办法》下的面向公众服务。该办法第 2 条明确规定，其适用对象是 “ 利用生成式人工智能技术向中华人民共和国境内公众提供 ” 相关服务；第 2 条第 3 款进一步排除了 “ 行业组织、企业、教育和科研机构 …… 研发、应用生成式人工智能技术，未向境内公众提供生成式人工智能服务的 ” 情形 [18] 。因此，对多数企业内部代理场景而言，首要法律框架仍是《网络安全法》《个人信息保护法》《数据安全法》和《网络数据安全管理条例》，而非先行讨论生成式 AI 备案或登记。
但这并不意味着内部部署 “ 监管更轻 ” 。只要代理接触员工、客户、患者、供应商或合作方信息，个人信息保护、网络数据安全、自动化决策、第三方管理、事件响应和跨境传输等全套通用义务，不因 “ 仅为内部工具 ” 而消失。如果代理后续向境内公众提供服务，或叠加具有舆论属性或社会动员能力的功能，再进一步讨论备案、标识、算法管理等特别规则，才是更稳妥的分析路径 [13][14][18] 。
-
欧盟： 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] 。
-
美国：分散规制，场景依赖
与数据保护立法一样，美国目前不存在统一的联邦 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),
[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),
[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,"
[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,
[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/
