安全模型做漏洞发现：能力声明、授权范围与修复建议的核对边界

如果你打算把安全模型接进漏洞发现流程，最该先问的不是“它能不能挖洞”，而是“它声称的能力、我给出的授权、它返回的修复建议，这三件事各自由谁证明”。就本次可用材料而言，能核对的只有 OpenAI 于 2026 年 11 月 5 日发布 GPT‑6 Cyber 的摘要所述三点：它被定位为网络安全模型，用于发现可利用的漏洞并开发修复，且在训练中被要求停留在授权范围内（来源）。摘要不等于全文，下面的核对边界都以这三句为限。

能力声明：定位句不是评测结论#

摘要给出的是任务定位——发现可利用的漏洞、开发修复——而不是可比较的性能口径。要把定位变成工程判断，还需要版本标识、调用方式、输入长度与格式限制、评测集与判定标准；这些本次材料未提供，属待核实。不要把“能做”直接读成“做得准”。

使用方可以自己补的核对项：

• 把“可利用”落成可判定条件：是能复现的崩溃或可绕过的校验，还是仅在阅读中被指出的可疑写法。判定条件不定，结果就无法比较。
• 固定输入：同一份代码快照、同一份依赖清单、同一份构建配置。换输入即换题目。
• 记录抽样方式：误报与漏报各自怎么抽、抽多少，而不是只记一个总数。

这一层的结论是：能力声明只能当假设使用，举证责任在使用方。

授权范围：至少分三层，不要合并#

“训练时被要求停留在授权范围内”描述的是模型侧的行为约束，不等于你的项目已经获得授权。三层来源不同、核对方式也不同：

第三层最容易被忽略：模型“愿意待在范围内”，不代表执行环境真的只在范围内。把目标清单、允许手法和时间窗写进配置，而不是留在口头约定里。下表与示例中的域名均为占位。

修复建议：走完四道门再谈“已修复”#

模型输出的是补丁建议。建议与“已修复”之间至少隔着四道门，应分别记录，不要合并成一个“完成”：

1. 建议：模型给出的改动描述或 diff，此时正确性未知。
2. 可编译：在目标分支与目标工具链上能构建通过。
3. 通过测试：原有测试不回退，且针对该漏洞新增了会先失败、修复后通过的用例。
4. 可上线：经人工评审确认未引入新的攻击面，并写明回滚方式。

下面的配置只示意“把授权范围写成可读字段”的结构，未执行，字段名与取值需按你的实际流程改写：

# 示意配置，未执行；域名与密钥为占位
scope:
  targets: ["app.example.com"]      # 占位域名
  window: "2026-11-10T02:00Z/2026-11-10T06:00Z"
  allow: ["static-review", "reproduce-crash"]
  deny:  ["write-to-production", "credential-reuse"]
credentials:
  token: "YOUR_KEY"                  # 占位，不入库
evidence:
  keep: ["input-snapshot", "model-output", "test-run-log"]

一份最小核对清单#

• 能力声明是否已转成可判定的验收条件，而不是营销句。
• 书面授权是否覆盖目标、手法、时间窗三项，且与配置一致。
• 执行环境的凭据是否只读、是否限制出口。
• 每条修复建议是否附带“通过/未通过”的测试记录。
• 模型输出、输入快照与测试日志是否留档，以便复核。

把这三层分开之后，安全模型在流程里的位置会更清楚：它是一个产出候选漏洞与候选补丁的组件，而不是授权的来源，也不是修复的证明。至于具体的版本能力、可用性与计费方式，本次材料的摘要不足以支撑判断，需要以发布方后续文档为准。