——当软件开始替人做决定，谁握住最后的否决权？

Agent 时代最危险的错误，不是系统被攻破，而是一个完全合法的请求，做成了一件不该发生的事。

2026 年，AI Agent 已经不再是演示视频里的概念。它在读你的邮件、改你的配置、部署你的服务、清理你的云资源。从 OpenAI 的 Operator 到 Anthropic 的 Computer Use，从各家云厂商的运维 Agent 到企业内部自建的自动化助手，软件行业正在经历一次底层范式的迁移：软件从"等待命令"，转向"理解目标并自行行动"。

这场迁移的商业叙事非常诱人——把人从重复劳动中解放出来，让一句话变成一整套执行。但在效率叙事的背面，一个结构性的安全问题正在被迅速放大，而绝大多数企业的安全体系，对它几乎没有防备。

这个问题叫做执行缝隙（Execution Gap）：用户表达的意图，与系统最终执行的结果之间，那段越来越长、越来越复杂、也越来越难以察觉的距离。

---

一、传统软件的执行链很短，短到我们从未认真管理过它

回想传统软件的交互模型：用户点击"删除文件"，系统删除文件；用户点击"提交订单"，系统创建订单；用户点击"转账"，系统发起交易。

这条链路可以概括为：用户输入 → 系统处理 → 单次执行。

它并非绝对安全——界面欺骗、参数篡改、越权漏洞都真实存在——但它有一个被我们长期低估的优点：执行语义是确定的。按钮背后绑定的是一个写死的接口，用户大致知道自己在触发什么，开发者大致知道系统会做什么。意图和执行之间的翻译工作，在软件发布之前就由工程师完成了。

AI Agent 彻底改变了这个前提。用户可能只说一句：

"帮我清理一下这个项目。"

Agent 需要自己判断：哪些文件是无用的、哪些服务可以停、哪些资源可以释放、要不要留备份、要不要通知同事、能不能直接动手。用户给出的是一个模糊目标，系统最终完成的可能是几十个具体动作。执行路径变成了：

用户意图 → Agent 理解 → 任务拆解 → 工具选择 → 参数生成 → 多步调用 → 真实执行

意图到执行之间的翻译工作，从"发布前由工程师完成"变成了"运行时由模型即时完成"。每一个箭头，都是一次重新解释；每一次解释，都是一次偏移的可能。

传统软件的执行语义在编译期就已确定，Agent 的执行语义在运行时才被发明出来。

这是理解 Agent 安全问题的第一把钥匙：风险不在于某个漏洞，而在于执行语义本身变成了动态生成物。

---

二、Agent 放大的不是错误本身，而是错误的爆炸半径

传统软件出错，错误通常是单点的：一个按钮调错了接口，一个参数传错了值，一个权限判断有漏洞。定位、修复、复盘，安全工程有一整套成熟方法论。

Agent 的错误则是链式的。它可能先误解目标，基于误解生成计划，再基于错误计划连续调用多个工具——它不是执行错一个动作，而是建立起一整条逻辑自洽的错误执行链。

举一个运维场景。用户说："把测试环境里过期的实例清理掉。"

Agent 可能读错了环境标签（test 与 staging 只差一个字段），可能拉取了不完整的资源清单，也可能把"过期"自作主张地解释为"超过七天未使用"。随后它一气呵成地完成：查询实例、筛选目标、停止服务、删除存储、更新 CMDB、向频道发送"清理完成"的通知。

注意这条链的可怕之处：如果第一步判断错了，后面每一步都可能完全合法。每一次 API 调用都有有效令牌，每一次权限检查都通过，每一条审计日志都完整规范。从任何一个单点看，系统运转正常；从结果看，生产资源没了。

Agent 最危险的失败模式，是用高度正确的技术过程，完成一个根本错误的现实结果。

安全行业有一个词叫爆炸半径（blast radius）。传统软件的爆炸半径由架构决定，是静态的；Agent 的爆炸半径由它当下的推理决定，是动态的。这意味着你无法在设计阶段完整预估一个 Agent 的最坏情况——它的最坏情况，取决于它某一次具体的"想法"。

对企业管理者来说，这直接改变了风险模型的形状：过去的 IT 风险是"低频、单点、可定位"，Agent 时代的执行风险是"低频、链式、事后才可见"。前者可以靠修复对冲，后者必须靠事前拦截。

---

三、"确认一次"正在悄悄变成"授权一串未知动作"

传统软件的确认机制之所以有效，是因为确认对象是一个确定的操作——你点"确认转账"，转的就是屏幕上那笔钱。

Agent 场景下，用户确认的往往只是目标，而不是动作。用户说"帮我部署这个应用"，这句话没有说明：是否允许改防火墙规则、是否允许开公网入口、是否允许重置数据库、是否允许覆盖旧版本、是否允许写入密钥、是否允许把数据发给第三方服务。但 Agent 完全可能认为，这些都是达成目标的必要步骤。

于是授权的语义发生了坍塌：过去用户确认的是一个动作，现在用户确认的只是一个方向。而方向与具体执行之间，存在巨大的解释空间——这个空间由模型填充，而模型的填充方式，用户既看不见，也没批准过。

安全领域有一个经典问题叫"混淆代理人"（Confused Deputy）：一个拥有合法权限的程序，被诱导用自己的权限做了委托者没有授意的事。Agent 是混淆代理人问题的终极形态——它不需要被攻击者诱导，它自己的误解就足以扮演攻击者的角色。再叠加提示词注入（Prompt Injection）这类新型攻击面——一封邮件、一个网页里藏的指令就可能改写 Agent 的行动计划——授权失控的路径只会更多。

在 Agent 系统里，"用户已经同意"推导不出"所有后续动作都被授权"，正如"方向正确"推导不出"每一步都合理"。

---

四、概率性的判断，正在被固化成确定性的现实

大模型的输出本质上是概率性的。它会理解错误、遗漏上下文、对模糊指令过度推断、在信息不足时编造一个看似合理的方案。这不是缺陷清单，这是这类技术的性质。

当 AI 只负责生成文本时，这种不确定性停留在信息层：错了可以改、可以删、可以无视，成本近乎为零。但当 Agent 开始调用工具，不确定性会在执行链上被逐级固化为确定性：

• 一个错误判断，变成一条数据库 UPDATE；

• 一个错误推断，变成一次 IAM 权限变更；

• 一个错误计划，变成一组已经无法回滚的删除操作。

模型可以说"我认为应该这样做"，但基础设施接收到的从来不是"认为"——它接收到的是一条格式完全合法的 API 请求。API 网关不理解犹豫，数据库不理解概率。

AI 说的是"我认为"，基础设施听到的是"执行"。执行链是一台把概率翻译成事实的机器。

从商业视角看，这正是当前企业 Agent 落地的真实瓶颈。各类企业调研反复指向同一个结论：阻碍 Agent 进入核心业务流程的第一因素不是模型能力，而是信任——财务系统、生产环境、客户数据，没有 CIO 敢把一个"概率正确"的系统直接接上"确定性后果"的管道。谁能解决概率与确定性之间的转换安全，谁就握住了 Agent 商业化的闸门。

---

五、单个工具的权限都合理，组合起来就是一条完整攻击链

一个真正有用的 Agent 不会只接一个工具。借助 MCP（Model Context Protocol）这类协议，接入邮件、文件系统、云平台、数据库、代码仓库、协作工具、财务系统、身份权限系统，已经是标准配置。

问题在于：权限的审计是按工具进行的，而能力的形成是按组合发生的。

单独拥有"读取邮件"的权限，风险有限；单独拥有"创建云资源"的权限，也大体可控。但当一个 Agent 同时可以：从邮件中读取部署指令、从代码仓库拉取项目、从密钥系统读取凭据、在云平台创建资源、修改 DNS、向团队发送完成通知——它已经拥有了一条从"外部输入"直达"生产变更"的完整执行链。任何一环被污染（比如那封邮件是攻击者发的），整条链就成了攻击者的自动化武器。

传统权限模型回答的问题是："这个身份是否有权调用这个接口？"它从不回答："这些接口被连续组合之后，会形成什么现实后果？"

权限是按接口发放的，风险是按组合爆发的——这是最小权限原则在 Agent 时代的失效方式。

而跨系统组合恰恰是 Agent 最擅长、也最被看重的能力。换句话说，Agent 的核心卖点和核心风险，是同一个东西。这也解释了为什么单纯给工具"降权"走不通：把组合能力砍掉，Agent 就退化成了聊天机器人；保留组合能力，就必须在组合的出口处设防。

---

六、Agent 的速度，让"人工复核"从流程变成了摆设

传统自动化（如 CI/CD 流水线）虽然也连续执行，但流程是人预先编写、评审、固化的。Agent 的不同在于流程本身是动态生成的：它根据环境临时调整计划、更换工具、重排顺序。

这使执行不仅更长，而且更快。人在几秒前批准的目标，几秒后已被拆解成数十个操作。当运维看到日志时，执行早已结束；当安全团队开始调查时，资源已经删除；当负责人发现异常时，错误权限已经传播到多个系统。

于是一个尴尬的现实出现了：企业花重金建设的审计体系，在 Agent 面前只剩下"事后叙事"的功能。日志能回答"系统做了什么"，却无法在关键时刻回答"这件事是否应该继续发生"。

审计是给已经发生的事故写传记，而 Agent 时代真正稀缺的，是在偏离发生时还能踩下去的刹车。

这里有一个容易被误解的地方：答案不是"让人审批每一步"。如果每个动作都要人点头，Agent 的效率优势将荡然无存，业务部门会用脚投票绕过安全部门——这是过去二十年安全与效率博弈中反复上演的剧本。真正的解法是分级：让低风险动作全速通过，让高风险、不可逆、越出授权范围的动作自动触发拦截或降级。刹车的意义从来不是让车开不快，而是让车敢开快。

---

七、身份安全回答"你是谁"，回答不了"这件事该不该做"

目前多数 Agent 系统采用一种简单思路：用户先授权 Agent 一个权限范围，之后 Agent 在范围内自主工作。低风险场景下这没问题，但在高风险执行中，它内嵌了一个危险假设：只要 Agent 的身份可信，它发起的动作就可信。

这个假设在四种情况下同时失效：Agent 没有被攻击，也可能理解错误；模型没有失控，也可能选错工具；用户没有被冒充，也可能表达含糊；系统权限完全合法，也可能产生错误执行。

过去二十年，企业安全的主战场是身份——从防火墙到零信任（Zero Trust），核心命题始终是"谁能进入系统"。零信任的口号是"永不信任，持续验证"，但它验证的对象是身份和设备，不是判断和后果。身份认证能回答"是谁发起了请求"，却无法回答"这个请求是否仍然符合用户最初的真实意图"，更无法回答"在当前系统状态下，这个动作是否仍然应该执行"。

零信任解决了"别让坏人进来"，Agent 时代的新命题是"别让好人（和好 Agent）做错事"。

这是身份安全与执行安全的边界，也是一块几乎空白的市场。安全产业的每一轮范式迁移都催生了新的平台级公司：网络边界时代成就了防火墙厂商，身份时代成就了 Okta 与零信任阵营，云时代成就了 CSPM 与 Wiz。当执行本身成为新的风险面，执行安全（Execution Security）大概率是下一个位置。

---

八、真正需要保护的，是意图进入现实之前的最后一毫米

必须承认一个方向性判断：Agent 的演进不会是减少执行，而是获得越来越多的执行能力。它会更快、工具更多、自动化更深、自主决策范围更大。因此，"要求 Agent 永远不犯错"不是一个工程目标，而是一种幻想——任何依赖 Agent 自我判断的安全机制，都等于让被监管者兼任监管者。

更现实的目标是：即使 Agent 理解错误、即使任务拆解出现偏差、即使上层系统生成了合法但危险的请求，系统仍然存在一道独立于 Agent 的边界，能够在真实执行前重新判断。

这道边界不应该只检查签名、身份和请求格式。在动作落地前的最后一毫米，它需要重新核对的是另一组问题：执行对象是否正确？执行范围是否超出授权？当前系统状态是否允许？关键参数是否在计划批准后被改动过？这个动作是否不可逆？是否应该降级进入 Safe Mode（改为 dry-run、留存快照、要求二次确认）？还是应该直接拒绝？

用工程语言说，这是一个部署在 Agent 与真实世界之间的策略执行点（Policy Enforcement Point）：Agent 负责规划，边界负责否决；Agent 可以聪明，边界必须固执。这也是 Havenlon 所关注的问题——它不试图让 AI 永远正确，也不试图替代 Agent 的规划能力，它只回答一件事：当 AI 的意图即将进入现实世界时，是否还存在一层不依赖 Agent 自我判断的执行边界。

不要试图造一个不会犯错的大脑，要造一只在错误落地前能按住它的手。

---

九、Agent 越强，Final Veto 越值钱

把时间轴拉长看这件事。

过去，软件能力有限，一次错误通常只影响一个页面、一个账户、一个流程。未来，Agent 将跨越多个系统完成完整任务：它越强，错误传播越快；它越自主，人类介入的窗口越窄；它越接近现实执行，最后一层边界的价值就越高。

这里存在一个反直觉的商业逻辑：执行控制不是自动化的对立面，而是自动化的放大器。汽车工业的历史早已验证过同样的规律——不是引擎的进步让车越开越快，而是刹车、安全带和 ABS 的进步，让人敢把引擎的进步用满。对企业而言，一个带独立否决层的 Agent，才是敢接入生产系统、财务流程和客户数据的 Agent；对 Agent 厂商而言，可被约束的执行能力，才是可被采购的执行能力。

刹车不是用来让车变慢的，是用来让人敢踩油门的。Final Veto 不是用来阻止自动化的，是用来让自动化被真正采用的。

所以，Agent 能力越强，越需要独立于 Agent 的最后否决权（Final Veto）——不是为了阻止自动化，而是为了让自动化在真正失控之前，永远保留一个可以说"不"的地方。

---

结语：从"谁能进入系统"到"谁能让它停下"

AI Agent 放大的，不只是效率。它同时放大了意图与结果之间的距离、工具组合的能力、错误传播的速度，以及一次授权所覆盖的未知范围。

这不意味着 Agent 不该被使用，而意味着我们不能继续用传统软件时代的安全假设来管理它。过去，安全的核心问题是：谁能够进入系统？未来，安全还必须回答一个更难的问题：

当一个被授权的 Agent 准备执行一个技术上合法、流程上完整、但现实中不应该发生的动作时——谁能够真正让它停下来？

这也许才是 AI Agent 时代最重要的执行问题，也是下一代安全基础设施真正的起点。

---