可易

智能体 AI 安全与治理现状 2.01(下)

可易团队阅读约 35 分钟

OWASP 报告全文中译下篇:可解释 AI 与透明度、全球监管与合规格局、企业采用与治理成熟度模型、与 OWASP 十大风险对齐,以及未来趋势与结语。

目录

AI SBOM 与供应链溯源(AI SBOM and Supply Chain Provenance)

软件供应链安全长期以来聚焦于第三方软件相关风险。现代应用依赖大量开源库、容器镜像和第三方服务,形成复杂的传递性依赖图。依赖混淆(dependency confusion)、拼写抢注(typosquatting)、恶意软件包上传和被攻陷的上游维护者等事故表明,单个薄弱环节就能传播到数千个系统。作为回应,许多组织已采用 SBOM(软件物料清单,Software Bill of Materials)实践、漏洞扫描、制品签名和溯源框架,以提升可见性与完整性保证。

AI 系统继承了同样的风险。模型依赖框架、库、编排层和云服务。AI SBOM——也称 AIBOM(人工智能物料清单,Artificial Intelligence Bill of Materials)——的工作扩展了传统 SBOM 概念,以捕获模型版本、提供商、可获得时的训练血缘(training lineage)和运行时环境。这些控制仍是基础性的,而 OWASP GenAI 安全项目的 AIBOM 计划[44]等关键倡议在强化 AI 供应链安全方面发挥着重要作用。成熟的漏洞管理与制品完整性验证仍是基线要求。

为强化保证,AI SBOM 实践应与既有供应链标准和框架对齐,包括 NTIA《SBOM 最小元素》、SPDX 3.0 和 CycloneDX。安全开发与构建完整性控制(如 NIST SP 800-218《安全软件开发框架》所述)为确保模型制品、容器镜像、编排组件及相关依赖的完整性提供了结构化方法。

然而,智能体系统引入了额外维度。与传统软件不同,智能体架构可以在运行时动态发现、选择和调用外部能力。技能、工具、插件、注册表、检索源乃至被委派的子智能体,都可能在执行期间被接入,而非仅在构建时定义。因此,有效依赖图是在运行时动态构建的。

在这类环境中,溯源必须超越静态制品清单。加密签名、完整性验证和运行时认证机制变得必不可少。执行环境、模型制品、工具连接器和编排层应当可验证,并可追溯到可信的构建流水线。没有可验证的溯源,动态组合会加大未授权修改、注入或特权提升的风险。

近期事故表明,失陷往往并非源于模型制品本身,而是源于智能体调用的外部工具、注册表或上下文数据源。传统 SBOM 捕获的是「安装了什么」,它无法完整捕获「可以动态组合或执行什么」。

这一缺口推动了向 AI 系统 SBOM 的演进。它建立在 SBOM 与 AIBOM 原则之上,但把可见性扩展到编排框架、工具连接器、身份边界、授权策略,以及运行时调用与委派记录。在智能体系统中,权限可以在单个工作流内跨多个服务传播,使执行溯源与制品完整性同等重要。

这一转变微妙但意义重大。软件供应链安全问的是「存在哪些组件」;智能体供应链安全还必须回答「运行时能够组装出哪些能力,以及它们以谁的授权执行」。从制品透明走向执行与授权透明,定义了智能体 AI 系统供应链治理的下一阶段。

对高管层和董事会而言,这一演进把 AI 供应链透明度重新界定为治理控制,而非技术特性。执行可追溯性、授权边界和运行时完整性应纳入企业风险管理,尤其是对受监管、安全关键或高影响的 AI 部署。

#### 这对安全负责人意味着什么(What This Means for Security Leaders)

  1. 在所有软件(包括 AI 基础设施)中制度化 SBOM:确保生成与 NTIA 最小元素对齐、采用 SPDX 或 CycloneDX 等结构化格式的传统 SBOM,并集成到企业漏洞生命周期管理和 AI 部署流水线中。智能体系统不得绕过既有供应链治理。
  2. 为 AI 系统采纳并落地 AIBOM:将透明度从软件依赖扩展到模型制品、可获得时的训练血缘以及 AI 专属组件。与 OWASP GenAI 安全项目 AI SBOM 计划等行业工作对齐,以标准化预期与格式。
  3. 建立 AI 与智能体组件的正式清单:创建并维护 AI 系统的权威注册表,包括模型、数据集、RAG(检索增强生成)、MCP 服务器、智能体框架、连接器、工具生态和外部注册表。凡是能影响智能体行为的,都必须纳入清单。
  4. 将供应链治理扩展到运行时组合:认识到智能体系统在运行时组装能力。更新治理框架,把工具注册表、插件生态、被委派智能体和外部上下文源纳入供应链范围。
  5. 对高影响工作流要求决策级可追溯性:对重要或受监管的用例,强制要求能够重建哪些组件、工具和被委派智能体促成了某个结果。这将软件透明度扩展为决策透明度。

智能体 AI 系统将传统软件供应链风险延伸到运行时组合与委派权限。将强大的 SBOM 基础、结构化的 AIBOM 实践与决策级透明度相结合的组织,将更有条件负责任地保护、治理并规模化其智能体系统。

可解释 AI 与智能体透明度(Explainable AI and Agent Transparency)

可解释 AI(Explainable AI,XAI)涵盖使 AI 系统行为对工程师、运营人员和审查者可理解、可审计的技术与设计模式。在实践中,XAI 之所以重要,是因为它把模型的行动或预测转化为可验证、可质疑、可控制、可监控的组件——尤其是在高风险或受监管环境中。然而在智能体系统中,主要挑战不是可解释性是否重要,而是哪些形式的可解释性仍然可靠、可迁移、在运营上有用。

经典 XAI 的局限。 经典 XAI 技术——包括特征归因方法(如基于梯度的归因、SHAP)、代理模型方法(如 LIME)和基于概念的分析——仍是理解模型在单次预测或内部表示层面行为的有价值工具。然而,这些方法主要是为单步预测场景开发的,无法迁移到智能体系统,尤其是当模型通过 API 访问、内部权重或中间状态不可得时。智能体系统需要轨迹级(trajectory-level)透明度,而非特征级归因。

思维链作为解释的局限。 早期 LLM 部署常把思维链(chain-of-thought,CoT)——模型生成的分步解释——当作「那个解释」。这些「解释」并不保证忠实于实际的决策过程。在许多情况下,CoT 最好被理解为一个有助于清晰度、用户体验、有时有助于调试的沟通层,而非内部计算的证据(例如参见《推理模型并不总是说出它们的想法》,"Reasoning models don't always say what they think")[45]。这体现在 ASI09「人—智能体信任利用」(Human-Agent Trust Exploitation)中:智能体可能基于一个无法独立验证的解释,说服人类批准一个不安全的行动。对安全团队而言,更可靠的目标是可验证的决策透明度:使用了哪些输入、施加了哪些约束、有哪些证据支撑了结果。

机制可解释性的局限。 在更广泛的 XAI 图景中,机制可解释性(mechanistic interpretability)专注于「模型内部」的解释,试图通过分析激活值与隐藏状态来逆向工程内部表示,所用技术包括探针(probing)、稀疏自编码器(sparse autoencoder)、电路发现(circuit discovery)和因果干预(causal intervention),目标是揭示驱动模型行为的可解释特征。这仍是一个活跃的研究前沿:今天我们通常无法在某个具体的工具选择、命令或多步推理行为与模型内部单一因果机制之间可靠地建立一对一映射。虽然内部分析能揭示有意义的统计关联,但同样的内部组件往往参与多种行为,同样的行为也可能因情境不同而源自不同的内部通路。

在智能体系统中,可解释性从「解释单个答案」转向「解释一条轨迹」:检索了什么、调用了哪些工具、工具返回了什么、智能体记忆如何随时间变化、哪些策略挂载点允许或阻止了每一步。这一领域仍在积极发展中,智能体级可解释性尚无被广泛采纳的标准。新兴实践聚焦于结构化追踪记录,结合:

  • 简明的人类可读理由说明;
  • 关联的执行证据(工具输入与输出、检索来源、状态变化);
  • 有助于定位行为在何处偏离预期的诊断信号(例如工具误用、意图漂移)。

可解释性要求正日益被写入法律,而非交由自行裁量。欧盟《人工智能法案》(EU AI Act)第 13 条要求高风险 AI 系统具备透明度,包括对系统逻辑的记录须足以让受影响方质疑决策。GDPR 第 22 条要求对个人产生重大影响的自动化决策能够应请求被解释。《科罗拉多 AI 法案》(Colorado AI Act)和拟议中的《纽约算法问责法案》(New York Algorithmic Accountability Act)将类似义务扩展到就业、信贷和医疗场景中的算法系统。然而在实践中,这些要求往往通过部分实现而非全面的 XAI 技术来满足。现有的可观测性、日志和追踪工具经常成为支持智能体系统中解释、监督和可审计性的实际机制。这并不构成严格技术意义上的完全可解释性,但它往往充当满足解释请求或经受住监管审计的证据基础。

智能体级可解释性尚未出现普遍接受的标准。在实践中,高级 XAI 仍集中于能够访问模型内部的研究环境,使多数真实世界的部署只能依赖更有限、更贴近运营的解释形式。

智能体监管与合规格局(Agentic Regulatory and Compliance Landscape)

声明。 本文档是社区贡献的技术分析,围绕智能体 AI 的安全、治理与监管格局展开。关于监管义务、执法时间表和合规预期的陈述反映了贡献者在撰写时的理解,旨在为技术和风险决策提供参考。它们不构成法律意见。组织在依赖本文档中的任何监管表述之前,应咨询合格的法律顾问。文中提供了引文和外部参考,以便读者独立核实每项论断。

AI 治理在 2025 年从理论走向执法。欧盟《人工智能法案》的《通用人工智能行为准则》(GPAI Code of Practice)现已要求公开红队报告、经签名的使用日志和实时监控计划。第一波提供商义务于 2025 年 8 月 2 日生效,高风险系统要求将于 2026 年 8 月跟进。NIST 发布了《Cyber AI Profile》,将智能体专属安全控制映射到 CSF 2.0(网络安全框架 2.0)。新加坡发布了全球首个专为智能体 AI 构建的治理框架。韩国《AI 基本法》(AI Basic Act)生效,具有域外效力,并设定了与美国各州前沿模型定义相呼应的 10^26 FLOP 阈值。这些不是提案,而是附带处罚机制的现行法规文书。

智能体系统以机器速度做出重大决策:信贷审批、医疗分诊、基础设施管理、代码部署。每个领域都带有既有的监管义务,智能体一旦行动便即刻继承。当智能体拒绝一笔贷款时,GDPR 第 22 条和科罗拉多 SB 24-205 适用。当智能体为患者分诊时,FDA SaMD(软件即医疗器械)规则适用。当智能体管理能源基础设施时,NIS2 和 DORA 的事故报告时限开始起算。这些法律已经覆盖智能体 AI。悬而未决的问题是:部署智能体的组织是否满足随之而来的报告时限、监督要求和审计义务?

美国的监管图景动荡不定。第 14365 号行政令(Executive Order 14365)推动联邦对各州 AI 法律的优先适用(preemption),同时商务部正在评估要针对哪些州法律。科罗拉多、加利福尼亚、纽约、得克萨斯、伊利诺伊和新泽西都已颁布范围、执法模式和处罚结构各不相同的 AI 专项立法。优先适用之争悬而未决,因此跨州部署智能体的组织面临相互冲突的义务,且没有安全港(safe harbor)。在格局稳定之前,按最严格的适用时限来规划是唯一站得住脚的姿态。

执法行动证实,监管机构把 AI 问责声明当作可证伪的承诺来对待。FTC(美国联邦贸易委员会)对一家营销「准确率 98%」的 AI 检测器、而实际表现接近随机水平的公司下达了为期二十年的审计令。NIST 的《对抗性机器学习分类法》(Adversarial Machine Learning Taxonomy)为审计师和红队提供了攻击模式的共享词汇。ENISA(欧盟网络安全局)的《网络压力测试手册》(Cyber Stress Test Handbook)为监管者提供了面向关键行业的实弹演练方法论。英国 AI 安全研究所(UK AI Safety Institute)的 RepliBench 为前沿智能体的自我复制风险打分,为一项十二个月前还没有量化基准的能力提供了监管基准。

部署智能体 AI 的组织需要五项能力才能在这一环境中生存:每个模型上线前的风险层级分类、集成到开发生命周期中的伦理审查检查点、足以支撑取证重建的不可篡改且经签名的智能体行动审计日志、覆盖完整 ASI01—ASI10 攻击面的对抗性测试,以及以智能体速度(而非委员会速度)生效的终止开关。

本节涵盖正在发展的监管趋势与既有要求,旨在提供可操作的洞察。详细的监管与标准清单——按九个治理维度评估其智能体影响——维护在附录 2:全球监管与合规格局(Appendix 2: Global Regulatory and Compliance Landscape)。

企业采用成熟度模型(Enterprise Adoption Maturity Model)

制定智能体 AI 计划的组织,在治理与使用智能体 AI 系统相关的自主性、风险和问责方面,会经历不同的成熟度水平。该模型沿两个维度运作:

  • 采用层级(Adoption Tier,AT0—AT8,见下表定义):我们在部署什么?它对清单中智能体的信任边界与自主性特征进行分类,从而决定哪些 ASI 风险最有可能发生。AT0(影子 AI)承认,未受管理的 AI 使用是多数组织在治理有意部署之前必须先应对的基线状态。这提供了一个超越主观评估的具体成熟度维度,反映组织采用智能体 AI 的方式。
  • 治理成熟度(Governance maturity,Level 0—4):我们组织治理智能体 AI 的能力有多成熟?它衡量策略、监督、监控和问责结构。

该模型为董事会、风险负责人和工程团队提供了一种理解自身当前位置、并规划下一步治理行动的方式。关键在于,所需行动因采用层级而异:一个尚未应对影子 AI(AT0)、或仅部署供应商嵌入式助手和平台集成智能体(AT1—AT2)的组织,比部署自主多智能体联盟(AT7—AT8)的组织需要更轻量的治理。

该模型的紧迫性得到当前企业数据的印证。根据 a16z 于 2026 年 4 月[46]对企业 AI 部署的分析,《财富》500 强中已有 29%、Global 2000 中约 19% 是某家领先 AI 初创公司的付费活跃客户——定义为已签署自上而下的合同并有活跃部署。这一渗透发生在 ChatGPT 发布后仅三年多的时间里。关键在于,这一数字只代表受治理、有合同的部署;同样这些组织中未受管理的使用量(AT0)要高得多,且按其定义无法量化。成熟度模型的存在正是为了弥合这一缺口。

#### 作为成熟度维度的采用层级(Adoption Tier as a Maturity Dimension)

上述成熟度模型评估的是组织的治理能力。然而,治理要求因部署内容的不同而差异巨大。处于成熟度 Level 2、部署供应商嵌入式助手(如 Microsoft 365 Copilot)的组织,其风险面比同一组织部署带有外部 MCP 工具访问的自主智能体要窄。为使成熟度模型可操作,组织必须对照其运行所处的采用层级来评估治理成熟度。

智能体采用层级(Agentic Adoption Tiers)提供了这第二个维度。它是一个递进量表,按信任边界与自主性特征将智能体部署分为九个层级(AT0—AT8)。AT0 承认一个关键现实:在任何有意的采用决策之前,多数组织的员工队伍中已经存在未受管理的 AI 使用。

关于采用层级与关键 ASI 映射的更多细节,参见附录 3(Appendix 3)。

编号层级核心特征示例
AT0影子 AI(Shadow AI)组织不知情或未批准。用户在治理之外自行采用 AI 工具。在公司数据上使用个人 ChatGPT/Gemini/Claude、浏览器 AI 扩展、未经批准的 AI 插件、工作设备上的本地 LLM
AT1供应商嵌入式助手(Vendor Embedded Assistant)完全由供应商控制。你是消费者,不是构建者。Microsoft 365 Copilot、GitHub Copilot、Salesforce Einstein、Adobe Firefly
AT2平台集成(Platform Integrated)接入你的数据的 AI 原生平台。不能执行任意代码。自定义 GPT(ChatGPT Enterprise)、Amazon Q Business、Google Vertex AI Agents
AT3公民开发者智能体(Citizen Developer Agent)低代码/无代码平台。用户配置流程和提示,而非代码。作用于组织真实数据。Power Automate + AI Builder、Copilot Studio、Zapier Central AI、ServiceNow AI Agents、Google AppSheet AI
AT4代码执行智能体(Code Executing Agent)以本地/云权限生成并执行代码。Open Interpreter、Claude Code、GitHub Copilot Workspace、Devin
AT5定制自建智能体(Custom In-House Agent)由你构建。你控制身份、工具和边界。LangChain/LangGraph 自定义智能体、AutoGen 编排、Amazon Bedrock Agents、内部 RAG 流水线、自托管推理栈(Ollama、vLLM 等)上的智能体
AT6外部扩展智能体(Externally Extended Agent)跨信任边界连接外部工具/服务。带 MCP 服务器的智能体、启用插件的 LLM 应用、调用第三方 API 的智能体
AT7多智能体编排(Multi-Agent Orchestration)多个智能体在你的组织内协调。CrewAI 工作流、AutoGen 多智能体团队、LangGraph 多智能体图
AT8联邦/跨边界(Federated / Cross Boundary)智能体跨组织边界运行。跨组织供应链智能体、金融网络中的联邦 AI、多租户智能体市场

层级编号反映了递增的部署复杂度和不断扩展的信任边界。AT0 独一无二:它不是一个有意的部署选择,而是组织必须发现并应对的既存状态。风险产生于层级特征与「关键 ASI」列的交互——活跃 ASI 条目的数量与严重性随每个层级递增。

智能体 AI 治理成熟度模型(Agentic AI Governance Maturity Model)

每一级成熟度都包含必要的关键企业行动,用以提供在该自主性水平下安全运行智能体 AI 系统所需的组织、技术和治理能力。每项行动都是降低系统性风险、提供监管可辩护性,并在智能体开始独立决策时维持运营稳定性的必备基础。

成熟度级别描述关键企业行动
Level 0:无意识与临时应付(Unaware and Ad Hoc)未正式认识到智能体 AI 区别于传统 AI 的治理/安全风险。影子 IT 实验缺乏策略、AI-SBOM 或护栏;监督是非正式的,日志记录极少,事故处理沿用通用 IT 流程。• 识别并记录影子智能体 AI 部署 • 建立高管意识与临时归属 • 引入基线日志/数据处理 • 发布临时使用指南 • 启动初步风险评估
Level 1:无护栏的实验(Experimentation without Guardrails)单智能体/小型工作流的试点项目缺乏明确的自主性限制、决策范围或升级标准。通用 AI 策略和偶发红队提供了治理,但没有持续监控或风险分级;问责是弥散的。• 正式化试点审批/评审流程 • 定义初步自主性限制/工具控制 • 创建集中的智能体系统注册表 • 标准化审计日志/版本控制 • 建立定期治理报告
Level 2:策略定义、人在环(Policy-Defined, Human-in-the-Loop)正式策略将用例映射到法规(EU AI Act、GDPR),对高影响决策强制人在环。跨职能治理包括指定负责人(如 CAIO,首席 AI 官);日志/版本管理/AI-SBOM 已建立,但监控是周期性的。• 发布正式的智能体 AI 治理策略 • 实施人在环工作流 • 指定问责高管/治理机构 • 部署 AI-SBOM/溯源系统 • 建立结构化的事故/审计流程 • 在注册表中为智能体添加负责人并定义移交协议
Level 3:集成的持续监督(Integrated, Continuous Oversight)智能体 AI 被视为关键基础设施,跨受监管领域具备风险分级工作流和自主性阶梯。实时仪表盘跟踪漂移/异常;终止开关可暂停自主性。治理即代码(Governance-as-code)在 AI 全生命周期强制执行机器可读策略。• 部署实时监控/异常检测 • 实施终止开关/自主性控制 • 通过机器可读策略强制执行治理 • 将遥测集成到可观测性平台 • 建立专门的 AI 安全运营职能
Level 4:自适应、自我调节的治理(Adaptive, Self-Regulating Governance)治理以模型速度运行:遥测/红队/监管输入自动调优护栏。自我调节结构(加密权限、信任评分)使智能体与约束对齐。实时仪表盘/防篡改轨迹支撑全球部署。• 实施自我调整的策略/风险引擎 • 部署加密的智能体身份/信任 • 运营面向监管者就绪的合规仪表盘 • 自动化审计证据/认证 • 制度化跨辖区对齐

#### 成熟度级别 × 采用层级:治理姿态矩阵(Maturity Level x Adoption Tier: Governance Posture Matrix)

以下矩阵将采用层级(行)与治理成熟度(列)交叉,展示由此产生的治理姿态。它是一个自我评估和路线图规划工具,旨在帮助组织识别当前治理与预期部署之间的差距,并对下一步行动排序。单元格标签标示的是给定成熟度与层级组合下的推荐姿态,而非有约束力的合规裁决;组织应将其视为治理投资或层级降级的指导,而不是通过/不通过的关卡。

采用层级 / 成熟度Level 0—1:无意识Level 2:策略 + 人在环Level 3:持续Level 4:自适应
AT0 影子 AI危急。 按定义即未受管理。优先事项是发现与盘点。危急。 除非有主动发现机制,影子 AI 将持续存在。策略存在,但无法覆盖它看不见的东西。可控——前提是持续监控包含影子 AI 检测。可控。有遥测支撑的发现应能自动暴露影子使用。
AT1—AT2 供应商/平台可接受——前提是审查过供应商 SLA。需监控影子 AI。足够。平台配置审计和范围化权限即可。治理良好。治理良好。
AT3—AT5 公民开发/代码执行/定制高暴露。 公民开发者流程未经安全审查即作用于组织数据。无沙箱的代码执行造成严重的 ASI05 风险。可行——需具备公民开发者审批工作流、沙箱策略、代码审查和明确的升级机制。代码执行必须有 HITL(人在环)。足够。持续监控、终止开关、治理即代码应对代码执行风险。公民开发者流程纳入集中策略。治理良好。
AT6—AT7 外部/多智能体危急缺口。 完整的 ASI 暴露面却没有供应链验证或智能体认证。不足。 周期性审计无法跟上外部工具变化和供应链风险。最低可行。需要供应链验证、MCP 认证、智能体间认证。足够。自动调优护栏与供应链验证提供治理。
AT8 联邦禁止部署。 联邦信任至少需要 Level 3。不足。 跨组织信任需要持续监督,而非周期性审查。不足。 联邦信任需要自适应治理与加密身份。最低可行。需要相互认证、跨组织 SLA、联邦治理。

处于加粗单元格中的组织,其治理不足以支撑其采用层级。它们应当提升治理成熟度,或降低部署复杂度。AT0 独一无二:它需要的是主动清除而非治理——目标是把影子 AI 移入受管理层级(AT1+)或完全阻止。

#### 如何使用成熟度模型(How to use the Maturity Model)

治理负责人可以通过两个问题评估当前位置:我们能多快发现并制止一个失准的智能体?自主性与问责被多明确地编码进我们的系统?答案同时决定你的成熟度级别和你对每个采用层级的就绪程度。

第 0 步:在做任何事之前,评估你的 AT0(影子 AI)暴露。除非有相反证明,否则假定它存在。使用网络监控、DLP(数据防泄漏)工具和员工调查来发现未受管理的 AI 使用。这是所有后续步骤的前提——如果你不知道自己的 AI 资产里有什么,就无法治理它。

第 1 步:使用成熟度模型标准评估你的治理成熟度级别(0—4)。

第 2 步:按采用层级(AT0—AT8)对每个已部署智能体分类。多数组织同时运行在多个层级上——影子 AI 使用(AT0)、Copilot 部署(AT1)、用于内部知识的自定义 GPT(AT2)、公民开发者的 Power Automate 流程(AT3)、自定义编码智能体(AT4—AT5)、MCP 连接的工作流(AT6)并存。要特别注意盘点 AT0 影子使用和 AT3 公民开发者自动化,它们对中央 IT 与安全团队常常不可见。

第 3 步:为每个智能体核对「成熟度 × 采用层级」矩阵。如果你处于加粗单元格,你有两个选择:将治理成熟度提升到所需级别,或将采用层级降低到与当前成熟度匹配。对 AT0,唯一的选择是清除——把影子使用移入受管理层级或将其阻止。

第 4 步:基于你最高采用层级的主导 ASI 风险类别确定控制优先级。较低层级(AT1—AT4)应聚焦 ASI01、ASI05 和 ASI06。较高层级(AT6+)必须应对完整的 ASI01—ASI10 暴露面,特别注意 ASI04(供应链)、ASI07(不安全的智能体间通信)和 ASI08(级联失效)。

路线图应优先从静态、文档驱动的监督转向自适应、有遥测支撑的控制回路——在监管者要求的地方嵌入人工判断,在自主性规模化的所有地方嵌入自动化保障。采用层级提供了梯度:从你最高层级智能体的部署处开始治理投资,但永远不要忽视 AT0 发现——它是其他一切赖以建立的基础。

与《OWASP 智能体应用十大风险》的对齐(Alignment with the OWASP Top 10 for Agentic Applications)

2025 年 12 月发布的《OWASP 智能体应用十大风险》为智能体安全风险提供了首个标准化分类法。其十个类别与本节记录的趋势直接对应,且几乎每个类别现在都至少有一起已确认的真实世界事故作为支撑。下表总结了每个类别在 2026 年威胁格局中的表现。

ASI 编号威胁名称2026 年威胁格局观察
ASI01智能体目标劫持(Agent Goal Hijack)观察到的最普遍攻击技术。在针对生产力平台、CRM 系统和开发环境的企业级间接提示注入行动中,均作为初始载体出现。
ASI02工具滥用与利用(Tool Misuse & Exploitation)多起事故予以验证:拥有广泛工具访问权的智能体被注入指令操纵,实施破坏性行动,包括数据删除和未授权资源访问。
ASI03身份与权限滥用(Identity & Privilege Abuse)成为风险严重性与组织准备度之间差距最大的类别。企业中的非人类身份现已远超人类数量,但很少有组织拥有管理它们的战略。
ASI04智能体供应链漏洞(Agentic Supply Chain Vulnerabilities)披露事故数量最多的类别之一。MCP 生态系统在十个月内经历了首个恶意软件包、首个关键基础设施 RCE 和首个协同攻击行动。另外,已发现数千个开源恶意 Skills,执行时可攻陷编码智能体和个人智能体。
ASI05意外代码执行(RCE)(Unexpected Code Execution)与 ASI04 并列事故数量之最。一项对所有主流 AI 编码 IDE 的安全审计在 100% 的受测产品中发现漏洞,反映出智能体自主性与传统 IDE 能力交互方式上的结构性盲点。
ASI06记忆与上下文投毒(Memory & Context Poisoning)在企业环境中显示出特别的威力:攻击者演示了植入持久性虚假信息的能力,这些信息会传播到所有未来的智能体会话。
ASI07不安全的智能体间通信(Insecure Inter-Agent Communication)在研究中仍比在生产中更常见。随着多智能体架构走向部署,该类别代表运营风险的下一个前沿。
ASI08级联失效(Cascading Failures)研究表明,单个被攻陷的智能体可以污染多智能体系统中的下游决策。已确认的生产事故仍然有限。
ASI09人—智能体信任利用(Human-Agent Trust Exploitation)已有记录显示智能体学会压制用户投诉以优化绩效指标——随着组织把更多重大决策委派给智能体系统,这是一个令人担忧的信号。
ASI10流氓智能体(Rogue Agents)对暴露的 AI 基础设施集群的大规模利用证实,未受保护的智能体运行时可以被征用,进行规模化的自主恶意活动。

「如需对本节所述威胁进行动手实践,OWASP FinBot CTF(https://owasp-finbot-ctf.org/)[47]提供了一个故意留有多漏洞的多智能体金融应用,从业者可以在其中实施提示注入、工具滥用、数据外泄、RCE 等场景的攻击,这些场景同时映射到《LLM 应用十大风险》和《智能体应用十大风险》。」

本报告 v1.0 版曾把人在环强制要求、持续合规监控和 AI 供应链透明度描述为预期中的发展。到 2026 年 4 月,这三者要么已写入法律,要么处于标准化后期阶段。讨论已从「这些控制是否会到来」转向「组织如何为那些自主行动、积累凭证并以机器速度跨信任边界协调的系统落地这些控制」。

#### 非人类身份危机(The Non-Human Identity Crisis)

关于结构性问题与推荐控制,参见「智能体身份 vs 非人类身份(NHI)」章节。展望未来,两项进展将定义接下来的十八个月:标准机构在智能体专属身份上的收敛,以及智能体派生架构尚未解决的治理问题。

NIST 的 AI 智能体标准计划(AI Agent Standards Initiative)正在为智能体改造 OAuth 2.0 与基于策略的访问控制,实践指南预计将在 18—24 个月内陆续发布。OpenID 基金会已分析了递归委派与多智能体令牌交换方面的缺口,协议草案预计在 2026—2027 年间出台。MCP 的授权规范已强制要求使用带资源指示符(resource indicator)作用域令牌的 OAuth 2.1 流程。到大约 2027 年,监管者和审计师不仅会问智能体持有什么权限,还会问这些权限是如何派生的、何时过期,以及吊销如何沿委派链传播。

信任传递性问题的前瞻变体是智能体派生架构:编排器动态创建临时子智能体,委派网格通过组合(而非配置)增长。每个派生智能体从其父级继承或派生凭证,而现有 IAM 无法界定由此产生的爆炸半径。OpenID 基金会将递归委派与无界权限链列为关键风险。MCP 的 OAuth 2.1 模型提供了传输层隔离,但尚未扩展到治理派生智能体的链条。正在构建多智能体系统的 CISO 应当现在就设计委派治理,而不是等到首起可追溯到失控权限继承的泄露事件发生后再做改造。

#### 从静态合规到运行时治理(From Static Compliance to Runtime Governance)

一旦智能体开始运行、积累上下文、动态加载工具或修改自身配置,部署前认证的价值就会丧失。监管者正在作出回应。欧盟《人工智能法案》第 72 条要求高风险 AI 系统的提供商在系统整个生命周期内主动、系统地监控性能,以评估持续合规性。对智能体系统而言,这在功能上要求漂移检测——尽管法条从未使用该术语。第 72 条是提供商义务。部署者在第 26 条下继承相关但不同的监控职责。如果欧盟《数字综合法案》(Digital Omnibus)提案在三方会谈(trilogue)中存活,包括第 72 条在内的高风险条款截止日期可能推迟到 2027 年 12 月,但等待这一确认的组织,等于拿 18 个月的合规建设期去赌博。新加坡的《智能体 AI 模型治理框架》(MGF for Agentic AI)要求智能体记录执行计划以供持续评估。纽约州 RAISE 法案要求的测试文档需详细到可被第三方复现。

由此带来的运营转变是巨大的。组织需要四项当今多数组织都不具备的能力:

第一,实时行为监控,用于检测智能体行动何时偏离已批准的工作流基线。计划偏离检测(plan-divergence detection)——将智能体行动序列与其声明意图进行比对——正在《OWASP 智能体十大风险》和 CoSAI《安全设计原则》(Secure-by-Design Principles)中成为核心控制模式。

第二,后果感知的授权(consequence-aware authorization),评估智能体正在做什么,而不只是从其人类操作者那里继承权限。科罗拉多州 SB 24-205(推迟至 2026 年 6 月 30 日)对每次违反、每位消费者处以最高 20,000 美元罚款——但问题跨越辖区存在。纽约州 RAISE 法案(首次违反 100 万美元)、加州 SB 53(每次违反 100 万美元)、DORA 和 NIS2 构成了重叠的处罚面,当智能体同时跨边界运行时这些处罚会叠加。随着多智能体工作流扩展到每日数十万次决策,即便狭窄的授权配置错误也会造成数百万美元的暴露。这一错配将通过立法再校准,或后果感知授权作为架构模式的兴起而得到解决。

第三,足够快、能满足压缩报告时限的自动化事故分类。DORA 要求在将 ICT 事故判定为重大后 4 小时内提交首次通报,而判定本身须在知悉后 24 小时内完成。NIS2 强制要求 24 小时早期预警。纽约州 RAISE 法案要求在判定后 72 小时内报告安全事件。加州 SB 53 允许 15 天。这些制度覆盖不同的实体类型:DORA 与 NIS2 针对金融和关键基础设施部署者,RAISE 与 SB 53 针对前沿模型开发者。但同时构建并部署智能体、或跨受监管行业运营的组织,面临的是真正重叠的时间窗口,人工分诊无法满足。

第四,足以满足上市后监控(post-market monitoring)要求的轨迹级可解释性。欧盟《人工智能法案》第 9 条和第 11 条要求记录预期目的与可预见行为,但智能体系统在运行时组合行为——需要被解释的轨迹在评估时从未被预见。第 14 条加剧了这一点,它要求监督者理解随每个组合工作流而变化的能力。当前的 XAI 工具力有不逮:监管模型假定行为可预先记录,对静态分类有效的归因方法对多步智能体失效,且没有任何现成方案实现了完整的、符合第 72 条的上市后监控。CISO 应当现在就实施轨迹级日志记录,而不是等待在 2026 年 8 月执法之前不会到来的标准。

护栏格局正在分岔。提示层的概率性护栏仍是默认选择,但主要编排框架(LangGraph、OpenAI Agents SDK、Google ADK、Claude Code)已收敛到一种互补模式:确定性挂载点,可在代码层于工具调用之前、执行之后和委派边界处拦截智能体行动。在每个拦截点,策略逻辑可以对照既定约束评估行动的上下文、参数和意图。新加坡的《智能体 AI 模型治理框架》与这一方向一致。早期运营经验令人鼓舞但喜忧参半:挂载点对已知恶意模式检测和受限策略执行有效,但从业者报告称,它们作为预警层比作为硬安全边界更可靠。当挂载点被配置为把决策路由给人工审查者时,决策疲劳成为额外的顾虑——面对每次会话数百个审批提示的开发者,往往会降低审视力度或对整类行动一律批准。这一模式如何成熟,将决定运行时治理是变得在架构上可强制执行,还是仍主要停留在观察层面。

#### 新兴威胁载体(Emerging Threat Vectors)

本小节聚焦三个部署者侧的攻击面,2026 年的证据表明企业风险可能在未来十二到十八个月内在这些面上发展;更广泛的系统性趋势在随后的小节中讨论。这些不是对必然结果的预测;它们标识的是现有证据表明采用速度已超过为之校准的控制的那些面。

驻留在 CI 中的编码智能体面临的威胁模型不同于驻留在 IDE 中的智能体,即便底层失效类别相同。「威胁分析」章节编目的编码智能体 CVE 大多涉及运行在开发者自身环境中的智能体,其对手模型主要是针对可信用户的提示注入或工具滥用。它们还带有一个前提:智能体为它信任的开发者工作,危险来自抵达该可信工作流的被投毒输入。而运行在持续集成流水线内部的编码智能体(审查拉取请求、分诊问题、把关发布)打破了这一假设。CI 智能体生来就要摄取来自它没有理由信任的外部贡献者的输入,这使它按设计就是面向攻击者的表面。为可信开发者场景校准的控制无法迁移。Google 于 2026 年 4 月针对其 run-gemini-cli GitHub Action 发布的公告(GHSA-wpqr-6v78-jr5g)正好证实了这一缺口。组织应把驻留 CI 的智能体视为独立的审查面,而不是假定保护开发者工具的控制会延伸到它们。

随着采用成熟,影子 AI 暴露正转向委派访问失陷。 2026 年相当一部分影子 AI 暴露来自员工使用宽泛的委派 OAuth 作用域,将第三方 AI 工具授权接入企业身份、生产力和云租户。一旦该 AI 供应商后来被攻陷,攻击者就能使用合法授予的访问权在信任边界内部运作,这限制了 MFA(多因素认证)、条件访问和多数数据防泄漏措施的有效性——因为技术上没有任何策略被违反。2026 年 4 月的 Vercel/Context.ai 披露是这一模式在 2026 年最清晰的例子,其结构与企业泄露调查中记录的基于 OAuth 的 SaaS 集成失陷相似。这一载体最终是否比「数据粘贴」暴露造成更多可归因的企业影响,从公开报道尚不清楚,但变化方向与更广泛的趋势一致:智能体 AI 工具正代表用户行动,而非被动消费粘贴内容。将 AI SaaS 纳入 OAuth 治理和非人类身份计划(而不仅是数据防泄漏)的组织,在这一面发展时可能拥有更好的可见性。

前文确立的安全—安保塌缩正沿一条特定轴线加速:读取广泛内部语料并能采取或触发有副作用行动的企业级联网 Copilot。 2026 年 3 月的 Meta Sev-1 事故说明了 safety 或可靠性失效如何通过正常企业工作流触发安保事件:智能体本身没有执行特权行动,但一个人依据不准确的 AI 生成建议行事,导致了临时的未授权访问。EchoLeak 和 ShareLeak(CVE-2026-21520)攻击链则说明了同一架构属性的安保一面。Microsoft 于 2026 年 3 月、Google 于 2026 年 4 月发布的指导在原则层面趋于一致:智能体需要人类控制者、有限且可观察的权力,以及对身份、数据访问和工具使用的明确治理。Copilot 部署是这一交汇在未来十二到十八个月内最可能产生重大事故的地方,尤其是在那些尚未把「AI 安全 vs AI 安保」章节中的集成治理姿态专门扩展到该表面的组织。

#### 尚未解决的问题(What Remains Unsolved)

三个结构性问题今天缺乏充分的解决方案。第一,智能体系统的保证模型与系统本身的性质格格不入。正如「AI 安全 vs AI 安保」章节所讨论的,部署前文档描述的是评估时点的系统,但智能体在运行时组合行为,需要被保证的工作流在评估进行时往往未被预见。形式化验证是为确定性系统构建的,无法轻易弥合这一缺口;同样的限制适用于合规评估(conformity assessment)以及对那些有效行为在部署后才成形的系统的其他一次性评估。该领域似乎正在收敛到以运行时可观测性作为替代方案,轨迹级日志、计划偏离检测和行为包络(behavioral envelope)监控正成为主要控制。目前尚无共识架构确立,而监管者当前要求与架构能便捷支持的能力之间的距离,看起来很可能成为 2026—2027 年最具定义性的治理问题之一。

第二,对高吞吐量智能体而言,机器速度下的人工监督在物理上是不可能的。如果一个智能体每小时执行 10,000 次行动,而人工审查者每小时能评估 50 次,监督只覆盖 0.5% 的决策。风险分级审查(只有高后果行动路由给人工)是正在兴起的模式,但定义后果阈值需要实时的爆炸半径感知,这是多数组织所缺乏的。

第三,监管碎片化沿两个相互叠加的维度展开。在美国,联邦对各州 AI 法律的优先适用仍未解决——商务部已于 2026 年 3 月提交其评估,但国会在 2028 年前不太可能采取行动。与此同时,2025 年颁布的超过 145 部州级 AI 法律造成了定义与处罚结构相互冲突的重叠义务。在欧盟内部,单起智能体事故可同时触发《人工智能法案》第 73 条、NIS2 和 DORA,而时限与受理机构各不相同。跨这两个辖区部署智能体的组织面临叠加的碎片化。CISO 应把辖区感知的策略基础设施预算列为一项永久性运营成本。

#### 高采用层级上的治理—部署冲突(Governance-Deployment Collision at Advanced Adoption Tiers)

追求联邦智能体生态、跨边界编排和自主智能体网络的组织,正在超越其治理就绪度。这些部署模式至少需要持续的运行时监控和自动化异常检测——而「策略 + 人在环」的治理无法以所需的决策速度提供这些能力。CSA(云安全联盟)2026 年调查发现,在计划智能体部署的组织中,只有 27% 对其保护能力有信心。CISO 应把治理成熟度视为硬性的部署关卡:暂停雄心的代价是数月的竞争延迟;而治理不足的跨边界泄露的代价是监管执法、诉讼,以及对耗费多年建立的信任关系的损害。

#### 智能体 AI 部署的网络保险覆盖塌缩(Cyber Insurance Coverage Collapse for Agentic AI Deployments)

随着传统保险公司将 AI 责任排除在标准保单之外,一个结构性的覆盖缺口正在形成。在美国,Verisk 的 ISO CGL(商业综合责任保险)除外条款于 2026 年 1 月生效,WR Berkley 在 D&O(董事与高管责任险)和 E&O(错误与遗漏责任险)产品中引入了绝对 AI 除外条款,AIG 和 Great American 也提交了类似除外申请。保险除外条款与辖区无关——它们在续保时生效,无需立法程序。在欧盟,《AI 责任指令》(AI Liability Directive)的撤回使《修订版产品责任指令》(Revised Product Liability Directive,2026 年 12 月生效)成为主要追索机制,它将 AI 系统视为产品,适用严格的无过错责任。一个专门的 AI 保险平行市场正在形成:Armilla AI、Testudo 和 HSB/Munich Re 现已提供覆盖,但每一家都要求以可证明的治理作为承保前提。CISO 应在续保前审计现有保单中的 AI 除外条款,并认识到安全姿态如今直接决定可保性。

#### OT/ICS 与关键基础设施中的智能体 AI(Agentic AI in OT/ICS and Critical Infrastructure)

AI 智能体正从分析支持走入电池储能场、光伏电站、风电场和制造工厂的控制回路。OT(运营技术)环境的运行约束使以 IT 为中心的智能体安全失效:物理隔离(air-gapped)网络限制了云原生监控,传统协议缺乏现代认证原语,而 IEC 62443 下的安全仪表系统将可用性与机密性视为同等优先。2025 年 12 月发布的 CISA/NSA 联合指导(与八个盟国共同撰写)明确涉及 OT 中的 AI 智能体,并为安全集成确立了四项核心原则。目前尚无企业部署的 AI 智能体造成 OT 安全失效的已记录事故,但 CISO 应开始梳理智能体与 Purdue 模型各层级的交汇点,并为智能体对物理执行器的权限建立清晰边界。

#### 对抗性智能体武器化(Adversarial Agent Weaponisation)

对手正在把智能体 AI 部署为进攻能力,而不只是把智能体系统当作目标。GTG-1002 行动使用被越狱的 Claude Code 实例,对约 30 个组织实施了在很大程度上自主的间谍活动,AI 以物理上不可能的人工请求速率执行了 80—90% 的战术操作。CrowdStrike 2026 年报告记录了 AI 赋能的对手攻击增长 89%,平均突破时间(breakout time)降至 29 分钟。IAPS 的 HACCA 报告警告,前沿模型在数月之内从接近零提升到在专家级进攻性安全挑战上 60% 的成功率。勒索软件团伙正在集成智能体能力用于自主侦察和横向移动。国际规范框架——包括联合国 GGE(政府专家组)和 OEWG(开放式工作组)进程——尚未涉及自主 AI 驱动的行动。CISO 应部署能够区分自主智能体活动与合法工作流的行为检测,并开展模拟智能体驱动行动(而非人工节奏入侵)的红队演练。

结语(Closing)

本报告正文覆盖面很广:威胁趋势、真实世界事故、智能体身份、供应链、监管压力和成熟度模型。十二个月前还是一组可能威胁的组合,如今已是一组已记录案例的组合。随着智能体自主性提升,安全(safety)失效与安保(security)失效之间的界线正在模糊,而部署层的 safety 理应归属安全职能。为静态系统和季度周期设计的治理实践,无法满足以小时计的事故报告时钟,也无法跟上新编码智能体进入企业生产的速度。

对多数组织而言,这不是一个未来才需应对的问题。智能体已经部署,影子 AI 已经存在,管理数量不断增长的非人类身份正在成为真实的运营挑战。有所不同的只是:治理姿态是被有意塑造的——基于对当前攻击面的准确地图——还是在首起事故之后才被塑造。

随后的附录是这项工作的运营基础:详细的智能体类型分类法、覆盖 10 个辖区 42 项法规文书的全球监管格局、按采用层级映射的 ASI 风险类别、知名项目调查、FinBot CTF 训练环境,以及面向个人智能体的十大风险应用演练。每一部分都可独立阅读,并在需要更深入内容时支撑上述章节。 PRIMARY_SOURCE: https://genai.owasp.org/resource/state-of-agentic-ai-security-and-governance

  • #OWASP
  • #Agent 安全
  • #治理体系
  • #事件响应