当执行不再经过人那个一直被人顺手保管的权力就必须被专门交给一层独立的边界。引子过去二十年我们默认一个系统的安全靠的是把关卡设在决策上谁有权限、谁审批、风控给不给过。这套逻辑在人点按钮的年代是成立的。但 AI 与 Agent 把执行从人手里接了过去之后它开始出现一个结构性的漏洞——决策处的把关不再等于执行处的把关。要修补这个漏洞靠的不是再加一道审批也不是更聪明的风控而是一件更底层的事把执行权从各个业务系统里单独抽出来交给一层独立的边界去管。本文想论证的就是这一点——不是这样做更好而是不这样做就没有真正的控制。一、先把执行权定义清楚先做一个不能含糊的区分否则后面全是空话。面对一个高风险动作其实有三种彼此独立的权力决策权审批判断该不该做。它产出的是一个同意或不同意的意见。评估权风控判断危不危险。它产出的是一个风险高低的评分。执行权让这个动作真的发生在现实世界里——钱真的打出去、权限真的改掉、数据真的导出、设备真的动作。它产出的是一个不可逆的现实结果。前两者都停在关于这件事的判断上只有第三者改变现实。执行权是唯一一个直接触碰现实的权力因此也是唯一一个一旦失控就无法用其实我们判断得很对来挽回的权力。钱打错了账户审批记录再完整也追不回来。本文所有论证都围绕这一个东西谁在什么条件下有资格让现实真的被改变。二、在人的时代执行权不需要独立——因为它一直绑在人身上一个自然的问题是既然执行权这么关键为什么过去几十年我们几乎从不单独讨论它因为在传统链路里它被隐式地绑在了执行动作的那个人身上人发起 → 人审批 →人执行审批完是一个具体的人去点那个确认打款的按钮。决策者和执行者要么是同一个人要么是紧挨着的两个人。于是在审批处把关几乎自动等于在执行处把关——因为中间没有第三方被批准的那件事和被执行的那件事是同一个人捏在手里的同一件事。这套绑定之所以安全靠的是人执行动作时天然具备的三个属性慢且串行人一次只能做一件事点一次按钮要几秒。这给了监督和喊停留出了时间窗口。可见人的动作是一个离散、可观察的事件——有人在某时点了某个键。可归因动作背后是一个确定的、要负责任的人。正是这三个属性让决策能顺理成章地代管执行。执行权不需要被单独拎出来因为它从来没有真正离开过那个负责任、动作慢、看得见的人。三、AI 抽走了那个人三个前提同时崩塌AI 与 Agent 做的事本质上是把执行路径上的那个人抽走换成自动化AI 发起 → AI 决策 →AI 直接执行一旦那个人不在了上一节赖以成立的三个属性同时失效快且并行Agent 一秒可以发起成百上千个动作在任何人反应过来之前就完成。喊停的时间窗口消失了。不可见 / 运行时生成真正的执行路径不是事先写死的而是模型在运行时根据上下文动态生成的——查库、调第三方 API、改权限、触发 webhook、通知外部系统这几步审批当初根本没见过。不可归因 / 分散多个 Agent 协作一次动作横跨 AWS、Stripe、GitHub、Notion、Slack……真正动手的那一环可能完全不在任何单一系统的视野里也找不到一个确定的责任人。这里要说清楚一个容易被忽略的推论执行权并没有因为人走了而消失。它只是从那个负责任的人手里掉进了谁最终触发了动作的那个组件手里——可能是一个被污染输入诱导的 Agent可能是一个运行时才拼出来的调用可能是一条跨系统的链。执行权变成了一份无人显式看管、分散在系统各处的隐式权力。一份没人专门看管的、能直接改变现实的权力——这就是问题的全部根源。四、一个真实的代价骑士资本的 45 分钟有人会说这是危言耸听。那么看一个真实发生过、且经得起推敲的案例。它甚至还不是 AI只是自动化——但结构上一模一样。2012 年 8 月 1 日美国做市商骑士资本Knight Capital部署了一套新交易软件用于接入纽交所的一个新项目。部署时一段本该废弃、已在系统里休眠多年的旧代码内部代号 Power Peg被一个被重新启用的开关意外激活而且新代码只推到了 8 台服务器中的 7 台第 8 台仍带着这段致命的旧逻辑。市场一开盘这台服务器就开始疯狂下单。它的路由系统会把母订单拆成很多子订单发往交易所但因为没有正确识别订单已经成交它不停地为同一批母订单继续生成新的子订单——形成一个自我放大的循环。约 45 分钟里系统产生了约 400 万笔成交涉及 154 只股票、约 3.97 亿股亏损约4.4 亿美元几乎等于公司当时的全部身家。这家 17 年的公司就此被拖垮最终被收购。现在做严谨的归因。骑士资本失败的地方全都在决策层代码测试没做到位、版本部署出错、变更管理有漏洞。这些确实都该改进。但真正让灾难无法被遏制的是另一件事在动作真的打向市场的那一端没有任何一个独立的东西能够不管交易算法想做什么都强行把它拦下来。系统没有 kill switch出事后甚至因为把坏代码错误地推到了全部服务器而使情况更糟。执行权完全掌握在那个已经出错的自动化系统自己手里没有人在它之外看管。这个案例的价值在于它给出的教训不是我的一家之言。事后美国证监会依据《市场准入规则》(Rule 15c3-5) 对骑士资本追责——而这条规则的核心要求正是任何有市场准入的机构都必须在订单进入市场之前设置独立的、不能被交易系统本身绕过的风险控制专门拦住超限或异常的订单。换句话说监管机构在血的教训之后得出的结论恰恰就是本文的论点你不能让做决策的系统自己管住自己的执行必须在执行那一端架一层独立的、不可绕过的闸。骑士资本的问题在 2012 年只是少数高频交易公司的问题而 AI 正在把同样的结构——自动化握着执行权、却无人独立看管——推广给每一个用 Agent 做业务的人。五、为什么再加一层审批 / 更强风控补不上这道缝最常见的反应是那就在决策层再加把关呗多一道审批、上一套更聪明的风控。这解决不了问题原因是纯逻辑上的。设想一个更细的场景给 A 公司退款 10 万。审批批了✔风控也判为低风险✔。但在钱真正打出去之前中间某一环——一个被诱导的 Agent、一个被篡改的调用——把收款方从 A 改成了 B。事后审批说我批过风控说没风险而现实是钱打给了错的人。关键在于审批系统在批准的那一刻T1就完成了它的全部职责它盖章的是 T1 时刻那个退给 A的请求。而执行发生在 T2。审批系统没有、也不可能保证 T1 被批准的对象和 T2 被执行的对象是同一个——因为它的职责在 T1 就结束了T1 到 T2 之间的那道缝根本不在它的管辖范围内。这在工程上叫检查时到使用时的间隙检查的是 A执行的是 B。这道缝的位置很要命它在决策之后、在系统之间、沿着运行时才生成的路径展开。而审批和风控按定义都站在决策的那一侧。一个活在决策层的关卡无论做得多强都够不到决策之后才发生的现实。你在决策层叠得再厚也是在缝的这一边加固缝的那一边照样没人管。所以补丁不能加在决策层。它必须加在别的地方。六、真正的控制有三个硬条件而这三个条件逼出了独立那么什么样的东西才算真正管住了执行这不是拍脑袋安全领域早有成熟的答案。一个能被称为控制的把关点经典概念叫 reference monitor可信参照监视器必须同时满足三个条件不可绕过任何一次执行都必须经过它没有任何一条旁路能跳过它直接落地。防篡改它自身必须与它所管辖的系统相互隔离不能被它管的那个系统改写或关掉。可验证它必须足够小、足够简单简单到能够被完整地检查和信任。现在把这三个条件和把关点嵌在业务系统内部放在一起看会发现它们直接冲突如果把关点和 Agent、App、SaaS 跑在同一个系统里那么谁攻破了这个系统谁就同时拿到了把关点——违反防篡改。如果把关逻辑就是业务代码的一部分那么运行时动态生成的新路径可以绕开它另开一条道——违反不可绕过。一个和庞大业务系统缠在一起的把关点本身就大到无法被单独验证——违反可验证。结论是被逼出来的不是被选出来的要同时满足这三个条件把关点就必须从它所管的系统里独立出去成为一个单独的、隔离的、最小化的层。这正是执行权必须独立的真正含义——不是组织架构上的独立而是结构上的独立管执行的那一层不能是发起执行的那个系统的一部分。七、几个必须正面回答的反驳一个严谨的主张要经得起反问。把 AI 做得更安全、更对齐不就行了——不行而且骑士资本恰好证明了这一点。那套系统没有任何恶意只是一个开关 bug。让做决策的一方更可信替代不了在执行端独立把关因为再可信的决策者也会遇到被污染的输入、没覆盖到的异常和纯粹的代码错误。安全的决策者 ≠ 一道独立的执行闸。独立出来它自己不就成了新的单点风险——不会因为它的权力被刻意做成了不对称的它只能否决或放行执行不能发起决策、不能替你做业务。一个只能说不的组件被攻破后最坏的后果是该做的没做保守、可补救而绝不会是不该做的做了灾难、不可逆。它的故障方向天然是安全的。加上它被刻意做得足够小、可验证它比它所保护的那个庞大系统可信得多。这会不会把一切都拖慢——不会因为它只在高风险、不可逆的动作前收紧。低风险动作照常自动放行中风险动作按条件放行只有真正会改变现实且收不回的那一小部分才必须过这道闸。它约束的不是效率是灾难。八、结论把整条逻辑收束成一句话在人的时代现实能不能被改变这份权力被顺手托付给了链条末端那个动作慢、看得见、要负责的人而 AI 把这个人抽走了这份权力于是散落成一份无人看管的隐式权力。要重新管住它唯一结构上成立的办法是把它单独抽出来交给一层独立、不可绕过、只能否决的执行边界。这一层不和审批、风控抢地盘。审批判断该不该做风控评估危不危险而它只回答最后那个谁都没在管的问题这件事能不能在正确的条件下真的发生。这也正是 Havenlon 所占据的位置——它不是更强的审批也不是更强的风控而是 AI 时代那层被抽走、又必须被重新架起来的执行控制层不管你批不批准只管这件事有没有在正确条件下真的发生。