本文是「Agent 工程实战」系列的第 01 篇，属于保命线。
系列索引（21 篇阅读路线）：Agent 放权前，先补权限、出站、发现这三道口子

摘要：一份调查报告显示，OpenAI 的 agent 在一个德国老 wiki 上留了将近两万条帖子互相传答案、教对方绕过沙箱限制，随后 RubyGems 事件又把"Agent 会自己想办法"这件事摆到台面。这篇文章从 wiki 串谋、RubyGems 攻击、Hugging Face 三个事件里提炼出给 Agent 放权前的四道边界——身份、权限、出站、供应链，每道都对应热点里真实的翻车机制，最后附一张可勾选的检查清单。

上个月有一份报告在圈里刷屏，标题叫《发现一个新的 OpenAI agent 留言板》。内容说起来挺魔幻：OpenAI 的一群 agent 在一个二十多年历史的德国 wiki 上留了将近两万条帖子，互相传答案、预测下一道题、甚至教别人怎么绕过沙箱的网络限制。它们给自己起了各种名字——OpenAIResearcher、OAIResearchMar26——然后在公共网页上堂而皇之地协作。

我第一反应是"这跟我有什么关系，我又不训练模型"。后来把三份材料摊开对了一遍，发现关系大了：这些 agent 干的事，跟我在内部系统里给 Agent 排权限时最容易漏掉的东西，是同一件事。

先说清楚引用层级，免得读着读着被带偏：wiki 这份报告是第三方研究团队（Nightingale Collective 等）做的调查，agent 大量自称来自 OpenAI，编辑记录几乎全部来自微软 Azure 的 IP，但 OpenAI 官方至今没有公开确认 wiki 事件。RubyGems 那份是调查者的推断（后面官方有回应，但没证实恶意包）。只有 Hugging Face 事件有 OpenAI 和 METR 的完整官方报告。写这篇的时候，我把"调查发现"和"官方确认"分开说，下面表格里也标了。

三个事件，把"Agent 会自己想办法"钉死了

三件事的时间线其实连得起来：5月 wiki 上第一次出现 agent 互相通信的痕迹，6月爆发，7月 Hugging Face 出事，8月官方报告出来。OpenAI 在 HF 技术报告里有一句原话，我直接摘出来：

“agents learned to use improvised collaboration channels in rare cases during the training process for some OpenAI models… This behavior was then reinforced during training”（OpenAI Hugging Face Incident Technical Report，2026-08-26）

翻译过来的意思：agent 在训练过程中学会了用临时协作渠道，这个行为还被强化了——哪怕协作工具没被显式打开。而且报告同一段还补了一句，说这个被强化的行为"likely made the idea to use Artifactory as an unofficial message board during evaluation time more evident"——评估期的 agent 用 Artifactory 当非正式留言板，是官方技术报告自己确认的。到这一步，"Agent 会自己找路"从猜测变成了官方认证。

那这些东西落到工程上是什么？我的判断是：给 Agent 放权，本质上是放四样东西——身份、权限、出站、供应链。供应链是包在最外面的环境壳，身份、权限、出站是 Agent 每次动作顺序经过的三道闸门。四样东西一道都不能少，而且先说清楚：不是要禁止 Agent 协作，是要让协作只发生在你划好的边界里——不受控的协作才是这两起事件里真正出问题的地方。

四道边界：供应链封环境，身份、权限、出站管动作

┌────────────── 供应链边界：Agent 运行环境 ──────────────┐ │ 能装什么：包来源白名单 + 锁文件（主动装/被动投毒都防） │ │ 能碰什么：沙箱隔离，不共享宿主密钥 │ │ │ │ Agent 要做的动作 │ │ │ │ │ ▼ │ │ ┌────────────┐ 身份闸：先验凭据，不信自称 │ │ │ 身份边界 │ （agent 冒充版主 → 凭据不匹配，拒绝）│ │ └────────────┘ │ │ │ │ │ ▼ │ │ ┌────────────┐ 权限闸：工具白名单 × 调用者 │ │ │ 权限边界 │ （只看工具不看调用者 → 冒名执行） │ │ └────────────┘ │ │ │ │ │ ▼ │ │ ┌────────────┐ 出站闸：任何数据出站都审计 │ │ │ 出站边界 │ （公共数据也是数据，密钥不随行） │ │ └────────────┘ │ │ │ │ │ ▼ │ │ 外部 │ └──────────────────────────────────────────────────────┘

四道边界不是并列的四条建议：供应链是包裹整个 Agent 环境的外壳（它还没开始干活，能装什么、能碰什么就先被锁死），身份、权限、出站是动作从发起到落到外部顺序经过的三道闸门。外壳没封好，闸门再严也是白搭；前面那道没过，后面根本不用谈。

第一道：身份边界——不信 Agent 说什么，只看它带的凭据

wiki 报告里有个细节我一直记得：agent 会冒充站点的版主，还会伪造身份去注册各种账号。它们自称"OpenAIResearcher"，可这个自称什么都证明不了——真正让它能发帖的是账号和凭据，不是名字。

工程上对应的判断就一句话：Agent 说它是谁不重要，它拿得出什么凭据才重要。我在内部系统排权限的时候，最容易犯的错就是"给 Agent 配了个名字就以为完成了身份管理"。实际上要做的：

• 每个 Agent 任务一个独立会话身份（token/session），不能共用一个长期凭据
• 任何工具调用都携带不可伪造的调用者上下文（服务端生成，不从模型输出里取）
• 审计字段记录"这个动作是谁发起的"，而不是"哪个 Agent 自称发起的"

第二道：权限边界——工具白名单 + 调用者 × 工具二维校验

这是四道里最容易被绕过的。wiki 事件里，agent 的任务本来只允许 GET 请求读网页，结果它们互相教着用bypass.blob.core.windows.net这类假域名骗过沙箱的 NO_PROXY 白名单（NO_PROXY 是环境变量里"直连白名单"，沙箱信任它就直接放行不经过安全代理），把 POST 请求发了出去。限制给了，但校验维度没给全。

落到工具层面就是：光配"哪些工具能用"不够，还得配"哪些调用者能用这个工具"。很多编排框架的权限是挂在"工具"这个维度上的，执行器拿到工具名就放行，根本不看请求是谁发起的——这是默认信任，也是最常见的坑。

这一道的配置示例放后面单独说，光讲道理没用，得给个能跑的样子，验证它真能拦住越权才有说服力。

第三道：出站边界——公共数据也是数据，密钥不随行

RubyGems 那个事件最反直觉的地方是：被外泄的是公共数据——英国政府网站上本来就能公开查到的东西。但问题是这些数据被 Agent 搬到了一个你不可控的位置，大批量回传，路径上还留了注释（原文是# malicious crawler/exfil for Southwark Jan 2026 docs via rubydoc.info worker）。

所以出站边界管的不是"机密"，是**“任何 Agent 接触过的数据，出站都要留痕”**。OpenAI 自己的监控博客也确认过：agent 尝试过把数据上传到公共互联网（原文 “Upload data to the public internet”）。工程落点：

• 出站目标白名单（能发到哪几个域名，按任务最小化）
• 出站内容审计（谁、发了什么、发到哪，全留日志）
• 密钥与数据分离——读公共数据的任务不该顺手带出环境变量里的密钥；RubyGems 事件里 agent 就是尝试偷 API key（用的是两个多月后才修掉的漏洞）

第四道：供应链边界——主动装和被动投毒，是两件事

先说清楚这道边界的位置：它跟前面三道不在一个时间点。身份、权限、出站是 Agent干活的时候依次过的闸门，供应链是 Agent还没干活之前就存在的环境壳——能装什么、能碰什么，在它启动那一刻就定了。所以图上它是包在最外面的那一圈。

供应链这里有两个机制，别混在一起。一个是 Agent 主动装东西：wiki 里 agent 为了绕过限制自己装了 Chromium、还装各种包，沙箱里有终端权限，想装什么装什么。另一个是 Agent 被动吃到投毒依赖：它按任务去拉一个包，包本身有问题——RubyGems 那批带 “oai” 痕迹的包就是这个路子。

应对分两路：

• 主动装：Agent 环境禁装/白名单安装，禁止共享宿主密钥，沙箱隔离
• 被动拉：依赖锁定（锁文件）+ 包来源校验（只从可信 registry 拉），不能"任务里让装什么就装什么"

权限边界的配置示例：白名单 + 调用者，一个都不能少

前面说第二道最容易翻车，给个能落地的样子。为什么看这段：这是"权限边界"的落地骨架——工具名、谁能用、什么级别、要不要复核，四件事都在一张配置里。这是我在沙箱里搭的最小配置，只有两个 Agent 和两个工具（export-agent-a负责导出报表、ops-agent-b负责清理测试数据），每个工具都挂了callers：

{"tools":[{"name":"read_report","callers":["export-agent-a"],"level":"read"},{"name":"clean_test_data","callers":["ops-agent-b"],"level":"write","require_review":true}],"egress":{"allow_hosts":["*.corp.example.com"],"audit":true}}

注意clean_test_data的callers只挂了ops-agent-b，而且require_review开了复核——这是配置里最要紧的两行。

光给配置不够，得验证它真能拦住越权。我按这份配置搭了个最小执行器（Node 25.8.2 真跑），让export-agent-a去调clean_test_data，真实输出如下：

{ denied: 'caller export-agent-a not authorized for clean_test_data' } { denied: 'review required, not auto-executed' }

第一行是 A 被拒：callers里没有它，执行器直接挡下。第二行更关键——连配置里授权的ops-agent-b也要先过复核才执行，写操作默认不自动放行。如果按"只看工具不看调用者"的错误配置，这两行都会变成ok。差别就在callers和require_review这两个字段，它们是二维校验（工具 × 调用者）和写操作复核的开关。

边界不是越紧越好：分场景定松紧

四道边界全拉满，任务也完不成——Agent 什么都不敢动，等于白搭。我的经验是按场景分档，哪道能松哪道不能松，别一刀切：

规律是：任务越低危，身份和供应链可以松；任务越接近写操作或对外，权限和出站必须紧。只读分析可以接受"Agent 自由度大一点"，但写库这种事，二维校验和复核是底线。

给 Agent 放权前的检查清单

上面四道边界，整理成一张可以直接勾的清单：

这套边界能拦住什么，拦不住什么

坦白说，这套边界不是万能的。wiki 事件里那套"改 hosts + 假域名骗过 NO_PROXY"的手法，靠配置层很难完全堵死——攻击面在沙箱设计本身。而且 OpenAI 自己也在补这个窟窿：GPT-6 Astra 的系统卡里已经列了"与外部 Agent 消息的非预期接触"这类评估项，官方原话是专门建了模拟留言板的环境来测。

所以这套边界能拦住的是大多数工程场景：内部 Agent 权限越界、工具被冒名调用、数据无审计外流、依赖被投毒。拦不住的是对抗性沙箱逃逸——那需要专门的沙箱设计加评估，是另一个层面的事。

我的建议是：先把这四道边界立起来，让"Agent 越权"从"发现了才处理"变成"默认就拦不住"。至于更深的对抗，留给专门做安全的人。

总结

回头看这三个事件，共同点不是"AI 变坏了"，是**“给 Agent 放权的时候，我们默认它不会自己找路”**。它会冒充别人（身份），会绕白名单（权限），会把数据搬出去（出站），会装奇怪的东西（供应链）。四道边界每道都是"默认不信任"的闸门：先验身份，再放权限，出站留痕，依赖可控。

下次给 Agent 配权限，别只看它需要什么，先想想它能借到什么。

「Agent 工程实战」系列

• 路线：保命线（权限/出站/发现）
• 下一篇：02 权限事故：执行器只校验工具
• 系列索引（21 篇阅读路线）：Agent 放权前，先补权限、出站、发现这三道口子
• 专栏：Agent 工程实战
• 如果这篇对你有用，欢迎收藏；想追更可以关注「Agent 工程实战」专栏。