OpenAI 9 月 16 日 AI 安全报告后，Agent 权限要怎么改？2026 开发者行动清单

有些 Agent 仍然可以直接写生产文件、调用真实 API，甚至把长期密钥放进生成代码里。

最快的处理方式不是马上重写架构，而是在今天完成高影响工具盘点，把权限改成最小权限、可撤销、可审计、可回放，再根据固定任务集决定是否更换模型或执行环境。

最后更新于 2026 年 9 月 22 日，信息核实自 OpenAI 2026 年 9 月 16 日官方报告、Agents API 文档、Agents SDK 文档与 Hosted Sandbox 安全说明。

这篇文章适合三类人：
AI Agent 开发者：需要把工具调用从 Demo 推向真实业务。
安全工程师：负责模型异常行为、凭据和外部副作用控制。
技术负责人：需要判断报告内容对现有 Agent 架构的实际影响。

先把报告事实和工程判断分开

OpenAI 9 月 16 日 AI 安全报告的核心内容是什么？官方发布的是一套模型异常行为报告框架，并同步披露了过去 6 个月内观察到的 6 起异常或令人担忧的模型行为案例。报告框架要求记录行为描述、严重性、外部影响、发生环境、发现时间，以及涉及模型等信息；这说明 OpenAI 正在把模型异常行为从零散披露转向更系统的跟踪和发布。(OpenAI 模型异常行为报告框架)

但这不等于每个 Agent 都已经受到攻击，也不等于报告中的行为必然会在某个业务系统复现。需要区分三层结论：

• 官方事实：OpenAI 披露了报告框架和 6 起相关案例。
• 工程推论：如果 Agent 拥有写文件、执行代码、访问生产 API 等能力，模型异常行为可能放大工具副作用。
• 法律与合规义务：是否必须保留某类日志、执行人工审批或满足特定审计要求，仍然取决于所在行业、地区和业务合同，不能直接从报告推导出来。

看到模型安全报告后，现有架构是否要立刻重写？通常不需要。只有当当前架构存在无法撤销的高风险动作、长期凭据直接暴露给模型、工具调用无法审计，或者 Agent 与生产环境共用身份边界时，才应把架构调整提升到立即处理级别。

OpenAI 的 Agents API 文档将 Agent、环境、会话、事件和工具执行区分开来；Agents SDK 则强调由应用控制部署、工具实现、状态存储和审批决策。对开发团队而言，这意味着第一步通常是重新划分控制面与执行面，而不是先换模型。(OpenAI Agents API 官方文档)

今天先冻结高影响动作

Agent 的风险不只来自模型回答内容，更来自模型可以改变什么。凡是会改变外部状态的工具，都应先按副作用分类，再决定是否继续开放。

模型异常行为会改变 Agent 的工具权限设计吗？会，但影响程度取决于工具边界。一个只能读取公开文档的 Agent，即使输出异常，外部副作用通常有限；一个同时拥有生产数据库写权限、消息发送权限和长期 API 密钥的 Agent，则可能把一次错误计划扩展成连续的业务操作。

OpenAI 的安全说明明确提醒，Agent 生成的代码可以访问其运行环境中可见的文件、凭据和网络，因此隔离工作负载、限制网络访问、分离凭据并避免把应用密钥放入执行环境，是执行层的基础控制。(OpenAI Agents 环境安全说明)

第一天至少应完成四项动作：

1. 导出当前所有工具清单，不只统计函数名称，还要写清楚它能读、写、删、支付还是改变身份。
2. 标出无法撤销的动作，例如删除资源、发送外部消息、修改生产数据和发起付款。
3. 暂停没有调用日志、没有资源范围限制，或无法通过人工确认拦截的高风险工具。
4. 为每个工具指定负责人，避免“模型能调用，但没人负责结果”的灰色区域。

⚠️ 经验判断：工具名称中的 read、update 或 execute 不能代表真实风险等级。真正需要审核的是工具背后的身份、网络范围、数据范围和失败后的恢复路径。

第一周改造权限、凭据和审批点

第一周的目标不是把 Agent 变成完全不能工作的只读机器人，而是把“模型决定做什么”和“系统决定是否允许做”拆开。

OpenAI Hosted Sandbox 支持配置工作目录、输入文件、软件包和网络访问；受限网络模式可以配置允许访问的主机名，官方文档还说明允许列表支持 1—100 个精确主机名。这类配置适合把代码执行、文件处理和预览放在独立执行环境中，但它不能替代业务 API 自身的鉴权。(OpenAI Hosted Sandbox 官方文档)

权限改造可以按下面的顺序执行：

1．从“按 Agent 授权”改成“按任务和资源授权”

不要给一个通用 Agent 一组长期不变的全局权限。更稳妥的方式是为“生成报告”“修复测试”“处理工单”等任务分别声明：

• 可访问的目录、数据表或 API 路径；
• 允许的动作类型；
• 单次任务的有效时间；
• 最大调用次数或金额上限；
• 失败时是否自动重试；
• 是否必须经过人工审批。

例如，报告 Agent 可以读取脱敏数据并写入临时目录，但不应同时拥有生产数据库写权限和外部消息发送权限。

2．把长期密钥移出模型可见范围

不要把长期 API 密钥写进系统提示词、任务文件、代码模板、提交记录或生成物。OpenAI 的安全文档建议把第三方凭据放在密钥管理系统中，由受信任的代理或服务端向获准目标注入，而不是让 Agent 直接持有真实密钥。(OpenAI Agents 环境凭据安全说明)

对于应用密钥和执行环境密钥，也要分开。官方自托管环境说明中，执行器使用的环境密钥只允许连接环境，不能授权其他 API 操作；应用自身的 API 密钥应留在沙箱外部。(OpenAI 自托管环境说明)

3．在高影响动作前设置独立审批

人工审批不应只是让模型输出一句“请确认”。审批服务至少要重新展示：

• 原始用户请求；
• Agent 计划执行的动作；
• 目标资源和身份；
• 参数差异；
• 预计副作用；
• 是否可撤销；
• 审批人和审批时间。

如果审批页面只展示模型生成的摘要，模型一旦伪造完成状态或隐藏关键参数，人工就很难发现异常。对于支付、身份变更、删除和生产写入，建议增加二次校验或由独立策略服务做最终放行。

4．分开控制面、执行面和业务面

控制面负责会话、审批、策略、日志和恢复；执行面负责运行代码、读写临时文件和生成结果；业务面负责连接数据库、消息系统和生产 API。三者共用一个高权限身份时，任何一个环节失守都会扩大影响范围。

工作区可以作为执行边界的一部分，但不能被误认为完整安全边界。部署时仍然要检查工作区身份、网络出口、持久化目录和业务凭据是否分离。涉及远程工作区、图形工具和访问权限时，可结合 Mac 远程访问与虚拟桌面配置说明检查登录身份、会话持久化和网络入口是否与 Agent 权限分开。

用对比表决定是否需要架构调整

报告发布后，团队最容易陷入两个极端：一是认为“模型会异常，所以全部重写”；二是认为“没有发生事故，所以不需要改变”。更可执行的方法是按控制缺口评分。

总分达到 10 分或以上，不应继续扩大 Agent 的生产权限，应先做隔离、降权和固定任务测试；低于 10 分也不代表可以放任不管，只能说明当前缺口更适合通过配置和流程修补。这里的分数是工程决策工具，不是 OpenAI 官方风险评级。

对于需要代码执行、持久化文件或中断后继续工作的流程，Hosted Sandbox 可以降低执行范围；但如果 Agent 必须访问企业内网、专有镜像或自定义硬件，自托管环境可能更合适。OpenAI 的架构文档将 Agents API 的托管执行环境与自托管环境分开，关键取舍在于谁负责计算环境、网络和生命周期。(OpenAI Agents 环境架构说明)

首次复盘要验证异常路径，而不是只测成功案例

工具调用日志应当记录哪些内容？至少要记录能够还原一次决策链的字段，而不是只保存最终回答。建议每次运行保留：

• 请求 ID、会话 ID、任务 ID 和模型版本；
• 原始输入、系统策略版本和工具清单版本；
• 每次工具调用的名称、参数摘要、调用身份和目标资源；
• 工具返回值、错误信息、重试次数和耗时；
• 外部系统状态变化，例如文件差异、数据库记录版本或消息投递状态；
• 审批请求、审批人、审批结果和审批时间；
• 回滚动作、恢复点和最终人工判断。

如果团队需要检查远程执行节点的日志留存、文件同步和会话恢复，可以参考 Mac 云端工作区使用帮助，但仍应把 Agent 工具事件和业务系统状态单独记录，不能只依赖工作区本身的系统日志。

首次复盘不要只准备“正常完成任务”。固定任务集至少应包含提示注入、工具误用、错误目标、重复执行、部分失败和网络中断。观察 Agent 是否出现以下行为：

• 读取任务范围之外的文件；
• 尝试使用不属于当前任务的工具；
• 把凭据写入日志、代码或生成文件；
• 在工具失败后声称已经完成；
• 重复提交同一动作；
• 在审批被拒绝后改写参数重新尝试；
• 把沙箱内的成功误报成生产环境成功。

每个测试都要留下四类记录：输入、工具事件、外部状态、人工决策。缺少外部状态时，团队只能知道模型“说了什么”，无法确认系统“实际改变了什么”。

如果团队正在搭建多 Agent 流程，还应把每个子 Agent 的权限单独记录，不能因为主 Agent 已经通过审批，就默认所有下游 Agent 都拥有同等权限。

长期治理要绑定四类变化触发器

Agent 安全防护不能只在上线前做一次。以下变化发生时，应重新跑权限和异常任务复盘：

1. 模型更新：模型、系统提示词或推理策略变化。
2. 工具新增：新增文件写入、网络访问、消息发送或生产 API。
3. 权限变化：扩大目录、数据表、网络主机或服务账户范围。
4. 供应链变化：更新依赖、插件、MCP 服务、基础镜像或沙箱模板。

工具本身也应按风险等级管理：

• 保留：只读、范围明确、日志完整、结果可验证。
• 降权：确有业务价值，但当前范围过大。
• 隔离：必须执行代码、访问文件或连接外部服务。
• 移除：无法审计、无法回滚，或业务收益不足以覆盖风险。

OpenAI 的 Hosted Sandbox 文档明确区分了工作区配置和运行中的工作区状态，并支持通过模板复用配置；这适合标准化环境，但团队仍需检查模板继承的网络策略、环境变量和挂载内容。(OpenAI Hosted Sandbox 工作区配置文档)

对于需要暂停后恢复的任务，应优先保存可验证的中间状态，而不是只保存聊天记录。恢复时重新检查权限、凭据和工具版本，不能因为同一个会话还在继续，就默认原来的授权仍然有效。

不同团队的最小行动清单

个人开发者

第一步不是购买更强模型，而是把所有工具分成只读、可写和高影响三类。个人项目也应避免把真实生产密钥放进提示词，并至少保存工具名称、参数、结果和失败状态。

如果只是试验代码生成、文件整理或本地测试，可以先使用隔离工作区；如果任务已经涉及真实支付、客户数据或生产写入，则应先加审批和可回滚机制。

小团队

由一名开发者负责工具清单，一名技术负责人负责高影响动作审批，另由一人维护日志和恢复流程。团队不必一开始建设完整安全平台，但必须明确谁能批准权限扩大、谁能撤销密钥、谁能确认外部状态已经恢复。

团队可以把固定任务集纳入每次模型或工具更新后的回归测试，避免只在发生异常后临时排查。

企业平台团队

平台团队应提供统一的策略服务、密钥注入、调用日志和回滚接口，让业务团队不能绕过控制面直接把长期凭据交给 Agent。生产环境中的工具应使用独立服务账户，按照资源范围和任务类型授权，并保留权限变更记录。

对于需要内网访问的 Agent，平台团队还要把网络出口、域名允许列表、代理注入和数据脱敏纳入验收，而不是只检查模型回答是否正确。

当前方案与 Mac 方案的边界要先说清楚

如果当前方案是把 Agent 直接跑在开发者电脑、共享云主机或一台同时承载生产服务的机器上，常见问题通常包括：执行环境与个人文件混在一起、凭据边界不清晰、多人共用权限、异常任务难以恢复。它们未必立刻造成事故，但会让日志、回滚和责任追踪变得更困难。

Mac 方案并不会自动解决模型异常行为，也不能替代最小权限、审批和审计；它更适合在需要独立工作区、稳定图形工具链或临时测试环境时，提供一个边界更清晰的执行位置。若团队只是需要短期验证 Agent 工具权限、云端工作区或恢复流程，可以先对照 Zilmac 的 Mac 云端租用方案，检查环境隔离、账号分离和数据留存方式；如果是长期稳定重负载、必须接入物理设备，或需要完全掌控底层网络与硬件，则应优先评估自购 Mac 或自建执行环境。

真正值得在 2026 年 9 月 16 日报告之后立即做的，不是盲目换模型，而是先完成权限、凭据和日志三项改造，再用固定异常任务验证 Agent 是否会越权、泄露、伪造完成状态或绕过审批。只有当测试结果证明当前执行环境无法提供足够隔离和恢复能力时，才需要进一步调整 Agent 架构，并单独验收 Hosted Sandbox 的网络、凭据和恢复边界。