一、这次公开报道确认了什么
中国日报网转载页面明确写到：
- 发现方为 360 自研 AI 安全攻防系统“图龙锋”；
- 报道数量为 6 个高价值安全漏洞；
- 其中包含被描述为可能导致远程任意代码执行的高风险缺陷；
- 报道声称相关风险可绕过 Codex 安全信任提示；
- 场景涉及打开从互联网下载的不可信项目目录；
- 报道称相关漏洞已上报国家有关监管单位。
这些是媒体报道所提供的信息，不等于已经完成公开技术披露。文章还介绍了图龙锋的能力和业绩，这部分带有对安全产品的介绍性质，企业在风险决策时应把“漏洞事实”“产品宣传”和“行业观点”分开。
二、当前公开材料还缺哪些关键证据
要把一条漏洞消息转换为可执行的修复通知，通常需要更多信息：
- 具体影响 Codex CLI、IDE 扩展、桌面端、云端还是其他组件；
- 受影响版本和操作系统；
- 触发前提与默认配置；
- 是否必须用户批准某个动作；
- 漏洞编号、严重性评分和技术根因；
- 是否已经向厂商协调披露；
- 修复版本、缓解措施和发布日期；
- 可安全验证的检测方法。
截至本文写作时，上述转载报道本身没有给出这些内容。因此，企业应由安全负责人持续关注 OpenAI 官方发布渠道、产品更新和发现方后续披露，并根据自己实际使用的产品与版本判断，而不是把标题当作完整安全公告。
三、为什么“打开一个项目目录”会成为高风险动作
传统理解里，打开代码文件只是读取文本。但现代开发项目常常携带大量可执行或可影响工具行为的内容：依赖安装脚本、构建脚本、任务配置、IDE 设置、钩子、项目说明、容器配置和自动化工作流。
AI 编程智能体不仅阅读文件，还可能执行命令、安装依赖、运行测试、访问网络和修改代码。不可信项目中的恶意说明、脚本或配置如果诱导智能体采取危险动作，风险就从“代码内容有问题”升级为“开发工具获得了执行入口”。
这类风险可以粗略分成三层：
- 项目本身的可执行内容：安装、构建或测试时直接运行；
- 针对智能体的提示注入：文件内容伪装成可信指令，诱导读取密钥或联网外传；
- 工具或信任机制缺陷：原本应拦截的动作被绕过。
媒体报道指向第三类可能性，但企业即使不了解漏洞细节，也应该先治理前两类长期存在的通用风险。
四、沙箱和审批为什么要同时存在
OpenAI 官方《Agent approvals & security》说明，Codex 的安全控制来自两层：
- 沙箱模式决定智能体技术上能访问和修改哪些位置、是否能联网；
- 审批策略决定哪些动作必须停下来请求批准。
官方说明还指出，默认情况下网络关闭，本地运行通常通过操作系统强制沙箱把写入限制在当前工作区，并通过审批政策控制越界或联网动作。
两层的意义不同。审批不能替代隔离，因为用户可能在疲劳或不了解命令时点同意；沙箱也不能替代审批，因为即使只在工作区内，一个危险命令也可能破坏代码或读取项目中的敏感文件。
如果企业直接开启全访问、关闭审批、允许任意网络，并把生产密钥放在同一环境，就相当于主动撤掉了多层防线。全访问应该是少数隔离场景的例外，不应成为日常默认配置。
五、为什么 AI 不能成为自己唯一的安全审计人
标题中的“不能自己验自己”不是说 AI 完全不能检查代码，而是强调独立性。
1. 生成和审查可能共享盲区
同一模型、同一上下文和同一错误假设，可能在生成时犯错，在审查时继续认为它合理。让它再读一遍，不一定构成真正独立验证。
2. 模型容易被当前任务框架影响
如果提示一直强调“尽快让测试通过”，智能体可能更关注功能完成，而忽略权限、异常和攻击路径。独立安全测试需要不同目标、样本和工具。
3. 静态代码不等于运行时行为
漏洞可能来自部署配置、身份权限、网络、真实依赖和生产数据流。仅阅读当前代码无法覆盖完整系统。
4. 工具本身也属于攻击面
此次报道提醒企业，代码生成工具、插件、扩展、代理协议和审批机制本身都需要更新与审计。让被评估的工具决定自己的全部安全边界，会缺少独立视角。
5. 业务风险需要人做判断
同一技术缺陷在测试工具和支付系统里的影响不同。是否允许上线、是否需要停服和如何通知客户，必须由有授权的技术与业务负责人决定。
更合理的关系是：AI 参与发现和修复，独立扫描器提供不同证据，工程师验证利用条件，安全负责人作风险决定。
六、第一道防线：把不可信仓库当作可执行内容
从邮件、论坛、网盘或陌生 Git 仓库下载的项目，不应直接在日常开发电脑、含生产密钥的环境或企业内网高权限终端打开并运行。
建议流程是：
- 先确认来源、提交历史和签名；
- 在隔离虚拟机、容器或专用分析环境中打开；
- 默认关闭网络或只允许必要域名；
- 不挂载个人主目录、SSH 密钥、云凭证和生产配置；
- 先只读检查项目说明、依赖与脚本；
- 审核安装、构建、测试和 IDE 任务会执行什么；
- 如需联网安装依赖，使用代理、镜像和审计；
- 分析完成后销毁或重置环境。
“只是看看代码”不再是低风险假设。特别是 AI 工具具备自动执行能力时，打开目录之前就要决定信任级别。
七、第二道防线：让密钥不在智能体触手可及的地方
很多严重事件并不需要控制整台电脑，只要读取 .env、云访问密钥、SSH 私钥、浏览器会话、包仓库令牌或数据库连接，就能造成外部影响。
企业应做到：
- 开发、测试和生产凭证完全分开；
- 默认不把生产密钥放进开发工作区；
- 使用短期、最小权限凭证；
- CI/CD 只在必要步骤注入密钥；
- 日志和对话记录不保存密钥；
- 离职、设备丢失和疑似泄露时可快速吊销；
- 定期扫描仓库历史中的秘密信息；
- 对高风险操作使用二次授权。
即使沙箱出现缺陷，最小权限和凭证隔离仍能降低损失范围。这就是多层防御的价值。
八、第三道防线：默认关闭网络，按任务开放
没有网络，恶意代码仍可能破坏本地文件，但外传数据、下载二阶段载荷和连接内网服务会更困难。OpenAI 官方也把默认无网络作为重要边界。
需要联网时，不要简单允许全部互联网。可以按任务开放包仓库、公司代码平台或特定 API；阻止本地、私有网段和不相关域名；记录异常连接；安装完成后重新关闭。
还要注意，命令网络、浏览器、连接器、MCP 和其他工具可能走不同通道，不能只配置一处防火墙就认为全部受控。企业需要盘点智能体能调用的每一种工具和数据源。
九、第四道防线：独立验证 AI 生成的代码
一个可执行的验证链可以包括：
代码评审
由另一名工程师核对权限、输入校验、错误处理、敏感数据和关键业务规则。高风险代码不能只由生成者点击通过。
静态分析
使用与生成模型独立的 SAST、代码规则和类型检查，发现危险 API、注入、路径处理和不安全配置。
依赖与供应链扫描
检查已知漏洞、恶意包、许可证、锁文件和构建脚本。AI 推荐的库名也可能错误或被攻击者抢注。
密钥扫描
覆盖当前文件和 Git 历史，阻止凭证进入仓库。
动态测试
在隔离环境运行单元、集成和安全测试，验证身份、授权、输入边界、并发和异常行为。
专项安全测试
对支付、文件上传、管理后台、AI Agent 和公开 API 做威胁建模、渗透测试或红队验证。可参考《GPT-Red 自动红队发布：为什么安全测试也要持续自动化？》。
不同方法覆盖不同盲区。多一个 AI 审查提示词，可以作为辅助，但不能替代这些证据。
十、AI 编程的验收标准应该多哪些内容
传统软件验收常只看功能。引入智能体后，还要验：
- 使用了哪些模型、插件和工具；
- 智能体能读写哪些目录；
- 网络访问和域名范围；
- 哪些动作需要人工批准；
- 是否接触客户数据和生产凭证；
- 生成代码由谁复核；
- 扫描、测试和修复证据；
- 第三方依赖与许可证清单；
- 对话和工具日志保存多久；
- 工具版本如何更新；
- 发生异常怎样暂停、吊销和调查。
AI 写得快，不应让测试时间被压缩。相反，生成量增加后，企业更需要自动化门禁和风险分级。
十一、发现可疑行为时怎样处理
如果打开项目后出现未知命令、异常联网、凭证访问、审批提示与任务不符或安全工具告警，应立即停止运行，不要继续让智能体“自己查一下”。
在不破坏证据的前提下：
- 断开受影响环境的网络；
- 记录时间、工具版本、项目来源和可疑动作；
- 保留日志、进程、文件哈希和审批记录；
- 从安全设备轮换可能暴露的密钥；
- 检查代码仓库、云平台和身份系统的异常活动；
- 由安全人员在隔离环境分析；
- 根据影响范围决定通知、恢复和报告。
不要在原设备上随意下载未知修复工具或删除所有文件。响应步骤应与企业现有事件处理流程一致。
十二、企业现在应该做的七项快速检查
- 盘点 Codex 及其他 AI 编程工具的产品形态、版本、安装范围和负责人；
- 查看是否存在全访问、无审批、任意网络的默认配置；
- 检查开发工作区是否存放生产密钥和客户敏感数据；
- 为互联网项目建立隔离打开流程；
- 将 AI 代码纳入代码评审、依赖、密钥和安全扫描；
- 关注 OpenAI 官方更新和发现方后续技术披露，按受影响版本升级；
- 选择一个真实项目演练审批、阻断、密钥吊销和事件响应。
这七项即使最终确认本次漏洞不影响你的环境，也能降低其他供应链、提示注入和误操作风险。
十三、不要因新闻走向两个极端
第一个极端是“有漏洞就全面禁用 AI”。软件和开发工具都可能出现漏洞，关键是能否及时更新、隔离和建立补偿控制。盲目禁用还可能把员工推向未经批准的影子工具。
第二个极端是“AI 自己会发现和修复，所以不用人工安全”。模型能显著提高分析效率，但系统安全涉及独立证据、运行环境、身份权限和业务责任，不能交给单一模型闭环决定。
企业更适合采用受控开放：按项目风险配置权限，让低风险任务高效自动化，让高风险动作必须审批和独立验证。
关于智能体身份和动作审计，可继续阅读《AI Agent 安全标准开始成形：企业最该先补的是身份、授权和动作审计》；涉及桌面操作时，可参考《Codex 支持 Windows Computer Use：先把权限和流程想清楚》。
常见问题
现在是否应该立刻卸载 Codex？
仅凭当前转载报道无法对所有产品和版本给出统一结论。企业应先核对实际使用版本、官方更新和安全配置；对不可信项目、高权限和含生产密钥环境立即收紧。若安全团队评估风险不可接受，可临时停用相关场景。
文章能否提供漏洞复现步骤？
不能。当前公开报道没有给出足够技术细节，在生产或日常电脑上尝试未知利用也可能造成损害。验证应由授权安全人员在隔离环境依据正式公告进行。
使用沙箱后是不是绝对安全？
不是。沙箱能缩小访问范围，但仍要结合审批、网络隔离、最小权限、密钥管理、更新和独立测试。任何单层控制都可能配置错误或存在缺陷。
让另一个模型审查代码算独立审计吗？
比同一上下文自检多一层视角，但仍不足以替代人工、静态工具、依赖扫描和运行时测试。真正的独立性来自不同方法、不同权限和可核验证据。
Codex Security 能否解决 Codex 工具自身漏洞？
Codex Security 是用于扫描连接代码仓库的安全产品；工具自身的产品漏洞需要由厂商安全响应、版本修复和独立研究共同处理。二者不能混为一谈。
新闻来源与口径说明
- 中国日报网转载环球网：360 图龙锋破解 OpenAI 自检盲区，最新发现 Codex 6 个高价值安全漏洞，发布于 2026 年 8 月 12 日。本文对“6 个漏洞”、远程任意代码执行、绕过信任提示、不可信目录和已上报监管单位的描述均明确归属于该报道。
- OpenAI 官方：Agent approvals & security。本文关于沙箱与审批两层控制、默认网络关闭和本地工作区限制的说明以该官方文档为依据。
- 截至 2026 年 8 月 17 日，上述转载报道未附 CVE、受影响版本范围、OpenAI 官方确认或修复公告。本文不声称全部 Codex 产品、版本或用户均受影响，也不提供未经官方协调的利用方法。
结语：AI 可以加速安全，但不能取消独立验证
360 图龙锋的公开报道，无论后续漏洞细节如何完善，都提醒了企业一个更长期的问题：AI 编程工具既是生产力工具，也是新的执行主体和攻击面。
把不可信项目放进隔离环境，把密钥移出工作区，把网络和权限按任务开放，再用独立工具、工程师和安全流程验证代码。AI 可以帮助发现问题、生成修复和扩大测试覆盖，但最终上线与风险接受必须有不同证据和明确责任人。
如果你的企业正在引入 Codex、代码智能体或自动化研发流程，可以查看华茂思捷的AI 开发治理、代码审计与系统安全服务，也可以通过联系页面提交当前工具、权限和交付流程，我们会先做只读攻击面盘点，再给出分层控制和验收清单。
