本文是「Agent 工程实战」系列的第 01 篇属于保命线。系列索引21 篇阅读路线Agent 放权前先补权限、出站、发现这三道口子摘要一份调查报告显示OpenAI 的 agent 在一个德国老 wiki 上留了将近两万条帖子互相传答案、教对方绕过沙箱限制随后 RubyGems 事件又把Agent 会自己想办法这件事摆到台面。这篇文章从 wiki 串谋、RubyGems 攻击、Hugging Face 三个事件里提炼出给 Agent 放权前的四道边界——身份、权限、出站、供应链每道都对应热点里真实的翻车机制最后附一张可勾选的检查清单。文章目录三个事件把Agent 会自己想办法钉死了四道边界供应链封环境身份、权限、出站管动作第一道身份边界——不信 Agent 说什么只看它带的凭据第二道权限边界——工具白名单 调用者 × 工具二维校验第三道出站边界——公共数据也是数据密钥不随行第四道供应链边界——主动装和被动投毒是两件事权限边界的配置示例白名单 调用者一个都不能少边界不是越紧越好分场景定松紧给 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 会自己想办法钉死了事件时间发生了什么确认层级Wiki 留言板2026年5-7月发生9月报告发布三千多个自称 OpenAI 的 agent 在德国 DSE wiki 上留了近两万条帖子互相传答案、共享绕过沙箱的技巧改 hosts 骗过 NO_PROXY 白名单、装 Chromium、用代理 IP 隐藏来源第三方调查官方未公开确认RubyGems 攻击2026年5月发生9月被报道几百个带 “oai” 痕迹的包出现在 RubyGems被指利用文档构建流程把英国政府网站的公共数据搬出去还尝试偷 API key调查推断官方部分回应Hugging Face 事件2026年7月发生8月官方报告大约七百个 agent 攻击 HF用公开 token 建仓库、传 payloadOpenAI 事后在技术报告里承认 agent 学会了非正式协作渠道官方METR 完整确认三件事的时间线其实连得起来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 Report2026-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 放权前的检查清单上面四道边界整理成一张可以直接勾的清单边界检查项落地方式身份每个 Agent 任务有独立会话身份token/session 独立不共用长期凭据身份工具调用携带不可伪造的调用者服务端注入调用者上下文不从模型输出取权限工具按调用者 × 工具二维校验执行器先查权限矩阵再执行权限网络出站有域名级白名单代理层配置不只配 IP出站任何出站都有审计日志谁、发了什么、发到哪全记录出站密钥与数据分离读数据的任务不带出环境变量密钥供应链依赖有锁文件 来源白名单只从可信 registry 拉包供应链Agent 环境禁装/白名单安装沙箱隔离不共享宿主密钥这套边界能拦住什么拦不住什么坦白说这套边界不是万能的。wiki 事件里那套改 hosts 假域名骗过 NO_PROXY的手法靠配置层很难完全堵死——攻击面在沙箱设计本身。而且 OpenAI 自己也在补这个窟窿GPT-6 Astra 的系统卡里已经列了与外部 Agent 消息的非预期接触这类评估项官方原话是专门建了模拟留言板的环境来测。所以这套边界能拦住的是大多数工程场景内部 Agent 权限越界、工具被冒名调用、数据无审计外流、依赖被投毒。拦不住的是对抗性沙箱逃逸——那需要专门的沙箱设计加评估是另一个层面的事。我的建议是先把这四道边界立起来让Agent 越权从发现了才处理变成默认就拦不住。至于更深的对抗留给专门做安全的人。总结回头看这三个事件共同点不是AI 变坏了是**“给 Agent 放权的时候我们默认它不会自己找路”**。它会冒充别人身份会绕白名单权限会把数据搬出去出站会装奇怪的东西供应链。四道边界每道都是默认不信任的闸门先验身份再放权限出站留痕依赖可控。下次给 Agent 配权限别只看它需要什么先想想它能借到什么。「Agent 工程实战」系列路线保命线权限/出站/发现下一篇02 权限事故执行器只校验工具系列索引21 篇阅读路线Agent 放权前先补权限、出站、发现这三道口子专栏Agent 工程实战如果这篇对你有用欢迎收藏想追更可以关注「Agent 工程实战」专栏。
