摘要
在传统业务系统里，人们习惯把"审批通过"理解为一件高风险动作已经被控制住了。付款申请被批准，权限变更被同意，数据导出被审核，脚本执行被授权，流程走完之后，风险似乎就已经被消化。
但这个判断，在 AI 和自动化系统全面接管执行链路之后，开始站不住脚。
审批解决的是"该不该做"的问题，而不是"最终有没有在正确条件下发生"的问题。
过去这两者之所以看起来接近，是因为中间一直站着一个人。人会停顿，会核对，会犹豫，会在最后一刻发现异常。AI Agent、自动化脚本、工具调用和业务系统深度集成之后，执行链路里的"人"正在批量消失。一个审批通过的动作，可能会被自动化系统立即转化为真实执行。此时，真正的风险不再只发生在审批之前，而是发生在审批通过之后、动作真正落地之前的那段缝隙里。
这也是 AI 时代需要重新确认的一件事：审批通过，不等于执行安全。
在正式展开论证之前，不妨先记住这一句话——它会在接下来的每一节里被反复验证：一件事被允许发生，和一件事真的按照被允许的样子发生，从来都不是同一件事。
一、我们为什么习惯把审批等同于安全
企业安全、业务内控和系统权限设计，长期以来都是围绕"审批"展开的。
一个人要付款，需要发起申请；要导出数据，需要提交理由；要变更权限，需要上级批准；要执行生产脚本，需要走工单；要进行资产转移，需要多方确认。
这套机制解决的是一组非常明确的问题：谁提出了请求？请求是否合规？发起人是否拥有对应权限？是否得到了组织认可？
只要流程完整、审批人正确、权限匹配、日志留存，人们就会倾向于认为，这件事已经被控制住了。
但这个默认成立，隐藏着一个很大的前提：过去，审批通过之后，通常还需要一个人继续完成执行。
这个"人"非常关键。他可能要登录系统，可能要复制一段命令，可能要打开一个后台，可能要再核对一次收款地址，可能要确认一遍金额，可能要等待页面加载——而在这整个过程里，他随时可能停下来，问一句："这个是不是不太对？"
也就是说，过去很多系统之所以看起来安全，并不完全是因为审批系统本身足够强，而是因为审批和真实执行之间，还存在一层由人类操作构成的缓冲。
人慢，人是串行的，人会看，人会犹豫，人会中断。这层限制过去一直存在，只是因为太过普遍，反而容易被系统设计者忽略。
举一个最典型的场景：财务出纳收到一笔已经审批通过的付款单，在录入系统之前，习惯性地把收款账户的开户行、姓名和账号再核对一遍。这个动作从来没有被写进任何流程文档，没有哪个制度要求他"必须再核对一次"，但正是这个不起眼的习惯，多年来拦下了大量因为审批环节信息被篡改、或者审批单本身存在录入错误而本该酿成事故的付款。
再比如运维人员在执行一条已经走完工单审批的生产环境命令之前，会下意识地再看一眼当前的环境变量，确认自己确实登录在预期的服务器上，而不是一个看起来相似但实际不同的实例。这种"再看一眼"的习惯，同样不属于任何正式流程，却是过去很多重大事故没有发生的真正原因。
这些行为共同构成了一种未被制度化、却始终真实存在的风险拦截层。它不体现在任何审批记录里，也不会出现在任何安全审计报告中，但它的作用，恰恰是在制度设计者完全没有意识到的地方，悄悄补上了审批机制天生留下的漏洞。
二、审批解决的是"判断"，不是"发生"
审批本质上是一种决策机制，它回答的是：这件事从规则上是否被允许？
以一笔付款为例，审批系统可以判断金额是否在预算内、申请人是否有权限、审批人是否同意、流程是否完整、附件是否齐全、供应商是否在白名单里。
但审批系统无法天然保证另一件事：最后执行时，金额是否仍然正确？收款地址是否仍然正确？执行环境是否仍然可信？调用的接口是否仍然是原来的接口？执行脚本有没有被替换？API 参数有没有被中途篡改？负责执行的 Agent 有没有在审批通过之后，又追加了新的动作？
这就是审批和执行之间最根本的区别。
审批是对一个"请求"的判断，执行是让一个"结果"发生。
请求可以是正确的，结果却可能是错误的。审批记录可以是完整的，执行过程却可能被污染。从业务系统视角看，一件事已经通过；从现实结果的视角看，真正危险的部分，才刚刚开始。
这个区别之所以重要，是因为它决定了安全设计应该把资源投入在哪里。如果把"请求是否合规"当作唯一需要把关的环节，那么整套安全体系的重心，会自然而然地集中在审批前——更严格的申请表单、更多层级的签字、更细致的规则引擎。这些投入确实能够提升"判断"的准确性，却无法回答"结果是否如实发生"这个完全不同的问题。一个系统可以在判断环节做到近乎完美，却依然在执行环节彻底失控，因为这两件事从一开始，就不属于同一个问题域。
三、AI 让这个问题变得更严重
在 AI 时代，这个问题被进一步放大。
因为 AI Agent 不只是"回答问题"，它开始拥有调用工具、执行任务、连接业务系统的能力。它可以调用 API，可以写入数据库，可以触发退款，可以生成合同，可以修改权限，可以调用脚本，可以移动资产，可以操作云资源，可以把一段自然语言意图，转化为一连串真实的系统动作。
这意味着，AI 带来的真正变化，不是"系统变得更聪明了"，而是执行链路变短了、执行速度变快了、执行动作变得连续了、执行过程更难被人逐步观察了。
过去，一个高风险动作从申请到执行，中间可能经过很多次人为停顿。现在，一个 Agent 可能在几秒钟内，就完成理解请求、生成方案、调用工具、提交操作、触发执行、返回结果的全部过程。
在这种模式下，如果我们还把"审批通过"当作最终的安全边界，就会出现一个严重误判：
我们以为自己控制了决策，实际上没有控制执行。
AI 不会天然停下来，自动化系统不会天然犹豫，脚本不会天然问一句"这真的安全吗"，工具调用也不会天然区分"审批通过的意图"和"执行时发生的现实变化"。所以，AI 时代真正危险的地方，不只是模型会不会答错，而是它一旦获得执行能力，错误、诱导、篡改和权限滥用，都可能被快速转化为真实且不可逆的结果。
更值得注意的是，AI Agent 的执行过程本身往往不是单一动作，而是一连串相互依赖的步骤。一个被批准的高层意图，可能会被 Agent 自主拆解成十几个具体的工具调用，每一步都建立在上一步返回结果的基础上。审批发生在最开始，针对的是那个高层意图；但真正决定风险大小的，是中间这一连串没有被单独审视过的执行步骤。只要其中任何一步的执行条件发生了偏离——无论是因为环境变化，还是因为恶意注入——最终落地的结果，都可能和最初被批准的那个意图,相去甚远。
设想一个具体的场景：一个 Agent 被授权"根据本月报销单，完成合规报销的自动打款"。这个高层任务本身经过了审批，看起来清晰、有边界、风险可控。但 Agent 在执行时，需要依次完成读取报销单、核对发票、匹配收款账户、调用支付接口这一整套动作。如果其中"核对发票"这一步依赖的第三方验真接口被伪造，或者"匹配收款账户"这一步读取到的是一份已经被篡改的对照表，那么最终真实发生的打款，仍然会顶着"已审批"的名义，流向一个完全错误的账户。审批的对象，从始至终都是那个笼统的高层任务，而不是链条中每一个具体的执行步骤——这正是问题真正发生的地方。
四、审批通过之后，系统仍然可能失控
很多人会说："那我们多加几层审批不就好了？"
这个想法很自然，但它仍然停留在决策层。多一层审批，确实可以提高"判断"阶段的门槛；多一个审批人，也确实可以降低某些人为错误；多一套规则，也可以拦截一部分明显异常。
但如果风险发生在审批之后，多加审批并不能根本解决问题。
比如：审批时看到的是 A 地址，执行时被替换成了 B 地址；审批时金额是一万，执行时参数被改成了十万；审批时脚本版本是安全的，执行时脚本已经被替换；审批时 SaaS 状态显示通过，执行端却从未做过独立验证；审批时 Agent 给出的计划看起来合理，执行时工具调用链已经被污染；审批时业务系统给出绿灯，底层执行环境其实早已被攻击者控制。
这些问题的共同点是：它们不是"审批前"的问题，而是"执行时"的问题。
如果执行端只是无条件相信审批系统给出的结论，那么审批一旦通过，后面所有真实动作就会自动放行。这不是一个闭环的安全设计，而是把执行权，完全交给了一个可能被伪造的审批状态。
而这个状态本身，可能来自 SaaS、数据库、业务系统、缓存、前端页面、API 返回值，甚至某个已经被攻击者控制的中间环节。一旦系统默认"审批通过 = 必须执行"，攻击者真正要攻破的，往往不是执行端本身，而是想办法让执行端相信"某个状态已经通过"。这就是传统审批模型，在面对高风险执行场景时，最根本的结构性弱点。
这类问题并不是理论假设，在不同行业的真实事故里，几乎都能找到对应的影子。在跨境支付场景里，攻击者通过篡改邮件或伪造通讯，让财务人员在审批环节看到的是合法收款方信息，而系统实际执行转账时，账户信息早已被替换——审批本身没有任何流程漏洞，出问题的完全是审批之后的那一步。在云资源管理场景里，一个已经审批通过的"临时扩容"请求，可能在执行时被自动化脚本错误地应用到了生产环境而非测试环境，因为执行端从未真正验证过"当前环境"是否等于"审批时描述的环境"。在 CI/CD 流水线中，一次代码变更审批通过之后，如果构建产物在部署前没有被重新校验哈希值，攻击者只需要在审批和部署之间的窗口期，替换掉即将上线的构建包，就可以让一段完全没有经过审批的代码，堂而皇之地进入生产环境。
这些案例分布在完全不同的行业和技术栈里，但它们的结构完全一致：审批环节没有任何问题，问题出在审批之后，没有人、也没有系统，去确认"现在的现实"是否还等于"审批时看到的现实"。
五、留痕越完整，越容易制造安全错觉
一个值得警惕的现象是：审批流程留下的记录越完整，人们对"这件事很安全"的信心反而越强。审批单据齐全，签字环节清晰，每一步操作都有时间戳，日志系统一应俱全——这些东西加在一起，会给人一种"整个过程都被牢牢掌控"的错觉。
但完整的记录，只能证明"曾经发生过一次符合规则的判断"，并不能证明"最终执行的动作，和这次判断描述的内容完全一致"。一份记录完整的审批单，完全可以对应一次被篡改过的执行；一条清晰的操作日志，完全可以只是攻击者在系统被入侵之后自己生成的、看起来一切正常的假象。日志系统本身，往往和执行系统运行在同一个信任域里，一旦执行环节被污染，负责记录这一切的日志，很可能也已经不再可信。
这意味着，审计留痕这件事,解决的是"事后能不能查清楚发生了什么"，而不是"事中能不能阻止一件不该发生的事情发生"。把这两者混为一谈，是很多企业在构建安全体系时，最容易掉进去的一个陷阱——他们投入大量资源去完善日志和审计能力，却误以为这同时也解决了执行环节的实时风险。
六、安全边界不能停在"允许"
真正的安全问题，不只是"是否允许这件事"，还包括：是否仍然允许？是否由正确的人发起？是否在正确条件下执行？是否没有被篡改？是否没有超出边界？是否可以被独立验证？是否可以留下执行证据？是否在最后一刻仍然可以被否决？
审批系统通常负责前半部分——它判断一个请求是否可以进入下一步。但执行安全必须负责后半部分——它要在真实动作发生之前，重新确认这件事是否仍然应该发生。
审批关心的是"流程是否通过"，执行控制关心的是"动作是否可以落地"。
审批可以告诉系统：这件事看起来被允许了。但只有执行控制能够决定：这件事，现在是否真的可以发生。这两者不是同一个层级，也不能互相替代。这也是 AI 时代最容易被忽略的一次转变：我们不能只控制请求的合法性，还必须控制执行的发生条件。
这种转变之所以容易被忽略，是因为审批通过的那个瞬间，给人的心理感受实在太强烈了——签字完成，流程走完，系统提示"已批准"，几乎所有人都会在这一刻默认风险已经解除。但对于一个由 AI 和自动化系统驱动的执行链路而言，这个瞬间只是整个风险周期的中点，而不是终点。真正决定结果好坏的，是从这一刻到动作真正落地之间，那段几乎没有人会去关注的过程。
换一个角度看，这也解释了为什么很多关于"AI 安全"的讨论，容易停留在错误的层面。人们习惯去追问：这个模型的判断准不准？这个 Agent 的方案合不合理？这些问题当然值得关注，但它们本质上仍然属于"决策是否正确"的范畴。而一个决策正确的方案，依然可能在执行环节被扭曲、被篡改、被中途替换。只盯着决策质量，却不去审视执行过程本身,是把安全体系的重心，放在了错误的半程。
七、审批不是没用，而是不够
强调"审批通过不等于执行安全"，并不是否定审批。
审批仍然重要，权限仍然重要，风控仍然重要，日志仍然重要，组织流程仍然重要。问题在于，它们不能被误认为最终的执行边界。
审批负责让组织知道，谁同意了什么；权限负责限制，谁可以发起什么；风控负责判断，请求是否异常；日志负责记录，系统看到了什么。但高风险动作真正发生之前，还需要回答一个不同的问题：即使前面都通过了，这件事现在是否仍然应该被允许执行？
把这几套机制放在一起看会发现，它们各自守住的，其实是同一条链路上不同的截面：审批守住的是发起前的合规性，权限守住的是身份和范围的边界，风控守住的是行为模式是否异常，日志守住的是事后能否被追溯。它们分工明确，各司其职，唯独缺了一环——没有任何一套机制，专门守在"动作即将真实发生"的那一刻，去做最后一次现实核验。这不是某一套机制设计得不够好，而是从一开始，这个问题就没有被划归到任何一套现有机制的职责范围之内。
这个问题，不是审批系统的自然延伸，而是一个全新的控制层要回答的问题。在 AI 与自动化时代，这一层会变得越来越关键——因为未来大量系统，不再由人一步步操作，而是由 Agent、脚本、自动化工作流、业务系统和第三方工具连续触发。当执行变得越来越快、越来越自动、越来越不可见，安全边界就必须从"审批通过"这一刻，下沉到"执行发生之前"的那一刻。
需要强调的是，这不是要求企业推翻现有的审批体系，重新建一套东西。恰恰相反，审批体系本身运转得越规范、留痕越清晰，越有利于后续在执行层做独立验证——因为执行控制需要的正是审批环节留下的那些确定信息：当时批准的金额是多少，当时确认的收款对象是谁，当时授权的操作范围有多大。执行控制层要做的，是拿这些确定的信息，去和执行那一刻的现实做比对，而不是重新发明一套判断规则。审批体系提供基准，执行控制层负责校验现实是否偏离了这个基准，这是两套机制协作的方式，而不是相互取代的关系。
结语：一个刚刚打开的问题
过去的安全常识是：先审批，再执行。AI 时代需要补上一句：审批之后，还要控制执行。
这不是流程的复杂化，而是安全边界的重新定位。因为 AI 并不会只停留在建议层，它会进入工具层、流程层、业务层和执行层。当 AI 真正开始触碰现实业务，安全问题就不再只是"模型是否可信"，而是：谁允许它执行？谁限制它执行？谁验证它执行？谁能在最后一刻阻止它执行？谁能证明它到底执行了什么？
这些问题之所以在这个时间点变得紧迫，是因为过去几年里，企业把大量原本由人执行的操作，一批一批地交给了自动化流程和 AI Agent，速度远远快过安全体系的更新速度。审批系统还是原来那一套，权限设计还是原来那一套，但执行端已经从"一个会犹豫的人"，变成了"一段不会犹豫的程序"。这种错位不会自动被时间填平，只会随着 AI 承担越来越多的执行任务而不断放大。
这些问题目前还没有答案。这也是本系列接下来要逐一展开的地方：
意图（Intent）和执行（Execution）之间，究竟隔着什么，为什么这道界限最容易被忽略；过去的系统为什么看起来更安全，恰恰是因为人一直站在中间，充当了一层从未被写进制度、却始终在起作用的缓冲；AI 真正的危险，不是它会不会思考，而是它有没有能力把一个想法，变成现实世界里不可逆的结果；Tool Calling 表面上只是改变了交互方式，实际上悄悄改写了整套安全模型，把 AI 的输出边界，从一段可以撤回的文字，扩展成了一个真实发生的系统动作；审批和真实执行之间，那道被称为 Execution Gap 的缝隙，究竟是怎么被打开的，又是怎么被利用的；为什么静态的审批规则，天生挡不住动态发生的执行风险；为什么当执行系统和审批系统处在同一个信任域里，软件往往管不住软件；为什么真正的执行控制，必须独立于审批系统、业务系统和 Agent 工具链之外存在；不可绕过、防篡改、可验证——这三个条件，为什么是执行控制层不可退让的底线；一个只能说"不"、不能主动发起任何动作的系统，为什么反而是最安全的设计；以及，把执行权真正关进笼子，会成为 AI 时代新的安全常识。
审批通过，不等于执行安全。决策被允许，不代表现实应该发生。真正的安全边界，必须站在执行发生之前。
这句话，是整个系列的起点，也是接下来每一篇文章，共同要回答的同一个问题。
