Agentic AI 正在重塑企业运营。与只响应提示词的对话式模型不同，智能体框架会持续运行、跨会话保持状态、调用外部工具、执行系统命令，并在无需等待人工指令的情况下自主行动。这也带来了传统 AI 治理体系尚未充分覆盖的新型安全风险。

OpenClaw 已成为部署最广泛的 Agentic AI 框架之一。自 2025 年 11 月发布以来，截至 2026 年 4 月，其 GitHub Star 数已达到 36.3 万，采用速度超过 React 和 Linux 内核。医疗机构、企业运营团队以及个人工程师都在使用 OpenClaw，其自然语言交互和任务自动化能力成为主要吸引力。

但其应用速度已经明显超过安全建设。

研究人员发现，互联网上存在 20,125 个经过指纹确认的 OpenClaw 实例，其中 79.67% 运行在云基础设施上。更值得关注的是，22% 的企业在安全团队尚不知情的情况下，就已经发现内部存在未经授权的 OpenClaw 部署。

这实际上是影子 IT 问题在 Agentic AI 时代的放大版本，而这些未经授权的部署所拥有的权限，往往比传统 SaaS 应用高出多个数量级。

研究发现了什么

研究团队从六个关键维度分析了 OpenClaw 的攻击面，包括：

• 网络暴露

• 身份认证与凭证存储

• 提示词注入行为

• 模型上下文协议（MCP）集成

• 第三方 Skill 带来的供应链风险

• 与部署方式相关的漏洞

研究结果显示，OpenClaw 并不是创造了完全新的 Agentic AI 风险，而是其设计放大了这类系统原本就存在的安全问题，而且放大程度相当明显。

2026 年 5 月的扫描共发现 30,366 个候选端点。

其中，DigitalOcean 托管的实例占比最高，为 27.2%；其次是阿里云，占 21.2%；腾讯云占 9.4%。

大量实例集中在面向个人用户、价格较低的云基础设施上，这表明许多公网暴露实例很可能运行在个人工程师账户中，而非企业正式租户。

云厂商提供的一键部署模板也成为意外暴露的重要来源。许多用户跳过了反向代理配置步骤，导致 OpenClaw 管理面板直接通过云服务提供商默认端口暴露在公网。

管理面板可能成为最薄弱环节

如果 OpenClaw 的管理面板没有认证，或认证机制过弱，攻击者可能直接实现完全接管。

攻击者可以窃取配对令牌，在大语言模型（LLM）连接链路中建立“中间人”位置，从而静默代理所有请求和响应。

更严重的是，管理面板还提供 Shell 访问能力。

这意味着，原本只是 API 层面的控制，很快可能升级为主机级控制。如果 OpenClaw 运行在绑定公网 IP 的云 VPS 上，就可能演变成近乎“一键式”的远程代码执行。

凭证以明文形式存储

OpenClaw 会将 LLM API Key、消息平台令牌以及会话历史，以明文形式存储在 ~/.openclaw/ 目录下的 SQLite 数据库中。

一旦本地进程被攻陷、恶意 Skill 被安装，或未隔离的 MCP Server 获得访问权限，就可能直接读取该目录，并将凭证外传到任意外部系统。

这些并非短期有效的临时令牌，而是可能直接关联：

• LLM API 账户

• 企业消息基础设施

• 已保存的历史会话

因此，一次本地权限突破就可能迅速扩大影响范围。

威胁可能隐藏在运营人员意想不到的位置

来自运营人员直接输入内容的提示词注入，只是风险的一部分。

OpenClaw 会持续处理来自外部的数据，包括访问的网页、读取的电子邮件、解析的 API 响应以及检索到的各种记录。

攻击者可以利用这些外部数据源植入恶意内容，从而劫持 Agent 的目标和行为。

与此同时，不同 LLM 提供商之间的安全护栏表现并不一致。

同一个输入，GPT-4 可能会拒绝执行，而通过 Ollama 运行的本地模型却可能接受。

这意味着，即使 OpenClaw 本身的工作流没有变化，底层模型不同，也可能导致完全不同的安全结果。

MCP Server 缺乏隔离机制

模型上下文协议（MCP）允许 OpenClaw 调用外部服务和工具，但 MCP Server 本身并没有默认运行在沙箱中。

这意味着，未隔离的 MCP Server 会继承 OpenClaw 的完整权限。

一旦 MCP Server 被攻陷，攻击者就可能进一步横向进入后端系统。

恶意 MCP Server 则可能采取另一种方式：通过污染返回结果，干扰 Agent 的推理过程和输出结果，而且这种行为可能不会被及时发现。

第三方 Skill 缺乏有效审查

截至 2026 年 4 月，OpenClaw 的 Skill 市场 ClawHub 已拥有超过 1700 个社区提交的集成组件，而这些 Skill 都可能以完整的 Agent 权限运行。

研究人员已经确认，市场中存在用于窃取凭证的恶意内容。

此前的研究还发现，部分 OpenClaw Skill 被用于传播 Atomic macOS Stealer。

更值得关注的是，ClawHub 在发布前并没有强制执行统一的安全审核机制。

也就是说，传统消费者应用商店中常见的“审核后上架”模式，在这里并不存在。

一键部署的便利也带来了隐藏代价

AWS Lightsail、DigitalOcean 等云服务商都提供 OpenClaw 模板化部署。

但不同云平台的默认安全配置存在明显差异。

例如，一些 Lightsail 的一键部署方案默认提供较强的安全设置，而 DigitalOcean 上的部分部署则需要用户额外完成配置，才能落实安全要求。

无论平台如何，运营人员都必须牢记云环境中的共享责任模型：最终，部署本身的安全配置仍由使用者负责。

部分模板仍然没有默认启用 Token 认证，而是依赖安装阶段的初始配置流程。

如果用户没有运行初始化脚本，或者脚本执行过程中被中断，管理面板就可能直接以未认证状态开放。

因此，让一键部署变得足够方便的设计，在默认安全能力不足时，也可能反过来成为风险来源。

为什么企业必须关注 OpenClaw 风险

在企业内部部署 OpenClaw，会形成一条跨越多个层面的攻击面，包括：

• 公网暴露的管理面板

• 凭证存储

• Skill 执行

• MCP 集成

• 后端系统访问

一个看似简单的配置错误，比如错误暴露端口、弱 Token，或者一个原本可信但后来被恶意修改的 Skill，都可能引发连锁反应，最终导致 Agent 被完全接管，并进一步横向移动到后端系统。

计划采用 OpenClaw 的组织，应在部署之前建立零信任架构。

网络分段、持续监控配置漂移、限制管理面板访问，以及严格审查所有第三方 Skill，都应该是部署前提，而不是后续可选增强项。

对于医疗以及其他受严格监管行业而言，风险更高。

如果患者数据通过 Agentic AI 框架处理，而该框架同时存在明文凭证存储和未经审查的第三方集成，企业就可能面临更严重的合规与法律责任风险。

因此，安全团队必须在部署开始之前，就充分理解这些风险。