Authentication 是现代安全体系最基础的能力。无论主体是人、设备、服务账号、工作负载还是 AI Agent，系统首先都要回答一个问题：当前发起请求的，究竟是不是它声称的那个主体。密码、多因素、证书、Passkey、硬件密钥、设备身份、工作负载身份、mTLS，本质上都在为这个命题提供证据。如果这一层不可靠，后续所有授权、策略与审计判断都失去可信基础——因为它们全部以"我们知道这是谁"为前提。

需要先澄清一点，以免后面的讨论建立在一个过时的印象上：现代认证并不只在会话起点做一次判断。持续认证、会话风险重估、异常行为触发的重新认证、针对高风险操作的 step-up authentication，都可以在会话生命周期内反复触发。认证事件的频率和上下文敏感度，这些年提升得非常明显。

但频率和强度的提升，并没有改变认证所证明的那个谓词。无论触发多少次、用多强的因子，它给出的结论始终是同一句话：这一次请求确实来自那个主体。在软件主要用于访问信息的年代，这句话加上一次权限查询，基本足以支撑一个安全决策，因为剩下那部分"这个动作合不合理"的判断，通常由一个看着屏幕上的金额和对象的人来完成。当 Agent 把理解意图、构造参数、调用接口、进入下一步执行压缩成一条自动链路之后，原本由人承担的语义确认环节消失了，而它并不会自动落到认证系统身上。它需要被显式地建模成另一个安全命题。

一、Authentication 证明主体真实性，Execution Qualification 证明一次动作的成立条件

认证的核心任务是在一个主体与某个可验证身份之间建立关系：

声称的身份 → 凭据验证 → 已认证主体

系统由此得到一个结论：当前请求确实来自 Subject A。这个结论不可或缺，因为只有确定了"谁在请求"，角色、权限、策略、审计与问责才有附着点。

但一次现实执行所包含的信息远不止 Subject。假设一个已经通过认证的 Agent 请求向 Account-B 转出五万。认证可以有力地证明这是 Agent-A 发出的请求，而它无法凭这一点证明：五万是不是原始任务要求的金额；Account-B 是不是原始意图中的对象；当前业务状态是否仍然满足执行前提；所需的批准是否存在，以及那份批准针对的是否正好是这个动作和这个对象；这笔操作是否已经越过累计额度；用于判断的状态证明是否已经过期。

于是一个经过认证的主体所获得的是 Authenticated Identity，而不是 Qualified Execution。这两者之间的距离，正是本篇要处理的对象。它不是认证做得不够好，而是认证从定义上就不负责回答这一段。

Authentication 证明"这是你发出的"；Execution Qualification 证明"这件事现在有资格发生"。

二、提高 Authentication 的强度可以提高证明的可靠性，但不能扩大它所证明的命题

安全工程里有一种很自然的直觉：动作越危险，就把认证做得越强。密码不够就加多因素，软件证书不够就上硬件密钥，普通设备身份不够就引入安全元件、TPM 或硬件信任根。这些措施确实显著提高了凭据被伪造、复制或盗用的难度，在各自的目标上都是有效的。

但认证强度作用的位置是"这个断言有多可信"，不是"这个断言说了什么"。一个硬件私钥产生的有效签名，可以极其可靠地证明这段数据由持有该私钥的主体签发；它不会因为密钥更安全，就顺带证明被签内容是一个正确的业务动作，更不会证明这个动作在当下具备执行资格。如果 Agent 自己构造了一个错误金额再用合法硬件密钥签名，那么这个签名只是非常可靠地证明了：Agent 确实签署了这个错误金额。密码学强度不会把错误语义转换成正确语义。

这里有两个值得单独回应的近似反例，因为它们看起来已经很接近执行资格。

第一个是 step-up authentication。高风险操作要求重新认证，确实把一次认证事件绑定到了一个具体动作上，缩短了身份证明与动作之间的距离。但它建立的命题仍然是"这一刻确实是本人在场并同意继续"，而不是"这一刻这个金额、这个对象、这个状态共同构成一次合法执行"。它排除的是会话劫持与凭据盗用，不是参数错误与语义偏移。

第二个是交易签名，尤其是网银体系中 WYSIWYS（所见即所签）那一类设计：待执行的内容本身被纳入被签数据，签名因此覆盖了动作参数。这已经是朝执行资格方向迈出的实质一步，它解决了"用户看到的内容与被提交的内容是否一致"这个问题，也确实堵住了一类中间人改写参数的攻击。但它仍然不回答：这份内容是否与最初的任务意图一致，是否有一个独立 Authority 针对同一个对象给出过批准，以及执行发生时的业务状态是否还允许这次动作。它把签名的覆盖范围从"主体"扩展到了"内容"，没有扩展到"条件"。

因此需要严格区分两个概念：Cryptographic Authenticity 解决数据与主体的真实性，Execution Validity 解决这份数据所代表的动作是否满足现实执行条件。混淆的典型后果，是用提升签名强度来回应一个语义层面的风险——不可否认性被做得很强，执行资格问题被原封不动地留给了下游。

更强的 Authentication 能更可靠地证明"这个决定是谁做出的"，但不能替代"这个决定是否应该被执行"的证明。

三、Execution Qualification 的验证对象不是主体，而是一组相互绑定的执行事实

如果 Execution Qualification 只是对认证再检查一遍，它就不值得成为独立概念。它真正的不同，在于验证对象换了。

认证的对象是 Subject。执行资格的对象是一组必须同时成立、且彼此对齐的执行事实，大致可以拆成六个维度。

WHO——哪些主体参与这次执行，包括 Agent、人、服务、设备以及其他必须出场的 Authority。这一维度依然依赖认证，因为系统首先要确认这些主体各自是谁。

WHAT——具体要执行什么动作。这里需要的是 Transfer、Deploy、Delete、Restart 这样的可执行语义，而不是"处理供应商付款"这样的业务描述。业务描述与可执行语义之间的翻译过程，恰恰是语义最容易偏移的地方。

OBJECT——动作作用于哪个对象：某个账户、某个生产集群、某台设备、某份合约。动作正确而对象错误，结果同样是错误执行，而且这类错误在事后往往更难挽回。

STATE——当前现实状态是什么。有些动作只在特定状态下才允许发生，而批准时刻的状态正确，并不意味着执行时刻的状态仍然正确。

PROOF——凭什么认为这些必要条件已经满足：批准证据、设备证据、状态证据、在场证据。

BOUNDARY——动作不得越过哪些边界：金额、频率、时间窗口、影响面、对象范围、累计风险。

判断对象因此从 Who are you? 变成了 WHO + WHAT + OBJECT + STATE + PROOF + BOUNDARY，输出也从 Authenticated 变成 Qualified 或 Not Qualified。

Authentication 建立主体身份；Execution Qualification 建立一次具体动作的完整执行资格。

四、字段各自为真不等于关系为真，执行资格的核心是绑定

上一章的六个维度容易被理解成"多加几项校验"。真正让执行资格成为一个独立技术问题的，是这些维度之间的关系。

设想系统手上握有这样四个事实：Agent-A 的身份有效；Approval-C 的签名有效；Account-B 是一个合法的注册账户；五万没有超过系统设定的最大单笔金额。每一项单独看都为真，任何一项的校验都会通过。

但真正需要确认的命题是：Approval-C 批准的，是不是 Agent-A 此刻提出的这笔向 Account-B 转出五万的操作。如果那份批准实际针对的是"向 Account-A 转出五千"，那么四个事实全部为真，它们的组合却不构成一次合法执行。

这说明执行资格不能停留在检查 Proof exists，而必须检查 Proof is bound to this exact execution。需要成立的是一组绑定关系：

Actor Binding → Action Binding → Target Binding → Parameter Binding → State Binding

从形式上看，各字段独立校验验证的是每个维度自身是否落在合法区间；而执行资格要验证的，是这些维度构成的组合中的那一个具体点是否被允许。合法区间的笛卡尔积远大于被允许的组合集合，这个差集就是绑定校验存在的理由。多数被称为"权限内的误操作"的事故，落点都在这个差集里。

绑定还有一个结构性质：它是一个跨主体的联合命题，链条上任何单个主体都无法独立断言它成立。提议方知道自己提了什么，但不知道批准方批的是什么；批准方知道自己批了什么，但不知道最终提交的参数是什么。这直接推出一个架构约束——绑定校验必须发生在执行侧，或发生在一个不受提议方与参数构造方控制的位置。放在提议方自证的绑定，在提议方失陷时不提供任何保证。

安全执行不是把若干真实事实摆在一起，而是证明这些真实事实之间存在正确的关系。

五、Approval 是执行资格的一项证据，不是执行资格本身

另一个常见的压缩，是把执行资格理解成"是不是有人批准了"。

批准是执行资格可能需要的一种证据，但它不等于完整资格。假设某人在上午批准"允许 Agent-A 向 Supplier-X 支付不超过两万"。执行真正发生时，系统仍然需要独立确认：当前支付对象是否仍是 Supplier-X，金额是否仍在两万以内，这份批准是否仍在有效期内，业务状态是否已经变化，同一笔操作是否已经执行过一次，累计额度是否因为其他并发操作而改变，以及当前这个请求是否仍然属于批准时的那个意图。

因此，Approval 表达的是某个 Authority 就某件事给出的同意；Execution Qualification 是把多个来源不同的条件组合起来，判断当前这次执行是否已经具备完整资格：

Authentication + Authorization + Approval + State + Evidence + Boundary + Binding → Execution Qualification

这个式子里每一项都是必要条件，没有任何一项可以单独推出结论。把其中任何一项当作资格本身——无论是"认证过了"、"有权限"还是"有人批了"——都是在用一个必要条件冒充充分条件。

六、身份可以长期有效，执行资格必须在执行时刻重新成立

身份结论通常具有相当长的生命周期。设备证书可以有效数月，工作负载身份可以覆盖整个运行周期，用户会话也会持续一段时间。这种持续性是合理的，它让认证结果可以被缓存和复用，也是大规模系统能够正常运转的前提之一。

执行资格没有这个性质。某项操作在 10:00 时批准有效、状态正常、额度充足、对象合规，到 10:05 可能因为另一笔操作刚刚完成而使累计额度触顶。请求本身没有任何变化，变的是它被放进的那个状态。同样，一份批准可能远未过期，但它当初所依据的状态已经不再成立——批准的有效期与批准所依据的前提，是两个不同的时间属性，前者过期可以检测，后者失效经常检测不到。

于是必须区分 Identity Lifetime 与 Execution Qualification Lifetime。前者可以按天甚至按月计，后者可能只有秒级。Qualified at t₁ 不能推出 Qualified at t₂，这也是执行资格必须关注新鲜度（Freshness）的原因。

这条性质带来一个直接的工程约束：执行资格不适合被缓存复用。认证结果可以缓存，因为它断言的是一个在有效期内相对稳定的事实；资格结论不能缓存，因为它断言的是一个瞬时命题。任何把资格判定结果保存下来供后续调用复用的设计——包括在批量执行中只对第一笔做完整判定——都是在把瞬时命题当持久命题用。批量场景下这种做法尤其危险，因为它同时放大了错误的传播速度和累计后果。

身份可以持续有效，执行资格必须随着现实状态重新建立。

七、认证失败是不知道你是谁，资格失败是知道你是谁但这件事仍然不能发生

两种机制在系统中的位置，可以通过它们各自的失败语义看清楚。

认证失败时，系统的判断是"我无法确认这个请求来自 Agent-A"，流程应当停止，这一点没有争议。而认证成功之后，系统所知道的仅仅是"确实是 Agent-A"。此时执行资格仍然可能失败：对象不匹配，状态已经过期，批准针对的是另一组参数，累计风险已经越过边界。这类失败的语义是——我完全知道你是谁，但这件事现在仍然不能发生。

把两者放在因果链上，位置是清晰的：

Authentication → 确立主体 → Execution Qualification → 确立动作资格 → Execution Control → 落实决定

这种分层的价值，在于它避免把所有安全判断压缩到"认证通过与否"这一个入口上。当一个系统的安全性主要由认证强度承载时，它实际上是在用一个只能回答 WHO 的机制，去兜住一个包含 WHAT、OBJECT、STATE、PROOF、BOUNDARY 的问题。

这里还牵出一个必须交代但本篇不展开的问题：如果上述某个条件处于未知状态——状态源没有响应，批准查不到，边界计数暂时不可用——系统应当如何解释。执行资格的逻辑要求是条件必须被建立而不能被假设，State = Unknown 不等于 State = Satisfied。这条语义规则如何在工程上落地、以及它与可用性之间的权衡，是本系列后面讨论 Fail-Secure 时的主题。

维度	Authentication	Execution Qualification
核心对象	Subject	一次具体动作
核心问题	你是谁	这件事为什么现在可以发生
证明类型	Identity Proof	Action Proof
典型输入	凭据 / 证书 / 密钥	Action / Target / State / Evidence / Boundary
关键校验	凭据与主体是否对应	各要素之间是否正确绑定
时间属性	相对持续，可缓存	瞬时成立，不可缓存
失败含义	主体真实性无法建立	主体已知，但动作缺少完整条件

结语：从 Identity Proof 到 Action Proof

必须重申，这两者不是替代关系，而且依赖方向是单向的。没有可靠的认证，执行资格根本无从判断各项证据来自谁——一份无法确认签发者的批准证据，在资格判定中不具备任何重量。认证是执行证明的起点，只是它不是终点。它回答 WHO，而执行安全还必须继续回答 WHAT、OBJECT、STATE、PROOF 与 BOUNDARY。

由此，一条在低风险系统中足够用的推导链开始失效：主体是真的，主体有权限，所以动作可以执行。这条推导之所以曾经成立，是因为中间那段语义确认由人默默承担了；一旦执行链路完全自动化，Authenticated 不再自动蕴含 Qualified，Authorized 也不再自动蕴含 Executable。主体可以长期持有某项能力，而每一次现实执行是否成立，都必须依据当时的对象、状态、证据与边界重新判定一次。

于是下一个问题自然出现。假设系统已经完整地建立了执行资格，得出了 Qualified 这个结论——这个结论本身，是否就等于现实执行？做出判断的那个组件，是否理所当然地应该拥有让动作发生的能力？换句话说，一个 Authorization Decision 与真正让动作落地的 Execution Control，是否仍然应该被当作两个安全对象来处理？这就是下一篇：Authorization vs Execution Control。

如果把本篇压缩成一句判断，它想建立的是：Authentication 证明主体没有被冒充；Execution Qualification 证明现实动作没有被身份的合法性所掩盖。