过去二十年，软件安全最习惯问的问题是：谁有权限？
谁能登录，谁能审批，谁能调用接口，谁能修改配置，谁能拿到管理员账号。整个权限体系因此越来越复杂，RBAC、ABAC、多因素认证、多签、审批流、策略引擎，一层层叠加起来，试图把“谁可以做什么”描述得足够精确。
但当 AI 开始从“提供建议”走向“替人行动”，这个问题已经不够了。
AI Agent 可以发邮件、调用 API、修改生产配置、执行交易，也可以进入设备控制、工业系统和企业自动化流程。软件第一次大规模获得了过去主要属于人的一种能力：不仅处理信息，而且能够推动现实发生变化。
这时，一个更底层的问题浮了出来：
一个人被允许做什么，和他实际上能让什么发生，并不是同一件事。
这也是我们近期发表在 arXiv Cryptography and Security（cs.CR）的论文Who Can Make the Action Happen? An Authority-Decomposition Framework for High-Risk Automated Systems想回答的问题。它讨论的不是某个具体漏洞，而是一个更基础的判断：在一个由人、AI、SaaS、密钥、策略系统、硬件和执行器共同组成的系统里，真正的权力究竟在哪里？
一、权限描述的是制度，执行权描述的才是现实
假设一家公司的支付系统里，员工提出付款申请，主管审批，财务系统生成付款指令，最后银行接口完成转账。从组织流程上看，主管有批准权；从软件系统上看，财务系统拥有 API 权限；从密码学上看，某个服务持有签名凭据。
那么，到底是谁让钱真正转出去了？
这个问题并不像表面上那么简单。主管批准了，但他自己未必能转账；财务系统能够生成指令，却可能还需要另一份签名；银行真正改变了账户余额，但它只是接受了前面一整组条件满足之后的请求。过去，我们习惯把这些不同能力统称为“权限”，可它们实际上对应着完全不同的权力：提出、批准、签署、否决、改变规则，以及最终让状态发生变化。
当软件只是帮助人处理信息时，这种混淆未必会立刻造成问题。但当 AI Agent 能够独立规划任务、连续调用工具并触发现实动作之后，我们就必须重新区分这些概念。
权限告诉我们谁被允许做什么，执行权告诉我们谁真的能让事情发生。
这两者之间的距离，正是未来很多自动化系统风险真正产生的地方。
二、批准通过，不等于事情应该发生
传统安全系统往往把大量精力放在动作发生之前：身份是不是可信，审批是不是完整，策略是不是通过，操作是不是由合法账号发起。于是只要审批链条走完，我们很容易产生一种感觉：安全问题已经解决了。
但审批只是组织意义上的同意，执行却意味着现实状态已经发生改变。
一笔钱被转走，一扇门被打开，一台设备被重启，一组生产配置被修改，这些结果一旦发生，就不再只是信息层面的“决定”。它们进入了现实。
因此，高风险系统真正需要问的，不只是“谁批准了”，而是：
最少控制哪些人、哪些系统和哪些设备，就足以让这个动作发生？
如果一个系统表面上需要三方共同参与，但只要拿下一名云管理员，就可以修改策略、替换证书、重新配置执行链，那么所谓“三方治理”只是流程上的三方，真实权力仍然集中在一个地方。
这也是论文里一个非常重要的思想：不要只数有多少人参与，而要反过来推导，究竟哪些最小组合已经足以导致结果发生。
换句话说：
流程图画的是制度，最小执行联盟暴露的才是权力。
一个系统真正是否分权，并不取决于界面上有几个确认按钮，而取决于有没有任何单一主体能够最终让其他约束失效。
三、真正危险的权力，往往藏在“正常流程”之外
系统设计最容易犯的一个错误，是只分析正常运行时会发生什么。
架构图通常画得很漂亮：请求经过审批，审批进入策略引擎，策略验证通过，再由执行器完成动作。每一个步骤都清楚、可控，甚至还有完整日志。可真实系统从来不只有业务流程。
它还有升级、恢复、重置、证书替换、紧急模式、策略修改、管理员覆盖、设备初始化，以及各种“出问题以后怎么办”的维护机制。
这些机制本身通常完全合理。任何成熟系统都需要恢复和运维能力。但问题在于，恢复能力也是权力，升级能力也是权力，改变规则的能力更是权力。
假设一个硬件执行设备规定，所有付款都必须得到两份独立授权。正常情况下，这当然很安全。但如果某个云端管理员可以单独修改设备所接受的策略，那么真正需要问的就不是“当前付款需要几个人批准”，而是“谁有能力把两个人改成一个人”。
谁能重新签发设备信任的证书？谁可以升级固件？谁能进入恢复模式？谁能重新定义边界的行为？这些权限可能极少被使用，却决定了系统真正的权力归属。
一个系统真正的权力，不只属于今天能执行的人，也属于能够改变明天执行规则的人。
这也是为什么很多看起来高度分权的系统，深入分析之后仍然可能发现一个超级管理员、一个恢复账户或者一个生命周期控制面，最终重新把权力收拢在了一起。
四、有一道安全边界，不代表它真的独立
今天几乎每一个高安全系统都会谈“边界”。HSM 是边界，安全芯片是边界，可信执行环境是边界，独立审批服务也可以被称为边界。
但一个组件位于执行链上，不代表它天然就是独立的。
真正的问题是：边界之外的人，能不能单独改变它最后会作出什么决定。
假设所有高风险请求最终都必须经过一个硬件设备，看起来这已经形成了最后一道控制。但如果云端可以修改它接受的规则，可以重置它的信任关系，可以关闭它，甚至可以绕过它，那么“所有请求都经过这里”并没有自动产生真正的安全性。
真正有价值的边界，必须保留一种上游无法单独夺走的能力：
说“不”。
即使请求合法，即使审批已经通过，即使 SaaS 认为没有问题，一个独立边界仍然应该有能力根据自己的状态、规则和证据拒绝执行。
因此，我们可能需要重新理解所谓安全边界。
真正的安全边界，不是所有请求必须经过哪里，而是谁无法单独改变结果。
这句话看起来简单，却意味着安全设计的重心发生了变化。我们不再只看组件摆在哪里，而开始关心它是否真正拥有独立权力。
五、能让事情发生是一种权力，能解释发生了什么是另一种
还有一种经常被忽略的权力，并不直接参与执行，却决定了我们之后如何理解一次执行。
那就是证据。
今天几乎所有系统都有日志。谁登录了，谁提交了请求，审批结果是什么，哪个接口被调用，执行是否成功，全部可以被记录下来。于是我们很容易认为，只要日志足够完整，事实就已经被保存下来。
但日志首先是系统自己的叙述。
如果一个系统既能执行动作，又能够修改所有相关记录，那么一旦它失陷，我们面对的就不仅是“现实被改变”，还可能是“关于现实的叙述也被改变”。
这就是为什么执行权和证据权最好分开来看。
一个系统可以没有能力阻止一笔转账，却能够独立证明转账发生时哪些条件满足、哪些设备参与、哪些规则被使用；另一个设备可能拥有最终否决权，却并不负责保存完整业务上下文。两者处理的是不同问题。
前者回答：
谁能让事情发生？
后者回答：
我们凭什么相信事情确实以这种方式发生过？
能改变现实是一种权力，能定义现实如何被记录，也是一种权力。
这在 AI 时代会变得越来越重要。机器执行速度会远远超过人类观察速度，我们不可能再期待所有高风险动作都有人盯着屏幕确认。越来越多时候，人类只会在事后面对结果。
如果这时唯一的证据仍然来自执行系统自身，那么所谓审计很可能只是系统的一次自我陈述。
如果一个人既能改变现实，又能改写记录，那么日志只是他的叙述。
六、AI 时代真正需要重新设计的，是权力结构
这篇论文最终想讨论的，并不是某个具体产品是不是安全。Havenlon 在论文中只是一个被分析的实例，真正重要的是一种重新观察系统的方法。
不要只从职位出发，不要只从账号出发，也不要只看谁在流程上点了“同意”。应该从一个具体动作反向追问：谁能提出它，谁能批准它，谁能否决它，谁能执行它，谁可以修改这些规则，谁可以绕过这些规则，又是谁负责独立证明最终发生了什么。
当这些问题被拆开以后，一个系统真正的权力结构才会显现出来。
过去的软件主要帮助人处理信息，人仍然是最后行动者。今天的软件正在获得越来越多代表人行动的能力。AI Agent 可以连续调用工具，可以跨越多个系统，可以在没有人实时观察的情况下完成一整条任务链。
因此，AI 带来的最大安全变化，可能并不是“机器比过去更聪明”。
而是：
AI 时代最危险的变化，不是机器开始思考，而是机器开始拥有让现实发生变化的能力。
当软件只有建议权时，错误的代价通常还是人类做错决定；当软件拥有执行权时，错误可以直接变成现实。
这时，我们就不能再满足于“给 AI 配一组权限”“再加一道审批”“多做一些日志”。真正需要重新设计的，是整个系统里的权力结构：谁拥有行动能力，谁拥有最终否决权，谁能够修改规则，又有没有任何一个主体强大到可以同时控制所有这些东西。
过去安全系统一直在试图找到更可信的人、更可信的软件、更可信的硬件。
未来也许更重要的是另一件事：
安全不是找到一个绝对可信的人，而是让任何一个可信的人，都无法成为唯一答案。
当 AI 真正进入支付、工业、医疗、云运维和更多现实执行场景时，我们最终需要保护的，可能不只是系统“把事情做成”的能力。
还包括另一种看起来消极、实际上非常宝贵的能力：
在所有人都说“可以”的时候，系统里仍然有人有资格说“不”。
本文讨论的研究来自：
Who Can Make the Action Happen? An Authority-Decomposition Framework for High-Risk Automated SystemsarXiv:2608.18965 Cryptography and Security（cs.CR）
