一、先讲两个价值十亿美元的 " 等一下 "
2016 年 2 月 , 孟加拉国央行存放在纽约联储的账户 , 被发起了三十多笔转账指令 , 总额接近十亿美元。指令来自真实的 SWIFT 终端 , 使用真实的操作凭证 , 携带真实的授权码 , 走完了真实的流程。在系统眼中 , 这不是攻击 , 这是一个再正常不过的工作日。
最终阻止这场灾难继续蔓延的 , 不是防火墙 , 不是风控模型 , 也不是某套先进的安全架构 , 而是一个拼写错误。黑客在某笔转账的收款方名称里 , 把 "foundation" 错拼成了 "fandation"。中转行一位工作人员觉得不对劲 , 停下来 , 拿起电话核实了一下。就是这个 " 停下来 ", 拦住了后续八亿多美元的损失。即便如此 , 已经放行的八千一百万美元 , 绝大部分再也没有追回。
再看另一个故事。2012 年 8 月 1 日上午 , 美国做市商骑士资本 ( Knight Capital ) 的交易系统 , 因为一段被错误激活的旧代码 , 在四十五分钟内自动执行了数百万笔错误订单 , 亏掉约 4.4 亿美元。这家在华尔街做了十七年的公司 , 几天之内濒临倒闭。整个过程中没有黑客 , 没有内鬼 , 没有权限泄露 , 每一笔订单在系统看来都是合法的。系统唯一的问题是 : 它跑得太顺了 , 顺到没有任何一个环节来得及说一句 " 等一下 "。
这两个相隔四年的事故 , 行业不同 , 原因不同 , 却共享同一个结构 : 拦住灾难的 , 是摩擦 ; 放跑灾难的 , 是顺滑。
之所以在 2026 年重提这两个旧案 , 是因为一个新变量正在进入几乎所有企业的执行链条 :AI Agent。它带来的效率跃迁毋庸置疑 , 但它同时在做一件很少有人认真讨论的事——把企业里残存的 " 摩擦 ", 系统性地、彻底地、不可逆地拿走。
而很多企业还没有意识到 , 那些摩擦 , 恰恰是它们用了三十年的、免费的安全系统。
二、摩擦 : 企业免费用了三十年的安全系统
过去几年 , 围绕 AI 的讨论大多集中在两个方向 : 它能不能生成更好的内容 , 以及它会不会替代人的工作。但对企业经营者来说 , 一个更深层的问题正在浮现 : 当 AI 不再只是回答问题 , 而是开始替人调用工具、提交请求、操作账户、修改配置、触发流程时 , 企业原本依赖的一整套安全假设 , 会被改写。
要理解被改写的是什么 , 得先看清一个长期被误读的事实 : 在传统的企业系统里 , 高风险动作从来不是瞬间发生的。
一笔付款 , 要有人填单 , 有人复核 , 有人审批 , 有人再次确认 ; 一次生产环境变更 , 要有人写工单 , 有人看变更窗口 , 有人在群里确认影响范围 ; 一笔大额转账 , 可能需要插入 U 盾 , 或者在另一台设备上重新按一次确认键。在数字化的叙事里 , 这些环节有一个统一的名字 : 低效率。它们是流程优化的对象 , 是 OA 系统要压缩的节点 , 是每一轮 " 降本增效 " 都想干掉的东西。
但从安全的角度看 , 这些 " 麻烦 " 承担着一种从未被写进任何采购清单的功能 : 它们让高风险动作在真正发生之前 , 被迫慢下来。慢下来 , 人才有机会重新看一眼金额、对象、时间、上下文和后果。孟加拉央行事件里那个拼写错误之所以能拦住八亿美元 , 前提是有一个人被迫参与了过程 , 而且他有停下来打电话的余地。
这里有一个多数管理者不愿意承认、但值得写在墙上的判断 : 很多企业没出事 , 不是因为安全架构足够先进 , 而是因为流程足够麻烦。
麻烦制造了时间差 , 时间差制造了反悔的机会。人要走到另一个办公室找领导签字 , 要等第二天的变更窗口 , 要在群里 @三个人确认——这些动作在效率报表上全是负资产 , 在风险报表上却全是隐形的保险。只是这份保险从来不出现在任何财务科目里 , 所以也从来没有人为它的消失做过评估。
企业数字化的历史 , 在很大程度上就是一部消除摩擦的历史 : 审批在线化 , 操作自动化 , 数据打通 , 流程闭环 , 系统之间减少人工转交。每消除一分摩擦 , 企业就获得一分效率 , 同时悄悄注销一分从未入账的保险。三十年来 , 这笔交易整体是划算的 , 因为摩擦消除得足够慢 , 人始终还卡在关键步骤中间。
AI Agent 改变的 , 是速度和彻底程度。
三、AI Agent 不是更快的工具 , 而是更短的链路
必须先说清楚一点 :AI 本身并不危险 , 把 AI 描述成风险源头是对问题的误读。AI 的价值恰恰在于减少中间步骤 , 把人从重复操作中解放出来。它可以理解自然语言需求 , 生成操作方案 , 调用内部系统 , 填写表单 , 提交审批 , 触发后续任务 , 甚至跨多个工具完成一整条业务链路。
真正需要看清的是它带来的结构性变化。以往的每一代自动化工具 , 本质上都是在加速某一个环节 :ERP 加速了记账 ,RPA 加速了录入 , 工作流引擎加速了流转。环节与环节之间 , 依然靠人来跨越 , 人依然是链条上的关节。
AI Agent 不一样。它第一次有能力把多个原本分散的步骤连成一个连续动作 , 把 " 我想做某件事 " 直接翻译成 " 系统已经开始做这件事 "。它不是把某个环节做快了 , 而是把环节之间的缝隙抹掉了。过去由人手动跨越的那些间隙——也就是企业过去依赖的 " 人会慢下来 " 的安全缓冲——会随着链路的贯通被一起压缩掉。
这会带来三个被普遍低估的变化。
其一 , 错误动作的传播速度变快。骑士资本用四十五分钟亏掉 4.4 亿美元 , 已经让当年的华尔街不寒而栗 ; 而一个被授权调用付款、采购、运维接口的 AI Agent, 执行一条错误链路的时间以秒计。
其二 , 错误动作在流程中的阻力变小。过去一个错误请求可能会在某个环节被人发现——金额不对 , 对象不对 , 时间不对 , 环境不对。人之所以能发现 , 有时并不是因为他多专业 , 而是因为他被迫参与了过程。当 AI 替人整理信息、压缩上下文、生成摘要、给出 " 建议批准 " 时 , 审批体验变轻了 , 但审批人面对的不再是真实动作 , 而是 AI 对真实动作的解释。
其三 , 错误动作被包装成合理动作的能力变强。这是与以往所有自动化最大的不同 : 以前的系统只会忠实地执行错误 ,AI 却会流利地解释错误。一个能生成完美审批理由的系统 , 同样有能力为一个不该发生的动作 , 生成一份看起来无懈可击的说明。
于是问题浮出水面 : 当企业的执行链变得前所未有地顺滑 , 原来靠 " 麻烦 " 承担的最后阻断能力 , 由谁来承担 ?
四、最危险的缝隙 : 审批看到的 , 和执行发生的 , 不是同一件事
要回答这个问题 , 先要找到 AI 时代企业风险真正的藏身之处。它不在入口 , 而在一条很少有人审视的缝隙里 : 展示层、审批层和执行层之间的语义差异。
审批页面上显示的是 " 向合作方付款 ", 但真实执行里包含的是具体账户、金额、币种、备注和一长串调用参数 ; 审批摘要里写的是 " 导出客户数据用于审计 ", 但真实执行时涉及的是字段范围、时间窗口、接收对象和下载权限 ; 运维工单里写的是 " 重启服务 ", 但真实动作对应的是哪个集群、哪个节点、什么时间、是否绕过降级策略。
在人主导执行的年代 , 这条缝隙是收窄的 , 因为审批的人和执行的人往往离得不远 , 执行者自己会看一眼参数。当 AI 接管了 " 翻译 " 和 " 执行 ", 审批人看到的是摘要 , 系统执行的是参数 , 两者之间隔着一层由 AI 生成的解释。只要这层语义差异存在 , 一个残酷的结论就成立 : 审批通过 , 只能证明流程走完了 , 不能证明动作是对的。
用一个开车的比喻。绿灯全亮 , 并不等于车该开。绿灯表示交通规则允许你继续 , 但它不会替你判断路口有没有行人、地面是否结冰、你是否开错了方向。审批系统就是那组绿灯 : 它能证明流程有记录、权限有校验、规则有匹配、责任有归属 , 但它并不能天然证明最后那个动作 , 仍然符合最初的真实意图。
由此引出 AI 时代企业风险的新主角。企业安全过去最熟悉的叙事是防止非法访问 : 账号被盗、密钥泄露、权限绕过、系统被攻破。这些当然依然重要 , 但 AI Agent 会让另一类风险变得更突出——合法授权下的错误执行。
账号是真的 , 权限是真的 , 审批是真的 , 流程也是真的 , 但最后执行的动作是错的。它可能是被错误上下文诱导出来的 , 可能是被恶意指令污染出来的 , 可能是因为 AI 摘要漏掉了关键字段 , 也可能是因为云端管理层被攻破后 , 错误指令仍能一路畅通地推向执行。
这类风险最麻烦的地方在于 , 它不表现为异常 , 而表现为正常。每一层都能解释自己为什么放行 , 每一条日志都显示流程完整 , 每一个参与者都以为自己批准的是正确的动作。孟加拉央行事件正是如此 : 在长达数小时里 , 所有系统都认为一切正常 , 唯一觉得不正常的 , 是一个人。直到动作真正发生 , 企业才发现问题不在于缺少权限控制 , 而在于权限、审批、策略和执行 , 被放在了同一条过于顺滑的链路里。
最贵的事故 , 往往披着最合规的外衣。
五、从钥匙到门闩 : 企业安全的重心迁移
看清了风险的位置 , 解法的方向也就清楚了。
过去的企业安全体系 , 很大程度上是围绕 " 钥匙 " 展开的 : 谁能登录 , 谁能访问 , 谁能提交 , 谁能审批 , 谁能调用接口 , 谁拥有管理员权限。身份认证、访问控制、权限管理、终端防护、日志审计 , 整个产业的产品谱系 , 几乎都在回答同一个问题——谁可以靠近系统。
这些问题依然重要 , 但它们解决的是进入资格和发起资格。AI Agent 进入执行链之后 , 更关键的问题变成 : 一个动作从被提出到真正发生之间 , 是否还有一道独立的边界 , 能够判断它到底该不该发生。
换句话说 , 企业过去关注的是钥匙 , 未来必须重新关注门闩。
门闩并不是新发明。在线下世界里它一直存在 : 老板付款前多问的那一句 , 财务打去核实的那通电话 , 运维工程师执行前再看的那一眼生产环境 ,U 盾要求的物理插入 , 银行大额业务要求的双人临柜 , 核设施要求的双钥匙同时转动。这些机制不一定聪明 , 也谈不上高效 , 但它们有一个共同点 : 把 " 可以发起 " 和 " 真的执行 " 分开了。发起是一种资格 , 执行是另一种资格 , 两者之间隔着一道不归任何发起方管辖的边界。
钥匙决定谁能靠近 , 门闩决定什么能发生。AI Agent 并没有让钥匙失效 , 但它让 " 仅有钥匙 " 变得不够——因为当系统越来越自动、越来越连续、越来越善于把意图变成动作时 ," 最后那一下 " 变得比历史上任何时候都重要。
这里必须澄清一个容易产生的误解 : 重建门闩 , 不是让企业回到低效率 , 更不是反对自动化。真正的问题是 , 当 AI 把那些原来靠人承担的停顿拿走之后 , 企业有没有用新的工程结构把它补回来。过去的门闩是 " 人肉 " 的 , 靠角色分工和物理不便自然形成 ; 未来的门闩必须是工程化的 , 被有意识地设计、部署和验证。它不能再依赖 " 流程恰好麻烦 ", 而要依赖 " 结构刻意独立 "。
六、什么才算真正的门闩 : 四个不能妥协的条件
需要警惕的是 ," 门闩 " 很容易被做成一个安慰剂。再加一个弹窗 , 再加一个审批按钮 , 再在日志里多写一条记录——这些东西看起来像门闩 , 实际上只是给顺滑的链路又刷了一层 " 看起来安全 " 的漆。如果所谓的最后确认 , 仍然存在于同一个业务系统、同一个云端控制平面、同一个可以被远程修改的软件域里 , 那么攻破了这个域 , 就等于同时攻破了门和闩。
一道真正有价值的门闩 , 至少要满足四个条件。
第一 , 它必须把发起权和执行权分开。用户、AI、管理员、SaaS、审批系统 , 都可以发起请求或给出判断 , 但任何一方都不应该因为自己发起了、审批了、解释了 , 就天然拥有最终执行权。高风险动作的最后一步 , 必须被单独拿出来重新判断——就像银行柜员可以受理业务 , 但金库的门不归柜员开。
第二 , 它必须校验真实执行内容 , 而不是流程状态。流程状态只能告诉你 " 是否通过 ", 执行安全要看 " 到底执行什么 "。对象、金额、参数、时间、上下文、调用方式、目标环境——这些才是动作进入现实世界之前 , 真正需要被绑定和核对的内容。门闩看的必须是那笔转账本身 , 而不是那张写着 " 同意 " 的批条。
第三 , 它必须有拒绝能力。很多企业系统有日志、有提醒、有风险提示 , 但这些在关键时刻往往只是 " 建议 "。门闩的核心价值不是提醒系统小心 , 而是在必要的时候让动作真的过不去。一个只能记录、不能阻断的系统 , 是摄像头 , 不是门闩。摄像头能帮你复盘损失是怎么发生的 , 门闩才能让损失不发生。
第四 , 它不能和发起、审批、解释、执行处在同一个信任域。道理很朴素 : 如果攻击者或者被污染的上下文能够控制这个域 , 那么域内所有的规则、按钮、页面、日志和审批状态 , 都会一起变得不可靠。门闩之所以有意义 , 是因为它在结构上保留了一个不容易被同一套软件逻辑 " 说服 " 的位置。孟加拉央行事件里 , 那个位置碰巧是一个看到拼写错误的人 ; 在 AI 时代 , 这个位置不能再靠碰巧。
用这四个条件去检验市面上的方案 , 会过滤掉大部分噱头。这也是判断 "AI 安全 " 产品成色的一把尺子 : 它到底是在装饰流程 , 还是在重建边界。
七、停得住 , 才配跑得快
从商业角度看 , 这一切意味着企业安全的采购逻辑和建设重心 , 将发生一次迁移 : 从访问控制 , 走向执行控制。
访问控制回答 " 谁可以靠近系统 ", 执行控制回答 " 什么动作可以真正发生 "。前者的市场已经成熟 , 后者的市场刚刚被 AI Agent 撬开。当 AI 真正进入付款、运维、客服、法务、采购、数据、供应链这些执行链条 , 每一位 CEO 和 CIO 都会被迫回答一组过去不存在的问题 :AI 能不能直接调用高风险工具 ? 审批内容和执行参数是否一致 ? 云端策略被攻破时 , 本地执行还能不能拒绝 ? 管理员或者最高权限持有者 , 能否单点造成灾难性动作 ? 动作发生之后 , 企业能不能证明它是如何一步步穿过边界的 ?
回答不了这组问题的企业 , 并非不能拥抱 AI, 而是它拥抱的东西需要被重新命名——一个只加速执行、不重建阻断的组织 , 得到的不是更智能的企业 , 而是一条更顺滑的风险传送带。传送带的特点是 , 它不判断货物 , 只负责运输 ; 放上去的是订单 , 它运订单 , 放上去的是灾难 , 它运灾难 , 而且风雨无阻 , 效率极高。
这也提示了一个更大的判断 : 未来衡量企业自动化成熟度的标准 , 会从 " 能自动完成多少 " 变成 " 能证明在哪里停得住 "。就像高铁的竞争力从来不只是时速 , 而是那套让所有人敢坐上去的制动与信号系统 ; 就像资本市场愿意给券商的自动化交易定价 , 前提是熔断机制存在。速度创造收益 , 刹车创造信任 , 而信任才是企业敢把执行权交给机器的前提。停不住的自动化 , 企业不敢真用 ; 敢停的自动化 , 才敢全速。
回到最初的问题。AI 没有发明门闩 , 门闩一直存在——只是过去它藏在人手里 , 藏在签字、复核、U 盾、电话确认和那句 " 等一下 " 里 , 藏得太深 , 以至于企业从未把它当作一项资产来管理。现在 ,AI 正在把这些停顿从流程里一个一个拿掉。企业接下来要做的 , 不是怀念低效率 , 而是把那些曾经由低效率默默承担的安全功能 , 重新工程化为独立的执行边界。
这才是 AI Agent 时代真正值得讨论的基础设施问题 , 它可以被压缩成一句话 :
当系统越来越擅长开始 , 谁来保证它在不该继续的时候 , 真的停得下来。
孟加拉央行的那个拼写错误 , 不会再有第二次了。AI 不会拼错单词。下一次 , 能拦住那八亿美元的 , 只能是企业亲手装回去的那道门闩。
