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 已经能够稳定归纳的每一行日志。

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

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

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

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

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

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

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

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

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

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