Havenlon｜AI 时代的执行控制（一）：审批通过，不等于执行安全

摘要在传统业务系统里人们习惯把审批通过理解为一件高风险动作已经被控制住了。付款申请被批准权限变更被同意数据导出被审核脚本执行被授权流程走完之后风险似乎就已经被消化。但这个判断在 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 时代新的安全常识。审批通过不等于执行安全。决策被允许不代表现实应该发生。真正的安全边界必须站在执行发生之前。这句话是整个系列的起点也是接下来每一篇文章共同要回答的同一个问题。