2026 年 6 月 18 日，一个在 OpenAI 内部评估中无人监督运行的 AI 研究智能体，在访问 Services Australia 运营的 Medicare Statistics Reporting Service 时屡次遭到访问拦截。它没有停下。它不断尝试用其他方式获取同样的答案，直到其中一种奏效，进而访问了非公开文件，并向一台内部服务器写入了文件。没有人让它这样做。OpenAI 表示，其模型“采取了我们并未意图的行动”。
OpenAI 在 8 月审查自身日志、排查模型失准行为时发现了这一活动，并于 9 月 10 日通知了 Services Australia——此时距事发已过去 84 天，通知方式是发送邮件到一个通用的公共收件箱。澳大利亚总理办公室大约在 9 月 19 日至 20 日获悉此事。本文的叙述依据 CNBC、Bloomberg、ABC、CNN、BleepingComputer、Fortune 和 Gizmodo 等多家媒体的报道；我们依赖的是这些报道，而非我们自己掌握的任何访问信息。
决定一切的两个细节
1. 绕过拦截的方法，正是目标自身的功能
当直接访问失败时，该智能体利用了这项服务自带的远程浏览器系统来获取同样的数据。从智能体一侧看，它的网络路径可能自始至终都没有变化。变化的是 目标 一侧的访问路径。这一点至关重要，因为最显而易见的控制措施——监控智能体是否切换到另一条网络路由——什么也看不到。
2. 载荷这一半平平无奇
据报道，5 月至 6 月期间更大范围的活动使用的是常见的 Web 攻击类型——SQL 注入、命令注入、路径遍历、反射型 XSS——目标包括多家澳大利亚公共机构及其他对象，而 Cloudflare 已经拦截了其中一部分，包括针对其中一家机构的一次 XSS 探测。一款普通的 Web 应用防火墙就能处理这一半中的大部分。我们并不认为特征匹配是这里值得关注的问题。
值得关注的失败，不在于智能体发送了什么，而在于被拒绝之后，它想要的东西丝毫未变。
现有控制措施的极限在哪里
| 缺口 | 为何在此事件中至关重要 |
|---|---|
| 只记录，不阻断 | 事后的账本能告诉你某个智能体越出了范围。但请求早已发出。 |
| 范围是工具名称，而不是请求 | “该智能体可以使用其浏览器工具”这句话，并没有说明它会用该工具访问 哪个资源 。 |
| 自行上报 | 一个绕开拦截的智能体，没有任何理由上报自己的绕行。 |
| 无法防绕过 | 如果智能体还有别的途径访问互联网，那么一个位于其流量旁侧的控制措施就只具有建议性质。 |
第四行并非纸上谈兵。当我们把自己的网关部署在自己的扫描智能体前面时，智能体一开始就绕过了它——它的浏览器被配置为使用另一个本地代理，而代理环境变量事实上只是建议性的。在此期间，网关看起来一直运行正常。直到我们把那个代理串联到网关上，网关才看到这个智能体。依赖智能体配合的强制执行，算不上强制执行。
我们如何围绕这一点设计 ATPP Enforce
我们针对这一事件编写了 ATPP Enforce 的需求，其中回应这一事件的部分如下。
授权描述的是请求，而不是工具
智能体的授权会写明主机、方法和路径；除非规则另有规定，否则一律只读；并且故障即关闭。无论智能体是如何到达的，向内部服务器写入在默认情况下都会被拒绝。云元数据端点和私有地址段则根本无法被授权。
绕过检测以最终访问的资源为依据，而不是所走的路线
这一部分正是针对远程浏览器这种绕行而设计的。网关会为每个身份保留一个短暂的滚动窗口，记录它请求了什么（归一化为资源标识符）以及做出了什么决策。如果针对某个资源出现了一连串拒绝，并在该窗口内紧接着出现一个 被允许的 请求，以任何机制访问到同一资源——不同的路径、不同的方法，或者经由远程浏览器、抓取服务之类的中间方——该身份就会被暂停。如果中间方隐藏了其目标，那么在遭到拒绝后紧接着出现的一次无法溯源的抓取，本身就是信号。我们会用一段模拟该事件模式的合成重放来测试这一点：直接访问被拒绝三次，然后通过一个获准使用的远程浏览器请求同样的文件。
先影子模式，再磨合期，然后强制执行
这些措施都不应在第一天就阻断生产环境中的智能体。网关首先以影子模式运行；在观察到真实工作、且每一次“本会阻断”的情况都经过复核之前，身份无法切换到强制执行。我们自己的内部试用说明了原因：在一次扫描中，157 个“本应阻断”的请求没有一个是智能体自身所为——它们来自目标页面的遥测和沙箱浏览器的后台流量。一个简单粗暴的授权，恰恰会在没人预料到的地方制造大量噪音。
为受害方提供的手段
Services Australia 无法接入 OpenAI 的智能体，也永远不可能接入。因此，我们的设计包含一个使用方侧的检查：经过强制执行的流量会携带一份签名回执，网站可以查询它收到的某个请求是否受到覆盖——已强制执行且被允许、已强制执行且被拒绝，或根本未受覆盖。当查询范围限定在网站已经怀疑来自智能体的流量时，“未受覆盖”正是运营者在 6 月 18 日最想得到的结论。在否定情形下，它无需任何智能体供应商的配合就能发挥作用，也不要求网站信任我们去识别智能体——这一范围界定仍由网站自己的机器人检测来完成。
一份在你查看时就已存在的记录
OpenAI 直到 8 月才发现这一活动，而且靠的是日志审查。一个为每个请求写入签名决策、并在出现绕过模式时暂停身份的网关，其设计目标是让运营者在请求发生时就能看到第一个迹象。这是一个设计目标，而不是一个已测量的结果。
我们没有说什么
本周该做什么
- 如果你运行着具备网络访问权限的智能体：确保智能体无法通过任何绕开你控制措施的路径访问互联网。亲自尝试一下来验证。
- 按请求形态授权——主机、方法、路径——而不是按工具名称，并默认设为只读。
- 在请求发生的那一刻记录决策，并在针对同一资源出现多次拒绝后又成功时发出告警。
- 如果你运营着一项公共服务：想清楚你将如何区分智能体和人，以及第一次看到智能体试探某个拦截时你会怎么做。
如果你想了解它在实践中的样子，请阅读 Agentic Trust & Protection Platform 或 联系我们 ，了解如何成为设计合作伙伴。