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 时的主题。维度AuthenticationExecution Qualification核心对象Subject一次具体动作核心问题你是谁这件事为什么现在可以发生证明类型Identity ProofAction Proof典型输入凭据 / 证书 / 密钥Action / Target / State / Evidence / Boundary关键校验凭据与主体是否对应各要素之间是否正确绑定时间属性相对持续可缓存瞬时成立不可缓存失败含义主体真实性无法建立主体已知但动作缺少完整条件结语从 Identity Proof 到 Action Proof必须重申这两者不是替代关系而且依赖方向是单向的。没有可靠的认证执行资格根本无从判断各项证据来自谁——一份无法确认签发者的批准证据在资格判定中不具备任何重量。认证是执行证明的起点只是它不是终点。它回答 WHO而执行安全还必须继续回答 WHAT、OBJECT、STATE、PROOF 与 BOUNDARY。由此一条在低风险系统中足够用的推导链开始失效主体是真的主体有权限所以动作可以执行。这条推导之所以曾经成立是因为中间那段语义确认由人默默承担了一旦执行链路完全自动化Authenticated不再自动蕴含QualifiedAuthorized也不再自动蕴含Executable。主体可以长期持有某项能力而每一次现实执行是否成立都必须依据当时的对象、状态、证据与边界重新判定一次。于是下一个问题自然出现。假设系统已经完整地建立了执行资格得出了Qualified这个结论——这个结论本身是否就等于现实执行做出判断的那个组件是否理所当然地应该拥有让动作发生的能力换句话说一个 Authorization Decision 与真正让动作落地的 Execution Control是否仍然应该被当作两个安全对象来处理这就是下一篇Authorization vs Execution Control。如果把本篇压缩成一句判断它想建立的是Authentication 证明主体没有被冒充Execution Qualification 证明现实动作没有被身份的合法性所掩盖。