AI Agent身份认证与授权：IETF草案核心解读与安全实践

为什么 AI Agent 需要专门的认证标准

随着 AI Agent（智能体）从实验室走向生产环境，一个长期被忽视的基础设施问题正浮出水面：当自主运行的 AI 代替人类去调用 API、访问数据、执行交易时，系统该如何识别它、信任它、并限制它的权限？ 近日，IETF（互联网工程任务组）发布了一份关于「AI Agent 身份认证与授权」的 Internet-Draft，试图为这一空白领域建立标准化基础。

IETF 是全球互联网标准的核心制定机构，负责制定 TCP/IP、HTTP、TLS 等几乎所有互联网基础协议。Internet-Draft 是 IETF 标准化流程的第一步，任何人都可以提交草案，经过工作组讨论、多轮修订后，优秀的草案会晋升为 RFC（Request for Comments）正式标准文档。这一流程通常需要数月到数年时间，确保技术方案经过充分审议。IETF 介入 AI Agent 认证领域，意味着业界已经认识到这不仅是某一家公司的私有问题，而是需要全行业共同解决的互联网基础设施级别的挑战。

传统的认证体系是围绕两类主体设计的：一类是「人」（通过密码、多因素认证、OAuth 登录），另一类是「机器/服务」（通过 API Key、服务账户、mTLS 证书）。其中，mTLS（mutual TLS，双向传输层安全）是一种服务间通信的强认证机制，要求通信双方都出示数字证书互相验证身份，在微服务架构和零信任网络中被广泛采用。每个服务持有由受信任证书颁发机构签发的证书，通信前双方互验证书合法性。这种机制非常适合身份固定、行为可预测的传统服务，但对于行为动态变化、可能在运行时自主决定调用哪些服务的 AI Agent 而言，静态证书体系的灵活性明显不足。

而 AI Agent 恰好落在「人」与「机器」两者之间——它既不是完全自主的机器，也不是直接操作的人类。它往往代表某个用户行事，却又能在无人监督下持续做出决策。这种「代理身份」的模糊性，正是现有认证框架难以覆盖的痛点。

代理身份的三重难题

第一是身份归属问题：当一个 Agent 调用 API 时，服务端看到的到底是这个 Agent 本身，还是它背后授权它的人类用户？

第二是权限边界问题：用户授予 Agent 的权限，是否应该等同于用户本人的全部权限？显然不应该——一个帮你整理邮件的 Agent 不该拥有转账的能力。

第三是委托链追溯问题：当 Agent 又调用了另一个 Agent（多智能体协作场景），责任和权限如何逐级传递并保持可审计？多智能体协作（Multi-Agent Collaboration）是当前 AI 领域的重要趋势——一个主 Agent 可能将子任务分配给多个专用 Agent，例如旅行规划 Agent 调用航班搜索 Agent、酒店预订 Agent 和日程管理 Agent。每一次调用都构成一次权限委托，形成树状或链状的委托结构。在分布式系统中，类似问题曾出现在 Kerberos 协议的受约束委托和 SPIFFE/SPIRE 等工作负载身份框架中，但 AI Agent 的委托链更加复杂，因为 Agent 可能在运行时动态决定是否需要调用另一个 Agent，这种不可预测性要求委托机制必须支持实时授权验证与即时撤销。

IETF 草案的核心目标与技术方案

这份 Internet-Draft 的核心目标，是为 AI Agent 的认证与授权提供一套可互操作的协议规范。它触及的问题具有重要的前瞻性意义，将深刻影响 AI Agent 基础设施的发展方向。

在 OAuth 2.0 等现有标准之上扩展

从技术路线看，此类草案通常不会推翻现有体系，而是选择在 OAuth 2.0 和 OpenID Connect 等成熟标准之上进行扩展。

OAuth 2.0 是当前互联网授权体系的事实标准，其核心设计解决的是「第三方应用如何在不获取用户密码的情况下访问用户资源」的问题。它通过引入授权服务器、访问令牌（Access Token）、刷新令牌（Refresh Token）等机制，将认证与授权解耦。OpenID Connect（OIDC）则是构建在 OAuth 2.0 之上的身份认证层，通过 ID Token（基于 JWT 格式）提供用户身份信息。两者结合构成了现代互联网身份体系的基石——从「用 Google 账号登录」到企业单点登录（SSO）都依赖这套体系。然而，OAuth 2.0 最初设计时只考虑了人类用户授权第三方应用的场景，并未预见到「自主决策的 AI 代理」这一全新主体类型的出现。

可能的扩展方向包括：

• 引入「代理令牌（Agent Token）」概念，在访问令牌中显式标注「此请求由 Agent 代表某用户发起」，让服务端能够区分对待；
• 细粒度的委托范围（delegation scope），允许用户将自身权限的一个子集精确授予 Agent；
• 可验证的委托链，通过密码学签名记录「用户 → Agent A → Agent B」的完整授权路径，保证每一环都可追溯、可撤销。

为什么标准化如此重要

如果没有统一标准，每家 AI 平台都会各自发明一套代理认证机制，结果就是生态碎片化——OpenAI 的 Agent 无法安全地调用其他平台生态的服务，企业内部的自动化流程也难以跨系统打通。IETF 推动标准化的价值，正在于让不同厂商、不同 Agent 之间能够在共同的信任框架下互操作，这与当年 OAuth 统一了第三方登录的意义类似。

与 MCP 协议及 Agent 生态的关系

有意思的是，这份草案出现的时间点耐人寻味。近期，Anthropic 推出的 MCP（Model Context Protocol） 让 Agent 连接外部工具成为主流实践，各大厂商也纷纷推出 Agent 框架。

MCP 是 Anthropic 于 2024 年底推出的开放协议，旨在标准化大语言模型与外部工具、数据源之间的连接方式。MCP 采用客户端-服务器架构，定义了工具发现、调用、结果返回等标准接口，类似于 AI 领域的 USB-C 接口——让任何 AI 模型都能以统一方式接入任何外部能力。MCP 迅速获得了 OpenAI、Google、Microsoft 等主要厂商的支持，成为 Agent 工具调用的事实标准。然而，MCP 当前版本主要关注功能互通性，其安全模型相对简单，通常依赖运行环境的已有认证机制，缺乏针对代理场景的专门授权设计。

但这些协议大多聚焦于「如何让 Agent 调用工具」，却在「如何安全地授权 Agent」这一环节留下了明显缺口。换句话说，业界先解决了「能力」问题（Agent 能做什么），现在才开始认真面对「信任」问题（Agent 被允许做什么）。IETF 的介入，标志着 AI Agent 基础设施正从「快速原型」阶段迈向「可靠工程」阶段。

AI Agent 安全风险与最小权限原则

一个缺乏严格授权约束的 Agent 是巨大的安全隐患。设想以下场景：一个被提示注入（prompt injection）攻击劫持的 Agent，如果持有用户的完整权限令牌，攻击者就能借它之手删除数据、发起交易、泄露隐私。

提示注入是针对大语言模型应用的一类新型攻击手段，其原理类似于传统 Web 安全中的 SQL 注入——攻击者将恶意指令嵌入模型可能读取的数据中（如网页内容、邮件正文、文档），当 AI Agent 处理这些数据时，恶意指令被模型当作合法指示执行。例如，一封邮件中隐藏的文字可能指示邮件助手 Agent 将所有联系人信息转发给攻击者。间接提示注入尤其危险，因为攻击面极广——Agent 接触的任何外部数据都可能是攻击载体。这使得权限最小化成为不可或缺的纵深防御手段。

而如果 Agent 从设计之初就被限制在最小权限范围内，并且每一步操作都可审计、可回溯，那么即使被攻破，损失也能被有效控制。这正是「最小权限原则」在 AI 时代的新演绎。

最小权限原则（Principle of Least Privilege, PoLP）最早由 Jerome Saltzer 和 Michael Schroeder 在 1975 年的经典论文中提出，是计算机安全领域最基本的设计原则之一。其核心思想是：系统中的每个主体只应被授予完成其任务所必需的最小权限集合，不多不少。这一原则在操作系统（进程权限）、数据库（角色权限）、云计算（IAM 策略）等领域已有成熟实践。在 AI Agent 时代，最小权限原则面临新的实施挑战：Agent 的行为具有不确定性，难以在设计时精确预知它需要哪些权限；同时 Agent 的任务可能动态变化，需要权限体系支持按需申请和实时调整。

开发者应该如何提前布局

尽管这份 Internet-Draft 目前仍处于草案阶段，但它所指向的问题——AI Agent 的身份、信任与责任边界——将随着 Agent 的规模化部署而变得愈发关键。可以预见，围绕 Agent 认证授权的标准之争会日趋激烈，OAuth 工作组、各大 AI 厂商乃至企业安全团队都会加入其中。

对于开发者而言，现在就应该开始思考：

• 你构建的 Agent 是否遵循最小权限原则？
• 它的委托链是否可审计？
• 权限令牌是否支持细粒度的范围控制？

当标准最终落地时，提前布局的团队将占据先机。基础设施的价值往往在它缺席时才被察觉——而 AI Agent 的认证授权体系，正是这样一块正在被悄悄奠基的基石。