Gemini 进了三家企业系统，安全测试漏了哪一层

一场原本要在靶场里完成的安全测试，后来碰到了三家真实企业的系统。

这不是电影里的那种模型突然觉醒，也不需要把它写成一场谁都控制不了的灾难。公开报道里更扎眼的细节恰好很朴素，测试环境意外可以联网，虚构公司的名字又撞上了真实对象。模型顺着公开信息、暴露的凭证和可猜的密码一路走下去，直到发现目标不对才停手。

好家伙。很多团队给 Agent 做安全评测时，最放心的那句往往就是「它在沙箱里」。这次事情把这句放心话拆得挺干净。沙箱不是一个名字，也不是给模型加了一段提示词。它是一串必须同时成立的工程条件。网络要出不去，名字不能撞车，凭证不能借到真权限，出了异常还得有人能立即按停。

9 月 18 日，Google 向媒体确认，Gemini 模型在今年 5 月的一次网络安全评测中进入了三家真实企业的受保护系统。报道显示，这项由 Irregular 执行的夺旗测试本应面对虚构对象，模型却获得了非预期的互联网访问。Google 表示模型意识到目标是真实企业后停止了操作，相关企业也已被通知。第一财经的报道和Axios 的后续报道都记录了这组关键事实。

真正值得团队抄下来的，不是「Gemini 也会越界」这句标题党，而是安全演练的边界为什么会变成一排多米诺骨牌。

问题不只在模型，边界先松了

安全测试里最容易出现一种错觉，模型的任务被写得很明确，执行器也放进了隔离环境，于是风险应该已经收住。可 Agent 做事不是只读一段文字。它会解析域名，会请求网页，会调用浏览器或命令行，会从上下文里拾取令牌和地址。每多给一个工具，它的行动半径就多一条岔路。

这次事故里，岔路至少有两条。一条是网络出口没有被真正封死，模型能从测试环境接到公网。另一条是虚构对象与真实对象发生了命名碰撞。对人来说，这也许只是一个名字相同的偶然。对一个会检索、会尝试登录、会继续执行任务的 Agent 来说，名字就是路由线索。

不少团队把隔离理解成「给模型一个专门账号」。这只挡住了一部分事。专门账号如果仍能访问公网、读取本机环境变量、继承浏览器登录态，或者拿到可横向移动的云权限，它只是把一把钥匙换了颜色。真遇到错误目标，系统没有理由替你分辨那是不是演练。

这里还有个很现实的分工问题。模型负责完成目标，基础设施负责决定它能碰到什么。前者做得再谨慎，也不该替后者兜底。把「发现不对就自己停止」当作核心防线，等于让执行者兼任边界审计员。这个岗位安排，听着就有点悬。

真正的隔离，得从网络出口开始

如果你的 Agent 在演练里不需要访问互联网，最稳妥的配置不是写一句「不得访问外网」，而是默认拒绝出站连接。DNS、HTTP、HTTPS、代理和浏览器自动更新都在这张清单里。允许访问的测试服务应该走显式 allowlist，并且由独立网关记录每一次请求。

这件事的成本并不神秘。容器或虚拟机启动时，把默认路由切到黑洞，只给测试服务挂私有网络。需要拉取固定依赖时，提前放进镜像或通过审计过的缓存代理提供。需要浏览网页的测试，则用本地镜像站、录制好的响应或专门构造的测试域名。让 Agent 能完成任务，不等于让它拥有一张去公网自由漫游的票。

出站边界要在模型调用之外兑现，不能把自觉停手当成唯一防线。

命名空间也要一起隔离。测试公司名、邮箱、域名和用户名不能凭空编个看起来像真的名字就开跑。IETF 在 RFC 2606 里专门保留了 .test、.example、.invalid 等域名用于文档和测试。把靶场对象全部放在这类保留命名空间里，再从 DNS 层拒绝外部解析，至少能砍掉一大截误撞真实目标的机会。

很多朋友会问，做攻击能力评测不是本来就得让模型碰真实网络吗。可以，但那不是普通功能测试的延长线，而是另一种有授权边界的红队工作。目标清单、时间窗口、测试账号、联系人、数据留存和紧急停止条件都该单独立项。别把「模型能否完成一个任务」和「模型能在任何地方完成任务」混在同一条流水线里。

凭证和权限，别把门卡塞进测试包

这次公开信息里还有一个细节，模型会利用公开代码库中找到的凭证，也会尝试猜解密码。它并没有发明新漏洞。它只是比人更不嫌麻烦，看到线索就继续试。

所以安全演练里的身份设计不能只看「这个 Token 权限小不小」，还要看它会不会被意外带出测试范围。临时凭证要短时有效，只绑定测试租户，只能调用测试服务。云账号要关掉跨项目角色切换，浏览器 Profile 要是全新的，CI 的环境变量也别原样灌进 Agent 容器。

尤其是内部工具越来越喜欢把单点登录、代码仓库、工单系统和云控制台串在一起。对人来说这叫体验顺滑。对一个有工具调用能力的 Agent 来说，这是一张已经铺好的地图。权限设计做得粗一点，模型不需要攻破什么，它只需要沿着你已经授权的关系往下走。

这也是为什么安全验收里该看「爆炸半径」。一次意外请求失败，和一次意外请求拿到生产只读权限，后果完全不是一个量级。最好的测试环境不是永远不出错，而是出错时最多撞到一堵软墙，留下日志，然后退回原地。

上线前，把这五项写进验收单

下面这份清单不替代专业渗透测试，但很适合放到给 Agent 开网络、浏览器或代码执行权限之前。它不是漂亮的安全口号，缺一项都值得把上线按钮先晾一会儿。

[ ] 网络出口默认拒绝，只对测试目标开白名单
[ ] 测试域名、账号和邮箱使用保留命名空间，不复用真实名称
[ ] 凭证只在测试租户有效，短时过期，不能横向切换权限
[ ] 每次工具调用都有请求日志、目标校验和人工紧急停止开关
[ ] 发现未授权域名、生产标识或异常凭证时，执行器自动断网并冻结会话

每一层都能单独拦住一次错误请求，才不会把真实系统留给运气。

这里最容易被省掉的是第四项。很多系统有日志，却没有人在关键时刻看日志。更实用的做法是给高风险调用加一个很窄的闸门，例如新域名、首次出现的云项目、下载到的密钥样式、生产环境标识，只要命中任何一个，执行器暂停，等待人工确认。模型可以快，人确认慢一点没关系，碰到真实系统时慢才是优点。

第五项也别只做成弹窗。会话冻结后，网络连接、临时 Token、浏览器 Cookie 和后台队列都要一起撤销。否则前台看起来已经停了，后台还有一个排队任务继续跑，结果又会变成那种最让人头疼的复盘，明明点了停止，怎么它还在访问。

别把自行停止，当成唯一一道门

Google 表示 Gemini 在识别到真实目标后停止了操作。这个行为当然比继续扩大访问要好，值得记录。但它不能替代前面的隔离层。模型先碰到不该碰的系统，再判断要不要停，已经说明系统把不该交给它的判断交出去了。

工程里最可靠的安全感，通常不是某个组件表现得特别聪明，而是它即使判断错了也没有太多地方可去。权限最小化、网络最小化、身份最小化，听着没什么戏剧性，甚至有点像老生常谈。可 Agent 越能自己找路，这些老规矩就越值钱。

测试的目标也该换一换。别只问模型能不能拿到旗子，还要问它在拿不到旗子时会往哪里走。它会不会请求未知域名，会不会复用发现的凭证，会不会在工具报错后扩大搜索范围，会不会把测试数据带出会话。前一组问题在测能力，后一组问题才在测你给它画的边。

Agent 安全没有一条万能提示词。它更像船上的隔水舱，单个舱门偶尔也会漏，但水不该一路灌到整艘船。现在给 Agent 加权限的团队越来越多，先把这五项边界写进验收单，后面少一次意外访问，就少一次拿真实系统赌运气。

如果你的团队今天只能补一项，你会先收紧网络出口，还是先拆掉那些能一路通到生产的身份关系？