blog
2026-07-20

恶意插件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

来源于:https://www.163.com/dy/article/L2AJHLKT0511ABV6.html    如有侵权请联系我们