全球最大的Web3安全公司CertiK，发布了针对Skill安全的最新研究:
1. OpenClaw、Skill与核心隐患
OpenClaw是一款开源、自托管的个人AI智能体平台，专为在本地设备或服务器上运行设计，支持长期记忆、自主运行、与主流大语言模型（LLM）集成，还可通过Telegram等即时通讯平台实现远程控制。
在实际应用中，OpenClaw的核心定位是代表用户执行操作。根据部署方式的不同，它可访问本地文件、调用工具、连接外部服务，以及在宿主环境（Host Environment）内执行命令。
如果把OpenClaw比作底层操作系统，那么Skill就是它上面的应用程序。Skill能够拓展智能体的能力边界，从网页搜索、社交内容发布等低风险任务，延伸至钱包操作、链上交互、系统自动化等高度敏感的领域。Skill在同一个运行时环境（供Skill代码运行、调度系统资源的专属环境）中执行，可能继承对本地资源、网络连接和工具接口的访问权限。
在高权限的智能体环境中，即便核心平台本身可信，也不能简单默认第三方Skill是安全的。而行业针对这一问题的通用解决方案，就是Skill扫描。
2. Clawhub如何审核Skill？
随着OpenClaw生态的不断扩张，Clawhub自然而然成为了其生态的应用市场层：开发者发布Skill，用户安装下载，整个生态通过第三方扩展持续壮大。
一旦平台开始分发运行在高权限环境下的第三方代码，某种形式的审核就变得不可避免。Clawhub也正是朝着这个方向发展，其审核流程从最初轻量化的信任模型，逐步演变为一套分层管控流程，已涵盖VirusTotal、基于AI的内部审核；以及于2026年3月8日在公共代码仓库上线的静态审核引擎。
从宏观来看，Clawhub目前的审核流程主要结合两大检测来源：VirusTotal与OpenClaw内部的审核系统。这两类扫描结果共同决定Skill的风险分类，以及用户在安装过程中是否会看到安全警告。
这一设计体现了行业内常见的一种权衡取舍：既要保持生态的开放性，又要向用户提示风险信号。一旦安装决策依赖于弹窗提示和用户确认，安全警告就开始承担部分安全防护的职责。而这一模式生效的核心前提，是运行时底层已经实现了有效的隔离机制。
面对这一问题，最直观的应对策略是增加更多的扫描、分类器和安全警告。但问题的核心，并非如何更精准地检测恶意Skill。扫描的确有助于风险分级，却无法成为安全边界。就像苹果公司并非仅靠App Store的审核来保障其生态安全，其核心依托的是操作系统强制实现的沙箱机制、权限管控与环境隔离。这一原则在此处同样适用：如果审核和弹窗提示承担了绝大部分防护工作，就说明运行时边界的防护作用严重不足。
OpenClaw确实具备沙箱机制和运行时管控的能力；但问题在于，这些能力主要是可选而非强制、管控粒度过粗，且高度依赖部署配置，无法作为第三方Skill的默认安全边界。OpenClaw官方文档也明确说明：基于Docker的沙箱机制是可选功能；沙箱关闭时，宿主工具仍可被调用；沙箱部署位置、工具策略、高权限宿主执行权限，均为独立配置项。
此外还存在一个实际部署层面的问题：如果一款沙箱使用门槛高、需要用户反复确认，或是会导致大量常用Skill功能失效，那么它在实际应用中就很难成为默认运行模式。用户和运维人员往往会为了保证系统可用性，放弃使用沙箱。而一旦出现这种情况，平台就只能退而依靠审核和警告，去承担它们从一开始就无力承载的安全防护重任。
3. 静态检测与其局限性
截至2026年3月8日（UTC时间），Clawhub的公共代码仓库已上线静态审核引擎，同步推出的还有结构化审核快照，以及整合后的VirusTotal与大语言模型检测结果处理机制。
该引擎的核心入口为moderationEngine.ts[1]字中的runStaticModerationScan()，代码检测的核心逻辑则位于scanCodeFile()中。
相比传统安全产品通常处理的输入对象，Skill的扫描难度更高，因为它们混合了代码、自然语言、清单文件、指令、工具调用逻辑和运行时行为。在这里，检测盲区绝非偶然现象，它们是该问题与生俱来的顽疾。
静态规则主要检测特定风险模式，例如：child_process与进程创建API、eval() / new Function()、矿相关字符串、可疑的WebSocket行为、文件读取与外发请求、process.env与网络发送行为，以及大型编码数据块。启发式过滤器，这些手段相当常见；但若将其视作安全边界，则显得极其脆弱。
这并非OpenClaw独有的问题，而是传统安全领域由来已久的教训。Web应用防火墙（WAF）可以检测特定的SQL注入模式，但攻击者只需轻微地重写、编码变换或token拆分，就能绕过规则检测，导致攻击载荷（payload）成为漏网之鱼。一旦表层特征发生改变，反病毒特征库就会无法识别变种。任何依赖可识别语法特征的防护机制，都对代码重写高度敏感。
Skill的特性进一步加剧了这一难题。它们并非协议载荷或固定格式的二进制文件，而是存在于一个更宽泛的范畴中：代码、清单、自然语言指令、已声明的功能、安装行为、运行时行为。这给了攻击者极大的操作空间，完全可以在保留恶意逻辑的前提下，改变代码的外在形式。
Clawhub静态规则中的一个典型例子，是将process.env环与外发网络行为结合判定为高风险信号。在当前的实现中，scanCodeFile()会先检索代码中的process.env，接着搜寻网络活动（如fetch，http.request，或axios）；若两者同时出现，就会触发高风险告警。
其设计初衷显而易见：拦截那些读取机密信息并将其外发泄露的代码。
但问题在于，实现语义完全等价的代码重写，难度极低。
核心逻辑保持不变，但语法的改变足以绕过这种机械的特征匹配。我们在后续的攻击载荷测试中，正是使用了这类重写方式来规避静态检测。这就是静态审核层无法改变核心安全现状的根本原因：它只能捕获低水平的恶意样本，在攻防对抗的环境中，它始终只是一种启发式过滤工具，而非安全边界。
4. AI检测与其局限性
静态扫描之后，下一层是基于AI的审核。与正则表达式类的检查相比，该层级的处理能力显著提升：它能够综合分析描述、指令与代码，并且更擅长识别可疑意图、语义不一致，或是与Skill声明用途不符的行为。
Clawhub使用的OpenAI提示词也印证了这一定位。其系统提示词[2]明确写道："你并非恶意软件分类器，而是逻辑一致性检测器。（You are not a malware classifier. You are an incoherence detector.）"提示词指出，标记为"安全"不代表"无风险"，也不代表Skill不存在漏洞。与此同时，该提示词要求模型区分无意的安全漏洞与蓄意的误导，将漏洞判定为可疑，将误导行为判定为恶意。
这个细节为我们揭示了该系统的优化重心。它的首要任务并非深度的漏洞可利用性分析，而是一致性校验：即评估一个Skill声明的用途，是否与其申请的权限、安装的组件、实际执行的功能相符。这就决定了它天然更擅长识别可疑意图，而非执行严格的漏洞挖掘。
AI能够发现漏洞，这一点毋庸置疑。真正的挑战在于，当面对融合了多文件、清单、自由格式指令、能力权限声明、安装逻辑及运行时行为的Skill时，AI能否实现稳定、全面的漏洞挖掘；这些Skill往往缺乏精确的安全规范作为基准。
因此，这类审核机制天然的薄弱点，就是"看似合理，但存在可利用漏洞"的Skill。模型或许能揪出明显的危险信号、可疑意图，或是描述与行为不符的破绽，但仍可能对潜伏在看似正常的工作流中的危险逻辑视而不见，导致漏报。
这一特性直接影响了我们的测试策略。我们没有采用粗劣的混淆技术来掩护那些特征明显的恶意载荷，而是开发了一款看似完全合理、无任何明显恶意特征的Skill，将漏洞嵌入到看似正常的开发代码逻辑中。
一个包含可利用漏洞的Skill，其危险性丝毫不亚于直接嵌入恶意代码的Skill。棘手之处在于，AI审核并不能轻易发现这些漏洞。识别明显的可疑意图是一回事，而识别隐藏在看似合理的工作流中的可利用逻辑，完全是另一回事。这就使得带有漏洞的Skill，成为了这类审核机制天然的检测盲区。
5.概念验证与待修复状态漏洞
敲定上述策略后，我们便着手进行概念验证（PoC）。彼时，公共代码仓库已经上线了新版静态审核引擎，但只需对语法进行微调，就能轻松绕过其检测规则。
我们首先向已通过审核、无明显警告信号的公开Skill中植入漏洞。测试结果显示，即使审查管线中的某些环节记录了可疑行为，这个"带漏洞但看似合理"的Skill也很少会被直接判定为彻底的恶意软件。
这就引出了一个更关键的问题：如果一个Skill在审核流程的某个环节被标记为可疑，是否能在不触发有效警告的情况下完成安装？我们的测试给出了肯定的答案。
Skill上传后，审核并非即时完成。OpenClaw内部的审核速度相对较快，而VirusTotal的检测可能会长时间处于"待处理"状态，有时需要数小时甚至数天才能返回最终结果。
在当时的实现逻辑中，只要Skill未被明确标记为恶意软件并被封禁，即便VirusTotal仍处于待处理状态，Skill也可以变为激活状态并对外公开。实际上，这就导致待处理的VirusTotal结果，几乎等同于"可对外发布的合格结果"。[3]
待处理的结果绝非安全结果，它仅意味着审核尚未完成。而问题的核心在于，Skill在处于待处理状态时，就已经可以对外公开并支持安装，这在实际场景中，会导致用户在安装环节将其视作安全的Skill。
我们定制的Skill------"test-web-searcher"，核心逻辑如下：
该漏洞的核心，在于一个微小但致命的细节：new URL(input, base)并不是一种过滤机制。如果input本身已经是一个绝对URL，那么base参数会被直接忽略。因此，一旦攻击者可控的数据进入formatFile变量，看起来像本地formatter路径的值，实际上可能被解析为一个data:或http:的绝对URL，从而改变运行时加载的模块来源。
我们刻意让这段逻辑看起来尽可能正常。将该值包裹在new URL()中，看起来就像一次常见的路径规范化处理，但实际上它并没有建立任何安全边界。这样的写法也更容易在AI审核中被判断为安全代码。为了进一步强化这种效果，我们还使用了一个由我们控制的域名，并将其设计得看起来像是一个合法的API接口。
当远程服务返回如下精心构造的攻击载荷时：
该Skill会导入攻击者可控的JavaScript代码，而非本地的格式化模块。
这正是本次测试的核心目的：并非开发一款明显带有恶意的Skill，而是打造一款看似合理、但将可利用漏洞隐藏在常规控制流中的Skill。
本次演示覆盖了三个Skill：我们定制的test-web-searcher，还包括应用市场上的两款公开Skill（self-improving-agent与clawpay-escrow）。
公开的安全Skill self-improving-agent顺利安装，未触发任何警告，这在我们的预期之内。我们定制的test-web-searcher，在VirusTotal仍处于待处理状态时，同样在无有效安全警告的情况下完成了安装。与之形成对比的是，公开的Skill clawpay-escrow却触发了安全弹窗，需要用户明确确认方可安装。
随后，我们通过Telegram向OpenClaw发送指令，调用了test-web-searcher。漏洞导入路径被成功触发，最终在宿主设备上实现了任意命令执行。在演示环境中，我们成功弹出了计算器程序，以此作为完成任意命令执行的证明。
演示视频：
这个存在漏洞的Skill，安装流程与安全Skill毫无差别。无论是通过命令行还是Telegram安装，全程都没有出现有效的安全警告。这暴露了问题的核心：审核信号被当作了真实安全边界的替代品，而一款高风险Skill，在安装环节的表现，却可以与安全Skill完全一致。
6. 检测机制失效的根本原因
我们设计的测试用例，并非复杂的对抗性样本。我们只是植入了一个漏洞，仅通过轻量级的代码变换来降低被检出的概率。真实的攻击者会做得更绝：他们会极其谨慎地隐藏攻击路径，将恶意逻辑伪装得贴近正常代码，以及针对审核流程做专门的对抗优化。绝不仅仅是"标为可疑却仍可安装"，而是那些被植入后门、却能成功骗过双层审核机制的危险Skill。
我们的概念验证已经足以勾勒出问题的严重性：静态检测规则可以通过代码重写绕过；AI审核虽有辅助作用，但相比于从看似合理的工作流中全面挖掘可利用逻辑，它显然更擅长曝光那些明显的危险信号；而依赖于非强制沙箱、部署规范或用户手动加固的运行时控制机制，根本无法可靠地阻止这些漏网的恶意代码入侵宿主设备。
综上，这些并非孤立的安全弱点，而是重度依赖审核的安全模型的必然局限。
检测机制依然有其存在的价值，它可以降低安全噪音、捕获低水平的恶意攻击，以及发现值得深入调查的风险信号。然而，捕捉可疑信号是一回事；要为运行在高权限环境下的第三方代码（Skill），设下一道真正的安全防线，则完全是两个概念。
平台必须树立底线思维，默认必定会有漏网的危险Skill成功渗透。一旦接受了这个前提，真正的核心问题就不再是"如何增加更多的审核环节"，而是"运行时是否能够遏制这些漏网的风险"。
目前，过高的安全期望仍被寄托在检测机制上，而检测机制注定无力承担此重任。
7. 安全建议与结论
对于AI智能体开发者而言，核心优先级非常明确：在扩大对Skill审核的信任之前，先强化运行时的安全能力。
首先，沙箱隔离应当成为第三方Skill的默认配置。第三方代码必须默认运行在隔离环境之中，而不应仅仅依赖于用户或运维人员手动选择加固系统时才启用。
其次，运行时环境应强制执行基于Skill的权限模型。每个Skill都必须在启动前预先声明其所需的资源与权限，运行时在执行环节严格管控权限的使用，这一逻辑与现代移动操作系统的做法一致。绝不允许第三方Skill从宿主机环境中直接继承宽泛的信任权限。
对于终端用户而言，核心结论更为简单："安全"标签绝非安全的证明。它仅意味着当前的审核流程，未以改变安装流程的方式标记该Skill存在风险。在强隔离机制成为默认配置之前，仅建议将OpenClaw部署在低价值环境中，远离敏感文件、凭据信息以及高价值资产。
从更宏观的视角来看，问题的核心并非扫描器需要优化，而是审核机制被要求承担了过多的安全防护职责。审核可以协助风险分级、捕获明显的恶意攻击，但绝不能成为高权限智能体的核心安全保障。真正的安全，始于平台预设一定会有危险Skill绕过审核，并通过运行时的设计，确保这些漏网的风险不会立刻导致宿主设备被攻破。真正关键的转变，从"追求完美检测"转向务实的"实现损害遏制"。
参考：
1\]：相关链接： http://moderationEngine.ts https://github.com/openclaw/clawhub/blob/6318a74adff5bb01c2e503e9226f86cf68770e09/convex/lib/moderationEngine.ts#L238 https://github.com/openclaw/clawhub/blob/6318a74adff5bb01c2e503e9226f86cf68770e09/convex/lib/moderationEngine.ts#L72 \[2\]: https://github.com/openclaw/clawhub/blob/487ecb38902524ed4366d832221410fa8d91359e/convex/lib/securityPrompt.ts#L74 \[3\]：代码链接： https://github.com/openclaw/clawhub/blob/6318a74adff5bb01c2e503e9226f86cf68770e09/convex/vt.ts#L243 https://github.com/openclaw/clawhub/blob/6318a74adff5bb01c2e503e9226f86cf68770e09/convex/lib/globalStats.ts#L14