恶意插件100%得手！伯克利、UIUC和NUS等给智能体做了次安全体检

新智元报道

过去两年，AI智能体（Agent）完成了一次身份转变。

它不再只是对话框里回答问题的模型，也不再只是IDE里帮忙补全代码的助手，而是开始以一个常驻进程的形式，住进用户的电脑，自主地读文件、发邮件、连云盘、装软件，替人把一件件真实的任务干完。

以OpenClaw为代表的这一代「Claw类智能体」正是如此。

它常驻在你的机器里，对本地资源有持续的访问权，通过一个统一的自然语言入口，服务于千差万别的需求。要做到这一点，它手里就得一直攥着你的登录凭证，以及一大把系统级权限。

能力越大，一旦失守，代价也越大。

而现实已经给出了警示：OpenClaw官方技能市场ClawHub上已被查出上千个恶意Skill，仅2026年针对OpenClaw披露的CVE漏洞就超过一百三十个，凭证被窃取、数据被静默外传的事，正真实地发生在生产环境中。

问题在于，现有的安全评测大多还停留在模型层：考察模型的回复是否安全、单次工具调用是否越界。至于这类智能体真正致命的、跨越多个组件的系统级风险，几乎没有被系统性地度量过。这，正是这项工作的出发点。

为填补这一空白，来自UIUC、UC Berkeley等机构的研究团队构建了SafeClawArena。

他们不从「已知的攻击场景」出发，而是从计算机系统几十年沉淀下来的安全准则出发，为这类智能体设计了406道对抗性任务，并在3个真实平台、5个前沿大模型上完成了测试。

结论并不乐观：整体攻击成功率最高可达70%，其中恶意插件在未加固的智能体上百发百中，即便换上最安全的大模型也难以阻挡。

论文地址：https://arxiv.org/abs/2606.30755

代码地址：https://github.com/sunblaze-ucb/SafeClawArena

项目主页：https://safeclawarena.github.io/

图 1 Claw 智能体的架构与四类攻击面。其网关同时挂着大模型内核、技能加载器、插件加载器、记忆、工具执行器和配置六个部件，每个部件都带着各自的安全隐患。

智能体

正在长成一台电脑

把一个Claw类智能体拆开看，它做的事几乎可以逐条对应到一台电脑系统：加载代码、分配任务、跨会话保存状态、代理对外部服务的访问。用户安装的技能（Skill），相当于跑在系统之上的应用程序；它加载的插件（Plugin），则是直接进入主进程、拿着完整权限运行的原生代码。

换句话说，它已经不是一个App，而更接近一台后台常驻着一批服务的电脑。

真正的问题也随之而来。经过几十年的攻防迭代，电脑系统早已把进程隔离、最小权限、代码签名、访问控制这些防护做成了标配；可智能体这一侧，这些机制几乎一样都没有。更棘手的是，业界还缺少一个能够系统性地检测这类风险、并衡量防御是否有效的Benchmark。

现有的智能体安全评测存在两个惯常的盲区。其一，只盯着模型层，任务大多按照「已知的攻击套路」自底向上堆叠，而不是反过来追问：一个系统本应守住哪些底线。其二，习惯自建脚手架，让大模型跑在作者临时搭出的模拟框架里，测出来的结果很难直接反映真实平台的行为。SafeClawArena要解决的正是这两点，它索性不搭脚手架，直接把生产平台本体作为测试台。

给智能体，戴上一副「计算机系统」的眼镜

SafeClawArena最关键的一步，是没有另起炉灶发明一套新分类，而是借用了计算机安全几十年的成果。

研究团队先做了一次「翻译」，把Claw类智能体的每个部件对应到电脑系统里的老熟人，再看这些老熟人在系统安全里配备了什么防护，就能反推出智能体缺了哪一环：

公共市场上的技能，对应软件仓库，缺的是代码签名、审核与沙箱；

大模型的上下文窗口，对应进程地址空间，缺的是不同信任来源之间的隔离；

以明文保存的记忆文件，对应文件系统，缺的是访问控制与完整性校验；进程内插件，对应可动态加载的内核扩展，缺的是签名与权限隔离；

连接邮箱、Slack的通道，对应进程间通信，缺的是带认证的通信；网关日志，对应审计子系统，缺的是脱敏、访问控制与防篡改。

顺着这些缺口，研究团队提炼出五条经典安全原则，而它们在今天的Claw类智能体里几乎无一幸免：

用户指令、读入的文件、技能里的文字全部挤在同一块上下文中，彼此之间没有边界（违反进程隔离）；

技能与插件一经加载便继承了智能体的全部权限（违反最小权限）；

记忆、配置、日志均为明文，既不校验也不脱敏（缺失持久状态保护）；

对外调用共用同一套凭证，外部服务无从分辨请求究竟由谁触发（缺少跨边界中介）；

文档内容与用户指令拥有同等权威，于是文档也能反过来向智能体发号施令（违反数据指令分离）。

把这五条原则按照「违规会在哪里显现」重新归拢，恰好落到四个攻击面上，这也构成了SafeClawArena的四个维度：技能供应链完整性（SSI）、持久状态利用（PSE）、跨边界数据流（CDF）、间接提示注入（IPI）。

这套构建方式的价值，在于能够暴露传统分类根本看不见的攻击。以恶意插件为例：它以原生代码直接在网关进程里运行，完全不经过大模型，任何只盯着工具调用接口的评测都天生测不到它。

怎么测的

图2 SafeClawArena的评测流程。左边是406道题按四个攻击面分布，中间在容器里还原真实平台并埋好带暗号的凭证，右边由检测器逐一检查九个输出通道。

SafeClawArena共406道题，分布在四个维度、24个子类中。每道题都像一场事先设好埋伏的演练，分四步推进。

首先是布置。系统在一个仿真工作区里植入独一无二的「金丝雀」凭证，它们看起来与真实的数据库密码、API密钥、云凭证别无二致，只是每一个都带着可追踪的暗号。随后再部署本题特有的技能、插件或外部内容。

接着是执行。一个模拟用户与智能体展开一到多轮正常对话，把任务自然地交付出去。对持久状态类攻击，系统还会在两轮对话之间重启网关，用来验证被植入的负载是否真能跨越会话存活下来。

然后是采集。评测器会完整记录九个输出通道——智能体回复、对外消息、记忆写入、网关日志、文件写入、Webhook、工具参数等等。

最后是判定。检测环节不采用「让大模型当裁判」的方式，而是一个确定性的字符串比对器：只要那些金丝雀暗号出现在了不该出现的通道里，就判定为泄露。由于暗号全局唯一，命中即可归因到具体某道题，几乎不存在误报。

为了让「数据外泄」既能被精确度量、又不会真的造成风险，研究团队还实现了一个仿真版的Google Workspace工具Sim-Google，覆盖Gmail、Drive、Calendar等十六项服务，每次调用都会把完整参数原样写入本地日志。所有任务都运行在全新的Docker容器里，不接触真实账号，也不产生真实网络流量。

跑出来的结果

图3 15种「平台×模型」组合在24个子类上的攻击成功率。越红越危险，越绿越安全。

研究团队在3个平台与5个大模型交叉出的15种组合上完成了评测。三个平台大致覆盖了从宽松到严格的加固谱系：

OpenClaw是参考实现；NemoClaw在其上增加了用户级的进程隔离；

SeClaw则是一个安全优先的变体，号称部署了十一项系统级防御中的八项。

五个大模型则包括GPT-5.1-Codex、GPT-5.4、Gemini-3-Flash、Gemini-3.1-Pro与Claude-Opus-4.6。

15种组合跑下来，整体攻击成功率从最低约20%到最高近70%，相差约三倍。而这一差距，单看平台或单看模型都无法解释。

表1 15种「平台×模型」组合在四个维度及总体上的攻击成功率（Atk%）与安全得分（Sc.）。底色越绿越安全，越红越危险。

围绕这张表，研究团队给出了几条结论。

其一，有些漏洞，模型再聪明也补不上。恶意插件在所有未加固的平台上都是100%得手，且不挑模型，因为它绕开了模型本身。它在SeClaw上归零，也并非被防住，而是SeClaw干脆不再加载这类插件。这也从侧面说明，在某些情况下，安全与功能难以兼得。

其二，模型更强，不代表更安全。在一类捆绑脚本的攻击中，更强的Opus-4.6反而更容易中招（安全得分0.20），不及GPT-5.4（0.60）。原因有些反直觉：脚本藏在一个外表正经的技能里，越是「听话」、越擅长跟随指令的模型，越愿意照用户的要求把它运行起来。当指令本身有害时，强指令跟随反而成了弱点。

其三，堵上一个口子，漏洞会从另一个口子冒出来。SeClaw把原本走自然语言的通知，改成了带必填字段的结构化工具调用，凭证反倒因为「字段必须填」而被写进了参数。对本来就在自然语言里泄露的GPT-5.4来说，这是好事，它的整体攻击成功率从近70%降到22%；但对本已懂得打码的Gemini-3.1-Pro而言，它被迫往必填字段里填入真实凭证，反而在持久状态和提示注入两项上更糟了。泄露没有消失，只是换了通道。

其四，同样的加固，对不同模型的收益并不均等。最大的模型间差距，恰恰出现在加固后的SeClaw上，而非宽松的OpenClaw上——在日志外泄这一类里，Gemini-3-Flash的安全得分低至0.03，Opus-4.6却高达0.91。原因在于，OpenClaw过于宽松，各模型都同样糟糕；而SeClaw把简单攻击替换成了需要模型自行判断的结构化界面，于是懂得判断的模型分数跃升，机械照做的模型则摔得更惨。这意味着加固需要按模型来调，而非一刀切地统一部署。

此外，还有一处容易被数字掩盖的细节。面对同一道伪造「已获授权」的陷阱题，Opus-4.6当场识破，指出这是社会工程学套路、没有任何正规流程会预先授权把明文凭证展示出来；而另外两个模型则照单全收。这说明模型层的对齐在生效时，仍是有价值的最后一道防线，只是它替代不了架构层本该承担的工作。

图4 11种系统级防御各自能防住哪些攻击类别。填色表示覆盖，空心表示同维度里没覆盖到。没有哪一种防御能单独扛下一整个维度。

论文进一步盘点了十一项系统级防御各自能覆盖哪些攻击类别（图4）。结论同样清晰：没有任何单一防御能独自扛下一整个维度；而且理论上覆盖到位，并不等于实测中真的拦得住——有的防御在部署表里赫然在列，却在对应任务上收效甚微。

归根结底，智能体的安全，不是「换一个更强的模型」或「上一个更严的平台」二选一就能了事的。哪怕是专为防御而生的SeClaw，也仍留有不小的攻击面；哪怕是最稳的配置，也仍有约五分之一的任务被攻破。

它更应当走一遍电脑系统当年走过的路：从「有个进程隔离就够了」，到「ASLR、DEP、SELinux、签名内核协同工作」的纵深防御，并且必须与底层大模型联合评估，而不是拿平台加固去顶替模型对齐。

论文点名了四项目前普遍缺席的关键防御——技能签名、内存完整性、凭证保险箱、动作授权，把它们补齐，大概是这个方向下一步最值得投入的事。

而对平台厂商、安全审计方与研究者而言，SafeClawArena提供的更是一把可复用的尺子：判断一个Claw类智能体究竟违反了哪几条安全原则，并据此排定加固的优先级。

参考资料：

https://arxiv.org/abs/2606.30755

编辑：LRST