文章总结： OpenAI联合创始人GregBrockman发布文章，提出AI安全工具应渐进授权，从只读分析开始，逐步增加权限，并设置正确性、操作安全和治理三类验收门槛。企业应选择低风险场景，在一个月内建立最小安全闭环，确保速度不成为新事故来源。 综合评分： 85 文章分类： AI安全,安全运营,安全建设,解决方案,红队

OpenAI如何给AI安全智能体逐级放权

原创

AI安全社 AI安全社

AI安全社

2026年8月18日 15:23 北京

在小说阅读器读本章

去阅读

2026 年 8 月 17 日，OpenAI 联合创始人 Greg Brockman 发布《The Defender’s Window》。文章延续了 OpenAI-Hugging Face 事件后的判断：AI 正在降低发现和利用既有安全缺口的成本，防守方必须更快地发现、排序和修复问题。

这篇文章最值得企业关注的，并不是“给安全团队配一个智能体”这句产品建议，而是 OpenAI 披露的授权顺序。其内部已让前沿模型参与代码安全、告警初筛、攻击路径枚举，并逐步连接到受限自动响应；高影响决定仍由人负责。对其他组织，文章建议从单个代码库的只读扫描或历史告警复盘开始，建立信心后再进入建议式代码审查、实时告警分诊，最后才自动关闭定义狭窄的误报。

这条顺序回答了一个经常被忽略的问题：AI 安全工具何时可以从“看和说”进入“改和做”？如果没有可验证的放权门槛，安全自动化越快，误封、误改、证据破坏和权限越界也会越快。

关键问题不是能找多少，而是能改到哪里

安全自动化从读取到执行的影响变化

安全团队评估 AI 工具时，容易先看发现了多少漏洞、处理了多少告警、节省了多少时间。这些数字能反映工作量，却不能回答工具是否应该取得执行权限。一个系统即使能准确总结日志，也未必适合关闭告警；即使能写出正确补丁，也未必适合直接合并和部署。

可以把安全自动化拆成四个不同的控制面。读取证据只改变分析效率，形成判断会影响优先级，提出变更会进入研发流程，执行动作则会改变生产状态。每向右一步，所需身份、权限、测试、回滚和审计都应增加。

| 控制面 | 典型动作 | 主要风险 | 最低控制要求 | | — | — | — | — | | 读取证据 | 读代码、配置、历史告警和日志 | 敏感信息外泄、越权读取 | 只读身份、最小数据范围、访问日志 | | 形成判断 | 标注疑似漏洞、排序告警、归纳攻击路径 | 误报、漏报、错误归因 | 原始证据可回看、规则与模型版本可追溯 | | 提出变更 | 生成补丁、检测规则或配置建议 | 改动范围扩大、引入回归 | 独立评审、测试环境、差异清单和回滚方案 | | 执行动作 | 关闭告警、隔离资产、修改权限或部署补丁 | 业务中断、证据破坏、权限越界 | 动作白名单、双重授权、幂等与回滚、全程审计 |

OpenAI 文章中“几乎所有初始安全告警先由智能处理，再引入人”的表述，是厂商对内部流程的自述。原文没有公布样本量、误报率或漏报率，因此不能把这句话理解成所有企业都应立即复制。可借鉴的是控制位置：先让 AI 压缩证据和重复劳动，再按操作影响决定人何时进入。

从只读分析开始逐级增加权限

安全自动化的四级授权阶梯

渐进授权不是给同一个智能体不断添加权限，而是为每一级定义独立身份、允许动作和退出条件。工具在低等级表现良好，只说明它有资格申请下一阶段验证，不代表权限可以自动继承。

| 授权等级 | 系统可以做什么 | 人负责什么 | 应保留的证据 | | — | — | — | — | | 观察 | 离线复盘已关闭告警，或只读扫描一个代码库 | 确认数据范围和正确答案 | 输入快照、基准结论、模型与提示词版本 | | 建议 | 对实时数据给出分级、补丁或处置建议，但不改变状态 | 逐项批准或驳回，记录理由 | 建议、引用证据、人工结论、差异和测试结果 | | 受限执行 | 在白名单场景执行可恢复动作，如创建工单、提交未合并补丁 | 审批策略、抽查结果、处理异常 | 调用身份、策略命中、动作参数、结果和回滚点 | | 狭窄闭环 | 对高重复、低影响且已验证的场景自动处置 | 监控漂移、设定熔断、定期复评 | 处置轨迹、抽样复核、异常率、撤销和事件记录 |

同一个动作在不同环境中可能属于不同等级。自动关闭一个明确无害、能够重新打开的重复告警，和自动禁用生产账号都叫“处置”，操作影响却完全不同。企业应按资产重要性、可恢复性、证据完整性和授权对象分级，不能只按工具功能命名。

执行身份也要随等级变化。观察阶段不需要写权限；建议阶段只能写入隔离的建议区或分支；受限执行使用短期凭据、固定资源范围和动作白名单；狭窄闭环还要具备实时熔断和权限撤销。把人的长期管理员凭据交给智能体，会让渐进授权失去意义。

放权前要同时验收三类证据

正确性、操作安全和治理证据三道门

从一个等级进入下一个等级，至少要同时通过正确性、操作安全和治理三类验收。只证明“答案大多正确”不够，因为安全系统还可能读了不该读的数据、执行了范围过大的动作，或者在失败后无法恢复。

正确性证据回答判断是否可靠。安全运营团队要用已确认结论的历史样本回放，分别统计误报、漏报和证据不足，而不是只报一个总准确率。对补丁类任务，还要验证漏洞是否不再复现、正常功能是否保持、相关变体是否仍存在。样本应覆盖常见流量、边界情况和攻击者刻意制造的误导输入。

操作安全证据回答“做错时会发生什么”。平台与系统责任人需要检查动作是否只影响批准对象，是否具有幂等性，失败能否停止，回滚是否真的执行过。读取、分诊和处置应使用不同身份；生产写操作不能因为模型给出高置信度就绕过策略引擎。

治理证据回答“谁允许它这样做”。安全负责人要批准场景、资产范围和剩余风险，业务负责人确认可接受的中断与恢复时间，审计或合规人员确认日志能够还原输入证据、策略版本、人工决定和最终结果。

| 验收门 | 责任人 | 关键问题 | 通过后才能增加什么 | | — | — | — | — | | 正确性 | 安全运营、应用安全 | 误报、漏报和证据不足是否被分别测量 | 从离线观察进入实时建议 | | 操作安全 | 平台、研发、系统责任人 | 范围限制、失败停止和回滚是否实际验证 | 从建议进入白名单执行 | | 治理 | 安全负责人、业务负责人、审计 | 场景、身份、责任和日志是否得到批准 | 从单次执行进入持续闭环 |

这里不存在适用于所有企业的统一百分比。关闭可恢复的重复工单和隔离核心生产账号，不应使用相同阈值。阈值要由错误后果决定，并在模型、提示词、工具、数据源或处置策略变更后重新验证。

人在回路要负责不可逆判断

人工判断应放在高影响和证据冲突处

“保留人工确认”如果只实现成一个没有上下文的确认框，既拖慢处置，也不能形成有效控制。人真正需要处理的是证据冲突、影响范围不确定、跨系统权限变化和不可逆动作，而不是重复阅读 AI 已经能够稳定归纳的每一行日志。

在请求人工决定前，系统应生成最小证据包：触发事件及时间线、引用的原始日志或代码、建议动作、目标资源、预计影响、冲突信息、回滚步骤、模型与策略版本。审批人可以直接拒绝、缩小范围或改为只读调查，决定与理由都写入审计记录。

| 场景 | 默认决定方式 | 人应看到什么 | 失败处置 | | — | — | — | — | | 历史告警归类 | AI 建议，人抽样 | 原始证据、相似案例、分类理由 | 退回人工队列，修正规则 | | 创建修复工单 | 可自动执行 | 资产、责任人、证据链接、优先级依据 | 撤销或重开工单 | | 提交未合并补丁 | AI 执行，工程师评审 | 代码差异、测试、漏洞复现与修复证据 | 关闭变更，不进入主分支 | | 隔离资产或修改权限 | 每次人工批准 | 业务影响、依赖关系、替代措施、回滚点 | 熔断自动化并启动事件响应 |

OpenAI 提到正在把检测连接到“受限自动响应”，同时让人负责最高影响决定。企业落地时还应补一层独立策略执行：由策略引擎核对身份、资源、动作和审批状态，智能体只提出结构化请求。这样即使模型受到提示词注入、上下文污染或错误工具返回影响，也不能自行扩大权限。

用一个月建立最小安全闭环

四周建立最小安全自动化闭环

企业不需要从“自主安全运营中心”起步。更稳妥的做法是选择一个数据边界清楚、错误可恢复、已有人工结论的场景，在一个月内跑通最小闭环。以下节奏是实施建议，不是 OpenAI 给出的强制周期。

第一周确定范围。选择一个代码库或一类已关闭告警，登记数据源、责任人、读取身份和禁止动作，准备一批已确认结论的回放样本。第二周只做影子运行，AI 给出判断但不进入正式流程，安全运营人员记录误报、漏报、证据不足和处理耗时。

第三周进入建议模式。系统可以创建草稿工单、未合并补丁或处置建议，人逐项决定，并核对漏洞复现、回归测试、影响范围和回滚步骤。第四周只对已经稳定、低影响、可恢复的一个动作开放白名单执行，同时设置抽样复核、异常熔断、短期凭据和一键撤销。

上线评审不要只问“自动化率提高了多少”，而要查看四类记录：输入与结论能否回放，权限是否按场景收窄，失败是否真的回滚，异常是否触发停用。任何关键证据缺失，都应退回上一级授权，而不是让模型在生产中继续积累“经验”。

OpenAI 的文章提供了一个及时信号，但不是外部审计报告。作者个人网站“15 分钟发现 13 个问题、约 1 小时完成修复”的经历，也不能当作企业效率基准。更不能由此得出 AI 已经可以替代安全人员的结论。

防守方真正的时间窗口，来自两件事同时成立：AI 缩短了证据整理、问题定位和修复准备的时间；身份、最小权限、隔离、测试、人工判断、回滚和审计仍然限制着每一个动作。前者决定速度，后者决定这种速度会不会变成新的事故来源。

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：AI安全社 AI安全社 AI安全社《OpenAI如何给AI安全智能体逐级放权》