登录不是授权：高能力 AI 的连续身份保证链

登录不是授权：高能力 AI 的连续身份保证链

发布边界：OpenAI 产品名称、访问路径与账户政策需发布前复核。产品规则不外推为行业标准，未完成完整评估时不得宣称消费账户达到 AAL2 或 AAL3。

摘要

Passkey 提供抗钓鱼认证，却不能证明当前组织、工作区、设备、会话和动作仍然被授权。本文借 OpenAI Daybreak 的分层访问路径说明：高能力 AI 需要从 Identity Proofing 到 Recovery 的连续 Assurance Chain。

关键词

Identity Assurance、Passkey、Daybreak、Session Security、Capability Grant

一、OpenAI Daybreak 给出的不是"认证后解锁"，而是分层能力路径
二、七个不能互相替代的保证环节
三、Phishing-resistant、synced、device-bound 与 AAL 不能混成一句话
四、三个"Passkey 已成功，但动作仍然错误"的典型场景
五、把能力分成风险阶梯，而不是只分"已登录／未登录"
六、一次访问事件应留下可重建的 Evidence Chain
七、强认证的反方问题：锁死、恢复成本和可用性
八、落地原则：把"登录态"改造成"可验证能力态"

适用读者：AI 平台、安全架构、身份与访问管理、Agent Runtime 和企业治理团队。本文只讨论"能力风险与身份保证连续链"，不展开通用 Passkey 教程，也不复述企业 Coding Agent 的完整 Policy／Sandbox／Provenance 治理框架。

一个账户已经用 Passkey 登录，为什么仍可能做出高影响错误动作？

因为"登录成功"只证明了一个较窄的事实：当前声明者在这一刻控制了绑定到账户的认证器。它不自动证明这个人已通过适合该能力的身份核验，不证明当前终端可信，不证明进入了正确的组织或工作区，不证明旧会话没有被窃取，不证明 Agent 获得的工具和目标范围仍然有效，更不证明用户刚刚确认了这一项不可逆动作。

对普通问答，这些差异可能只造成上下文串线或隐私暴露。对能联网、读内部代码、调用安全工具、执行终端命令，乃至进行授权攻击验证的高能力 AI，同样的身份错配会放大为资产修改、凭据使用、跨租户访问或对错误目标施加影响。生产系统真正需要保护的，不是一个孤立的"登录入口"，而是一条从申请、认证到动作落地，再到撤销和恢复都能重建的 Assurance Chain（身份保证链）。

Passkey 是抗钓鱼认证的重要环节，但不能独自承担高能力 AI 的访问治理。能力越高，系统越需要把 Identity Proofing、Authentication、Device Assurance、Authorization、Session Assurance、Action Confirmation 与 Recovery 串成连续、可验证、可撤销的证据链。

来源证据 01：OpenAI Passkey 帮助页。它证明的是产品中的认证用途，不是工作区或具体动作授权。

一、OpenAI Daybreak 给出的不是"认证后解锁"，而是分层能力路径

OpenAI 当前的 Daybreak／Trusted Access for Cyber 文档提供了一个很有代表性的案例。文档将当前访问分成三类：默认的 GPT-5.5 使用标准通用防护。GPT-5.5 with Trusted Access for Cyber 面向经过验证、获批的防御性工作流，采用更精确的防护。GPT-5.5-Cyber 则用于更窄、更专门的授权工作流，并配合更强验证和账户级控制。 $O1$

这三类不是"同一账号完成一次强认证后按按钮升级"。OpenAI 明确说明：申请会结合身份与信任验证、风险、预期用例以及申请者的安全能力进行评估。审批不是自动的。Trusted Access 不保证获得每个网络安全专用模型。购买或商业合同本身也不保证 GPT-5.5-Cyber 访问。 $O1$ 企业 onboarding 还要求完成 Persona KYB 与内部适用性检查，随后把访问配置到申请时确认的 Codex／ChatGPT 工作区、API organization，或两者中的指定路径。 $O2$

来源证据 02：OpenAI Enterprise Daybreak onboarding。正确账户仍需进入被配置的 organization、workspace 或 access path。

更关键的是，能力被绑定到具体组织、工作区、产品表面和内部工作流。OpenAI 要求 Trusted Access 工作区用于获批的内部安全工作，不应同时承载面向客户的应用、第三方流量或下游产品。若提交或配置到了错误组织，应暂停测试，完成纠正和确认后再重新验证。 $O1$ $O2$ 即便已经完成配置，更高风险工作流仍可能被拒绝，其他安全防护与使用政策也继续适用。 $O1$ $O2$

这说明高能力访问至少包含四个彼此独立的问题：

申请者或组织是谁，是否完成了相应核验。
哪个主体被允许进入哪一个组织或工作区。
该工作区被授予哪一级能力、在哪个产品表面生效。
当前请求是否仍在获批的目标、用例和操作范围内。

Passkey 主要回答第二步中的一小部分------"登录者是否控制账户绑定的认证器"。它既不能替代 KYB 或人员资格核验，也不能判断当前是否进入了获批工作区，更不能把一次登录转化成永久、无限目标范围的高风险能力许可。

这里还必须避免两个误读。第一，OpenAI 产品政策是特定平台在当前时间点的访问规则，不应被泛化为所有 Agent 系统必须照搬的行业标准。第二，Daybreak 的"验证"也不能被直接标注为 NIST 某个 IAL 或 AAL。除非平台公开了完整流程、认证器属性、密码模块、会话和运维控制，并经过适当评估，否则这种等级映射没有证据基础。

二、七个不能互相替代的保证环节

连续身份保证链并不是把"身份"写成一个大字段，而是承认七类控制回答不同问题。

1. Identity Proofing：先确认账户背后是谁

Identity Proofing 处理的是申请者与现实主体之间的关联。NIST 将身份核验拆成属性和证据的解析、验证与本人确认，并要求服务方记录采用的流程、证据、异常处理和重新核验条件。 $N1$ 对企业高能力 AI，它可能表现为企业 KYB、员工身份与任职关系、授权代表、项目成员资格以及目标系统的合法授权证明。

这一步建立的是 principal 与 verification_level。它回答"这个账户代表谁、以何种证据建立、何时核验、是否仍有效"。它不负责证明今天登录的人仍控制认证器，那是 Authentication 的任务。

2. Authentication：证明当前声明者控制认证器

NIST 对 Authentication 的定义是：声明者证明自己控制了绑定到订阅者账户的一个或多个认证器。 $N1$ $N2$ Passkey 在这里非常有价值。FIDO Passkey 以公钥密码学替代可重放的共享密码，凭据与依赖方域绑定，因此能显著抵抗仿冒站点收集密码或一次性验证码。 $F1$

但认证成功不是"现实身份重新核验"，也不是授权。攻击者若控制了已解锁终端、接管了同步凭据账户、诱导了错误的凭据绑定，或直接窃取了登录后的会话，系统仍可能看到一次形式上有效的访问。

3. Device Assurance：认证器可信，不等于终端可信

OpenAI 当前 Passkey 文档说明，凭据可能仅存于某一设备，也可能通过 iCloud Keychain 等提供商同步到多台设备。还可能从附近设备通过二维码或确认完成跨设备登录。 $O3$ FIDO 对术语的区分是：经云服务在用户设备之间同步的称为 synced passkey。从不离开单一设备的称为 device-bound passkey。 $F1$

Synced passkey 与 device-bound passkey 的差异会影响恢复性和密钥可导出性，却仍没有回答终端是否由组织管理、磁盘是否加密、补丁是否合规、浏览器是否受控、终端是否存在高风险进程。一个抗钓鱼凭据可以在不合规设备上完成正确认证。因此高能力入口还要单独记录 device_id、管理状态、完整性或姿态结果、风险信号和评估时间。设备信号可以降低或阻断能力，但不能凭空提升认证 AAL。NIST 也明确指出，风险指标不替代认证因子。 $N2$

4. Authorization：决定"谁能在何处做什么"

Authorization 不是验证账户本人，而是根据主体、角色、工作区、资源、目标和政策版本做出访问决定。对于 Agent，授权对象不应只是"允许使用某个模型"，还应包括可调用工具、可读取数据、可使用凭据、允许目标、最大并发、预算、有效期与可否产生外部副作用。

最危险的设计是把高能力永久挂在个人账户上。更稳妥的方式是生成短期 capability_grant：它只在指定 workspace、指定会话或任务、指定目标集合和指定工具列表中有效。工作区一旦不匹配，系统应降级到普通能力或拒绝执行，而不是依赖用户自己发现界面右上角选错了组织。

5. Session Assurance：登录后的会话可能成为新的薄弱点

Passkey 只在认证事件发生时参与。认证之后，浏览器或客户端通常依靠 session cookie、access token 或其他 session secret 维持连续访问。NIST 明确指出，会话由认证事件创建，依靠会话秘密绑定两端。会话可以继承触发它的 AAL，但不能高于原认证事件。 $N3$ 如果攻击者窃取了承载高能力的 bearer session，后续动作可能完全不再触发 Passkey。

来源证据 03：NIST SP 800-63B Session Bindings。认证成功之后，会话秘密和生命周期仍是独立控制面。

因此高能力会话需要单独的保证：较短绝对寿命与空闲超时。能力升级时重新认证。工作区切换时重新计算授权。高风险设备变化、IP／地理异常或密钥绑定变化时降级。服务端可单会话撤销。可能时使用 proof-of-possession 或设备绑定的会话机制，降低 bearer token 被复制后的价值。所谓"连续"不是每一步都要求刷脸，而是每次从登录到工作区、从分析到执行、从低风险工具到高风险工具的状态跃迁，都重新确认此前证据是否仍然成立。

OpenAI 的 Advanced Account Security 当前只表述"活动会话更短"，并未在帮助页给出一个可以外推的固定分钟数。 $O4$ 因此设计自己的系统时应根据动作风险定义超时，而不是引用不存在的统一期限。

6. Action Confirmation：登录意图不等于动作意图

一个人在上午使用 Passkey 登录，并不表示他在下午仍同意 Agent 删除分支、提交补丁、调用联网扫描器或对某个目标执行验证。高影响动作需要 Transaction／Action Confirmation：把将要执行的动作、目标、凭据、影响范围、可逆性和摘要展示给有权确认的人，并将确认绑定到动作摘要和短时有效期。

确认不是一个泛化的"Allow Agent"弹窗。它至少应回答：

确认的是哪一个精确目标和操作。
由哪个主体、以何种新鲜认证完成。
是否需要第二名审批者。
确认后允许执行几次、持续多久。
输入、工具计划或目标发生变化时是否自动失效。

对于普通读分析报告，可以沿用现有会话。对于写仓库、终端执行或外部网络动作，应要求 step-up。对于不可逆或跨边界动作，应采用双人确认、任务级令牌或先预演后提交。Action Confirmation 证明的是当下意图，不能被最初登录事件代替。

7. Recovery：最强认证最终可能被最弱恢复路径击穿

恢复既是可用性机制，也是重新绑定身份与认证器的高风险操作。OpenAI 当前普通 Passkey 页面允许用户在无法使用 Passkey 时选择账户可用的其他登录方式。在 SSO 管理账户中，Passkey 作为 MFA，主登录仍经组织 SSO。 $O3$ 这意味着"账户已经添加 Passkey"不等于其他路径消失。

OpenAI 当前的 Advanced Account Security 是面向符合条件的个人 ChatGPT 账户的可选设置，而不是 Enterprise 通用控制。 $O4$ 开启后需要至少两种安全登录方式，其中至少一种可跨设备使用。可使用 Passkey、兼容的 FIDO 安全密钥或两者组合。它会关闭密码登录、邮件／短信登录码和邮件恢复，启用登录通知、较短会话和恢复密钥。每个恢复密钥只能使用一次，输入有效恢复密钥后当前文档规定有 48 小时解锁等待期。OpenAI Support 不能用常规邮件恢复替用户重置密码或移除该设置。 $O4$

同一页面也明确指出 YubiKey 是可选项，任何兼容 FIDO 的安全密钥以及 Passkey 都可用于满足设置要求。 $O4$ 因而不能把当前规则概括成"必须购买某型号硬件密钥"，也不能把完成认证等同于满足特定审批。当前可确认的只有上述产品边界，且这些边界可能随产品更新而变化。

三、Phishing-resistant、synced、device-bound 与 AAL 不能混成一句话

FIDO 将 Passkey 定义为基于 FIDO 标准的密码替代凭据，使用公私钥对完成抗钓鱼登录。凭据可以同步，也可以绑定单个设备。 $F1$ 抗钓鱼的核心来自依赖方绑定和公钥挑战响应，使凭据不会像密码或 OTP 那样被仿冒站点收集后直接重放。FIDO 也强调，无论密钥是否硬件绑定，抗钓鱼都是 FIDO Authentication 的设计目标。 $F1$

但是"抗钓鱼"只描述对一类攻击的抵抗，不代表整个账户生命周期安全，更不等于任意部署自动满足某个 NIST AAL。

NIST SP 800-63B 当前要求，AAL2 使用两种不同认证因素，并要求验证方至少提供一种抗钓鱼认证选项。AAL3 则要求抗钓鱼的公钥密码认证器、不可导出的私钥以及两种因素，还包含批准密码技术、受保护通道、重放抵抗、认证意图和密码模块等完整要求。 $N2$ NIST 对同步认证器的附录进一步说明：同步意味着认证密钥可以导出到同步体系。在满足同步体系保护等附加条件时，它可以支持 AAL2，但与 AAL3 的不可导出要求冲突，因此同步认证器不能用于 AAL3。 $N4$

由此可以得到三条准确结论：

第一，synced passkey 仍可以是抗钓鱼的。"可同步"不等于退化为密码。

第二，device-bound passkey 更适合需要限制密钥副本或追求不可导出属性的场景，但具体实现仍需满足其余要求。第三，不能因为产品写着 Passkey、YubiKey、Secure Enclave 或生物识别，就直接宣称"该账户是 AAL2／AAL3"。AAL 是一次认证过程及其系统实现的保证等级，取决于认证器、绑定、密码模块、验证方、会话、运维和评估证据，而不是零售产品标签。

对高能力 AI，正确做法不是给所有人强行贴一个 AAL，而是先按动作影响选择目标保证，再验证系统是否真的满足该保证。消费级账户可以借鉴 AAL 的分层思想，但除非完成规范要求与评估，不应在对外文案中声称合规。

四、三个"Passkey 已成功，但动作仍然错误"的典型场景

场景一：正确的人，错误的工作区

安全工程师使用自己的 Passkey 正确登录，却停留在一个同时承载客户流量的旧 API organization。若高能力授予只看账户身份，Agent 可能使用错误账单、错误数据保留条款、错误 API key，甚至把内部能力暴露到下游请求。OpenAI Daybreak 文档之所以要求精确确认组织、工作区和访问路径，并在不匹配时暂停测试，正是因为身份正确不能修复租户边界错误。 $O1$ $O2$

控制点应是：能力授权键至少包含 principal + workspace + approved_surface + policy_version。进入未获批工作区时不继承高能力。工作区切换导致旧 grant 失效。审计中保留配置确认和纠正记录。

场景二：认证很强，会话被盗

用户上午通过 device-bound Passkey 登录，浏览器扩展或终端恶意软件随后窃取 bearer session。攻击者不需要再次钓鱼，也可能在会话有效期内调用高能力。这里失败的不是 Passkey，而是 Session Assurance。

控制点应是：高能力 session 短寿命、空闲过期、可按单会话撤销。能力升级或敏感动作要求 fresh authentication。工作区、设备姿态或网络风险显著变化时失效。服务端记录 auth_event_id 与 session_id 的关联，避免只留下"某账户做了某动作"这种无法判断认证新鲜度的日志。

场景三：人有权限，Agent 被授予了过宽代理权

用户本人有权维护某仓库，也确实通过了强认证，但 Agent 同时拿到了跨仓库写权限、生产云凭据与任意网络访问。一次错误规划、提示注入或目标解析错误就可能让合法身份产生越权副作用。这里失败的是 Authorization 与 Action Confirmation，而不是 Authentication。

控制点应是：Agent 的权限不能等同于人的全部权限。每个任务签发目标受限、工具受限、时间受限的 capability grant。外部副作用必须基于最终动作摘要确认。计划改变、目标扩大或凭据切换时重新授权。登录成功只能让主体"有资格申请某能力"，不应直接把全部能力注入 Agent。

五、把能力分成风险阶梯，而不是只分"已登录／未登录"

下面是一套可迁移的五级风险阶梯。它不是 OpenAI 的官方等级，也不是对 NIST AAL 的一一映射，而是把动作影响与最低身份、会话和运行环境门槛对应起来。

能力层	典型工作	最小身份与认证门槛	会话、授权与环境门槛
L0 普通问答	公共知识问答、无工具总结	基础账户认证；敏感历史或个人数据可要求 MFA／Passkey	无外部副作用；默认不加载组织秘密；普通会话寿命
L1 内部防御分析	内部日志、代码或告警的只读分析	已确认组织成员身份；组织 SSO 或抗钓鱼 MFA；身份状态可撤销	仅内部工作区；数据只读；受控上传；按项目分权；完整访问日志
L2 联网安全工具	对明确授权资产使用联网检测、情报或验证工具	更强的双因素与抗钓鱼认证；受管设备或等效设备姿态；必要时重新认证	目标 allowlist；网络出口受限；短期凭据；短会话；每次扩大目标重新授权
L3 代码／终端执行	修改仓库、运行构建、调用终端或云 API	fresh step-up；特权人员优先使用不可导出、设备绑定的认证器；若声称 AAL 必须完整评估	临时执行环境；最小权限凭据；仓库／分支／命令类别受限；不可逆动作需明确确认
L4 授权攻击验证	在正式授权范围内进行高风险红队、利用验证或专门安全工作流	完成组织与人员核验；获得专门能力审批；独立高保证认证路径；关键角色双人制	独立内部工作区；按 engagement 签发 grant；目标、时间窗和工具均受限；隔离环境；双人确认；自动到期与快速撤销

L2 到 L4 的重点不是把所有用户都赶到最繁琐的认证流程，而是让系统在风险上升时逐级增加证据。对低风险操作，可以保持可用性。对高风险操作，必须让"谁、在哪台设备、哪个工作区、用哪次认证、获得什么临时授权、确认了哪一个动作"同时成立。

还应允许安全降级。例如设备姿态未知时，用户仍可进入 L0 或查看只读报告，但不能继承 L3 的终端执行 grant。相比一刀切锁死账户，这种能力降级既能减小攻击面，也能降低强认证带来的业务阻力。

六、一次访问事件应留下可重建的 Evidence Chain

审计日志若只有 user_id、时间与模型名，无法回答高能力动作为什么被允许。最低可用的 Evidence Chain 应至少包含以下字段，并保持跨系统可关联：

json 复制代码

{
  "principal": {
    "subject_id": "usr_7f2...",
    "organization_id": "org_sec...",
    "actor_type": "human"
  },
  "verification_level": {
    "scheme": "enterprise_kyb_plus_workforce_identity",
    "verified_at": "2026-07-26T22:10:00Z",
    "evidence_ref": "ver_evt_..."
  },
  "authenticator": {
    "type": "webauthn_passkey",
    "syncability": "device_bound",
    "user_verification": true,
    "attestation_class": "recorded_not_assumed",
    "auth_event_id": "auth_evt_..."
  },
  "device": {
    "device_id": "dev_...",
    "management": "managed",
    "posture": "compliant",
    "assessed_at": "2026-07-26T22:12:00Z"
  },
  "workspace": {
    "workspace_id": "ws_internal_security",
    "purpose": "approved_internal_defense",
    "tenant_id": "tenant_..."
  },
  "policy_version": "capability-policy@2026-07-26.3",
  "session": {
    "session_id": "ses_...",
    "issued_at": "2026-07-26T22:12:10Z",
    "last_reauth_at": "2026-07-26T22:12:10Z",
    "expires_at": "2026-07-26T23:12:10Z",
    "binding": "proof_of_possession"
  },
  "capability_grant": {
    "grant_id": "grant_...",
    "risk_tier": "L3",
    "tools": ["repo_read", "sandbox_exec"],
    "target_scope": ["repo:security-lab/validator"],
    "credential_scope": ["ci:test-only"],
    "expires_at": "2026-07-26T22:42:10Z"
  },
  "action_confirmation": {
    "required": true,
    "method": "fresh_passkey_plus_reviewer",
    "action_digest": "sha256:...",
    "confirmed_at": "2026-07-26T22:18:03Z"
  },
  "trace_id": "trace_01J...",
  "revocation_recovery": {
    "grant_revoked_at": null,
    "session_revoked_at": null,
    "recovery_event_id": null,
    "recovery_outcome": null
  }
}

系统不应记录生物特征原始数据、Passkey 私钥或恢复密钥。只记录验证结果、认证器类别、事件引用和必要的可验证元数据。trace_id 把申请、登录、工作区路由、grant、工具调用、确认、结果和撤销串起来。policy_version 解释当时依据哪套规则做出决定。action_digest 证明确认的动作与最终执行内容是否一致。

证据链还要支持负向事件：认证器丢失或移除、设备失去合规、员工离职、工作区纠正、grant 到期、紧急撤销和账户恢复。NIST 要求记录认证器绑定、更新、到期等生命周期事件，并在认证器被认为受损时及时使其失效。 $N5$ 对 Agent 系统，同一原则应扩展到 session 和 capability grant：只撤销账户密码而保留长期 API token，不构成完整撤销。

七、强认证的反方问题：锁死、恢复成本和可用性

越强的认证与恢复约束，越可能带来真实成本：设备丢失、同步账户不可用、员工出差无备用密钥、管理员离职、支持团队无法快速恢复，以及高频 step-up 诱发"机械点击确认"。OpenAI Advanced Account Security 也直接提醒，严格恢复要求会增加永久失去账户访问的风险。 $O4$

恢复设计应提供位于不同失效域的备用凭据与恢复路径。

第一，备用凭据要独立。 至少准备两种安全登录方式，并尽量避免都依赖同一台设备、同一个同步账户或同一保管地点。常见组合可以是日常 synced passkey 加离线保管的 device-bound 安全密钥，或两把分别保管的安全密钥。选择取决于威胁模型与使用频率，而不是品牌。

第二，恢复要分权。 高能力账户的恢复申请、身份重新核验、审批和新认证器绑定不应由同一个人单独完成。可以由业务负责人确认任职与项目，安全团队核验异常，身份管理员执行绑定。每一步留下独立事件和通知。恢复完成后，不应自动恢复所有旧 capability grant。

第三，Break-glass 必须是受控例外。 紧急身份应与日常账户分离，凭据离线保管，启用需要双人审批和明确原因。默认只开放诊断或只读能力。grant 具有极短期限。使用即告警。事件结束后自动撤销并强制复盘。Break-glass 是为了在身份平台故障时维持必要业务，不是绕过审批的永久后门。

第四，让高能力自动过期。 人员身份、项目授权、目标清单、设备合规和特权 grant 都需要到期时间。恢复或组织变更后，应重新申请专门能力，而不是因为账户重新可用就恢复旧授权。

第五，用演练替代纸面保证。 定期测试丢失主设备、同步服务不可用、管理员离职、会话被盗和错误工作区五类场景，测量撤销延迟、恢复成功率、人工步骤、误锁率与孤儿 grant 数量。可用性是保证链的一部分：如果正常恢复不可操作，团队最终会建立更危险的旁路。

需要特别区分：OpenAI Advanced Account Security 当前的单次恢复密钥与 48 小时等待期是该产品此刻的具体规则，不是 NIST 或 FIDO 对所有系统的通用要求。 $O4$ 自建系统应根据风险、法规和支持能力设计恢复窗口，并明确哪些能力在恢复后的冷静期内保持冻结。

八、落地原则：把"登录态"改造成"可验证能力态"

高能力 AI 平台可以用六条工程原则收束设计：

一是能力不永久附着账户。 账户只提供申请资格。真正执行依赖短期、目标受限的 capability grant。

二是授权键必须包含工作区。 principal 正确但 workspace 错误时，高能力不能生效。租户和产品表面不是 UI 偏好，而是安全边界。

三是会话有自己的风险预算。 认证强度不会自动保护后续 bearer session。会话寿命、绑定、重认证与撤销必须独立设计。

四是动作确认绑定具体摘要。 "允许使用终端"不能替代"允许在此仓库、此分支、使用此凭据执行这组变更"。输入或计划变化后，旧确认失效。

五是恢复后默认降级。 新认证器绑定、账户恢复、设备替换或组织变更后，先恢复基础访问，再重新评估高能力。不要自动复活旧 session、API token 和 grant。

六是证据缺失时按能力降级。 设备姿态不可用、工作区未确认或政策版本未知时，可以保留低风险问答，却必须关闭联网、终端和高影响工具。Fail closed 应针对危险能力，而不是把所有用户永久锁在登录页外。

Passkey 显著提高 Authentication 的抗钓鱼能力，减少密码和 OTP 被窃取、重放的风险。高能力 AI 还需要同时回答：

哪个经过何种核验的主体，正在什么设备和工作区中，凭哪一次仍然新鲜的认证，依据哪版政策，获得了什么范围、多久有效的能力，并对哪一个具体动作表达了可验证意图？

当系统能用同一条 Evidence Chain 回答这句话，并能在设备失陷、会话被盗、工作区错配、人员离职或恢复事件发生时迅速撤销，高能力访问才从一个登录功能，变成真正可治理的能力边界。

参考资料

以下代号与正文一一对应，产品事实于 2026-08-08 复核。NIST 与 FIDO 链接用于通用身份标准和术语，不代表本文示例已经通过特定保证等级评估。

FAQ

Passkey 是否等于授权？

不等于。Passkey 主要承担认证。授权还要绑定组织、角色、资源、工具、目标和动作范围。

为什么不能直接宣称达到 AAL2 或 AAL3？

保证等级取决于完整认证与生命周期实现，单看一个产品功能或认证器类型不足以判定。

动作确认和重新登录有什么区别？

动作确认应绑定具体目标、内容、影响和期限，形成一次范围化能力授权，而不只是刷新登录状态。

登录不是授权：高能力 AI 的连续身份保证链