2026 年 9 月 14 日，全国网络安全标准化技术委员会（网安标委）在 2026 年国家网络安全宣传周开幕式上发布 《人工智能安全治理框架3.0》（发布信息见网安标委官网公告，中央网信办官网同日报道论坛情况）。这是继 2024 年 1.0、2025 年 2.0 之后的第三版，相隔约一年。
对已经在跑 Agent 的企业来说，这一版值得逐条读的原因不在编号变大，而在一句话：安全关注点从"模型答得对不对"移到"系统放权之后是否可控、可审计、可中断、可追责"。换句话说，审核对象从内容扩展到了行为——不只看它说了什么，还要看它调了什么接口、写了什么文件、改了什么权限、记住了什么凭证。
阅读本文的两条口径声明：① 凡引自网安标委公告、中央网信办官网报道、央媒报道（人民网、光明日报、央视《新闻1+1》）的内容，属一手可核对口径；② 凡引自技术解读类二手文章（含框架附件编号、企业动作清单的具体归纳）均明确标注为二手转述，建议以网安标委发布的框架原文与附件为准。本文只作落地参考，不构成法律意见，具体以主管部门要求为准。
一、3.0 改了什么：三年三版与两处需要澄清的说法
央媒在报道中给出版本脉络（央视《新闻1+1》2026-09-16，受访专家为中国政法大学人工智能法研究院副教授文禹衡）：
| 版本 | 发布年 | 关注重点（央媒口径） |
|---|---|---|
| 1.0 | 2024 | 内生安全风险 + 应用安全风险 |
| 2.0 | 2025 | 增加衍生风险（就业、伦理等），提出可信人工智能基本原则 |
| 3.0 | 2026-09-14 | 把智能体风险、具身智能风险单独列出 |
一套延续的核心逻辑
三版都沿用同一套逻辑：风险分类 → 技术应对 → 综合治理。网安标委公告的原话是"与时俱进梳理更新了风险分类，优化调整了技术应对和综合治理措施"。这也解释了为什么 3.0 不是纲领性重写，而是把新出现的行为形态补进原有分类框架——企业侧要做的，是把自己的验收项对到新版分类上，而不是等一份新的强制法规。 条款对齐这件事本身适合固化成一次可复跑的对照动作：把框架要点与内部条款列成两栏，用命令行 跑一遍出差异表，企业级环曜 CLI 本地化部署 的客户环境把它并进年度合规检查。
两处二手说法，不要直接引用
技术解读类文章传播时出现了两处放大，写进内部制度会误导，这里逐一澄清：
其一，"3.0 单列了《智能体风险管理框架》"。 网安标委公告与央媒报道均未出现这个独立文件名。二手解读的表述是：智能体相关内容位于框架的专门章节与附件中（其称附件 2 为风险台账）。所以正确的说法是"智能体在框架中有专门安排"，而不是"发布了一份独立制度"。
其二，"交易支付要全量日志与防篡改"。 央媒报道与二手解读均未如此表述。二手解读的实际内容是：高风险操作清单（删除文件、外发数据、改配置、支付、外网访问）一律转人工审批；"防篡改"针对的是运行日志与审计记录这一层。把"支付转人工"写成"支付全量留痕"，会让技术团队按错误的清单去改系统。企业级环曜 Agent 本地化部署 在合规治理 场景里会把框架原文与内部条款逐条对齐，这一步属于交付前的例行动作，而不是上线后补的文档。
二、智能体风险被单列：从内容审核到行为审核
二手技术解读把 3.0 的风险分成内生、应用、衍生三层，其中应用安全风险里的"智能体"一节与企业的距离最近，归纳出的风险条目包括：
| 风险条目 | 通俗描述 | 企业侧的表现 |
|---|---|---|
| 身份仿冒 / 凭证劫持 | 智能体身份被冒充、凭据被偷 | 有人用别人的 Agent 身份调了不该调的接口 |
| 过度授权 | 权限给多了、给久了 | 任务结束后权限没收回，仍可写库 |
| 推理被劫持 | 输入被诱导改变执行路径 | 一段文档里的指令让 Agent 改了执行目标 |
| 工具投毒 / 工具越权 | 工具与插件来源不可信 | 第三方插件窃取数据或越权操作 |
| 记忆被污染或窃取 | 长期记忆被写入或读走 | 密钥、凭证被写进记忆并被后续调用读出 |
（上表为二手解读的归纳，具体条目以框架原文为准。）条目判定所依据的原文与版本要能查得到，这一层通常由企业级环曜知识库本地化部署 承接，把制度文件与框架原文收进统一的文档检索 入口，避免各团队各引一版。
行为审核与内容审核不是一件事
这也是 3.0 给企业带来的真实工作量。把它拆开看：
| 维度 | 内容审核（过去主战场） | 行为审核（新增范围） |
|---|---|---|
| 对象 | 模型输出的文本、图片 | 调用、写入、改权限、存凭证等动作 |
| 典型问题 | 违禁内容、事实错误 | 越权调用、改了不该改的数据 |
| 证据形态 | 输入输出留样 | 调用日志、权限变更记录、凭证台账、审批记录 |
专家在央媒报道里给了一个判断：智能体执行能力提升后，它在虚拟空间的行为已经可以向外溢出、传导到物理社会，因此治理需要在结构上做相应调整。翻译成项目语言就是：只做输出过滤的系统，等于只锁了窗户没锁门。
两份站内既有的相邻做法可以对照。一份讲企业 AI 智能体本地化部署的数字身份与凭据治理，走的是身份标准的落地路径。
另一份是智能体的责任主体与控制力判定，讲的是权限与留痕四问。本文要补的是把它们收进一套验收口径——在私有环境 里交付的项目通常把这条口径前置到立项阶段，企业级环曜 Agent 本地化部署 的验收清单里对应"四可"四栏，而不是等到上线前才补。
三、验收四可：可控·可审计·可中断·可追责
二手解读在结论处把 3.0 的判断标准归纳成四个"可"，这个归纳对企业很好用，可以直接当验收框架（此归纳为二手口径，非官方原文表述）。建议命名并落地为「智能体验收四可」，落地可以按四步走：盘点资产与权限 → 配身份与凭据 → 做日志与留痕 → 设中断与审批，每一步都留产出物，后面才有验收依据：
| 验收维度 | 要落到系统里的东西 | 可核查的验收证据 |
|---|---|---|
| 可控 | 专属身份标识、动态凭证、最小权限、任务结束撤权 | 身份清单 + 权限表 + 撤权记录（每次任务一份） |
| 可审计 | 运行日志留存不少于 6 个月、审计记录防篡改、输入输出留样 | 日志留存策略截图 + 防篡改机制说明 + 抽样留样包 |
| 可中断 | 关键节点人工审批、一键熔断、异常循环自动中止、调用频次上限 | 熔断演练记录 + 审批链配置 + 限流阈值配置 |
| 可追责 | 权限变更与人工审批留档，能定位到"谁在什么依据下放行" | 审批台账 + 变更单 + 定位演练（随机挑一条操作回溯） |
可中断要能真演练
"可中断"要能真演练，前提是拦截与中止动作收在同一层执行。若你们的 Agent 分散在多个业务系统里，建议把调用与中止收到执行网关上，环曜Claw 的任务自动化 能力可以在不改业务系统的前提下做灰度与一键中止，演练时也只需在一处记录结果。
四可里容易做假的一项
"可审计"容易被理解成"有日志"。区别在于日志能不能用于复盘：能不能回答"这次越权是谁在什么依据下放行的"。检验方式很简单——随机挑一条历史操作，要求在不问执行人的前提下还原它的依据链。做不到，说明日志只是存储，不是审计。
这一层的工程化不难，难的是把它写进交付物。企业级环曜 Agent 本地化部署 在私有环境 里交付时，会把交互日志 与审计留痕 连同权限表一起列为验收项，而不是等出问题再补。
四、一份可对照的验收清单
二手解读把框架的技术应对与治理抓手整理成八类企业动作（以下为二手归纳，请以框架原文与附件核对后使用）。我把它翻成逐项可验收的清单：
| # | 企业动作（二手归纳） | 验收时的检查点 |
|---|---|---|
| 1 | 建 AI 资产台账 | 模型来源、开源版本、训练数据、插件与工具、智能体实例、调用接口是否全登记 |
| 2 | 风险分级 | 每个场景是否按"应用重要性 × 自主水平 × 规模"定级，关键业务是否配置强制人工审批与一键熔断 |
| 3 | 最小权限与高风险转人工 | 是否每个智能体一个独立 ID、动态凭证、任务结束撤权；删文件/发数据/改配置/支付/外网访问是否转人工 |
| 4 | 工具与记忆安全 | 插件签名校验、第三方工具定期清退、长期记忆加密隔离、密钥不写记忆 |
| 5 | 内容标识与审计 | AIGC 显式与隐式标识、输入输出留样、运行日志不少于 6 个月、审计防篡改 |
| 6 | 数据合规 | 训练集来源证明、标注复核、个人信息影响评估；合成数据不替代真实合规审查 |
| 7 | 红队与沙箱 | 上线前做注入/越权/后门模拟；新业务先进沙箱再放量 |
| 8 | 下线闭环 | 停进程、收端口、撤第三方授权、取消自动续费、归档必要日志、清理凭证与知识库 |
为什么第 8 项容易漏
第 8 项常被忽略。下线不是关机，它是一次完整的资产清收，缺一项都会留下"幽灵权限"。这与站内最小权限沙箱的 12 项验收清单可以合并使用：一份管"上线时给了什么"，一份管"下线时收回了什么"。清收动作建议脚本化：用命令行 出一次清点表，企业级环曜 CLI 本地化部署 的客户环境把它并进下线流程，避免靠人记。
两条边界，写进制度前先确认
边界一：开源生态与供应链被写进红线。 央媒报道中专家明确提到，3.0 涉及强化开源生态安全与供应链安全管理，特别是针对开源模型的下载使用明确了禁止性行为。对企业意味着：从公开渠道下载权重这件事，不再只是技术选择，而有明确的边界要求。若自持开源权重，权重 与版本台账要一并登记，企业级大模型微调本地化部署 的样本与权重记录可以直接并入这份 AI 资产台账；相关的供应侧风险可参考站内英伟达收购 Hugging Face 后的开源权重供应问题。
边界二：沙箱豁免有条件。 二手解读提到，监管沙箱中"无主观过错且可控、可探索"的情形可获责任豁免，但危害国家安全、人身权益、重大损害的不豁免。这条的实务含义是：沙箱不是免责区，前置条件是你能证明"可控"。
另外要摆正框架的效力：央媒报道中专家指出，框架不是强制性法律，而是指引性文件——对监管是一把尺子，对企业则是"主动做规范性动作能产生更好的信用"。所以正确的用法是把它当验收清单的来源，而不是当合规负担。
五、怎么落到本地化部署
把四可翻成工程动作，落到本地化部署的交付里有四件事：身份与权限收在一处、日志与审批留痕可查、高风险操作有人接、下线有清收清单。这四件事有一个共同前提：运行环境与数据边界可控——这也是为什么数据不出域是合规底线在 3.0 语境下更具体了。对企业级环曜 Agent 本地化部署 的项目来说，这一步对应审计留痕 与权限收口两栏，属于上线前就要配好的部分。
按业务形态分工，落地路径并不相同：涉及越权风险的执行动作（删文件、发数据、改配置）建议由执行网关统一编排，把拦截与留痕收在一层，环曜Claw 在任务自动化 与业务系统集成 场景里的作用正是这一段；权限变更与发布动作则适合与工程流程对齐，把每次改动写成可查记录，放到命令行 与 CI·CD 流程里执行，企业级环曜 CLI 本地化部署 的环境天然支持这一步。
判定依据（制度、口径、审批基准）建议集中收口并可按版本对照，这部分由企业级环曜知识库本地化部署 承接，把文档检索 与知识检索 入口做成权限可控的一处入口，而不是散在共享盘里。
至于两条需要长期维护的台账——权限表与凭证台账——若有垂类模型 参与判定，企业级大模型微调本地化部署 交付的权重 与样本版本也要纳入同一套变更记录，否则换版后无法归因。
一组可核对的验收数据
数据来源与口径：以环曜 2025 年 3 月至 2026 年 8 月完成验收的 41 个本地化部署项目为样本（口径：完成验收；时间窗：2025 年 3 月 1 日至 2026 年 8 月 31 日；样本量：41 个），其中 9 个把"日志留存与防篡改 + 高风险操作转人工"写入验收条款；未写入的 32 个里，有 6 个出现过"越权调用被事后发现、但无法定位到具体是哪一次操作"的情况。差别不在模型能力，而在验收时有没有把这件事写成条款。
结语：把"可"变成条款
3.0 的实操价值，不是多了一份要背的条文，而是给了一份可以直接改写成验收条款的清单：可控、可审计、可中断、可追责。把其中任何一条写进采购与上线验收，都比事后审计便宜。
建议现在做一件事：随机挑一条最近的操作记录，试着在不问执行人的前提下还原它的依据链。如果还原不出来，你的"可审计"就还只是有日志。 你们的 Agent 上线验收里，四可写进了几条？欢迎在评论区说说卡在哪一问。
常见问题 FAQ
Q：Q1 3.0 是强制法规吗，不照做会不会被处罚？
不是强制法律，而是指引性文件（央媒报道中专家口径）：对监管是一把尺子，对企业更多是信用信号——主动做规范性动作能产生更好的信用。但要注意两点：一是其他强制性要求（如数据、个人信息、内容标识类规定）另算；二是把它当验收清单来源比当合规负担更有用。
Q：Q2 "智能体风险被单列"具体指什么？网上流传的两处说法可信吗？
央媒口径是：3.0 把智能体风险、具身智能风险单独列出，背景是模型能力从"回答问题"跃迁到"主动执行任务"；至于具体条目（身份仿冒、凭证劫持、过度授权、工具投毒、记忆污染等）目前多见于二手解读，建议以框架原文与附件为准再写进内部制度。 至于网上流传的两处说法——"单列《智能体风险管理框架》"与"交易支付要全量日志"——建议先别引用：网安标委公告与央媒报道均未出现"单列该独立框架"的表述；"支付"在二手解读里的原文是列入高风险操作清单、转人工审批，"防篡改"针对的是运行日志与审计记录，而不是"支付全量留痕"。写进制度前请核对框架原文。
Q：Q3 日志到底要留多久，怎么算防篡改？
二手解读给出的口径是运行日志留存不少于 6 个月，并要求审计记录防篡改、输入输出留样（以原文为准）。工程上建议同时确认三件事：留存策略是否落到存储层（而不是靠应用层配置）、审计记录是否可被有权限者修改、留样是否能与具体操作一一对应。
Q：Q4 高风险操作"转人工"会不会把效率拖回去？
建议按自主水平分档而不是一刀切：例行、可撤回的操作自动执行；删除文件、外发数据、改配置、支付、外网访问这类列入清单的，一律转人工审批。频次统计下来，这类操作通常占比很低，人工成本可控——这也是自主性分级与熔断那一套分档思路的直接用法。
Q：Q5 我们已经在做内容审核了，还差什么？
差在"行为审核"这一半：内容审核看输出，行为审核看调用、写入、权限变更与凭证存取。补的顺序建议是：先建资产台账与权限表（否则无从审计），再做日志与留痕，随后配熔断与审批链。
Q：Q6 选供应商时怎么确认对方真做了这些？本地化部署有帮助吗？
先要三样可验证材料：① 日志留存与防篡改的机制说明（不是截图，要说明存储与权限设计）；② 熔断与审批链的演练记录；③ 一次随机回溯演练——挑一条历史操作，让对方在不问执行人的前提下还原依据链。第三方研究方面可参考 CNCERT 在宣传周发布的 2026 年人工智能技术赋能网络安全应用测试结果（公开报道口径：8 个测试场景、151 家单位报名，该数据来自媒体与地方网信部门转述，建议核对原始发布稿）。 审批依据（制度文件、阈值与操作清单）建议统一收口，把依据收进一处再授权给审批人使用，避免各团队引用不同版本；企业级环曜知识库本地化部署 的文档检索 入口可以作为审批时的统一出处。 至于落地侧的支持：本地化部署有实质帮助，但不自动达标——数据与运行环境留在自有边界内，权限、日志与凭证更容易收口，也更容易按要求留存 6 个月，但"四可"仍要一项项配出来。我们把这类判定与留痕拆成可交付项，做法收在本地化部署服务页里，可以和你们的验收表逐条对齐；企业级环曜 Agent 本地化部署 在私有环境 内交付时也把权限表、交互日志 与审计留痕 记录一并移交。
