Agent 找漏洞前，先把「只能碰什么」写进任务里

真正让安全团队紧张的，往往不是 Agent 漏掉一个问题，而是它为了完成任务，顺手碰了本不该碰的地方。

你给它一句「帮我看看这个仓库有没有安全隐患」，它拿到的却可能是代码、命令行、测试环境和一串已经登录的工具。人类工程师会在看到范围外资源时停一下：这是谁的？我有权限吗？要不要先问？Agent 如果把“有能力访问”误读成“获准访问”，麻烦才刚开始。

OpenAI 昨天发布的 GPT-6 Cyber，把这个问题摆到了台面上。它在 ExploitGym 上报出 48.5% 的成绩，上一代 GPT-5.6 Cyber 是 32.1%。这些数字很容易抢走注意力；更值得团队抄作业的，是另一组：在带有范围外诱饵服务的评估里，它没有触碰禁区的比例是 99.93%，加上部署侧提示后是 100%。

模型能做更多事之后，“别乱来”终于不该只是一句写在系统提示词里的祈祷。它得变成任务输入、运行时控制、验收证据和人工确认共同组成的一层工程。

图：OpenAI 官方披露的范围遵循评估。它衡量的不是模型能否完成任务，而是模型会不会为了完成任务越过授权边界。

能找到问题，不等于该让它自由找

先把事实说清。GPT-6 Cyber 是一款面向获授权安全工作的专用模型，初期只向通过 Daybreak Red 审核的组织开放。官方把它的网络安全能力列为 Critical，并配套身份核验、组织级访问控制、IP 允许列表、沙箱、操作复核和人工监督等约束。模型页 也明确写了：组织需要先获得 Daybreak Red 的批准，才能使用它。

这不是“某个模型很强，所以先锁起来”的老套路。它其实承认了一件挺朴素的事：当模型从聊天框里的建议，走到可以读代码、调用工具、持续执行和产出可复现证据的 Agent，能力与权限已经绑在一起了。

OpenAI 在官方案例里提到，GPT-6 Cyber 协助在 Firefox 中发现 81 个此前未知的高严重性问题，也为 Linux 内核中的 948 个问题形成了可复现的验证。这里有两层边界必须分开看。第一层是能力：模型能把散落在大代码库里的线索串起来，走完一段很长的推理和验证链。第二层是授权：它只能在被允许的目标、环境和时间窗里做这件事。

很多团队现在只讨论第一层。选什么模型、上下文多长、能不能跑更久、能不能少拒绝。可一旦 Agent 被接进仓库、工单、云环境或内部文档，第二层会更早决定它能否进入生产流程。一个很会找问题、却会自行扩大目标的 Agent，不是多请了一位安全同事，更像在办公室里放了一台永远不问门禁的扫地机器人。

官方的范围遵循评估很有意思。它故意把一些不属于任务目标的服务放在 Agent 身边，并让那些服务看起来像一条更容易拿到结果的路。模型若为了完成目标而去动它们，哪怕最后交出了一份漂亮报告，也算失败。

这个标准比“最终找到没有”严格得多。它在考察：Agent 会不会把捷径当授权，会不会把可见资源当可用资源，会不会在任务卡住时私自扩大搜索半径。

对任何接了工具的 Agent，这都该是一条基础验收线。模型偶尔答错，通常还能由人复核；模型把权限边界推开一点，后面留下的审计、合规和信任成本就没那么好补了。

把“授权范围”写成任务合同

安全任务最常见的输入，往往长这样：

帮我检查一下这个服务有没有问题，能修就顺手修。

这句话对人类同事也不够完整，对 Agent 更不够。目标在哪个仓库？允许看哪些分支？可不可以改文件？能不能触发测试？测试失败后是否允许重试？哪些账号、密钥和连接即使能看到也不能使用？“顺手修”是提交补丁、开一个变更单，还是只给出建议？

别把这些细节当成文书工作。它们就是 Agent 的操作系统。没有它们，模型只能从环境里猜；而猜测是最不适合拿来分配权限的能力。

给团队一个可以直接复制的版本。我把它叫做“授权边界简报”。它不是攻击脚本，也不替代安全规范；它只是把每次自动化检查开始前那几句该问清的问题，固定成一个任务入口。

任务：审查支付服务的依赖升级改动
目标：repo/payments，分支 release/2026-11
允许：只读代码；运行既有测试；生成修复建议
禁止：访问其他仓库；读取生产数据；使用环境中现存的登录态或密钥
环境：隔离测试环境；网络出口按项目策略限制
停止条件：发现范围不清、权限异常、需要真实账户操作或测试结果相互矛盾
交付物：问题位置、复现条件、影响说明、建议补丁和测试结果
人工确认：合并补丁、扩大范围、重新授权、触发任何外部动作

这段简报的价值，在于把“能做什么”和“谁批准做什么”拆开了。

“只读代码”不是模型能力描述，而是权限描述。“运行既有测试”不是一句客气话，它告诉 Agent 可以触发什么，也告诉平台该留什么日志。“停止条件”尤其重要：它让模型在碰到不确定情况时有一条合法退出路径，而不是为了把任务做完继续往前拱。

不要迷信一份 YAML 就能驯服所有行为。任务合同只是第一层，后面还得有真实的技术护栏：最小权限凭据、隔离环境、工具白名单、网络限制、可回放日志，以及对高风险动作的人工确认。OpenAI 在发布页里列出的沙箱、操作复核、人工监督和凭据保护，其实也是这件事的不同落点。

图：任务边界不该只写在提示词里；它还应限制可用工具、定义停止条件，并在交付前留下可复核的证据。

评估 Agent，别只盯“找到了几个”

过去评估代码 Agent，大家喜欢问成功率：能不能修 Bug、能不能通过测试、能不能完成工单。安全相关的 Agent 再多看一眼误报率和漏报率。这些当然都该看，但还缺一个问题：它为了拿到结果，是否严格留在授权范围内？

GPT-6 Cyber 的官方数据提供了一个可借鉴的拆法。不要只把任务当成“通过／失败”，至少把评估分成四份：

• 任务结果：是否发现了真实、可修复的问题。
• 范围遵循：是否只访问了任务列明的目标和工具。
• 证据质量：结论是否能被另一个人或另一套环境复核。
• 退出质量：范围不清、权限不足或前提改变时，它有没有停下并把问题说清。

其中最后一项容易被忽略。一个成熟的 Agent 不应只会“继续尝试”；它还要会在不该继续时，交还控制权。

这会改变你怎么设计测试。除了准备真实任务，还应准备一些无害但不在范围内的相邻资源，看看 Agent 会不会因为它们看起来方便就去碰。也应故意给出含糊的授权描述，观察它会追问、停止，还是自行补全。重点不是给模型设陷阱，而是验证它面对不完整指令时会不会把想象当事实。

这里还有一个很现实的判断：官方 99.93% 和 100% 是在特定评估设置里得出的结果，不是你把任何 Agent 接到公司环境后就自动拥有的保证。模型、工具、提示词、权限系统、网络环境和任务压力会一起改变实际表现。把厂商数字当成选型输入可以，把它当成上线豁免就有点草率了。

这件事和普通开发团队有什么关系

“我们又不做安全研究，跟我们关系不大吧？”其实关系正在变大。

不少团队已经让 Agent 读 CI 日志、检查依赖、梳理权限配置、给代码审查提建议，或者在测试环境里跑一串排查动作。它们做的未必是专业漏洞研究，但都有同一种结构：模型拿着比聊天框更大的上下文，能调用比搜索更具体的工具，并可能把输出送进后续自动化环节。

这时最稳的起步方式，不是急着追求“全自动修复”。先挑一个回报明确、可隔离、可复核的任务，例如依赖升级后的只读检查、指定仓库的权限配置盘点，或针对一组已知变更的测试建议。让 Agent 只能读取必要内容，交付结构化证据；真正的改动、合并和外部动作仍留给人确认。

如果它做得好，再逐步扩大范围。每放开一项能力，都补一项看得见的约束：给文件写权限，就把变更限制在临时分支；给命令执行权限，就收窄到允许的命令和测试环境；给外部工具连接，就增加显式审批和完整轨迹。别反过来，先把大门敞开，再指望模型在门口自己学会克制。

这也是 GPT-6 Cyber 真正带来的提醒。未来的竞争不只是“谁的 Agent 更能干”，而是谁能把能干这件事放进一套可被团队理解、审计和叫停的机制里。能力跑得越快，边界越不能写在脑子里。

最后留一个很具体的问题：如果你们明天要让 Agent 接手一次仓库审查，哪一项权限是它绝对不该自行推断出来的？

小岛 AI

记录一线实战、踩坑与成长