> ## Content Index > Fetch the complete content index at: https://www.hubwiz.com/blog/llms.txt > Use this file to discover other available public pages before exploring further. # AI Agent 认证方式怎么选：API Key、OAuth、mTLS 与短期凭证 - URL: https://www.hubwiz.com/blog/ai-agent-authentication-methods/ - Published: 2026-10-24T18:49:04.000Z - Updated: 2026-10-24T18:50:19.000Z - Description: API Key 证明"这是一个集成"，OAuth 证明"这是替某人办事"，mTLS 证明"这个进程手里有私钥"。认不清身份边界，换再新的机制也只是把旧问题搬个家。 - Author: admin - Tags: AI Agent, 身份认证, OAuth, mTLS, 凭证管理, AI 安全 **一句话结论**：选认证方式时，先别问"用哪种机制"，先问**四个问题**——证明哪个身份、向哪个系统证明、证明多久、代表谁。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 客户端可以用共享密钥、证书或签名断言来完成认证。 **结论：它们不是可互相替换的选项。有些负责建立身份，有些负责携带身份声明，另一些负责定义最后拿到的那张凭证能活多久。** ## 二、八种方式一张表 原文的对照表是本篇最有用的部分，重制如下（列含义：证明的身份 / 拿到的凭证 / 典型寿命 / 委托上下文 / 最适合 / 主要风险）： | 方式 | 证明的身份 | 凭证形态 | 典型寿命 | 委托上下文 | 最适合 | 主要风险 | | ------------------------ | --------------- | -------------------------------- | ----------------- | -------------- | -------------------- | ----------------------- | | API Key | 集成或应用 | 共享的 bearer 密钥 | 通常长期 | 通常没有 | 简单 API 集成 | 重放；归因能力弱 | | OAuth / OIDC | 用户 | 访问令牌，可选 refresh token 与 ID token | 访问令牌通常短期 | 用户委托 | 代表用户访问 SaaS / API | refresh token 暴露；委托范围过宽 | | OAuth Client Credentials | 应用或服务 | 客户端密钥、私钥断言或证书，用于换取访问令牌 | 访问令牌通常很短；引导凭证可能更久 | 应用上下文 | 服务间调用、后台工作流 | 多个 agent 共享同一个应用身份 | | Workload Identity / 联邦 | 工作负载或运行时 | 基础设施背书的断言，换成临时凭证 | 通常短期 | 工作负载上下文 | 云原生、跨云工作负载 | 信任配置出错 | | mTLS / X.509 | 客户端或工作负载 | X.509 证书 + 私钥 | 可配置 | 通常是工作负载或客户端上下文 | 服务间认证 | PKI 与密钥管理负担 | | 签名令牌 / JWT 断言 | 用户、应用、工作负载或其它主体 | 签名的 JWT 或类似令牌 | 通常限时 | 灵活 | 联邦、令牌交换、跨域身份 | 未被绑定发送方时仍可重放 | | SPIFFE 工作负载身份 | 工作负载 | X.509-SVID 或 JWT-SVID | 设计上就是短期 | 工作负载上下文 | Kubernetes、多云、动态基础设施 | 证明（attestation）与信任域复杂度 | | 短期凭证 | 取决于签发方 | 临时令牌、证书或派生凭证 | 分钟、小时，或随任务时长 | 取决于签发上下文 | 需要尽量不留长期密钥的工作流 | **寿命短并不修正过宽的权限** | 这张表的关键读法：**纵向看"证明的身份"，横向看"寿命"与"委托"。** 你换一行，通常换掉的是前两列；你换"短期凭证"这一行，换掉的只是寿命那一列。 ## 三、什么是 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 读走的](https://www.hubwiz.com/blog/llm-api-key-leakage-agent-context/)）。 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 的权限一起被放大（安全问题）。这两条在任何"中心化权限收窄"方案里都存在，与具体厂商无关。 ## 九、怎么选：先身份，再寿命，最后才是权限 原文给出的选型顺序，值得照抄成流程： **第一步，从"目标系统需要信任什么身份"出发。** | 目标系统需要信任的 | 合适的做法 | | --------------- | -------------------------- | | 只需要认出"这是一个集成" | API Key 可能就够了 | | 需要知道"这是替某个用户办事" | OAuth 用户委托 | | 需要一个应用自己的后台工作 | Client Credentials | | 需要基础设施背书的机器身份 | Workload Identity / SPIFFE | **第二步，评估凭证生命周期。** 问：长期密钥放在哪、凭证怎么轮换、临时凭证能否替代静态凭证、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，（首发 agntid.ai） - 原文配图：标题卡（未使用）与八行对照表截图（已重制为本文第二节表格） **相关阅读（本站）** - [API Key 是怎么被 LLM 读走的：三个模型实测与四道拦截](https://www.hubwiz.com/blog/llm-api-key-leakage-agent-context/)——凭证为什么会自己走进模型上下文 - [LLM 网关被攻破：LiteLLM 三个漏洞如何偷走 provider key](https://www.hubwiz.com/blog/litellm-gateway-api-key-theft/)——"把 key 收到一处"之后的集中风险 - [多 Agent 同机：Git 作者、凭据与提交归属怎么分](https://www.hubwiz.com/blog/multiple-coding-agents-identity-git-attribution/)——一 agent 一身份在工程侧怎么落 - [Agent 安全事故九起与六项控制](https://www.hubwiz.com/blog/agent-security-nine-incidents-six-controls/)——宿主 / 身份 / agent 三个攻击面 - [Agent / MCP / 自动化完全指南](https://www.hubwiz.com/blog/agent-stack/)——本专题总目录 本文由汇智网编译整理，转载请注明出处。原文版权归原作者所有；"编者补充"部分为本站观点，与原作者无关。 > **这是「Agent / MCP」专题的一部分。**完整地图见：[Agent / MCP / 自动化完全指南](https://www.hubwiz.com/blog/agent-stack/)