权限的终点不是执行重新理解 AI 时代的控制权现代软件安全在过去几十年里建立起了一套非常成熟的秩序先确认一个主体是谁再确认它拥有什么权限最后根据这些权限决定某个资源能否访问、某个接口能否调用、某项操作能否执行。Authentication、Authorization、RBAC、ABAC、IAM、PAM以及围绕 Credential、Token、Certificate、Key 建立起来的大量安全工程本质上都在不断提高同一件事情的精度确认一个主体是否有资格使用某种能力。这套体系没有错而且在未来仍然会是安全基础设施的一部分。真正发生变化的是另一件事。当软件越来越多地停留在“工具”阶段时获得权限与最终执行之间始终存在一个天然缓冲层——人。系统负责验证身份和资格人则在动作真正发生以前理解上下文、判断目标是否合理并在最后一刻决定是否继续。很多时候这个过程甚至没有被正式写进系统设计但它真实存在财务人员看到陌生账户会停一下运维人员发现生产命令不对会重新检查一个拥有 Root 权限的管理员也不会因为“能执行”就把所有命令都执行一遍。因此传统系统能够长期把“拥有权限”和“可以执行”放得很近并不完全因为权限体系足够完善而是因为两者之间始终存在一层人的判断。AI Agent 正在改变这一点。一、Agent 真正改变的是从判断到现实之间的距离把 Agent 理解成“更聪明的软件”其实低估了它带来的变化。传统软件通常等待明确指令点击、输入、确认然后响应。Agent 则可能从一个相对抽象的目标开始自行拆解任务、选择工具、获取数据、调用接口根据中间结果继续推理再决定下一步动作。随着 Agent 获得越来越多 API、Credential、支付能力、云资源权限乃至物理设备控制能力它正在接管过去由人承担的一部分判断链路。这时候一个原本没有那么危险的逻辑开始暴露问题有权限所以可以执行。对于人而言一次错误判断通常受制于操作速度、注意力、组织流程和物理时间对于 Agent一次错误理解却可能在极短时间内沿任务链向下传播并被转换成一系列完全有效的调用。它不一定需要突破系统也不一定需要获得额外权限只需要在某个足够早的位置错误理解了一件事情后面的自动化就可能忠实地放大这个错误。因此Agent 更适合被放进一种并不浪漫、但更准确的安全假设里它首先是一个 Fallible Subject——一个可能失败的行动主体。这里的“可能失败”并不是说模型能力弱而是承认任何能够解释目标并发起行动的主体都可能出现偏差。人会被骗模型会误解上下文SaaS 可能失陷配置可能漂移Policy 可能写错设备也可能异常。AI 带来的安全变化因而不只是“机器能够做更多事情”而是机器正在显著缩短一次判断偏差与现实结果之间的距离。这才是为什么今天需要重新讨论控制权。二、Permission、Authority 和 Execution不应该再被当成一件事很多软件系统长期把权限、控制权和执行能力混合在一起。谁拥有 Key谁就拥有控制权谁拿到 Root谁就可以执行谁掌握一个 API Token谁就能够调用相应接口谁拥有私钥谁就能够签名并广播交易。从操作系统、访问控制和密码学的角度看这些说法并没有问题因为 Credential 本身就是一种能力证明。但进入 Agent 时代以后仅仅用“谁拥有能力”来定义控制权开始显得不够。这里至少需要拆开三个概念。Permission回答的是这个主体是否被允许参与某类操作。Authority回答的是这个主体所作出的判断在整个执行链中究竟具有多大的约束力。而Execution则意味着更具体的东西某个动作已经真正改变了系统状态甚至改变了现实世界。这三者过去经常重叠但它们并不天然相等。一个 Agent 可以拥有调用交易接口的 Permission却不意味着它应该独自拥有决定一笔交易最终广播的全部 Authority一个 SaaS 可以拥有云基础设施管理能力也不意味着 SaaS 一旦失陷攻击者就应该自然继承改变生产环境的最终执行能力一个管理员可以拥有设备维护权限也不意味着任何来自管理员身份的命令都应该无条件成为现实。因此未来控制权真正需要回答的问题不再只是Who is allowed to act?还要继续向下追问Whose decision is sufficient to make the action happen?如果一个系统无法区分这两个问题那么再精细的权限体系也可能只是把“有资格”更加精确地连接到了“现实已经发生”。三、AI 时代最难处理的可能恰恰是“完全合法”的错误传统安全体系非常擅长寻找不合法。错误密码、伪造 Token、Credential Theft、越权访问、Privilege Escalation、异常登录、未经允许的 API 调用这些事件通常都会在某一个安全边界上暴露出不一致。但 Agent 会让另一类问题越来越重要主体身份是真的Credential 是真的Permission 也是合法的API 调用符合协议甚至 Policy Engine 也明确返回了 Allow但最终发生的事情仍然不是原始目标真正希望发生的结果。这类执行很难被归入传统意义上的 Unauthorized Action。它可能从头到尾都是 Authorized 的。问题只在于它不应该发生。我更愿意把它叫作Authorized but Undesirable Execution。这类问题之所以值得单独讨论是因为它绕过的不是某一个安全机制而是整个安全体系长期依赖的一项假设只要身份、权限和策略判断都正确最终执行通常也应该是正确的。但在 Agent 系统中这个推理已经不再可靠。攻击者甚至不一定需要窃取 Credential。他可能只需要污染上下文、改变输入、影响工具选择、操纵中间状态或者让 Agent 对“用户到底想完成什么”形成一个足够合理却错误的解释。之后系统完全可能使用合法身份、合法权限和合法接口一步一步完成错误执行。这意味着两个过去经常被默认连接起来的等式必须拆开Identity Correct ≠ Intent Correct。Authorization Correct ≠ Execution Correct。身份认证能够确认“是谁”权限系统能够确认“能做什么”但它们都不能自动证明眼前这一笔具体执行仍然是最初那个意图所要求的执行。而这恰恰是执行控制开始成为独立问题的地方。四、人工审批并不能自动填上这条缝隙面对 Agent 的不确定性一个非常自然的工程选择是 Human-in-the-Loop高风险操作交给人审批超过阈值的动作需要确认重要任务需要第二个人点击 Allow。这些机制当然有价值。问题在于“有人批准”并不天然等于“最终执行受到了有效控制”。这里容易被忽略的是审批对象与执行对象之间的连续性。一个人看到金额 10 并点击批准执行器最终发送出去的参数是否仍然是 10人批准的是地址 X后续任务重试、状态更新、参数转换之后是否仍然是地址 X人看到的是一笔具体交易系统真正拥有的授权到底是“这一笔”还是“这一类”只要 Approval 和 Execution 之间仍然存在一段可变化的状态那么审批就可能发生漂移。如果两者之间没有对象绑定、状态绑定以及执行前重新验证那么一份审批记录最多只能证明曾经有人看过并批准过某个对象。它不能证明现在即将发生的这个现实动作就是当时被批准的那个对象。所以 Human-in-the-Loop 真正重要的并不是 Human 是否 Presence而是 Human 的判断是否能够形成真实 Authority并且这个 Authority 是否会在最终执行时被强制兑现。这也是为什么执行控制不能被简化成Agent → Human → Execute。更完整的链条应该不断验证同一件事意图是什么批准的对象是什么现在即将执行的对象是什么现实状态是否已经变化而所有这些信息是否仍然能够被证明属于同一次执行。Intent ≠ Execution。中间那段距离不能靠“应该没变”来填满。它必须被结构性地证明。五、真正的控制权最终体现为拒绝权讨论控制权时我们习惯从正向能力理解它谁能够创建谁能够修改谁能够批准谁能够 Override谁能够执行。但对于高风险自动化系统一个更重要的问题其实是反方向的当所有东西都在推动一次动作向前发生时谁仍然能够让它停下来这可能才是控制权最硬的一部分。一个真正存在的安全边界必须拥有拒绝能力而且这种拒绝不能只是 Alert、日志、Dashboard 上的红色状态也不能只是执行以后再告诉管理员“这里可能有问题”。它必须发生在现实状态被改变以前。这会直接引出 Fail-Secure。现代工程系统天然追求可用性网络失败就重试数据缺失就使用默认值服务异常就降级依赖不可用就考虑 Fallback。这些设计在大多数业务系统里都是合理的因为系统的目标通常是尽量完成任务。但进入执行边界以后同一种工程习惯可能产生完全不同的后果。Unknown、Missing、Expired、Conflict 这些状态都有一个共同点系统掌握的信息正在减少。如果一个高风险执行系统在信息最不完整的时候仍然倾向于继续那么它事实上是在对现实知道得越少反而越敢改变现实。这显然不是一个安全边界应该具有的性质。因此执行控制需要建立一条与普通可用性系统不同的默认原则ALLOW 必须被证明而不能由缺省产生。必要证据缺失就不能证明。状态无法确认就不能证明。审批对象和执行对象不一致就不能证明。不同控制边界之间存在冲突也不能证明。这不是“默认拒绝”四个字那么简单它背后真正表达的是一种认识论立场系统只有在知道得足够多时才有资格允许现实发生变化。也正是在这里Access Control 和 Execution Control 开始真正分层。Access Control 主要回答的是你能不能进入、能不能调用。Execution Control 则回答在当前这一刻、针对这个具体对象这件事情最终能不能发生。前者保护能力入口后者保护现实结果。六、从寻找可信主体到设计可信结构传统安全体系经常试图找到一个足够可信的主体。可信管理员、可信设备、可信服务、可信模型、可信硬件、可信 Credential。但系统越复杂这种思路的局限就越明显。没有哪个主体能够永久保持正确。人会误判模型会误解软件会出现漏洞SaaS 会被攻陷设备会故障Policy 也可能被错误配置。如果承认这一点那么安全系统的目标就不应该是找到一个“永远正确的人或组件”而应该变成即使其中某一个主体失败结构本身仍然不能允许这一次失败直接穿透到现实。这是从 Subject Trust 到 Structural Trust 的变化。它意味着一次现实执行不能由某一个主体从头控制到尾。意图需要被独立验证审批必须与具体对象绑定执行以前需要重新检查现实状态真正落地以后还应该留下能够独立验证的 Evidence。这里最重要的不是组件数量而是权力不能重新汇聚到同一个地方。如果 Agent 负责理解 Intent同时掌握 Credential同时能够修改 Policy同时负责最终 Execute那么无论内部增加多少条逻辑判断它仍然是同一个主体在不同代码路径里批准自己。同样如果一个 SaaS 同时负责解释、审批、仲裁和执行那么整个系统最终依然只存在一个真正的信任域。因此所谓 Authority Decomposition并不是为了把架构画得更复杂而是为了回答一个很朴素的问题一个主体失败以后它还能不能独自让现实发生如果答案仍然是“可以”那么这条执行链其实并没有真正完成拆权。七、为什么 Execution Control 需要成为一个独立层沿着上面的逻辑继续往下推一个真正独立的 Execution Control Layer 会自然表现出一些与普通业务系统完全不同的性质。它不能过度依赖 Agent 自己提供的解释否则它只是 Agent 的另一个模块它不能把 Policy Result 直接视为 Final Authority因为 Policy 同样可能失效它必须拥有执行前的独立拒绝能力并且这种拒绝必须能够真实阻止最终动作。它还应该刻意保持简单。执行控制层的任务不是比 Agent 更懂业务也不是重新做一次复杂推理。恰恰相反它应该尽可能少做那些难以证明的事情只判断当前这一次执行是否满足已经明确表达的边界。这也是为什么用来承载执行控制的 Policy Runtime 不一定应该追求通用计算能力。一个普通程序设计语言希望表达更多可能性而安全边界的目标很多时候恰好相反减少无法验证的可能性。因此确定性、无副作用、有限表达能力、必然终止在普通应用开发中可能看起来是限制但对于执行控制而言它们反而可能构成安全属性。安全边界有时候不是因为它能力更强而值得信任而是因为它主动放弃了不需要拥有的能力。HAVENLON 正是在这样的思路里逐渐形成。我们并不试图建立一个更强大的超级权限中心也不希望创造一个位于所有系统之上的“最终管理员”。真正想做的事情反而是拆开一次行动从意图到现实之间的权力让任何一个主体都无法天然拥有完整路径。Pass Key 可以判断。Auth Key 可以表达批准或拒绝。Hub 可以进行仲裁。Executor 承担最终动作。但其中任何一个“同意”都不应该天然等价于现实必然发生。因为Policy ≠ Final Authority。真正的 Final Authority 应该来自一个被完整证明的执行条件而不是某一个组件单独说了“Allow”。从这个角度看HAVENLON 只是这套结构的一种工程实现。更重要的问题并不是某一台设备、某一种协议或者某一种 Policy Language而是软件安全是否应该开始承认一件事情Permission 只是执行链条的开始不是执行的终点。八、重新理解控制权过去半个世纪的软件工程一直在努力赋予机器更多能力。更多 API更灵活的权限更快的自动化更强的模型更自主的 Agent。这条道路没有问题。AI 的价值本来就来自它能够承担越来越复杂的工作。但当软件开始直接参与支付、交易、云基础设施、工业设备以及其他能够改变现实状态的系统时我们也必须开始建设另一半工程能力不仅告诉机器它能做什么还要明确哪些事情即使它能够做到也不能仅凭自己的判断决定发生。因此AI 时代的安全重心可能正在发生一个很微妙、但非常重要的迁移。过去我们不断提高证明主体身份和权限的能力。未来还需要继续证明另一件事情为什么此时此刻的这一次具体执行有资格成为现实。这要求 Intent 能够被验证Approval 能够被绑定Authority 能够被拆分Execution 能够被拒绝而在动作发生之后整个过程仍然能够留下可以独立检查的 Evidence。到这里控制权的定义也许就应该发生变化。它不再只是“谁拥有最大的权限”。也不只是“谁掌握最终 Credential”。真正值得问的是Who can make the action happen?以及在 AI 开始拥有越来越多现实能力之后那个可能更加重要的问题Who can still stop it?