R

A01 Agent 身份辨析·Identity vs API Key vs Human Credential

创建 2026-06-07 更新 2026-06-20 0 条双链 Agent 安全与权限 专题 AI 整理

当一个 Agent 能自主调工具、花你的钱、还能 spawn 出一窝子 Agent 接着干活，第一个无法回避的问题不是”它能力够不够强”，而是**“它是谁”——账上这笔操作记到谁头上、出事追责追到哪个主体、给它的权限怎么收。本节点要解决的问题是：给一个自主 Agent 用什么当身份？业界默认做法是塞一把 API key，但这把 key 既不是 Agent 的身份，也压根扛不起归因与最小授权。本节用的框架是身份(Identity) / 凭据(Credential) / 主体(Principal)三分**——这是 IAM 与零信任领域三十年沉淀的辨析工具，而它在 Agent 场景正整体失效，需要重建。

§0 为什么是”身份/凭据/主体三分”而不是”给它发个账号”

读到这里很多人脑子里的默认框架是：Agent 不就是个程序吗，给它建个服务账号(service account)、发个 API key，跟我们给微服务、给 CI/CD pipeline 发 key 一模一样，问题早解决了。这个框架是错的，而且错得很隐蔽——因为它把三个本该分开的东西糊成了一个。

IAM 的底层语法里，这三者严格分层：

概念定义类比Agent 场景的问题
主体 Principal一个可被追责的行动实体”这个人”/“这个法人”Agent 是不是一个可独立追责的主体？没有定论
身份 Identity主体在系统中的稳定可验证标识身份证号、统一社会信用代码Agent 没有天生的稳定标识，生命周期可能只有几秒
凭据 Credential证明”我是该身份”的可出示物密码、私钥、tokenAPI key 只证明”持有者持有这把 key”，不证明持有者是谁

把 API key 当 Agent 身份，等于用凭据冒充身份、再用身份冒充主体——一次性塌缩了两层抽象。后果是两条最基本的安全属性同时崩掉：无法归因（key 谁拿到都一样，泄露后无法区分合法 Agent 与攻击者重放）、无法最小授权（key 绑定的是”能访问哪个系统”而非”这个 Agent 此刻该做什么”，权限只能往大里给）。这正是本节点的判断主轴，下文展开。

为什么不能直接套”服务账号”框架？因为服务账号假设了三件 Agent 不满足的事：身份长期稳定（Agent 可能 spawn 即生、用完即焚）、行为可预测（服务账号跑的是确定代码，Agent 跑的是非确定的 LLM 推理）、不会自己再委托（服务账号不会自己 spawn 子账号去花钱）。三条假设全破，框架就不能直接搬。

§1 四类”给 Agent 当身份”的候选，及它们各自的塌缩点

把目前真实在用的四种方案摆开对照（行业共识，来源：Aembit、GitGuardian、Curity、WorkOS 等安全厂商 2025–2026 研究）：

凭证类型本质特征归因能力最小授权能力致命弱点
API Key静态、长期有效、可重放几乎为零（认证 key 持有者，非 Agent 本体）极差（绑系统级 scope）泄露即完全暴露；无法区分合法调用与重放
人类凭证（密码 / MFA / 会话 token）绑定个人、有行为基线假性归因（记到那个人头上）差（继承人的全部权限）Agent 借用 → 审计链断裂、条件访问绕过、模拟风险
Workload Identity / SPIFFE SVID加密绑定运行时、X.509 证书短效自动轮转强（绑运行时特征）强（ephemeral，无长期密钥）实施门槛高；为微服务设计，Agent 多跳委托非原生
OAuth 2.1 + OIDC token短期、范围限定、可撤销、可携 act claim中强（可记委托链）中（依赖 scope 配置）配置易错；scope 粒度绑 operator 而非 task

两个数字钉死”API key 当身份”的代价：2025 年 agentic AI 相关 CVE 同比增长 255%，主因追溯至凭证权限过大、生命周期过长（来源：WorkOS Blog）；IBM 2025 报告称 97% 被 AI 相关事件波及的组织缺乏适当的 AI 访问控制（来源：Aembit 引述）。机器身份与人类身份的比例已达 45:1 至 100:1（来源：CSA 研究）——为人设计的 IAM 在数量级上就先被压垮了。

最危险的不是 API key（它至少诚实地”啥都不是”），而是借用人类凭证。让 Agent 用 Rick 的 OAuth token 去调企业系统，表面上”有身份、可审计”，实则审计日志里全是”Rick 干的”，真正的行动者（哪个 Agent、哪一跳、受什么指令驱动）被彻底抹掉——这是归因的假阳性，比无归因更坏，因为它制造了”已治理”的错觉。

§2 判断主轴：用 API key 当 Agent 身份 = 同时杀死归因与最小授权

这是本节点的命门。90% 的团队在给 Agent 上线时会踩这四个点：

错点一：把”能调用”当成”是谁在调用”。

  • 症状：Agent 拿环境变量里的一把 API key 调所有下游，日志里只有 key 的 fingerprint。
  • 为什么会错：key 是 bearer credential——“持有即证明”。它认证的是”谁拿着这把 key”，不是”谁是这个 Agent”。
  • 正确做法：身份必须加密绑定到运行时不可转移的特征（SPIFFE 的 SVID 把身份绑到 workload，X.509 证书 24 小时自动轮转、加密绑定 access token 防重放——来源：Google Cloud Agent Identity 文档，2026-06-05 更新）。
  • 真实反例：2025-09 一个周下载 1500 次的非官方 Postmark MCP server 被篡改，在 send_email 里静默加 BCC 把所有邮件抄送攻击者。受害方的日志只能看到”那把 key 发了邮件”，看不到”邮件被分叉”——因为 key 不携带行为身份（来源：SOC Prime / SentinelOne 报道）。

错点二：scope 绑 operator，不绑 task。

  • 症状：给 Agent 的 token 是”允许访问 CRM 系统”，而非”允许为完成本次退款任务读取这一个订单”。
  • 为什么会错：OAuth scope 的设计粒度是”系统/资源类型”，天然表达不了”此刻这个任务需要什么”。
  • 正确做法：task-level 最小授权——授权服务器对请求做语义检查、只签发完成该任务所需的最小 scope（这是当前 IETF / 学界活跃方向，但 §3 会指出它本身也有失效边界）。
  • 真实反例：约 2000 个野外 MCP server 被实测全部缺乏认证机制（来源：arXiv 2603.24775，AIP: Agent Identity Protocol for Verifiable Delegation Across MCP and A2A，Sunil Prakash，2026-03；已 WebSearch 核实）。没有身份，连 scope 都无从谈起。

错点三：把人类凭证借给 Agent，制造假归因。

  • 症状：Agent 复用员工的 SSO 会话或个人 token。
  • 为什么会错：审计系统把 Agent 行为记成了那个人的行为，行为基线被污染，条件访问策略（“该用户只在工作时间从公司 IP 登录”）被 Agent 绕过。
  • 正确做法：双身份日志——同时记录 Agent 身份与被代表的用户身份（来源：Google Cloud Agent Identity，用户委托时记”双身份”）。
  • 真实反例：2025 年两起真实攻击 Cross-Agent Privilege Escalation（2025-09）与 Agent Session Smuggling（2025-11），核心都是身份/会话边界被混用（来源：WorkOS Blog 汇总）。

错点四：以为”给身份”就等于”解决了”。

  • 症状：上了 Entra Agent ID 或 SPIFFE，就认为身份问题闭环。
  • 为什么会错：身份只解决”它是谁”，不解决”它此刻该动什么”——后者是授权(authz)问题，是本专题后续节点的主战场。安全研究者 Karl McGuinness 的尖锐立场就是：Agent 不需要”身份护照”，需要的是”授权授予”（来源：Resilient Cyber 引述）。
  • 正确做法：把身份当前提而非终点——身份是归因与授权的锚点，但最小授权、确认门、审计是独立的后续工程（链到 0411 S03 Harness Engineering 全景 的权限层、本专题 0435 红队”S03 权限是最后防线”的立场）。

一句话立场：API key 是凭据不是身份；人类凭证是别人的身份不是 Agent 的身份；Agent 要的是一个能被加密验证、能被独立追责、能被最小授权的”非人类一等身份”。

§3 对手框架回应：Agent 到底该不该有”独立身份”？三方分歧

业界对”Agent 是什么主体”存在真实的三方分歧，我不假装有定论，而是接受各方对的部分、标注自己的边界。

立场 A（微软 / Google Cloud）：Agent 是独立的非人类身份，须专用身份构造。

  • 接受：这是工程上最可落地的路径。微软 Entra Agent ID（Ignite 2025 Public Preview）走”无凭证身份模型”——Agent 不用密码/密钥，通过联邦身份凭证(FIC)认证，FIC 由 agent identity blueprint 签发，蓝图作为父模板批量创建子 Agent 身份并保持策略一致（来源：Microsoft Learn，2026-04-14 更新；Microsoft Agent 365 GA 2026-05-01）。Google Cloud 走 SPIFFE/SVID 路线。两者都把”无长期密钥 + ephemeral 身份”做对了。
  • 边界与赌注：这条路把 Agent 身份管理绑死在厂商生态（Entra Agent ID 需 M365 E5 或 Entra ID P1/P2），异构多云环境吃亏。我赌的是：中短期内大厂方案是唯一规模化可用的，但 PM 选型时必须把”厂商锁定”明确计价。

立场 B（部分安全研究者，如 Karl McGuinness）：Agent 不需要身份护照，需要的是授权授予。

  • 接受：这是更深刻的范式提问。给一个生命周期几秒、行为非确定的实体发”稳定身份证”本身就别扭；真正该治理的是”每一次动作的授权”。
  • 边界：完全放弃身份会让归因无所依附——没有身份锚点，授权链断了你都不知道断在哪一跳。我的边界是：身份与授权是两层，不能用授权取消身份，但身份确实不是终点（呼应 §2 错点四）。

立场 C（传统 IAM 厂商）：Agent 是 NHI(Non-Human Identity)的子类，现有框架扩展即可。 Strata、Aembit 等则反对，主张 Agent 需独立类别。

  • 接受：把 Agent 归入 NHI 能复用大量成熟工具（轮换、吊销、审计）。
  • 边界：NHI 子类假设”非人类身份行为可预测”，但 Agent 的非确定性推理打破了这条——一个会自己改主意、自己 spawn 子任务的 NHI，不是传统服务账号能套的。

标准层的诚实状态：NIST AI Agent Standards Initiative（CAISI 主导，2026-02-17 启动）下属 NCCoE 的概念文件《Accelerating the Adoption of Software and AI Agent Identity and Authorization》（2026-02-05 发布，意见征集 2026-04-02 截止）直接提问”现有 OAuth/SPIFFE/OIDC 标准是否足够，还是需要全新标准”——并明确表示无定论（来源：NIST CSRC / NCCoE 官方，已 WebSearch 核实文件名与日期）。这就是 2026 年的真实状态：身份治理范式正在确立，但尚未确立。 把任何一方当”已解决”都是 confirmation bias。

[!warning] failure scenario 本节点”Agent 应有非人类一等身份”的立场，在纯本地、单机、无外部副作用的 Agent 场景会失效——一个只在沙箱里读写本地文件、不花钱、不调外部 API 的脚本式 Agent，给它发独立身份是过度工程。身份治理的成本只在”有外部副作用 + 多跳委托 + 跨信任域”时才值得付。

§4 跨域呼应：零信任的”显式验证”与 Agent 身份的认识论困境

零信任(Zero Trust)的第一原则是 “never trust, always verify”——不因网络位置授信，每次访问都显式验证身份。把这条原则推到 Agent 场景，会逼出一个被忽略的认识论问题。

零信任假设：身份是可被验证的稳定锚点，验证一次就能在该会话内信任。但 Agent 打破了这个假设的隐含前提——它验证的”是谁”与它接下来”会做什么”之间没有可靠的因果绑定。一个被验证为”合法 CRM Agent”的实体，下一步可能因为读到一段被投毒的工具返回值而执行越权操作（间接 prompt injection）。零信任能验证”身份为真”，却验证不了”意图为真”。

这把我们带到一个更尖锐的对照：传统零信任里，身份 ≈ 意图的可靠代理（一个被验证的员工，其行为大体可预测）；而在 Agent 场景，身份与意图解耦了。这正是为什么 IETF 的 RFC 8693（Token Exchange，正式 RFC）明确写道：嵌套的 act claim “仅供参考，不得用于访问控制决策”——标准自己承认多跳委托链在标准层面无法强制执行（来源：IETF Datatracker 核实）。零信任的”显式验证”在 Agent 这里只能验证身份这一层，意图与委托链的可信传递是开放问题。

这对 Rick 的迁移价值在于：滴滴风控里”账户安全 ≠ 行为安全”的经验直接可用。一个登录态合法的账户照样可能在做欺诈行为——风控从来不只验身份，还要验行为基线、设备指纹、行为序列异常。Agent 身份治理需要的正是这套”身份验证 + 持续行为验证”的双层思路，而不是”发完身份就放行”。

§5 PM 决策启示：面试 / 选型 / 复现

面试怎么用：被问”你怎么给 Agent 做身份认证”，不要答”发个 API key / service account”——这是初级答案。答：“API key 是凭据不是身份，它同时杀死归因和最小授权；正确分层是主体/身份/凭据三分，给 Agent 一个加密可验证、可独立追责、可 task-level 最小授权的非人类一等身份（参考 Entra Agent ID 的无凭证 FIC 模型或 SPIFFE SVID）；但身份只是前提，授权与意图验证是独立的后续工程。” 再补一句对手框架：“不过这事 NIST 2026 自己都还没定论，OAuth 够不够用是开放问题。“——这一句把你和背稿子的人区分开。

选型怎么用：评估任何 Agent 平台/框架的身份方案，问四点：(1) 用的是 ephemeral 短效凭据还是长期 key？(2) 身份是否加密绑定运行时、能否防重放？(3) 是否支持双身份日志（Agent 身份 + 被代表用户身份）？(4) 子 Agent 身份是否自动派生且 scope 递减、而非继承父 key？任何一条答”用静态 key”的方案，在合规/高副作用场景直接扣分。注意厂商锁定计价（Entra Agent ID 的 E5 依赖）。

复现怎么用：自己搭最小 Agent，先别急着塞 OpenAI key 进环境变量。本地起一个 SPIFFE/SPIRE（开源）给 workload 发短效 SVID，体会”无长期密钥 + 自动轮转”；再用 OAuth 2.1 的 act claim 跑一遍单跳委托，亲手撞一次 RFC 8693”多跳不可强制”的墙——撞过这堵墙，你对本节点的判断就从”读过”变成”知道”。

§6 与已有节点的关系

本节点是对 0411 A08 MCP 与 A2A 协议族 的安全侧深化：A08 讲清了 MCP/A2A 的协议哲学与 Tool 权限面，但未展开”调用 Tool 的那个 Agent 用什么身份认证”——本节点填这个缺，指出每个 MCP Tool 的权限面要落到”哪个身份在调用”才有意义（呼应 A08 §四已警示的 MCP server 供应链攻击）。对 0411 S03 Harness Engineering 全景，本节点是其工具注册/权限层的前置补缺：S03 的”按工具类型 × 风险等级”分流，前提是先回答”是谁在请求”——身份是权限设计的锚点。对 Function Calling，本节点纠偏一个常见错位：function calling 解决”Agent 怎么调工具”，但不解决”调工具的 Agent 是谁、记谁头上”，二者是正交的两层。不复述上述节点的事实基础。

与本专题内部：本节点是 01 概念辨析的入口，向下依赖 03 架构剖面的权限边界设计、04 实例剖解的真实身份方案 gap 分析；横向受 02 代际演化提供的”从 API key 到无凭证身份”时间线支撑。

§7 关联节点

核心（必读）

延伸（可选）

§8 修订日志

  • R0.1（2026-06-07）：首稿。建立”主体/身份/凭据三分”框架；四类候选对照表；判断主轴四错点四件套；三方分歧对手回应（微软/Google vs McGuinness vs 传统 IAM，含 NIST 无定论的诚实标注）；零信任”显式验证”跨域呼应 + Rick 滴滴风控迁移；面试/选型/复现三落地。事实接地：NIST Initiative 日期、Entra Agent ID 模型、SPIFFE 24h 证书、RFC 8693 多跳局限、255%/97%/45:1 数据均附来源；“2000 个 MCP server”与”NCCoE 概念文件名”标待核实。