摘要在 AI 和自动化系统里人们很容易把用户想做什么和系统最后做了什么混为一谈。用户说帮我给供应商付款AI 把这句话理解为一个付款意图业务系统生成一条申请审批流显示通过执行系统最终调用接口把钱转了出去。从表面看这是一条连续、顺滑的链路。但从安全角度拆开看这里面至少存在四层完全不同的东西Intent用户想做什么、Approval组织是否允许、Execution系统实际执行了什么、Reality现实中最后发生了什么。过去人一直夹在这几层之间所以它们看起来像是一回事——人会看、会停、会确认、会修正。AI Agent 和自动化系统出现之后这些层之间的距离被急剧压缩甚至被完全隐藏。于是一个最大的误解悄悄出现了只要 Intent 正确Execution 就一定正确。Intent 不是 Execution。意图被理解不代表执行会被正确约束请求被批准不代表现实结果会按原样发生。AI 时代真正危险的地方恰恰在于它能把一个看似合理的意图快速转化为一连串真实动作。这就是为什么执行控制必须站在 Intent 和 Execution 之间。一、AI 时代Intent 变得越来越重要过去的系统大多是按钮式的。用户要做一件事通常需要进入某个页面选择某个功能填写某些字段点击某个按钮。系统看到的是明确的动作提交付款、导出数据、修改权限、执行脚本、创建订单、发起退款。AI Agent 改变了这个入口。用户不再需要点击具体按钮而是表达一个自然语言意图——帮我处理这批退款把这个客户的数据整理出来检查服务器问题必要时自动修复根据合同内容完成付款流程。这些话描述的是一个目标而不是一条完整的执行路径。AI 的能力恰恰在于它可以把这个目标自主拆解成一连串具体步骤理解任务、识别对象、选择工具、生成参数、调用接口、等待结果、决定下一步。这确实极大提高了效率但安全问题也正是在这里出现的人说的是目标AI 执行的是路径。目标可以正确路径却可能出错意图可以合理执行却可能失控。这就是 AI 时代最容易被低估的一层。这种转变,本质上是把如何做这件事的决定权从用户手里转移到了 AI 手里。过去用户点击的每一个按钮本身就是对执行路径的一次显式确认——选择了这个功能就等于确认了这条路径。现在用户只表达目标路径怎么走、调用哪些工具、按什么顺序执行全部由 AI 在背后决定。这本身不是坏事,恰恰是 AI 提供价值的地方,但它意味着,过去藏在用户点击哪个按钮里的那一部分安全确认现在必须由别的机制来补上而不能假设它依然存在。二、Intent 只是想做什么不是实际做了什么Intent 的本质是对一个目标的表达。它可能来自用户也可能来自业务系统、自动化规则、另一个 Agent甚至某个计划生成器。但无论来源是什么Intent 都只是一个起点它不能天然保证执行结果。比如用户说帮我把这笔款付给供应商这个 Intent 听起来完全正常。但要真正把它执行出来系统还需要独立回答很多问题供应商是谁收款账户是哪一个金额和币种是多少是否在预算和限额之内是否需要多人确认执行接口是否可信最终参数有没有被中途篡改如果这些问题没有被独立控制那么 Intent 再正确也无法保证 Execution 正确。同样在链上资产场景里用户说把资产转到冷钱包Intent 本身是安全的但执行时依然可能出现地址被替换、链 ID 错误、合约调用被伪装、授权额度异常、前端显示和真实签名内容不一致等情况最终结果可能完全偏离最初的意图。再看一个更日常的场景一名员工在企业内部系统里说帮我给新入职的同事开通项目权限。这个 Intent 本身完全合理没有任何恶意。但要真正安全地执行系统还需要独立确认这位新同事的账号是否真的对应本人开通的权限范围是否和岗位职责匹配是不是被错误地开成了管理员权限而不是普通协作者权限如果 Agent 在理解这句话时把项目权限默认解释成了更大范围的系统权限那么即便 Intent 表达得再清楚最终执行出来的结果也早已偏离了说话人原本的设想。Intent 的正确性不能直接传导为 Execution 的正确性。中间必须有一层独立的控制。三、Approval 也不是 Execution在系列第一篇里我们讨论过审批通过不等于执行安全。这里可以再往下拆一层。审批处理的是 Approval——在某个时刻某个请求被某条组织规则允许了。这仍然不是 Execution因为 Approval 只是对 Intent 或请求的认可而 Execution 是真实动作的发生。举个例子审批系统批准了一笔十万元付款这个 Approval 说明申请流程通过、审批人同意、金额在规则内、系统记录完整。但它不能自动说明最后付款金额一定是十万收款账户一定没被替换执行接口一定没被劫持执行前的状态一定没有变化。Approval 是流程状态Execution 是现实动作这两者之间不能画等号。AI 和自动化让这个问题更严重因为 Approval 一旦产生后续动作可能立刻被系统自动接管——审批从过去人工下一步的参考变成了自动化链路里的放行信号。一旦 Approval 被系统理解为可以直接执行它就不再只是一个组织决策而是变成了执行触发器。这时候如果没有独立的执行控制审批状态本身反而可能成为风险的入口。这个转变值得多停留一秒去理解。在纯人工操作的年代审批通过之后,还有人要去登录系统、复制参数、点击确认——审批状态和最终动作之间永远隔着一段可以被人为打断的距离。而在自动化链路里Approval 这个状态字段很可能直接被下游的执行程序读取一旦读到已通过程序不会追问这个状态是否仍然可信只会立刻按照预设逻辑触发下一步。审批状态原本只是给人看的参考信息现在却变成了机器可以直接消费、并据此触发真实动作的信号源这中间的角色转变恰恰是很多系统设计者没有意识到的地方。四、Execution 也不是 Reality还要再往下拆一层。Execution 是系统实际执行了什么Reality 是现实世界最后发生了什么这两者也不完全一样。系统可能显示执行成功但现实状态未必符合预期。转账广播成功不代表资产已经安全到账退款请求提交成功不代表客户收到了正确金额权限变更执行成功不代表权限范围符合原始意图脚本执行完成不代表生产环境没有产生副作用API 返回成功不代表最终业务结果正确。这就是为什么AI 时代不能只看 Intent也不能只看 Approval甚至不能只看 Execution必须关心 Reality——这件事最终有没有按正确条件真实、可验证地发生。如果没有执行证据系统就只能相信自己的日志如果没有独立验证系统就只能相信自己的状态如果没有边界控制系统就只能相信发起方没有出错。这不是一个可靠的安全模型。以链上转账为例这种区别体现得最直接Execution 层面交易已经被节点广播、被打包进区块系统完全可以判定执行成功但 Reality 层面还需要确认接收地址确实归属于预期的对象确认没有中间人在广播前替换了交易参数确认这笔资产最终真的进入了它该进入的地方而不是停留在一个看起来相似、实际完全无关的账户里。Execution 是系统对自己动作的描述Reality 是这个描述之外独立存在的客观事实。两者之间的落差往往就是事故真正发生的地方。五、AI Agent 最大的问题是把这些层压扁了AI Agent 的强大之处在于它能把 Intent 到 Execution 的路径自动化用户表达意图模型理解目标生成计划调用工具工具执行动作系统返回结果模型继续下一步。从用户视角看这个过程非常顺滑但从安全视角看这恰恰很危险。因为中间很多关键转换被隐藏了Intent 被如何理解计划由谁生成工具为什么被选中参数从哪里来执行前有没有重新验证某一步是否被注入、篡改或诱导如果系统只关心用户原始 Intent 看起来没问题就会忽略后面每一次转换所带来的风险。设想一个具体场景用户对 Agent 说帮我处理这批客户退款这是一个高层意图。Agent 需要依次完成读取退款申请列表、核对退款金额、匹配客户账户、调用支付接口这几个步骤每一步都建立在上一步返回结果的基础上。如果核对退款金额这一步读取到的数据源已经因为系统缓存延迟而不是最新数据或者匹配客户账户这一步因为客户姓名重复而匹配到了另一个人的账户——这些偏差不会出现在最初的 Intent 里也不会被审批环节看到只会在链条内部悄悄发生最终体现为一笔发给错误对象的退款。AI 不是把 Intent 原封不动地变成 Execution它会解释、扩展、拆解甚至重写 Intent——这正是它有用的地方也正是它在高风险动作里危险的地方。六、Intent 被污染比指令错误更隐蔽传统系统里攻击常常表现为明确的恶意指令比如直接要求转账给攻击者、删除数据库、导出全部用户数据。这些动作看起来明显异常容易被拦截。AI 时代的风险可能更隐蔽攻击者不一定直接发出恶意指令而是选择污染 Intent 所依赖的上下文——在邮件里夹带诱导信息在文档里植入错误的收款信息在网页内容中隐藏提示在多 Agent 协作中传递一个已经被污染的中间状态。这时AI 可能仍然认为自己在执行原始 Intent但 Intent 的解释实际上已经被悄悄改变。更危险的是从日志上看一切可能都显得合理用户确实发起了请求AI 确实生成了计划审批确实通过了工具确实被调用了系统确实返回成功。但最终的 Reality早已偏离了人的真实意图。仅仅记录 Intent 是不够的系统必须在执行发生之前把最终动作重新拉回到可验证、可限制、可否决的边界内。这种隐蔽性,恰恰是它比传统攻击更难防范的原因。传统的异常检测,擅长识别指令本身看起来不对劲——一笔金额异常巨大的转账,一次发生在深夜的权限提升,这些都容易触发规则告警。但当攻击者选择污染的是 Intent 赖以成立的上下文,而不是 Intent 本身,整条链路上的每一个环节,单独看都无懈可击:请求是真实用户发起的,金额在正常范围内,时间也在工作时段。异常不在于任何一个字段,而在于这个字段所依赖的信息源早已不是最初被信任的那一个。这种攻击面,几乎无法通过检查任何单一环节来发现,只能通过在执行前重新核验关键信息的来源和一致性来拦截。七、执行控制层要守住的是转换关系很多人理解执行控制时容易把它想成最后一道审批但它不是。执行控制层真正要守住的是 Intent 到 Execution 的转换关系——原始意图是什么审批允许的范围是什么最终执行参数是什么执行动作是否仍在原始边界内。它要问的不是有没有审批而是这次即将发生的执行是否仍然对应最初被允许的意图。这就是执行控制和审批的本质区别审批看的是请求是否可以通过执行控制看的是执行是否仍然忠于被允许的边界。如果 Intent 是 AApproval 允许的是 AExecution 却变成了 B系统就必须阻止——哪怕审批记录完整哪怕 Agent 给出了合理解释哪怕 SaaS 状态显示一切正常。因为真正要控制的从来不是页面上的状态而是现实中即将发生的动作。八、为什么这一层必须独立如果 Intent、Approval、Execution 全部在同一个系统里处理就会出现一个结构性问题系统既发起请求又解释请求又批准请求又执行请求还负责记录自己执行得很好。这在低风险场景里可能足够但在高风险场景里这是一种典型的信任集中——一旦这个系统被攻击、被误导或被配置错误它就可能从头到尾自己证明自己是正确的。真正可靠的结构必须把这些角色分开Intent 可以由用户或 Agent 发起Approval 可以由组织规则判断Execution 可以由底层系统完成而 Control 必须在执行前拥有独立的否决权。尤其是资产转移、权限提升、密钥使用、数据导出、生产发布这类高风险动作不能只依赖发起系统自己的解释因为发起系统最容易受到上下文污染审批系统最容易被当成放行状态日志系统最容易只记录一个已经发生的结果。它不需要替业务系统做所有判断不需要理解全部业务语义也不需要接管整个流程但它必须在真实执行前拥有一个最基本的能力判断即将发生的动作是否仍然在被允许的边界之内。这里有一个容易被误解的地方角色分离不等于流程变慢也不等于把简单问题复杂化。执行控制层要做的判断,通常是非常聚焦的——它不需要重新审视整个业务逻辑,只需要拿到 Intent 阶段和 Approval 阶段留下的确定信息(谁、多少、对谁、在什么范围内),去和 Execution 即将发生的那一刻的真实参数做一次比对。如果两者一致,放行的过程可以做到几乎无感;只有当两者出现偏差时,它才需要真正介入。这种默认沉默、异常时才现身的工作方式,恰恰是它能够独立存在、又不拖累整体效率的关键。九、Intent 不是信任根AI 时代还有一个常见误区只要用户 Intent 是真实的系统就应该执行。这并不够因为 Intent 不是信任根。用户可能表达不完整可能被诱导可能看错对象可能把复杂任务交给 Agent 之后就不再逐步核对Agent 可能误解上下文可能被污染工具可能返回错误执行参数可能在中途被替换。同样Approval 也不是信任根SaaS 状态也不是信任根前端显示也不是信任根Agent 给出的计划也不是信任根。在高风险执行场景里真正需要的是一个独立的、不可绕过的、可验证的执行边界。它不是替代 Intent而是约束 Intent不是否定 Approval而是验证 Approval 和 Execution 是否一致不是阻止 AI而是让 AI 的执行能力被放在边界之内。这句话背后,其实是在回应一个更根本的疑问:既然 Intent、Approval、Execution 都有各自的局限那安全体系到底应该相信谁?答案是,不应该完全相信任何单独一层而应该相信这几层之间是否彼此吻合。用户真正想做的事、组织实际批准的范围、系统最终执行的动作这三者只要还能被独立地拿出来相互印证风险就有被拦截的机会一旦某一层被单方面污染而其他层又选择无条件信任它风险就会一路畅通无阻地流到最后一步。十、AI 时代的安全问题本质上是转换问题如果用一句话概括这一篇的核心那就是AI 时代最危险的不是某一层单独出错而是层与层之间的转换失控。Intent 转成计划计划转成工具调用工具调用转成 API 参数API 参数转成真实执行真实执行转成现实结果现实结果又反过来反馈给 Agent触发下一步动作——每一次转换都是一个潜在的风险点。传统审批系统通常只看其中一段权限系统只看谁能发起日志系统只看发生之后的记录风控系统只看请求是否异常。但真正的执行安全必须贯穿整个转换链条尤其要守住最后一段即将发生的执行是否仍然忠于被允许的意图这就是Intent 不是 Execution这句话的核心意义。把这条链条拉长来看会发现每一次转换,都是把一种表达形式,翻译成另一种表达形式:自然语言翻译成结构化计划,结构化计划翻译成具体的工具调用,工具调用翻译成接口能够识别的参数。翻译这件事,天然存在信息损耗和歧义空间——就像人类语言之间的翻译一样,一句话在不同语言之间转换,含义很容易发生细微的偏移。AI 系统里的这条转换链条,同样存在这种偏移的可能只是它发生的速度太快、环节太多很难被人工逐一核对。执行控制层存在的意义正是在最后一次翻译完成、动作即将落地之前做一次逆向的核验把最终参数,重新翻译回最初的意图,看两者是否还能对得上。结语AI 时代Intent 会越来越多。人会越来越少点击按钮而是直接表达目标Agent 会越来越多地拆解任务、选择工具、调用接口业务系统会越来越多地把自然语言意图转化为真实的系统动作。这会带来巨大的生产力但也会带来一个新的安全问题我们是否还能分清楚用户想做什么、系统批准了什么、机器实际做了什么、现实最终发生了什么如果分不清所有的安全判断都会被压扁成一句话——系统显示通过。但这远远不够。Intent 不是 ExecutionApproval 不是 ExecutionExecution 也不天然等于安全的 Reality。AI 时代真正需要被重新设计的正是这些层之间的边界因为真正的风险往往不是出现在用户表达意图的那一刻而是出现在意图被系统解释、扩展、转化、调用并最终落地的整个过程中。这也是为什么仅仅追问这个 Agent 聪不聪明这次审批走没走完流程已经不足以回答 AI 时代的安全问题。更值得追问的是在 Intent 变成 Reality 的这条路上每一次转换有没有留下可以被独立核验的痕迹如果答案是没有那么无论前面几层看起来多么完美风险都已经在某个看不见的转换环节里悄悄埋下了。这也是本系列接下来要继续拆开的地方过去的系统为什么看起来更安全是因为人一直站在这些层之间充当了从未被写进制度、却始终在起作用的缓冲AI 真正的危险不是它会不会思考而是它有没有能力把一个想法变成现实世界里不可逆的结果Tool Calling 表面上只是改变了交互方式实际上悄悄改写了整套安全模型审批和真实执行之间那道被称为 Execution Gap 的缝隙究竟是怎么被打开又是怎么被利用的为什么静态的审批规则天生挡不住动态发生的执行风险为什么当执行系统和审批系统处在同一个信任域里软件往往管不住软件为什么真正的执行控制必须独立于 Intent、Approval 和 Execution 之外单独存在不可绕过、防篡改、可验证为什么是执行控制层不可退让的底线一个只能说不的系统为什么反而是最安全的设计以及把执行权真正关进笼子会成为 AI 时代新的安全常识。Intent 不是 Execution。意图不是现实请求不是动作通过不是发生。真正的安全边界必须站在它们之间。