一、权限描述可能性，权威决定现实

计算机安全在过去几十年里反复回答的，其实是同一个问题：谁被允许做这件事。

口令、角色、令牌、API Key、凭证体系、IAM、RBAC、特权访问管理，直到零信任，这条技术谱系不断提高的是同一个答案的精度——谁可以登录，谁可以读取，谁可以修改，谁可以调用某个接口，谁可以批准一笔交易。

这套体系在人类主导计算机操作的年代足够好用，原因不在于它本身多么完备，而在于它背后有一个从未被写进规范的隐含前提：只要确定了"谁被允许做"，后面的执行大体上就是确定的。操作由人发起，节奏由人控制，提出意图的主体同时也是理解后果的主体，权限与执行之间那段距离短到可以忽略。

AI Agent 出现之后，这个前提开始松动。

一个 Agent 可以持有完全合法的凭证，调用完全合法的接口，提交一个完全符合 Schema 的请求，通过所有既定检查，最终造成一个根本不应该发生的现实结果。它没有越权，没有绕过认证，没有窃取密码，甚至没有攻击任何系统。链条上的每一步都是"合法"的，事情仍然错了。

这说明我们可能长期混淆了两个并不相同的问题：

Who has permission?

Who can make the action happen?

前者是权限（Permission），后者是权威（Authority）。财务人员拥有转账权限，不意味着他发起的每一笔转账都应该发生；管理员拥有 DELETE 权限，不意味着任何通过认证的 DELETE 都应该真正改变生产数据；Agent 持有支付接口，更不意味着它生成的每一个结构合法的请求都应该进入清算网络。

权限描述的是一个主体被允许提出什么，权威决定的是这个主体究竟能让什么事情真正发生。Permission describes possibility. Authority determines reality.

传统系统把两者放得太近。认证成立就获得权限，获得权限就能调用接口，接口检查通过执行随即发生，整条链条固化成一种工程直觉：授权成立，执行便是授权的自然结果。

在高风险自动化系统里，这种结构开始变得危险。需要追问的已经不是"这个主体有没有资格提出这次操作"，而是：为什么一个主体一旦获得资格，就同时获得了把意图一路推进到现实结果的能力？

权威分解要处理的，正是这个问题。

二、权威坍缩：分层的界面与合一的因果

我们习惯把安全事故归因为"某个人权限太大"，于是对策也顺理成章：收紧权限、增加审批、缩短令牌有效期、加一道多因素认证、把一个管理员变成两个管理员。

这些措施都有价值，但它们绕开了一个更深的结构问题：那些在语义上本应彼此独立的权力，是否最终仍然落在同一个失陷域里。

设想一个典型的自动化执行链。Agent 理解任务、产生意图、持有凭证，调用 SaaS 接口；SaaS 保存策略、判断请求是否合法、决定是否执行，再向真正的执行组件下发命令。架构图上，这里可能同时存在 Agent、网关、IAM、策略引擎、审批流和执行服务，层次分明，职责清晰。

但只要问一个问题，图上的层次感就会消失：如果攻击者控制了其中某个关键主体，他是否仍然可以沿着这条链一路走到最终执行？如果答案是肯定的，那么这些组件在执行意义上从未构成独立边界。它们只是多个软件模块，共享同一份最终权威。

这种现象是权威坍缩（Authority Collapse）。

严格地说，权威坍缩不是指系统只有一个用户或一个服务，也不是指某个角色被授予了过多权限。它指的是：本应具有不同语义、处于不同阶段、承担不同安全职责的权力，在最终执行的因果链上重新汇聚到同一个主体、同一份凭证、同一个运行时或同一个失陷域之中，以至于该主体一旦失陷，就足以独自把意图推进为现实。

谁产生意图，谁批准意图，谁解释策略，谁判断当前状态，谁裁决是否放行，谁真正让现实发生——这本是六个不同的问题。在许多系统里，它们最后由一份凭证、一套运行时、一家 SaaS，甚至同一个进程完成了。

界面上是分层的，组织上也是分工的，但因果意义上没有分权。

判断一个系统是否发生了权威坍缩，不能看它画了多少个方框，而要看它在假想失陷之后还剩下什么。界面上的分层，不等于因果链上的分权。 安全最终要保护的从来不是界面，而是因果链。

三、权威分解的定义

因此，权威分解不等于"多人审批"，也不只是传统意义上的职责分离。在执行工程的语境里，它需要一个更严格的定义：

权威分解（Authority Decomposition），是将一个意图转化为现实结果所必需的不同执行权威进行结构性拆分，使任何单一的不完美主体，都无法独自完成从意图产生到现实改变的完整因果链。

这个定义包含三个不可省略的特征：被拆开的是性质不同的权威，而非同一种能力的份额；拆分是结构性的，体现在凭证、运行时、策略来源与执行域上，而不仅体现在流程与组织图上；判定标准是单一主体的失陷不足以完成整条执行链，而不是"审批环节变多了"。

一次真实执行，至少牵涉以下几类性质不同的权威：

意图权威（Intent Authority） 决定"要做什么"被提出。

授权权威（Authorization Authority） 决定某个具体意图是否获得了必要的许可。需要强调的是，授权产生的是一个有范围、有时效的历史事实，而不是一张长期有效的执行通行证。

策略权威（Policy Authority） 决定"在什么条件下可以被允许"。它是规则的来源，而不是个案的裁决者；它规定边界，不负责宣布边界在此刻成立。

运行时裁决权威（Runtime Adjudication Authority） 决定在执行即将发生的这一刻，全部条件是否仍然同时成立。原文称其为 Runtime Decision Authority，此处调整命名的原因是：上述每一类权威都在做出某种"决定"，"decision"一词不具备区分度；这里真正特指的是对一次具体请求所做的、不可提前、不可缓存的即时裁决，"裁决"更准确。

执行权威（Execution Authority） 决定谁真正拥有改变外部现实的能力，也就是谁能让副作用落地。

它们可以协作，但不应彼此等价，更不应互相替代。

需要特别澄清一点：证据（Evidence）不是一种权威。 证据构成的是一个横切各权威的证明平面（Proof / Evidence Plane），用来使意图、授权、策略版本、状态判断与最终裁决可被独立验证。把证据本身写成一种权威，等于承认"谁生产证据谁就有权决定"，这恰好会制造一个新的坍缩点。证据不做决定，它让决定可被检验；一旦它开始决定，它就已经不再是证据。

四、为什么它不是把一把钥匙切成三把

这里最容易产生误解：原来一个管理员可以完成的操作，现在改成三个管理员共同签字，这算不算权威分解？

可能算，也可能完全不算。关键不在人数，而在于这三个人手里的究竟是不是性质不同的权威。

如果三个签名只是共同解锁同一把超级密钥，那么被拆分的仍然是同一种能力的份额。这属于门限授权（Threshold Authorization），它解决的问题是"单一主体不能独自授权"，这是一个真实而重要的问题，但也仅此而已。如果这三个签名还是由同一个客户端组装请求、在同一个运行时内汇聚、经由同一条通道下发到执行端，那么在因果链上，它在最终一跳依然是一次坍缩。

权威分解的追问从授权成立之后才真正开始：既然授权已经成立，谁来判断此刻的现实状态？谁证明作用对象没有在批准之后被替换？谁确认即将发生的动作仍然与最初的意图一致？谁保证策略没有在过程中被悄悄改写？谁掌握触发现实改变的最后一步？

因此，有效的权威分解必须满足一条硬性标准：不同权威在语义上不等价，在能力上不可相互替代。 由它可以直接导出四条约束：

意图权威不因为提出了意图，就自动获得执行权威；

一次授权不因为曾经发生，就自动成为未来任意时刻执行的充分条件；

策略引擎输出 ALLOW，不等于外部副作用必须发生——它陈述的是"不违反规则"，而不是"应当落地"；

执行方拥有执行能力，也不因此获得决定"什么应该被执行"的资格。

只有当这四条同时成立，拆分才不是形式上的。

五、对抗性完整提出问题，权威分解给出结构

权威分解与对抗性完整（Adversarial Completeness）之间，是问与答的关系。

在《何为"对抗性完整"》中我们接受了一个并不舒适但更接近现实的前提：任何主体都可能失陷。Agent 可能被提示注入影响，操作员可能误操作，凭证可能泄露，SaaS 可能被攻破，策略可能写错，网络可能被劫持，设备可能故障。这就是不完美主体（Fallible Subject）的含义——它不是对某个具体实现的怀疑，而是对"永远正确"这一假设本身的放弃。

一旦接受这个前提，一个直接的问题就会出现：如果这个主体失陷，会发生什么？

如果答案是"它失陷之后，就足以让最终执行发生"，那么无论在它前面部署多少认证、审计与监控，这个主体实际上已经是系统中的单点最终权威，系统也就没有达到对抗性完整。

对抗性完整是安全要求，权威分解是结构性回答。前者问：What if this subject is compromised? 后者答：它的失陷不得构成完成这次执行的充分条件。

这里需要说清楚权威分解不承诺什么。它不承诺所有组件都不会失败，也不承诺失陷不造成损害。一个被攻破的主体依然可以生成恶意意图，可以污染数据，可以拒绝服务，甚至可以让整个系统停下来。权威分解接受这些后果，并在可用性与正确性之间明确选边：宁可执行不发生，也不接受未被证明成立的执行发生。

它要保证的只有一件事——单点失陷不等于执行权威的完全失守。

六、与最小权限、零信任、职责分离的区别

最小权限关心的是少给权限，零信任关心的是不因网络位置或历史认证而持续信任，职责分离关心的是关键任务不由同一角色独揽，多签与门限授权关心的是单一主体不能独自授权。

这些机制都有效，权威分解不取代其中任何一个。它们大多在回答"权限如何收缩、信任如何撤销、授权如何多人化"，而权威分解把问题推到更靠近执行的位置：一次现实改变，究竟由哪些性质不同的权力共同构成，其中哪一项在失陷之后会重新吞并其余各项？

这也是为什么权威分解往往不只需要分人，还需要分阶段、分语义、分凭证、分策略来源、分运行时、分执行域，必要时分到物理信任边界之外。它试图避免的，从来不是"某个人拥有太多权限"，而是因果权威重新坍缩到单一主体手中。

一句话概括：目标不是把权限分配得更细，而是不让因果权威收拢回一个主体。

七、拆开之后，必须针对一次具体执行重新组合

于是出现一个看似矛盾的问题：如果所有权威都被拆开了，系统最后还怎么执行？

答案是，权威必须重新组合，但只能针对一次具体执行、在执行发生的那个时刻组合一次。

系统不能说"这个人过去被批准过，所以他今后可以执行"，也不能说"这个 API Key 拥有权限，所以它的所有调用天然合法"。它必须在副作用真正发生之前重新判断：谁在行动，要做什么，作用于哪一个具体对象，当前现实状态是什么，有哪些可验证的证据支持上述判断，以及这次执行必须落在哪些边界之内。

即：

ACTOR / ACTION / TARGET / STATE / EVIDENCE / POLICY → DECISION

在更高一层的语义上，它们分别回答 WHO、WHAT、OBJECT、STATE、PROOF、BOUNDARY。

此处发生的不是一次普通的权限校验，而是被拆开的权威围绕一个具体动作、在一个具体时间点，临时构成一次执行的充分条件。这次组合的有效期只覆盖这一次执行：目标发生变更、状态出现漂移、证据过期或策略版本更替，充分条件即刻不再成立，而不需要任何人主动撤销。

这背后是一个更基本的时间性区分：授权是过去发生的事实，执行是此刻发生的现实改变。 过去的事实可以成为当下判断的输入，却不能替代当下的判断。因此执行资格不能只继承历史授权，必须在运行时针对当前事实重新成立。

先拆开，再针对具体事实重新组合。权威分解与运行时重组，本来就是同一件事的两半。

八、最终权威属于谁

顺着这条线继续追问会得到一个不太符合直觉的结论。

如果意图的提出者不是最终权威，批准者不是，策略引擎不是，SaaS 不是，执行组件也不是，那么最终权威究竟属于谁？

执行工程给出的答案是：不属于任何主体。

让一次执行成立的，不是"老板说了"，不是"Agent 持有密钥"，不是"系统里显示已批准"，也不是"策略引擎返回了 ALLOW"，而是在执行发生的这一刻，若干相互独立的条件同时成立并且可被验证：意图与动作一致，授权覆盖本次动作，目标未被替换，状态仍然成立，证据完整且未过期，边界没有被突破。

于是：

Owner ≠ God.

Policy ≠ Final Authority.

Authorization ≠ Execution.

最终权威不属于主体，而属于被证明成立的边界。

这句话需要一点限定，否则容易被误读成"边界是一个新的绝对可信物"。边界本身不是主体，它不会被说服、被贿赂、被提示注入，但它同样不会自动正确：它由人定义，可能写错，也必须能够被修订。区别在于，边界不产生意图，也不主动执行，它只决定"未被证明成立的事不得发生"；而修改边界本身，同样应当受权威分解的约束，否则最终权威就会从执行时刻悄悄转移到配置时刻。

九、从理论到工程：为什么会推导出独立执行边界

理解了上面这条链，再回头看各种执行控制架构，就能分辨两种完全不同的推导顺序。

一种是先决定"我要做一个硬件"，再去寻找硬件存在的理由。

另一种是从不完美主体出发：主体可能失陷，因此系统必须满足对抗性完整；要满足对抗性完整，就必须打破权威坍缩；要打破权威坍缩，就必须进行权威分解。到这一步，还会剩下最后一个问题——谁来阻止上游软件在自身失陷之后，把这些已经拆开的权威重新合并回去？

一个纯粹在软件层面完成的分权，如果所有分支最终仍然汇入同一个可被上游改写的路径，那么分权在失陷后就会被撤销。要让逻辑上的分权成为工程事实，某一类执行权威必须离开原有的软件失陷域，落在一个上游主体无法单方面重写的位置上。

这就是独立执行边界（Independent Execution Boundary）的由来。

它的价值不在于"硬件比软件安全"，也不在于硬件天然可信。硬件同样是不完美主体，同样会有实现缺陷、供应链风险和物理故障，因此它也不能成为新的绝对可信根，不能成为被重新命名的 God。它的意义只有一个：让某种执行权威脱离上游主体的失陷域，从而使前面所有的分权无法在事后被重新合并。

这也约束了它的职责边界。独立执行边界不产生意图，不替使用者决定"什么应该被执行"，它只在证明不成立时拒绝放行；它自身的规则更新，也必须受同样的分解约束，否则它会把执行时刻的权威悄悄搬到升级通道上。把它写成"单一最终可信点"，等于在系统的末端重建了一次权威坍缩。

从这个角度看，任何独立执行边界的具体工程形态——Havenlon 的实现只是其中一种——都只能被评价为权威结构中一个难以被替代的组成部分，而不是整个安全性的来源。

十、从寻找可信主体，到设计可信结构

人类在很长时间里都习惯于寻找可信主体：可信的管理员、可信的系统、可信的服务商、可信的模型、可信的硬件，然后把越来越大的权威交到它手里。每一次失败之后，我们做的往往是更换一个更可信的主体，而不是质疑这种委托方式本身。

AI Agent 时代可能迫使我们换一个方向。未来足够安全的系统，也许不是因为我们终于找到了一个不会犯错的主体，而是因为我们终于不再要求任何主体永远正确。

这正是不完美主体的起点，是对抗性完整的要求，最终落在权威分解上：系统需要解决的不是"如何找到一个值得拥有最终权威的主体"，而是"如何设计一种结构，使任何单一主体都不再拥有独自改变现实的充分权威"。

权威分解的本质因此既不是不信任人，也不是不信任 AI，而是承认一个更成熟的工程事实：凡是主体，就可能失败。既然如此，安全就不能建立在"它不会失败"之上，而应当建立在"即使它失败，也不足以让错误成为现实"之上。

从寻找可信主体，走向设计可信结构。权威分解是这两者之间的那座桥。