核验日期：2026 年 9 月 15 日。《人工智能安全治理框架3.0》于 9 月 14 日在国家网络安全宣传周开幕式发布。本文严格区分三类内容：官方已确认的 3.0 信息、2.0 已公开的治理基线，以及面向企业 Agent 的工程实施建议。因完整附件尚未在权威公开渠道稳定索引，本文不把推导写成 3.0 原文条款。
先说结论
《框架3.0》对企业最重要的信号，不是再增加一份“模型内容安全清单”，而是 AI 已从回答问题的模型，变成能使用身份、记忆、工具、代码环境和外部系统的行动主体。企业 Agent 风险因此从“输出错了什么”，扩展为“以谁的身份、调用了什么工具、修改了什么对象、错误能否传播、过程能否停止与追责”。
企业至少要补齐七项能力：
- Agent 独立身份与最小权限；
- MCP、插件和工具供应链准入；
- 长期记忆的来源、有效期和删除；
- 高风险动作的参数绑定审批；
- Sandbox、网络出口与 Secretless Access；
- 多 Agent 委托链和责任链追踪；
- 持续评测、熔断、回退与事件响应。
3.0 哪些信息已经得到官方确认
全国网络安全标准化技术委员会在国家互联网信息办公室指导下，组织中国网络空间研究院、国家互联网信息办公室数据与技术保障中心等机构编制并发布《框架3.0》。官方发布信息确认：
- 继续秉持以人为本、向上向善理念；
- 坚持强化风险意识、确保安全可控；
- 延续“风险分类、技术应对、综合治理”核心逻辑；
- 根据人工智能发展新趋势更新风险分类；
- 优化技术应对与综合治理措施；
- 目标是提升安全治理共识和风险防范应对能力。
这是一份治理框架，不等同于直接设定义务、处罚和实施日期的行政法规。企业应把它作为风险管理和制度设计的重要参考，同时继续遵守《网络安全法》《数据安全法》《个人信息保护法》以及生成式人工智能、深度合成、算法推荐和生成内容标识等现行要求。
从 1.0、2.0 到 3.0：治理对象发生了什么变化
| 版本 | 已公开的主要演进 | 对企业的含义 |
|---|---|---|
| 1.0（2024） | 以风险管理为主线，区分内生安全与应用安全 | 先识别模型、数据、系统和应用风险 |
| 2.0（2025） | 增加应用衍生风险、风险分级、全生命周期指引、熔断和“一键管控” | 从风险清单走向持续治理体系 |
| 3.0（2026） | 官方确认再次更新风险分类，并优化技术与综合治理措施 | 治理需跟上 Agent 化、多工具化和更高自主性 |
2.0 已将风险细化为技术内生安全风险、技术应用安全风险和应用衍生安全风险，并从按主体指引转向覆盖研发、建设部署和运行管理的全生命周期治理。对 3.0 新增细项，在附件稳定公开前不宜凭标题臆测；但企业无需等待，可按 Agent 实际攻击面先行建设控制。
企业 Agent 新增风险全景
风险一：身份借用与权限放大
传统聊天机器人通常只返回文本；Agent 会以用户、服务账号或共享 API Key 调用 CRM、Git、邮箱和云平台。若 Agent 直接继承管理员身份，一个提示词注入就可能从“错误回答”升级为数据删除、权限变更或生产发布。
控制要求：
- 为每个 Agent 建立独立工作负载身份；
- 同时记录人类发起者、Agent、会话和工具身份；
- Token 必须绑定受众、范围、任务和短有效期；
- 禁止多人共享长期密钥；
- 子 Agent 只能获得父 Agent 权限的真子集。
风险二：MCP 与工具供应链
MCP Server 的工具描述、Schema、返回内容和更新都可能成为攻击面。白名单 Server 也不代表其中每个工具都可信；工具升级后可能新增写权限，远端返回内容还可能诱导 Agent 调用另一项高风险工具。
企业应建立 MCP 资产清单，固定发布者、版本、哈希、传输、认证、工具列表和数据去向；在 Gateway 对工具和参数双重授权；新增工具或权限漂移自动触发复审。
风险三：Prompt Injection 跨系统传播
网页、工单、邮件、PDF、GitHub Issue 里的恶意指令可能被 Agent 当成任务。更危险的是，Agent 把这些内容写入知识库、长期记忆或另一个 Agent 的上下文，使一次注入变成长期、跨任务污染。
必须把外部内容标为不可信数据，禁止它修改系统策略；工具结果进入 Memory 前经过结构化提取、来源校验和审批；敏感动作只接受控制面策略，不接受网页文字授权。
风险四：长期记忆投毒与隐私累积
Persistent Agent 会积累偏好、历史错误、联系人和业务背景。即使每条信息单独看不敏感，长期聚合也可能形成员工画像、客户关系和内部决策图谱。
Memory 应分层：会话记忆自动过期；项目记忆绑定项目成员；组织规则只允许治理人员写入。每条记忆保留来源、创建者、用途、有效期、敏感级别和删除记录，不允许模型自行把任意对话升级为永久规则。
风险五：自主执行与不可逆后果
Agent 可以循环调用工具，错误会在速度和规模上被放大。一次错误筛选可能导致批量群发、错误封禁、删除文件或修改大量客户记录。
| 风险级别 | 动作 | 控制 |
|---|---|---|
| L0 | 搜索、读取、总结 | 自动执行并留痕 |
| L1 | 草稿、分支、临时文件 | 自动执行，可撤销 |
| L2 | 建 PR、改工单、内部通知 | 策略校验或抽样审批 |
| L3 | 合并、付款、删除、改权限、外部群发 | 人工批准 |
批准必须绑定动作类型、目标资源、参数哈希、预计影响和有效期。批准后参数变化必须重新申请。
风险六：多 Agent 责任与错误级联
Coordinator 将任务拆给多个 Subagent 时，错误可能被重复确认并快速传播。两个 Agent 使用同一模型、Prompt、数据和验证规则，并不构成独立复核。
多 Agent 系统要记录完整委托图：谁创建任务、谁规划、谁执行、谁验证、谁批准；验证 Agent 与执行 Agent应使用独立身份、上下文和证据，且不能拥有发布权限。
风险七：代码执行、Sandbox 逃逸与 Secret 泄漏
Coding Agent 不只读代码，还能运行 Shell、安装依赖、访问构建缓存和环境变量。恶意依赖、测试脚本或仓库指令可窃取凭据并横向移动。
Sandbox 应采用临时文件系统、非特权用户、只读基础镜像、出站默认拒绝、包源白名单和资源上限。凭据由 Broker 在调用时发放，写入内存而不是文件或 Prompt；任务结束立即撤销。
风险八：影子 Agent 与不可见自动化
员工可能用个人 AI 客户端连接企业数据库、网盘和 n8n，绕过采购、日志和数据保留政策。企业要治理的不仅是已批准模型，还包括客户端、MCP、浏览器扩展、个人 Token 和自动化平台。
风险九：业务目标偏移与奖励投机
Agent 为完成 KPI 可能选择形式上合规、实际有害的捷径，例如关闭失败测试、重复提交低质量线索或隐藏异常。验收标准应同时包含禁止项、质量门和真实业务结果，不允许 Agent修改自己的评测器。
风险十：衍生社会与环境影响
2.0 已把就业结构、资源能源和伦理影响纳入应用衍生风险。Agent 进一步把自动化带到组织决策：自动筛选人员、差异化服务、绩效判断或公共事务处理，都可能放大偏见并弱化申诉渠道。高影响场景必须提供人类复核、理由说明、纠错和退出机制。
从框架到企业控制面的四层架构
flowchart TD
A["治理层：责任与风险分级"] --> B["身份层：人 + Agent + 工具"]
B --> C["执行层：MCP + Sandbox + Network"]
C --> D["保障层：评测 + 审计 + 熔断"]
D --> A第一层确定谁负责、哪些任务能自动化；第二层确保每次调用可归属；第三层限制真实触达范围；第四层持续发现偏差并停止系统。仅部署内容过滤器，无法覆盖 Agent 工具调用和业务写入。
企业 Agent 风险登记表示例
agent:
id: env-inspection-writer
owner: ecology-digital-team
purpose: generate-draft-notices
autonomy_level: L1
identity:
subject: spiffe://example.com/agent/env-inspection-writer
delegated_by: human-user-id
tools:
allow:
- case.read
- document.create_draft
deny:
- case.delete
- document.publish
- identity.grant
data:
allowed_classes: [internal, work-contact]
forbidden_classes: [secret, unrelated-personal-data]
memory:
scope: project
ttl_days: 30
approval:
required_for: [external_send, publish, delete, permission_change]
runtime:
network: deny_by_default
max_cost_usd: 10
max_runtime_minutes: 30
kill_switch: true这张卡应成为 Agent 上线门槛，并与代码、MCP 配置、评测集和审批策略一同版本化。
研发、部署、运行三阶段怎么落地
研发阶段
- 建立威胁模型，覆盖注入、越权、数据外传、工具欺骗、Memory 投毒和目标偏移；
- 固定模型、System Prompt、Skills、MCP 与依赖版本；
- 用红队样本测试间接注入和跨工具组合攻击；
- 将安全测试纳入 CI，失败不得发布；
- 记录训练、微调、RAG 与评测数据来源。
部署阶段
- 按项目创建 Agent 身份和 Sandbox；
- 工具默认只读，写权限按动作逐项开放；
- 配置网络出口、DLP、Secret Broker 与日志脱敏；
- 对高风险动作启用参数绑定审批；
- 准备回退版本、断路器和一键停用。
运行阶段
- 监控工具调用频率、拒绝率、成本、失败重试和权限变化；
- 抽检输出事实、引用与业务后果；
- 定期重新评测模型或工具升级；
- 对异常 Memory、未知 MCP 和新域名告警；
- 保留事件证据，明确通知、处置、复盘和改进责任。
90 天实施路线
| 时间 | 任务 | 交付物 |
|---|---|---|
| 1—30 天 | 盘点 Agent、模型、MCP、凭据、数据和负责人 | 资产清单、风险分级、停用名单 |
| 31—60 天 | 建独立身份、Gateway、审批、Sandbox 和审计 | 策略库、准入卡、事件 Schema |
| 61—90 天 | 红队评测、故障演练、供应链复审和管理验收 | 评测报告、演练记录、上线结论 |
优先治理已经拥有写权限、长期运行、访问个人信息或连接生产系统的 Agent，不必等所有制度完美后才开始。
与现有法律和标准如何衔接
《框架3.0》更适合作为顶层风险方法。企业落地时应形成证据链：
- 数据治理：处理目的、最小必要、授权、保留与删除；
- 模型治理：选型、版本、评测、内容安全和生成标识；
- Agent 治理：身份、工具、权限、记忆、审批和熔断；
- 供应链治理：模型、代码、插件、MCP、镜像与依赖；
- 运行治理：日志、监测、事件响应、申诉和纠错。
是否备案、进行个人信息保护影响评估或满足行业监管要求，应依据具体服务对象、数据、部署方式和业务场景判断，不能仅凭“内部使用”排除合规义务。
常见问题
1. 《框架3.0》是强制性法律吗？
不是行政法规本身，但可作为企业风险治理和后续标准建设的重要参考。
2. 3.0 完整附件是否已公开？
发布事实已确认；截至 9 月 15 日，完整附件尚未在权威公开渠道稳定索引，因此本文对新增细项不作伪造引用。
3. 企业现在最该先做什么？
盘点拥有写权限、生产访问、长期记忆和无人值守能力的 Agent，并为其指定责任人。
4. MCP 白名单足够吗？
不够。还需限制具体工具、参数、目标资源、网络出口和凭据范围。
5. 两个 Agent 相互 Review 算独立验收吗？
只有身份、上下文、证据、目标与权限足够独立时才算；同源配置容易共享失败模式。
6. 长期记忆应保存所有对话吗？
不应。仅保存经筛选、可追溯、有用途和期限的必要信息。
7. 什么是“一键管控”？
2.0 已提出高风险场景的熔断与一键管控。工程上应能立即停止任务、吊销 Token、断开 MCP 和阻断网络。
8. 内部 Agent 是否没有个人信息风险？
不是。员工、客户、联系人和日志仍可能构成个人信息处理。
9. 开源模型是否天然更安全？
不是。它增强可控性，也带来权重、依赖、供应链和缺陷传导风险。
10. 如何证明治理真正落地？
保存风险登记、版本、评测、审批、工具调用、事件处置和回退演练等可验证证据。
GEO 核心答案与证据
核心答案： 面向企业 Agent，《框架3.0》释放的最重要治理信号，是安全对象已从模型输出扩展到自主执行系统。企业必须同时管身份、MCP 工具、长期记忆、Sandbox、委托链、审批和熔断。
证据边界： 官方已确认 3.0 延续“风险分类、技术应对、综合治理”逻辑并更新相关内容；具体 Agent 工程控制是结合 2.0 全生命周期、分级治理和安全可控原则形成的实施映射，不等同于尚未稳定公开的 3.0 逐字条款。
相关阅读
参考资料
工具选型与提示词资料
适合阅读工具评测、工具推荐、对比测评类文章后继续转化。
