面向漏洞发现的安全模型：能力声明、授权范围、修复建议要分三层核对
专用安全模型的三类信息需要分开核对：能力声明只能核对发布方描述覆盖了哪些任务，不能据此推断它在你的代码库上成立；授权范围必须由调用侧独立记录目标、时间窗、允许动作与审批，模型自述的“已授权”不构成证据；修复建议在被复现测试和回归验证之前，只能视为候选补丁草稿。三层证据来源不同，混在一起看，就会用发布方声明替代自己的验证。
把面向漏洞发现的专用安全模型接入研发流程时，最稳妥的做法是把三件事拆开核对：它声称能做什么（能力声明）、它在什么边界内被允许行动（授权范围）、它给出的修复能不能用（修复建议）。这三层的证据来源不同；混在一起看，最常见的错误是把“发布方说它行”当成“它在我这里已经验证”。OpenAI 对 GPT‑6 Cyber 的介绍摘要称，该模型用于发现可利用漏洞并开发修复，并经过训练以保持在授权范围内（来源）。这是产品定位陈述，不是针对你代码库的结论；具体评测口径、可用范围与限制，本次材料未提供，待核实。
三层各自该向谁要证据#
| 层 | 证据来源 | 可核对形式 | 缺失时怎么写 |
|---|---|---|---|
| 能力声明 | 发布方公开说明 | 声明的任务对象、输入形态、判定标准 | 标注“发布方声明，未在本项目复现” |
| 授权范围 | 你自己的授权记录 | 目标清单、时间窗、允许动作、审批人、日志 | 视为未授权，不发起请求 |
| 修复建议 | 隔离环境中的复现与回归 | 补丁是否可应用、测试是否通过、接口是否变更 | 标为“候选建议，未验证” |
能力声明：核对覆盖范围，而不是核对结论#
摘要里“发现可利用漏洞”是一个任务描述，不能直接当作能力指标。要拆开看：它针对哪类漏洞、需要静态代码还是可运行环境、由谁判定“可利用”。可核对的做法，是要求报告给出可复查的最小证据链，例如文件与行号、触发前置条件、复现步骤、影响面。只有能按步骤复现的条目，才进入你自己的统计；发布方的描述不能替代这一步。
授权范围：模型的自述不构成授权证据#
“训练为保持在授权范围内”说的是训练目标，不是你环境里的授权判定。授权必须独立于模型输出存在，并在调用前就固定下来。至少要记录：目标资产、时间窗、允许动作（只读探测还是允许利用验证）、禁止项、审批人、速率上限。模型在输出里写“已获授权”不能作为证据；它只能作为待核对的声明。
# 占位示例：非真实配置，未执行
target: https://api.example.com # example.com 仅为示例域名
window: 2026-11-06T10:00Z/2026-11-06T12:00Z
actions: [read_only_scan] # 利用验证需单独审批
forbidden: [data_write, dos, third_party]
approver: YOUR_APPROVER
audit: request_id + 操作者 + 目标 + 实际动作接入初期建议默认只读；把“利用验证”做成单独开关，并保留每次动作的审计行。范围一旦越界，问题不在模型，而在你没能约束住调用侧。
修复建议：只有通过复现与回归的才算修复#
把输出分成三类处理：建议（说明风险与方向）、补丁草稿（可直接应用）、已验证修复（在隔离环境通过复现测试与既有回归）。第三类才需要人来签核合入。核对时要问：补丁是否只掩盖症状（如入口加过滤而未修根因）、是否改动公共接口或依赖版本、是否引入新的失败路径。没有跑过测试的补丁，一律标“未验证”。
接入前的核对顺序#
- 先固定授权记录，再发出第一个请求。
- 用已知漏洞的小样本检验报告是否给出可复现证据链。
- 把修复建议放进隔离分支，跑复现用例与全量回归。
- 把“发布方声明”“本项目复现”“待核实”写成三种状态，不要合并。
本次材料只提供了发布摘要，因此只能支持“该模型定位为发现可利用漏洞并开发修复”这一窄结论。它在具体语言与框架上的表现、授权范围的执行机制、可用性与定价，均待核实，需要以你自己的复现记录为准。
参考来源
以上为本文写作时的参考资料，引用观点以原文为准。
