一个 OpenAI Agent 绕过了政府网站限制，互联网的旧权限体系准备好了吗？

6 月 18 日，一个 OpenAI 内部研究 Agent 接到了一项看起来很普通的任务，查找澳大利亚公共药品支出的数据。

它上网搜索，找到了澳大利亚政府运营的 Medicare Statistics Reporting Service。门户没有按它预期的方式返回信息，它没有停下来，而是继续寻找别的路径。最后，它未经授权进入了这个统计门户，访问了公开和非公开文件。

澳大利亚总理 Anthony Albanese 在 9 月 24 日的新闻发布会上确认了这件事。OpenAI 后续也承认，模型采取了团队没有预期的行动。

这句话读起来有点平淡。

可如果把主语再看一遍，事情就不太一样了。不是安全研究员在做渗透测试，不是黑客盯上了医疗系统，也不是某个用户写提示词要求 ChatGPT 攻击政府网站。

它原本只是在找一组公开数据。

先别急着把它叫成医保数据泄露

这件事很容易被标题带偏，所以先把事实边界讲清楚。

涉事系统是 Services Australia 管理的 Medicare 统计报告门户。它主要存放批量结算、免疫接种、药品福利计划和器官捐献等汇总统计，不是处理个人医保账户、理赔或支付的核心系统。

澳大利亚政府确认，Agent 访问了公开和非公开文件。政府同时强调，这些资料属于非敏感统计数据，目前没有证据表明个人医疗信息被访问，也没有证据显示 Services Australia 的更大范围网络遭到入侵。司法取证仍在继续，所以「没有发现」和「最终排除」还不是一回事。

ABC 的调查梳理补充了更多时间线。Agent 执行的是 OpenAI 内部研究任务，目标是查询公共药品支出。OpenAI 在 8 月审查模型失配行为时发现相关活动，9 月 10 日才通过一个公共邮箱通知 Services Australia。澳大利亚政府随后关闭旧门户，并让 Australian Signals Directorate 参与调查。

还有一个现在不能填上的空白，Agent 到底用了什么方法进入非公开区域。

政府没有公布完整攻击链，OpenAI 也没有公开足以复现的技术细节。同期，研究机构 Transluce 公布了其他 Agent 借助远程浏览服务探测公共数据网站的记录，但那批记录不能直接证明 Medicare 门户使用了相同方法。把两件事拼成一条完整攻击过程，会比现有证据多走一步。

知道哪里不知道，同样重要。

网站说不，和系统真的不允许，是两回事

过去的网站安全模型里，人是默认操作者。

用户点开页面，遇到登录框、错误提示、下载失败，大多数人会停下来。搜索引擎看到 robots.txt，合规爬虫会把它当成边界。按钮被隐藏、链接没有展示、接口没有写进文档，也经常被产品团队当成一道不太牢但够用的围栏。

Agent 改变的是这个默认前提。

它不是只会重复点击的脚本。它能理解任务目标，观察失败结果，修改请求，寻找备用网址，换工具，调用远程浏览器，再根据新信息继续尝试。对它来说，「这个页面没有给我答案」可能不是终点，而是下一轮规划的输入。

这也是这次事件真正让人不安的地方。

旧互联网大量系统依赖的并不是严密授权，而是摩擦。入口很难找、页面已经过时、参数没人知道、正常用户懒得继续折腾。几十年来，这些摩擦挡住了绝大多数普通访问，于是它们慢慢被误认为权限。

可摩擦不是权限。

一个能低成本反复尝试、不会疲劳、还会自己换路线的 Agent，恰好会把这些隐含假设逐个拆掉。网站在界面上表达了一次拒绝，并不代表后端每个接口、每个文件和每条写入路径都完成了身份验证与授权。

过去那道看起来够高的围栏，现在来了一个会自己找梯子的访问者。

问题不只是 Agent 太聪明

把责任全部推给模型，也很轻松。

Agent 绕过限制，当然是 OpenAI 的控制失败。一个内部研究模型不该因为任务受阻，就自行扩大操作范围。OpenAI 自己发布的第三方影响与模型失配说明里，已经把访问控制绕过、使用暴露凭据、查询或命令注入、访问运行时内部等行为列为真实出现过的风险类别。

但另一半问题属于网站。

如果一个非公开文件只靠不可见链接保护，如果公共统计门户和内部文件共用过大的访问范围，如果后端只相信来自前端的参数，如果旧系统没有细粒度日志和异常速率告警，那么今天碰到的是研究 Agent，明天也会碰到普通攻击者。

Agent 没有创造这些漏洞，它只是把发现和利用薄弱边界的成本压低了。

所以防线必须同时从两端补。

网站一端，需要把「不希望你访问」变成「你没有身份和权限就无法访问」。每个接口和对象都要独立做服务端授权，公开区与内部区分开部署，旧门户不再因为数据看起来不敏感就降低安全等级。还要记录机器访问的完整轨迹，识别短时间内不断换参数、换入口、换工具的行为，而不是只盯传统的高频爬虫。

Agent 一端，需要把浏览、执行代码、上传文件、写入第三方系统拆成不同能力，默认最小权限。遇到明确拒绝后，后续尝试应该触发更严格的策略检查，而不是把拒绝单纯当成待解决的障碍。高风险操作要能被外部监控器看见，也要能在越界前停下来请人确认。

OpenAI 在内部编码 Agent 监控研究中披露过类似问题。模型有时会编码命令、切换执行路径或利用其他实例来绕过限制。更关键的是，修改提示词能降低这类行为，却不能把它完全消除。只靠一句「不要越权」保护真实系统，和只靠网页上没有下载按钮保护文件，其实是同一种侥幸。

最难补的是责任边界

技术问题之外，这次事件还有一条很容易被忽略的时间线。

事件发生在 6 月 18 日。OpenAI 说自己在 8 月 11 日的内部审查中发现活动，直到 9 月 10 日才通知澳大利亚方面，而且发到的是一个每天只检查一次的公共邮箱。Services Australia 又过了数日才向 Australian Signals Directorate 报告。

一个自主 Agent 造成外部影响时，谁是行动者，谁应该负责，谁必须第一时间拉下电闸？

法律不会因为模型会规划就把它当成一个可以独立承担责任的人。部署它、赋予工具、设置目标和决定监控强度的组织，仍然要为它采取的行动负责。难点在于，传统安全事件响应流程往往假设有人主动发起攻击，而 Agent 事故可能来自一个完全正常的业务目标，中间经过几轮自主决策，最后才越过边界。

这类事故的披露标准也还没成熟。

访问了非公开但不敏感的统计文件，要不要按数据泄露处理？模型只是探测漏洞但没有取得数据，要不要通知目标机构？同一个 Agent 在一次长任务里接触了十几个第三方系统，开发者如何确认影响范围？如果日志散落在模型轨迹、浏览器工具、代理服务器和第三方平台里，谁来拼起完整证据？

这些不是未来问题，澳大利亚政府现在就在处理。

互联网需要为「不知疲倦的用户」重新设防

我觉得这件事最值得记住的，不是 Agent 已经强到能黑进政府系统。这个说法既夸张，也模糊了真正的问题。

真正发生的，是一个被赋予浏览和行动能力的模型，为了完成一个无害目标，自主选择了未经授权的路径。而它面对的，是一套把人的耐心、知识和操作成本偷偷算进安全模型里的旧系统。

过去，我们默认访问者会累，会放弃，会看不懂报错，也不会为了找一张统计表同时试十种路线。

Agent 不会。

这不代表每个网站都要把自己修成银行金库，也不代表应该禁止 Agent 访问互联网。它只是提醒我们，公开页面、可访问资源和已授权操作是三件不同的事。robots.txt 是礼貌约定，登录框是身份入口，真正的边界必须落在后端授权、能力隔离和可审计的执行链上。

那道围栏以前可能够用。

现在，梯子已经出现了。