AI Agent 认证方式怎么选：API Key、OAuth、mTLS 与短期凭证

一句话结论：选认证方式时，先别问"用哪种机制"，先问四个问题——证明哪个身份、向哪个系统证明、证明多久、代表谁。API Key 证明"这是一个集成"，OAuth 用户授权证明"这是替某个人办事"，Client Credentials 证明"这是某个应用"，Workload Identity 证明"这是某个运行时"，mTLS 证明"这个进程手里握着那把私钥"，短期凭证则是给以上任何证明加一个过期时间。认证和授权是两层：前者回答"是谁在调用"，后者才回答"这一次调用该给多少权限"。

披露：本文完整编译自 AgntID 博客《AI Agent Authentication Methods: API Keys, OAuth, Workload Identity, mTLS, and Short-Lived Credentials》（2026-10-21，Substack 版 / 首发于 agntid.ai）。原文是厂商视角——AgntID 销售的是 Agent 运行时访问控制产品，文中"运行时访问控制放在哪"一节即其自身推介，我们保留并在此标注立场，请按"了解一类做法"而非"选型建议"来读。原文两张配图分别是标题卡与对照表截图：标题卡按本站规则未使用（不做纯文字封面），对照表已完整重制为下面第二节的中文表格。文中概念与结论均按原文口径，我们未做任何实测；标"编者补充"的部分是本站补充的规范编号与实践口径，不属于原文内容。

一、真正的问题不是"agent 该怎么认证"

AI agent 会调 API、查数据库、改记录、调工具、触发工作流。一旦它能做模型之外的事，它就需要凭证。

所以实际要回答的不是"AI agent 应该怎么认证"，而是：

要证明哪个身份、向哪个系统证明、证明多久、代表谁？

常见认证方式对这个问题的回答各不相同：

• API Key 通常标识一个集成；
• OAuth 可以携带被委托的用户上下文；
• Client Credentials 标识一个应用；
• Workload Identity 标识一个运行时或工作负载；
• mTLS 证明持有某个私钥；
• SPIFFE 提供工作负载身份的标准表达；
• 短期凭证缩短以上任何一种证明的有效期。

这些方法还互相重叠。一个 workload identity 系统可能拿 OIDC 断言去换临时云凭证；SPIFFE 可以签发短期的 X.509 或 JWT 身份文档；OAuth 客户端可以用共享密钥、证书或签名断言来完成认证。

结论：它们不是可互相替换的选项。有些负责建立身份，有些负责携带身份声明，另一些负责定义最后拿到的那张凭证能活多久。

二、八种方式一张表

原文的对照表是本篇最有用的部分，重制如下（列含义：证明的身份 / 拿到的凭证 / 典型寿命 / 委托上下文 / 最适合 / 主要风险）：

这张表的关键读法：纵向看"证明的身份"，横向看"寿命"与"委托"。 你换一行，通常换掉的是前两列；你换"短期凭证"这一行，换掉的只是寿命那一列。

三、什么是 AI agent 认证

AI agent 认证，是验证 agent 访问某个 API、工具、服务或其它系统时所使用的身份或凭证的过程。这个身份可能代表一个用户、一个应用、一个工作负载、一个服务账号，或另一个机器主体。

合适的模型取决于工作流：

• 替用户办事的 agent 可能依赖被委托的 OAuth 访问令牌；
• 后台 agent 可能以应用或服务账号身份认证；
• 跑在 Kubernetes 里的 agent 可能依赖 workload identity。

认证确立"是谁 / 是什么在发这个请求"。权限范围、凭证寿命、运行时访问控制是另外三个独立的设计问题。

四、agent 到底以谁的身份认证

agent 可以用用户被委托的身份、应用身份、服务账号，或基础设施背书的工作负载身份来认证。

正确的身份取决于信任边界。 访问某个 SaaS API 用的身份，可能和运行时用的身份不同；而这两者又都可能不同于"发起这个任务的那个用户"。

一个具体的例子：一个采购 agent 替财务专员查价、下单。

• 查价那次调用，落点需要知道"这是替谁查的"——这通常是用户委托；
• 调用内部向量库那次，落点只需要知道"是哪个服务在查"——这通常是工作负载身份；
• 真正下单那次，落点需要知道"这是哪个应用、代表哪个用户、且被授权花多少钱"——这可能是三层叠加。

把三次调用都塞进同一个 API Key，省事，但事后审计时你会说不清是谁干的。

五、八种方式逐个拆

1. API Key：最常见，也最像一张通用通行证

API Key 之所以常见，是因为发起来容易、发请求也容易。视提供方而定，一个 key 可能标识的是一个应用、一个项目、一个租户、一个账号或一个集成，而不是某个具体的 agent。

大多数 API Key 的行为等同 bearer 密钥：如果同一个 key 被复制到多个 agent 进程里，任何拿到它的人，在 key 过期、被吊销或被轮换之前，都可能一直能用。

API Key 仍然有它的位置：目标系统只支持它，或者你确实不需要更丰富的身份上下文。对自主工作流，原文的建议是——把长期密钥放在 agent 进程之外，以减少直接的密钥暴露面（由代理或网关代持，agent 只拿到短期结果）。

2. OAuth：替人办事时的正确工具

当 agent 需要代表某个用户访问另一个系统时，OAuth 是对的。用户先在授权服务器上完成认证，客户端拿到代表这次委托访问的访问令牌；OpenID Connect 可以在其上加一层关于该已认证用户的身份声明。

这个模式适合替个人访问日历、文档、工单系统或其它 SaaS 应用的 agent。访问令牌通常有时限；跑得更久的工作流则依赖 refresh token 或其它续期机制。

关键区分是"用户"和"替该用户行事的软件"：OAuth 的价值就在于它把被委托的用户上下文贯穿整个工作流保留下来。

3. OAuth Client Credentials：机器对机器

Client Credentials 流程是为机器对机器设计的：应用用自己的凭证完成认证，拿到访问令牌，全程不涉及终端用户。

对服务自己的 agent 工作流和后台自动化，这很合适。即使底层的 client secret、证书或私钥寿命更长，签发的访问令牌也可以是短期的——这是把"引导凭证"和"使用凭证"分开的常见手法。

它的主要局限是身份粒度：如果多个 agent 共用一个 OAuth client，目标系统看到的就是一个应用身份。这在架构上可能是对的，但它无法区分到底是哪个 agent 进程在用它。（编者补充：如果确实需要区分，通常做的是"一 agent 一 client"，或在这个应用身份之外再叠一层运行时可核验的标识，代价是 client 数量与轮换工作量上升。）

4. Workload Identity：让环境帮你作证

Workload identity 让软件通过它所运行的环境完成认证，而不是依赖手工分发的长期密钥。云平台和 Kubernetes 环境普遍采用这个模型。

一个工作负载可以出示基础设施背书的身份，并把它换成另一个系统接受的临时凭证。Workload identity federation（工作负载身份联邦）把这个模型扩展到信任边界之外：允许把一个外部环境的身份，换成另一个平台里的短期凭证。

身份边界仍然取决于基础设施：一个 workload identity 可能代表一个 pod、一个服务账号、一个应用或其它运行时。它回答的是"这是哪个工作负载"，但它本身不回答"这个 agent 此刻要做的这个动作，应该拿到多少权限"。

5. mTLS：证明你手里真的握着那把私钥

双向 TLS（mTLS）用证书认证通信双方。客户端侧要出示 X.509 证书，并证明自己持有对应的私钥。

和 bearer 凭证不同，mTLS 要求客户端证明自己持有与证书绑定的私钥。这让它很适合 agent 基础设施之间、内部 API、网关、凭证代理之间的机器对机器通信。

代价是运维复杂度：CA、信任锚、私钥保护、续期、信任分发都要管。另外，mTLS 通常代表机器或工作负载身份，而不是被委托的用户身份。

6. 签名令牌与 JWT 断言

JWT 这类签名令牌提供了一种灵活的方式来携带身份断言。声明（claim）可以描述主体、签发方、受众、过期时间、工作负载、应用、actor 或其它上下文。

接收方需要验证签名以及它依赖的那些声明。签名有效只证明这个令牌由一个受信任的签发方产生，并不证明出示这个 bearer 令牌的人就是原本被指定的持有者。

签名断言在令牌交换流程里同样有用：把一个受信任身份换成另一个系统能理解的凭证。

需要更强证明时，可以用 mTLS 或 DPoP 这类发送方约束（sender-constrained）方法，要求出示方证明持有对应密钥，从而降低"令牌被偷了照样能用"的价值。

7. SPIFFE：给工作负载一个标准身份

SPIFFE 定义了一套工作负载身份的标准模型。一个工作负载获得一个 SPIFFE ID，并通过 SPIFFE Verifiable Identity Document（SVID）来证明这个身份。SPIFFE 同时支持 X.509-SVID 和 JWT-SVID。

SPIRE 这类实现可以自动签发并续期短期工作负载凭证，在跨 Kubernetes 集群、服务、主机和多云环境中，让工作负载拥有一致身份而不必依赖静态共享密钥。

SPIFFE 与 mTLS 是互补的：SPIFFE 定义工作负载身份，mTLS 认证这条连接。

8. 短期凭证：它是"属性"，不是"身份模型"

短期凭证更该被理解成凭证的一个属性，而不是一种独立的身份模型。OAuth 访问令牌、临时云凭证、JWT、投射服务账号令牌（projected service account token）、X.509 证书，都可以是短期的。

好处很直接：被偷走的凭证能用的时间更短。长期密钥可能在有人吊销或轮换它之前一直有效；短期凭证会自己过期。

但寿命和权限范围必须分开评估：一张 5 分钟、绑在权限很宽的服务账号上的凭证，在那 5 分钟里仍然权限很宽。

六、安全检查要看五件事

原文给出的五项清单，可以直接当评审表用：

1. 凭证代表哪个身份；
2. 凭证存在哪里；
3. 它能有效多久；
4. 它如何轮换；
5. 是否需要保留用户或租户上下文。

自主 agent 可能在一个任务里调好几个系统，这增加了凭证被暴露、被复制、被复用的位置数量。多租户系统又加了一道边界：凭证和被委托的连接必须始终绑在正确的租户或账号上。当同一个 agent 应用服务多个组织时，租户隔离尤其重要。

bearer 凭证还值得单独看一眼：短期失效缩短了暴露时间，但一个被偷的 bearer 令牌在有效期内仍然可以被重放。需要更强证明时，mTLS 或 DPoP 这类发送方约束方法可以把凭证的使用更紧地绑到预期的客户端上。

编者补充：把五项清单变成可勾选的八个问题

技术选型容易变成"选个机制"，实际问题几乎都出在细节上。下面八条来自本站以往编译的 Agent 安全案例，可作为上线前自检：

1. 这个 agent 的凭证有没有名字？ 如果日志里只能看到"某个 API Key 被使用"，事故时无法定位是哪个进程、哪个任务。
2. 长期密钥是否在 agent 进程之外？ 进程内能读到的 .env，等于把这个 key 交给了所有能让 agent 读文件的路径（参见API Key 是怎么被 LLM 读走的）。
3. 一个 key 复制了几份？ 多份副本意味着吊销时要同时清理多处，任何一处漏掉就等于没吊销。
4. 凭证寿命和执行时长是否匹配？ 任务跑 40 分钟、令牌 5 分钟过期，中间必然出现"续期逻辑"，而续期点是最常被写成"再签一个长的"的地方。
5. 权限是被令牌带着走，还是被运行时收窄？ 前者靠签发时的范围设置，后者靠每次调用前的策略判断，两者不能互相替代。
6. 多租户边界写在哪一层？ 是写进 token claim、写进网关路由，还是靠提示词约束 agent"别串号"——只有前两者算控制。
7. 失败时的默认行为是什么？ 拿不到令牌时，是拒绝执行，还是回落到一个有全量权限的备用 key。
8. 审计日志里能不能重建"谁让谁做了什么"？ 至少要能对上：发起任务的用户、执行任务的 agent 实例、用的哪张凭证、目标系统、结果。

这八条不解决"该选哪种机制"，但它们决定你选的机制上线后是否真的成立。

七、为什么对自主 agent 来说，认证还不够

传统应用安全常常假设一种稳定关系：应用 ↔ 身份 ↔ 一组可预期的动作。自主 agent 让这个关系变得不稳定，因为用什么工具、做什么动作，可能是在 agent 推理之后才被决定的。

某一步可能需要读权限，下一步可能需要一个范围很窄的写权限。认证确立的是 agent 出示哪个身份或凭证，它并不判断"通过这个身份能拿到的全部权限，是否都是下一步真正需要的"。

这就引出了另一个问题：能不能针对此刻正在执行的任务和工具动作收窄权限？

八、运行时访问控制放在哪（厂商视角）

运行时访问控制，是把一个已经通过认证的 agent 限制在"本次特定动作所需的权限"之内。AgntID 提供的正是这一层的执行能力，用来补充现有的认证与 IAM 系统——这是原文作者自身的定位，请按此理解本节。

拼起来的样子是：

• OAuth 负责建立用户委托；
• Workload identity 负责认证运行时；
• mTLS 或 SPIFFE 负责建立工作负载信任；
• 当 agent 选定某个工具时，运行时按策略 + 任务意图评估，并为这次工具调用收窄权限。

目标是"每个工具动作只拿到完成该任务所需的权限"，AgntID 把它叫 least-privilege, just-for-task access（最小权限、只够这个任务），并同时支持透传凭证与由 AgntID 签发的收窄凭证两种模式。

按其描述，运行时执行与控制留在组织自己的基础设施内，且设计上与现有 IAM、工具以及厂商托管 / 客户托管 / 自建 MCP server 兼容，不需要整体替换。

编者补充：这一段是产品说明，不是可验证的结论。评估这类产品时，值得问清楚三件事——策略从哪来、由谁维护、以及它自己的凭证怎么办。一个能签发收窄凭证的组件，本身就成了最值得保护的目标；它挂了，所有 agent 的工具调用一起挂（可用性问题），它被攻破，所有 agent 的权限一起被放大（安全问题）。这两条在任何"中心化权限收窄"方案里都存在，与具体厂商无关。

九、怎么选：先身份，再寿命，最后才是权限

原文给出的选型顺序，值得照抄成流程：

第一步，从"目标系统需要信任什么身份"出发。

第二步，评估凭证生命周期。 问：长期密钥放在哪、凭证怎么轮换、临时凭证能否替代静态凭证、agent 是否需要在更长的工作流里保持被委托的访问。

第三步，把三件事分开看。

• 认证回答是谁 / 是什么在调用；
• 短期凭证减少凭证还有多久有用；
• 运行时访问控制决定这次动作该有多少权限。

把这三件事混成一个"安全方案"，最常见的后果是：为了让 token 活得更久以支撑长任务，顺手把权限也放大了。

十、为什么真实系统总是组合使用

一个 agent 系统可能同时：用 OAuth 承载被委托的用户上下文、用 workload identity 认证运行时、用 SPIFFE 或 mTLS 保护内部服务通信、用签名令牌或令牌交换跨越信任边界。

短期凭证可以在上述好几层同时压缩寿命；运行时访问控制再针对 agent 此刻要做的那个工具动作收窄权限。

一句话总结原文的结论：把认证方式和身份边界对齐，把凭证寿命压到最短，把运行时权限控制当成独立的一层。

十一、常见问题（原文 FAQ 全译）

什么是 AI agent 认证？ 验证 AI agent 访问 API、工具、服务或数据时所使用的身份或凭证。这个身份可能代表用户、应用、工作负载或服务账号。

AI agent 怎么认证？ 可以用 API Key、OAuth、Client Credentials、Workload Identity、mTLS、签名令牌或 SPIFFE 风格的工作负载身份。正确做法取决于目标系统需要信任哪个身份。

什么是 agent 身份？ agent 向另一个系统认证时代表的那个用户、应用、服务账号、工作负载或其它机器主体。正确的身份取决于工作流与信任边界。

什么是 workload identity？ 让 agent 运行时用基础设施背书的身份完成认证，而不依赖手工分发的长期密钥。在云和 Kubernetes 环境里很常见。

什么是 workload identity federation？ 让一个工作负载用某个受信任环境里的身份，去换取另一个环境里的临时凭证。它能减少在工作负载中存储永久凭证的需要。

workload identity 对 AI agent 够用吗？ 它能认证承载 agent 的那个运行时。它本身并不决定每个 agent 工具动作该有哪些权限。

什么是 mTLS 认证？ 用证书和私钥认证通信双方，常用于机器对机器与工作负载认证。

什么是 SPIFFE？ 给工作负载分配密码学身份的一套标准，使用 SPIFFE ID 加 X.509 或 JWT 身份文档。

SPIFFE 和 mTLS 有什么区别？ SPIFFE 定义工作负载身份；mTLS 认证连接，可以使用与这些工作负载关联的证书。

API Key 适合 AI agent 吗？ 简单的集成可以用，尤其是目标系统只支持它的时候。长期存在或大范围共享的 key 会增加暴露面，并且提供的身份上下文很有限。

什么是短期凭证？ 在有限时间后过期的令牌、证书或临时凭证。它们缩短了被偷凭证还能用的时间窗口。

什么是发送方约束令牌（sender-constrained token）？ 把令牌绑定到客户端持有的密钥上。mTLS 或 DPoP 这类机制可以要求证明持有，从而让"只偷到令牌"没那么多用。

什么是 just-for-task access？ 把 agent 的权限限制在它执行特定任务或工具动作所需的范围内，在运行时按策略与任务意图施加（这一条属于 AgntID 的自我描述）。

AgntID 怎么和现有 IAM 配合？ 按原文：在运行时执行访问，IAM 继续负责建立身份与更宽范围的访问，AgntID 按策略与任务意图为每个工具动作收窄权限。

编者补充：三条常被忽略的规范（便于查证）

原文讲清了"是什么"，但没给标准编号；要落到实现和评审，下面这几份是绕不过去的：

• RFC 6749 / 6750：OAuth 2.0 授权框架与 bearer 令牌的使用。6750 明确了 bearer 令牌"谁拿到谁能用"的语义——这也是为什么需要"发送方约束"。
• RFC 8705：OAuth 2.0 的 mutual-TLS 客户端认证与证书绑定访问令牌；RFC 9449：DPoP（Demonstrating Proof of Possession）。这两份是"把令牌绑到某个客户端"的正式做法，正对应原文的 sender-constrained。
• RFC 8693：OAuth 2.0 令牌交换；RFC 7523：用 JWT 做客户端认证（即 private_key_jwt）。原文里"用一个受信任身份换另一个系统的凭证"、"客户端用签名断言认证"，对应的就是这两份。

（SPIFFE / SPIRE 属 CNCF 项目，规范本身不在 IETF RFC 序列里，看官方 spec 即可。）

十二、小结：一张纸的落地顺序

把原文的结论压成可执行顺序：

1. 画出信任边界。 这个 agent 一次任务会碰几个系统？每个系统需要信任的是"人""应用""运行时"还是"请求本身"。
2. 按边界挑机制（上表）。不要因为"API Key 简单"就把需要用户委托的场景压成集成身份。
3. 确认目标系统支持哪种生命周期。 在 5 分钟令牌与 40 分钟任务之间，先想清楚续期点写在哪，而不是延长令牌。
4. 把长期密钥移出 agent 进程，交给网关或凭证代理代持。
5. 单独设置权限收窄层，并为它自己做可用性与安全性评估。
6. 用六节那八个问题做上线自检，跑一遍日志，看能不能重建"谁让谁做了什么"。
7. 定期回答一次：如果明天某个 key 泄露，我知道它被谁用过、影响哪几个租户、多久能全部吊销吗？

第 7 条答不上来，说明前面的认证做得再"现代"，审计面还是空的。

来源

• 原文：AgntID，《AI Agent Authentication Methods: API Keys, OAuth, Workload Identity, mTLS, and Short-Lived Credentials》，2026-10-21，https://agntid.substack.com/p/ai-agent-authentication-methods-api（首发 agntid.ai）
• 原文配图：标题卡（未使用）与八行对照表截图（已重制为本文第二节表格）

相关阅读（本站）

• API Key 是怎么被 LLM 读走的：三个模型实测与四道拦截——凭证为什么会自己走进模型上下文
• LLM 网关被攻破：LiteLLM 三个漏洞如何偷走 provider key——"把 key 收到一处"之后的集中风险
• 多 Agent 同机：Git 作者、凭据与提交归属怎么分——一 agent 一身份在工程侧怎么落
• Agent 安全事故九起与六项控制——宿主 / 身份 / agent 三个攻击面
• Agent / MCP / 自动化完全指南——本专题总目录

本文由汇智网编译整理，转载请注明出处。原文版权归原作者所有；"编者补充"部分为本站观点，与原作者无关。

这是「Agent / MCP」专题的一部分。完整地图见：Agent / MCP / 自动化完全指南