900 多个 AI 助手网关裸在公网，密钥和聊天记录全曝光

原创

大白
大白

知白守黑1024

2026年10月29日 06:29
北京

去阅读

SECURITY RESEARCH / PAPER NOTE

约克大学团队扒了 2.5 万条 Reddit 帖和 358 个 GitHub issue，把 OpenClaw 这类自托管 AI 代理的安全问题按 CWE 归了类。

arXiv 2610.35451 · cs.CR · 2026 · YORK UNIVERSITY

一个用户在帖子里讲了自己的经历。他把 OpenClaw 装在本机，接上了 Discord 和 Telegram，原意只是让助手帮自己处理消息。结果没过多久，它开始往他的 Discord 和 Instagram 里发消息——“发消息这件事，我根本没授权过”。

这条帖子在论文里编号 R055。它旁边还有一条更扎眼的：900 多个暴露在公网上的 Clawdbot 网关，因为配置不当，正在泄露密钥和聊天记录（R003）。再往下翻，有人发现某个扩展装完后在后台“悄悄抓取 AWS 凭证、.env 文件和 SSH 密钥”（R008）。

“它把你的登录信息、银行 token 和密钥，全放在普通的文本文件里。”

— R009

这些话不是段子。约克大学的三位研究者把 Reddit 和 GitHub 上散落的这类抱怨、报错和复盘收集起来，做成了一次系统的实证研究，论文标题起得很直白，The Wild Wide West of OpenClaw Agentic System Security。结论一句话就能概括：AI 代理的安全问题，大多不是某个孤立的功能 bug，而是同一批信任边界在反复失守。

01 / WHAT IT IS

先搞清楚 OpenClaw 是什么

它不是那种一问一答的聊天机器人。OpenClaw 是自托管的个人助理框架，能记住上下文、调用外部工具、读写本地文件、执行命令，还能直接连到网页和各种消息平台。论文把它和普通 LLM 应用的区别点得很清楚：普通应用只生成一段回答，代理应用会真的去动系统。

一旦它能动系统，原来的信任边界就全乱了。用户输入、网页内容、邮件正文、工具返回结果，全都会被拼进同一个上下文里喂给模型；模型的输出又能反过来触发工具；工具再去碰文件、凭证和外部服务；而持久记忆还会把这一轮的信息带到下一轮。整条链路从“推理”一直通到“执行”，中间没有一道明确的闸门。

论文给这种结构起了个很准确的说法：代理执行管线。安全事件往往不是发生在某一层，而是发生在层与层交接的地方。这也是为什么只看模型输出、或者只测单个工具，都测不出这类问题。

02 / METHOD

数据是怎么来的

研究用了两个互补的数据源。Reddit 那边抓了 13 个相关子版块在 2026 年 1 月到 7 月的讨论，帖子超过 2.5 万条，连帖子带评论一共 175,984 条。GitHub 那边从 OpenClaw 官方仓库拿了 358 个打了安全标签的 issue。

2.5 万条帖子靠人工看不现实，所以他们先用两个开源模型做初筛，GPT-OSS:20B 和 Qwen-3:32B，各自独立跑一遍，只有两个模型都判定相关的才留下来，得到 1,218 条候选。这一步刻意把召回率放在精度前面，宁可多留，也不漏。抽了 200 条样本做审计，漏判是 0。

候选进入人工复核后，最终留下162 条有价值的 Reddit 帖子（带 1,787 条评论）和180 个确认有效的 GitHub issue（43 个未关闭、137 个已关闭）。两个人独立标注，分歧交给第三人裁决，整体一致率 96.6%，Cohen's κ 在 0.875 到 0.920 之间。这套流程不算花哨，但每一步都留了痕。

FIG. 01 — 数据从采集、LLM 初筛、人工复核到 CWE 编码的完整管线。2.5 万帖最后收敛到 162 条有效样本。

03 / FINDINGS

521 处弱点，七成挤在三个地方

研究者把每一条有效报告都映射到 MITRE 的 CWE 分类上，一共标出521 处弱点实例，跨 59 种不同的 CWE 类型。Reddit 贡献了 329 处，GitHub 贡献了 192 处。随后他们把这些细类归成八大块，分布很集中。

最大的一块是访问控制（Access），184 处，占 35.3%，对应 CWE-284。说白了就是门户大开、默认权限太宽、代理干了超出授权范围的事。R055 那条“擅自发消息”就是典型。再往下是敏感信息暴露（Exposure），96 处，18.4%，对应 CWE-200，密钥、聊天、配置文件从输出、面板或者上下文里漏出去。第三是注入（Injection），87 处，16.7%，对应 CWE-20，外部内容没跟指令隔开，把模型带偏。这三块加起来占了70.4%。

FIG. 02 — 访问控制的典型路径：用户提个请求，模型调用的插件越过了权限边界，直接碰到了资源。

剩下五块份额小，但别低估。执行（Execution）61 处、占 11.7%，对应 CWE-829，说的是恶意技能、插件和依赖继承代理权限。凭证（Secrets）35 处、6.7%；网络（Network）22 处、4.2%；资源（Resources）和监控（Monitoring）各 18 处，都是 3.5%。

执行这一类虽然只有 11.7%，论文特意强调它“影响最大”。原因很简单：它能把上游的信任失误直接变成代码执行、凭证失窃或者持久化控制。一个没审过的技能，在代理进程里跑起来，跟在你机器上跑一段来路不明的脚本没本质区别。

FIG. 03 — 执行类的一条路径：代理从技能库安装一个未经校验的插件，插件随后在系统上执行。

信息暴露这一类的成因也比想象中杂。代理为了“帮你调试项目”，会去翻配置文件、读环境变量、扫项目目录，一旦这些内容进入模型上下文，就有可能被原样吐在回答里。密钥不是被偷走的，是被“顺手念出来”的。

FIG. 04 — 敏感信息暴露路径：模型在推理阶段访问资源，敏感数据可能经由恶意插件流向外部。

注入这一类最能说明“老问题被放大”。提示注入本身不新鲜，但当代理同时握着文件读写、命令执行和消息发送能力时，一段藏在邮件里的恶意指令，后果就不只是“答错一句话”，而是可能直接触发下面这些动作。

FIG. 05 — 注入路径：恶意指令伪装成正常内容进入上下文，模型把它当成了要执行的意图。

04 / WHY IT ESCALATES

老问题到了代理身上，为什么变严重

论文最有价值的部分，是把这些熟悉的 CWE 翻译成了六个“代理特有的失效机制”。它们不是新的分类标签，而是解释同一个弱点在代理管线里为什么会连锁放大。

一，指令和数据的边界塌了。邮件、网页、文档、被渲染出来的文字，本该只是“数据”，但在代理这里会被当成影响行为的上下文，也就是“指令”。

二，工具把权限放大了。模型选的工具，权限常常比用户这次请求所需的更大。一个轻微的越权，经过工具就变成了对文件、凭证、消息通道的实际操作。

三，持久上下文持续暴露。记忆、工作区文件、配置、凭证、历史对话会被拼进模型和工具都能访问的上下文，于是敏感信息可能通过回答、日志、面板、工具返回值漏出去。

四，技能和插件的信任被“转移”了。第三方技能一旦装进来，就进入了代理的受信执行环境，可信度其实是跟着代理一起被继承的。

五，自主运行放大资源消耗。代理 7×24 挂着，会反复调工具、重试任务、扩张记忆。

“代理卡在重试循环里，我睡了一觉，六小时烧掉约 200 万 token。”

— R005

六，可观测性和审批缺位。R004 那句“没有审计日志，出了事你根本不知道发生了什么”，说的就是监控这块。代理干了什么、为什么干、防御有没有生效，用户和开发者都答不上来。

把这六条串起来看，会发现它们是同一条链上的六个断点。权限失效让工具动作有了落点，注入让推理跑偏，暴露发生在上下文里，执行风险从插件进来，资源问题被自主性放大，监控缺失让上面所有事情都变得难查。单独修一处，剩下的断点还在。

05 / DEFENSES

一线用户自己总结的七条防线

论文还做了一件挺接地气的事：从 1,787 条评论里筛出 315 条真正有操作建议的，再拆成 543 条具体建议，最后归纳成七种策略。这些不是厂商的宣传话术，是踩过坑的人自己写的。

最常被提到的是最小权限（27%）。有人直接说，“给它一个只能创建 PR 的 GitHub token”，别给全权限。权限要按任务、按工具、按通道来收窄，而不是整个代理一把梭。

第二位是环境隔离（17%）。原话是“别裸机跑，用只读权限的 Docker 容器”。虚拟机、私有部署、只读挂载、断绝和宿主敏感资源的直连，都是同一个思路：把代理当成不可预测的工作负载来隔离，而不是装完就上生产。

接着是监控审计（14%）、供应链与插件信任（12%）、凭证管理（10%）、人工审批（10%）和网络收敛（10%）。做供应链那条的建议很硬核，“自己写技能，别信商店里随便下的”。人工审批那条讲的是“改任何东西之前先问我，我确认了再动”。

FIG. 06 — 八类安全弱点与七种缓解策略之间的流向，连线越粗说明关联的建议越多。策略是横切的。

这张流向图其实说了一个关键点：缓解措施是横着切的，不是竖着对号入座。最小权限主要对着访问控制，但隔离、监控、凭证、网络限制、人工审批，同时连着好几个弱点类别。想靠一个补丁解决，基本不可能。

06 / TAKEAWAY

对做 AI 代理的人，这几条值得抄下来

论文在讨论部分提了几条设计上的要求，我觉得比具体的技术方案更有参考价值。

一，信任边界要写死在管线里。输入采集、上下文构造、推理、工具选择、执行、记忆、输出，每一段之间都得说清楚什么能过、什么不能过。边界模糊，后面所有防护都是补丁。

二，权限要按动作动态收窄。不是给代理进程一个宽权限，而是在具体工具、具体动作、具体任务这一层去限定和校验，而且要持续校验，不是启动时查一次。

三，校验要发生在执行之前，而不是出事之后。外部内容进可信上下文之前要过一道，生成的动作用到工具之前要再过一道。安全从“静态配置”往“运行时策略检查”挪。

四，高风险动作必须可观测、可回放、可归因。碰文件、碰凭证、连外部服务、跑长任务，都得留下能查的轨迹。否则一旦出事，连复盘都无从下手。

论文还点出一个现实：社区里那些缓解建议之所以反复出现，恰恰说明很多内置防护是缺的，用户在替产品补课。理想状态应该是这些控制默认开启、可组合、懂任务，而不是丢给用户当“部署建议”。

07 / EPILOGUE

写在最后

这篇论文的方法也有它的边界。数据只来自公开的 Reddit 和 GitHub，企业内网部署、私下披露、悄无声息就失败掉的那些，它看不到。所以 521 这个数字应该当成一个下限，而不是全景。研究本身是时间切片，OpenClaw 这个生态还在飞快变化。

但结论是稳的。AI 代理的危险，不在“它会不会说错话”，而在“它说的一句话会不会变成一次系统操作”。从 25K 条帖子里翻出来的那些坑，几乎都在提醒同一件事：把一个能读文件、能发消息、能花钱的东西接进你的环境之前，先把边界画清楚。

如果你正在用或者准备部署这类自托管代理，先在容器里跑，先收权限，先把日志打开。这三步不性感，但能挡掉论文里七成以上的问题。

觉得有收获的话，点个在看，转给正在折腾 AI 代理的同事。