Agent Governance 正在迅速成为企业 AI 安全体系的组成部分。当 Agent 开始拥有工具调用、接口访问、长期记忆、任务编排与跨系统操作能力之后，一系列治理问题自然出现：谁可以创建 Agent，它使用哪个模型，能访问哪些数据，能调用哪些工具，是否需要人工审批，任务可以运行多久，能否派生子 Agent，行为如何被监控与记录。

这些问题都需要答案。没有 Agent Governance，一家企业甚至无法知道环境中运行着多少 Agent，也无从判断它们持有哪些凭据、正在执行什么任务、是否已经偏离最初目的。这是必要的基础工作。

上一篇结尾提出的问题在于治理的绑定对象。同一个删除生产集群的动作，可以来自 Agent，也可以来自值班工程师的一条命令、一段定时任务、一个 SaaS 的自动化规则、一次流水线的回滚步骤。如果治理体系是围绕"这是不是 AI"建立的，那么它会在同一个动作换一个发起者时失效。于是问题变成：安全体系究竟应该治理 Agent，还是应该治理任何能够改变受保护现实状态的执行能力？

一、Agent Governance 的对象是主体，Execution Governance 的对象是受保护动作

Agent Governance 的出发点是 Agent 本身。它要弄清楚这个 Agent 由谁创建、使用什么模型、持有什么身份、能访问哪些工具与数据、运行多久、能否派生子 Agent、哪些行为需要人工确认、行为如何被记录。这些控制围绕同一个问题展开：这个 Agent 应该被允许如何运行。

Execution Governance 的第一个问题完全不同：哪些现实动作属于受保护执行。资金转移、生产部署、云资源删除、凭据轮换、工业设备控制、高风险数据库写入——先把这些动作识别出来并登记为治理对象，然后追问第二个问题：不论由谁发起，这个动作必须满足哪些执行条件。

治理逻辑因此从 Agent → Allowed Behavior 变为 Actor + Action + Target + State + Evidence + Boundary → Execution。这里的 Actor 是输入之一，而不是治理的锚点。它可以是 Agent，也可以不是。

Agent Governance 约束机器主体怎么行动；Execution Governance 约束什么现实结果有资格被制造出来。

二、绑定在主体上的规则，会被换一个主体绕过

只做 Agent Governance 最容易遇到的架构问题就在这里。假设企业规定所有 Agent 执行生产部署都必须经过审批，这条规则看起来足够严格。但如果同一个部署接口仍然允许人工操作员、CI 流水线、服务账号与自动化脚本从其他路径调用，那么真正被保护的不是"生产部署"，而是"由 Agent 发起的生产部署"。攻击者甚至不需要突破 Agent Governance，他只需要把同一项能力换到另一条自动化路径上。

这个问题的本质是一个覆盖关系错配：规则的作用域是主体集合，而风险的作用域是动作集合，两个集合并不同构。只要存在任何一个不在规则主体集合内、却能触达同一动作的主体，规则就有缺口。

更重要的是这两个集合的演化速度不同。主体集合持续膨胀——每接入一个新的自动化工具、每上线一个新的集成、每创建一个新的服务账号，集合就扩大一次，而这些变更通常不经过安全评审。动作集合相对稳定：一家公司能够转出资金、删除集群、部署生产的方式，几年之内变化有限。规则应当绑定在变化慢的那一侧，否则治理体系会永远追赶主体清单，而每一次追赶滞后都是一个窗口。

因此稳定的安全边界应当是：只要动作属于受保护执行，无论请求来自人、Agent、工作流、SaaS 还是自动化脚本，都必须满足同一组执行条件，都不能绕过同一条执行边界。

如果安全边界只保护 Agent 而不保护动作，那么同一种危险能力换一个主体就会重新出现。

三、Tool Governance 缩小能触碰的能力，Execution Governance 缩小这些能力的结果

工具治理是 Agent Governance 中很有效的一项能力。给 Agent-A 开放检索、数据库读取、支付接口与部署工具，给 Agent-B 只开放检索与内部知识库——这种允许清单直接缩小了能力面，应当继续做。

但工具本身通常仍是一个较宽的抽象。一个支付工具可能既能转出十美元也能转出十万，既能作用于已注册对象也能作用于任意账户；一个部署工具可能同时覆盖开发、预发与生产。工具访问权限回答的是"Agent 能不能使用这把工具"，它不回答"即使可以使用，它具体能通过这把工具制造什么结果"。

这与本系列讨论最小执行权与能力约束时的结论是同一件事在治理层的重述：能力入口的收窄与能力后果的收窄是两个独立动作，前者做得再好也不产生后者。

四、人在环上不等于人在执行边界上

不少 Agent 系统把人工审批当作最高安全机制：高风险动作触发时，Agent 请求审批，人点击确认，然后执行。这确实显著降低了完全自主执行的风险，但它是否构成执行治理，取决于一个问题——人到底批准了什么。

如果审批只是一次"同意"点击，而最终执行参数在批准之后仍然可以变化，那么批准并没有约束现实。人批准的是把 Image-A 部署到 Service-B，最终执行的是把 Image-X 部署到 Service-C，人在环上，执行安全照样失败。

因此执行治理要求批准与具体动作建立不可替换的绑定关系：批准 ↔ 动作 ↔ 对象 ↔ 关键参数。审批由此从一个流程节点，变成执行证据的一部分——它不再只是"发生过一次人工确认"，而是"存在一份能够证明这一次执行被授权的可验证对象"。

这里还有一个容易被忽略的裂缝：人只能批准他看得懂的东西。如果呈现给审批人的是一段摘要，而被绑定和签名的是完整参数，那么摘要之外的字段实际上没有经过任何人的判断；反过来如果被绑定的只是那段摘要，那么未被摘要覆盖的字段可以在批准之后自由变化。这是本系列讨论认证时提到的"所见即所签"问题在治理层的形态——呈现内容、被批准内容与最终执行内容必须是同一个对象，任何一处不一致，人工审批提供的保证都会打折。

顺带一提，把人工审批设为大量动作的默认要求，通常会让它退化成机械点击，既未提高安全性，也抵消了自动化价值。审批的有效性依赖于它足够稀少、且每一次都携带足够的信息。

人在环上不自动意味着人在执行边界上；只有批准对象与最终动作被绑定，人工审批才真正成为执行治理的一部分。

五、行为正常与执行越界是两类不同的信号

Agent Governance 自然会引入行为监控：是否调用了异常工具，是否出现提示注入迹象，是否访问了异常资源，是否偏离任务目标，是否出现反常的调用模式。这些关注的是行为偏离。

执行治理还需要另一类判断：因果越界。一个 Agent 完全可能表现正常——按既定流程调用既定接口，频率平稳，没有任何异常模式——而最终对象错了，或状态已经过期，或累计执行越过了业务边界。此时行为是正常的，执行是不安全的。

两类检测的可观测量不同，这决定了它们不能相互替代。行为异常检测的输入是主体的动作序列：调用了什么、多快、按什么顺序，它把这些与历史基线比较。执行越界检测的输入是动作与其应有语义之间的差：这一次的对象是不是被批准的那个，这一次的参数是不是决策时的那组，当前状态是否仍然支撑这次执行——它需要一个参照物，即原始意图与批准。

区别就在这里：行为检测没有参照物，只有基线。没有参照物的检测只能发现偏离常态的东西，不能发现常态本身就是错的。如果一条错误的执行路径从第一天起就以稳定的频率运行，它会成为基线的一部分。而参照物驱动的校验从第一次就会失败，因为它比对的不是历史，是这一次应该是什么。

行为监控发现异常的行为；执行治理还要拦住看起来完全正常、现实结果却已经越界的动作。

六、执行治理的强度应当分层，而不是一刀切审批

如果执行治理最终意味着所有动作都要人工批准，它会摧毁自动化本身的价值，并且在实践中根本无法维持。真正的目标是建立分层的执行边界，让治理强度与后果严重程度对齐：

风险等级	执行治理方式
低风险	边界内自动执行，事后证据留存
中风险	自动执行，但要求完整的执行前证据
高风险	独立批准 + 执行边界校验
极高风险	多个独立 Authority + 受保护执行器

这里的分层依据应当是本系列反复使用的那一组：动作是否可逆、恢复成本多高、影响面多大、错误执行的损失与短暂拒绝的代价如何比较。它不应该是"这个系统重不重要"这样的粗粒度判断，也不应该按发起者是不是 AI 来划分。

按这种方式组织之后，人工审批的位置发生了变化——它不再是所有高风险动作的默认前置条件，而是执行权需要临时升级时才出现的机制。Agent 在边界内高速运行，系统只在越界或证据不足时提高治理强度。这样自动化的价值被保留，而人的注意力被投放在真正需要判断的少数位置上。

好的执行治理不是让机器少执行，而是让自动执行只发生在系统能够承受的边界之内。

七、Execution Governance 不是 AI 专属概念

如果执行治理只适用于 AI Agent，它的理论范围就仍然过窄，而且会在几年后随着技术形态变化而失效。

错误执行是一个长期存在的问题。人工操作员会输错对象，自动化脚本会在错误环境运行，流水线会部署错误版本，管理员会误配置，批处理会重复执行。AI Agent 没有创造这个问题，它改变的是四个量：速度、规模、自主性、执行链复杂度。更准确地说，它把过去由人类理解、界面确认与组织流程隐式承担的执行边界，变成了必须被机器系统显式承担的东西。那些边界一直存在，只是从未被写下来过。

这也是为什么执行治理的判据不应该是"这个主体是人还是 AI"，而应该是"这个主体能不能改变受保护的现实状态"。前者是一个关于技术形态的分类，后者是一个关于因果能力的判断，只有后者在主体形态变化时保持稳定。

在这个更一般的视角下，还有三件事必须纳入治理范围。

第一，执行权往往不属于单个主体。 一次真实执行可能涉及用户、Agent、子 Agent、工作流、服务、执行器；Agent 决定对象，策略引擎决定边界，人提供批准，编排层构造最终载荷，执行器持有凭据。治理单个主体无法覆盖这种结构，必须回到本系列第二阶段建立的分析方式——哪些主体组合之后可以形成完整的执行权，以及这些组合是否被威胁模型允许。

第二，执行语义必须跨系统一致。 Agent 平台有自己的策略，工作流平台有自己的权限，云平台有自己的 IAM，支付平台有自己的风控，每一个内部都可能治理良好；而一次真实执行会横穿它们全部。如果上游允许的对象、边界与证明在下游无法被理解，治理就在交界处断裂。WHO、WHAT、OBJECT、STATE、PROOF、BOUNDARY 之所以值得作为一组稳定语义，正是因为它们不依赖任何具体框架或云厂商，任何受保护执行都需要回答这几个问题。

第三，治理链的终点必须是现实。 如果监控只覆盖 Agent 输出了什么、调用了哪个工具，边界就停在了 AI 系统内部，而风险发生在外部。完整的治理链需要一直走到 Intent → Decision → Capability → Execution → External State Change → Result Evidence，直到系统能够回答：最终现实发生的事情，是否仍然是最初被允许发生的那件事。

与此配套的是责任的归属方式。复杂执行的责任分布在多个 Authority 上，事故之后很容易出现每个组件都声称自己只是执行了上游要求的局面。可行的做法是让 Authority 与 Evidence 对齐——意图权产出意图证据，批准权产出批准证据，决策权产出决策证据，执行权产出结果证据，形成 Authority → Decision → Evidence → Responsibility 的对应。这样系统不仅能回答谁做了什么，还能回答谁对哪一段执行因果链负责。

Execution Governance 不是为了治理 AI，而是为了治理任何能够把数字决定变成现实后果的权力。

结语：从 Access Security 到 Execution Security

回看这十二篇，它们其实在做同一件事：把一个此前被合并处理的安全对象拆出来。

前四篇处理的是传统控制的边界。零信任消除默认信任之后，仍然留下默认执行权；最小权限压缩了能力集合，没有压缩这些能力可达的现实状态空间；认证证明主体真实，不证明这一次动作具备资格；授权做出正确判断，不保证判断的语义能原样抵达执行点。第五、六篇转向权力结构：能够做出判断的组件不必然应当持有让判断成为现实的能力，而安全层数与独立权力数量是两个不同的变量。第七、八篇处理证明：证据从事后观测移到执行之前的决策输入，并规定不完整的证明不能自动转化为 ALLOW。第九、十篇更换分析对象：从身份关系图转向因果权力图，再把权力沿时间展开成从意图到现实的因果路径。最后两篇回到能力本身：保护凭据是保护能力入口，约束能力才是限制现实后果；而这种约束不应当依附于某一类主体。

需要再说一次的是，这个系列从头到尾没有主张传统安全机制失效。恰恰相反，它们全部是执行安全的前提——没有可靠的认证就无法归属权力，没有最小权限就无法设计有意义的执行边界，没有授权体系就没有东西可以挡住绝大多数根本不该进入执行链的请求。真正变化的不是这些机制的有效性，而是软件本身的位置：它正在从主要"访问信息"，转向直接"改变现实"。当系统主要读取数据时，Who can access what 几乎覆盖了全部安全语义；当系统开始自主操作资金、基础设施与设备之后，还必须继续回答 Who can make what happen。后一个问题建立在前一个问题之上，而不是取代它。

AI Agent 让这件事变得紧迫，不是因为它天生比人更危险，而是因为它第一次把理解、决策、参数构造与现实执行以机器速度连接在一起。过去一名员工持有某个权限，与他真正让某件事发生之间，隔着理解成本、界面确认、同事的一句提醒、审批流程和时间摩擦。这些从未被写进任何安全设计文档的东西，长期承担着实际的执行边界职责。自动化把它们逐一压缩掉了，而被压缩掉的部分不会自动出现在别处——它必须被显式地重新建模。

所以这个系列真正想确立的判断只有一句：Execution 应当成为一个独立的安全对象。它不属于身份，不属于权限，不属于策略，也不属于某一类机器主体；它有自己的资格条件、自己的证据要求、自己的失败语义、自己的权力结构与自己的边界。无论一个动作来自人、Agent、工作流还是其他任何主体，只要它准备改变受保护的现实状态，它就应当先证明自己具备执行资格，并且始终不能拥有超出系统所能承受范围的执行权。