OpenAI 把一部分安全团队的“第一眼”交给了模型：新告警先由 AI 分诊，人再处理高影响决策。8 月 17 日，Greg Brockman 在一篇安全文章中把这套安排摆到台前，也给出了一个更具体的主张：安全团队不该只用 AI 多找漏洞，还要让它缩短修复真正漏洞的路径。
这不是一项单独发布的软件功能。它更像 OpenAI 对自动化攻防节奏的一次公开说明：模型已经能把漏洞、错误配置和过度授权的身份关系串成攻击路径，防守方若还按传统工单节奏推进，积压会先于能力升级变成风险。
告警分诊先自动化
OpenAI 称，今天“几乎所有”最初的安全告警都会先经过智能系统分诊，再把人拉入处理环节。公司还在把检测结果接到有边界的自动响应上，但把高影响决定留给人。
原话是：“The goal is to ensure we can detect and respond to security issues at machine speed.” 自然一点说，就是把机器适合做的重复筛查提速，把权限扩大、生产变更和事故判断留给安全人员。
文章给出的个人案例也说明了它想推广的工作方式：Brockman 让公开可用的 GPT-5.6 Sol 检查个人静态站点，约 15 分钟找出 13 个问题；随后又在约一小时内协助完成 DNS、TLS、依赖和部署迁移的修复。这个案例来自公司负责人，不应被当作通用性能基准；但它展示了“发现—验证—修复”被压缩到同一条工作流里的方向。
先扫最窄的一段路
OpenAI 没有建议企业直接建设无人值守的安全运营中心。它给出的路径很克制：先对一个代码仓库做只读扫描，再让模型阅读已关闭告警；确认流程可靠后，再进入拉取请求审查、在线告警分诊，以及范围明确的误报自动关闭。
这种次序值得注意。安全自动化最容易出问题的地方，常常不在模型是否能找到异常，而在异常被接入了什么权限。文章反复提到最小权限、网络隔离、监控和安全发布等传统控制；AI 被放进流程后，这些控制并没有失效，反而更需要明确。
对开发团队而言，眼下可验证的指标不该只是“模型找了多少问题”。更实用的是：高优先级问题从发现到确认耗时多久、修复是否带回归测试、自动化动作是否始终受权限边界约束。OpenAI 的新表态，把这些工程指标推到了 AI 安全产品叙事的前面。
参考来源：OpenAI 安全文章；CocoLoop；核验 AI 告警分诊、人工决策边界与个人站点案例。