Agent 身份管理实战：用 OIDC 构建安全的 AI Agent 认证体系

Agent 身份管理实战：用 OIDC 构建安全的 AI Agent 认证体系

AI Agent 与传统用户不同，它们没有浏览器 session，需要机器对机器的认证机制。OpenID Connect (OIDC) 是构建安全 AI Agent 认证体系的最佳选择，通过标准 JWT 令牌和 JWK 密钥交换，可以实现 Agent 与后端服务间的信任传递。

作为工程师，我最近在为一个多 Agent 协作的系统设计身份方案时深刻体会到：直接套用 OAuth2 的用户登录流程会踩很多坑。Agent 需要的是持久的、可验证的、细粒度的身份标识，而不是临时性的 access token。

为什么传统认证不适合 AI Agent

我遇到过最典型的问题是这样的：让 AI Agent 使用 username/password 认证，但 Agent 没有“记忆密码”的能力，每次重启都要重新获取凭据，这在分布式系统里完全不可行。

另一个常见错误是让所有 Agent 共用同一个服务账号，这样审计时就无法追踪是哪个 Agent 做了操作，出了问题也找不到责任人。我意识到必须为每个 Agent 建立独立身份。

OIDC 的优势在于它支持 client_credentials 授权模式，这是专门为机器身份设计的。Agent 可以用自己的 client_id 和 client_secret 换取 JWT 令牌，无需人类介入。

为每个 Agent 分配独立身份

在实操中，我给每个 Agent 注册独立的 OIDC client。配置示例如下：

# OIDC Client 配置示例
agents:
  - id: agent-data-analyzer
    name: "数据分析师 Agent"
    grant_types:
      - client_credentials
    scopes:
      - read:datasets
      - write:reports
    jwks_uri: https://agents.internal/jwk/agent-data-analyzer
    token_endpoint_auth_method: client_secret_post
  
  - id: agent-content-writer
    name: "内容创作者 Agent"
    grant_types:
      - client_credentials
    scopes:
      - read:knowledge-base
      - write:articles
    jwks_uri: https://agents.internal/jwk/agent-content-writer
    token_endpoint_auth_method: private_key_jwt

这里我注意到一个重要细节：安全性高的 Agent（比如能写入生产数据的）应该用 private_key_jwt 认证方式，而不是简单的 client_secret。这样即使 secret 泄露，攻击者也无法伪造令牌。

Token 结构设计要点

我设计的 Agent JWT 必须包含几个关键字段：

interface AgentTokenClaims {
  sub: string;        // Agent 唯一标识
  agent_id: string;   // 业务层 Agent ID
  agent_type: 'analyzer' | 'writer' | 'orchestrator';
  iat: number;        // 签发时间
  exp: number;        // 过期时间
  scope: string;      // 权限范围
  iss: string;        // 签发者
  jti: string;        // 令牌唯一ID，防重放
}

实践中我发现 exp 不宜设置太长，建议 5-15 分钟。Agent 需要定期刷新 token，这能限制泄露窗口。我见过有人设 24 小时，一旦 token 被截获，风险极大。

资源服务如何验证 Agent 身份

后端服务拿到 Agent 令牌后，需要验证签名并检查权限。我实现的验证流程如下：

from jose import jwt
from jose.exceptions import JWTError

class AgentAuthenticator:
    def __init__(self, jwks_url: str):
        self.jwks = None
        self.jwks_url = jwks_url
    
    def _get_jwk(self, kid: str):
        """获取指定 key ID 的公钥"""
        if not self.jwks:
            self.jwks = self._fetch_jwks()
        return self.jwks.get(kid)
    
    def verify_token(self, token: str) -> dict:
        """验证 Agent 令牌"""
        try:
            # 获取未解码的 header 以提取 kid
            unverified = jwt.get_unverified_header(token)
            kid = unverified.get('kid')
            jwk = self._get_jwk(kid)
            
            # 验证签名和声明
            claims = jwt.decode(
                token,
                keys=jwk,
                algorithms=['RS256'],
                audience='agent-service',  # 目标服务
                issuer='https://agents.internal'
            )
            
            # 额外检查：token 是否属于当前 Agent
            if claims['sub'] != claims['agent_id']:
                raise ValueError("Token identity mismatch")
            
            return claims
            
        except JWTError as e:
            logger.warning(f"Agent token validation failed: {e}")
            return None

这里我踩过一个坑：最初没有验证 aud 和 iss，导致从其他系统泄漏的 token 也能被本服务接受。加上这两个校验后，安全边界清晰多了。

端到端 Agent 调用的完整流程

在我的生产环境里，一个完整的 Agent 调用链路是这样的：

1. Orchestrator Agent 向 OIDC Provider 申请 token，带上自己的 client_credentials
2. Resource Agent 收到请求后，验证 token 签名和权限范围
3. 如果 Orchestrator 需要代表人类用户操作，还会携带 user_assertion，Resource Agent 验证后合并权限
4. 所有调用记录写入审计日志，包含 agent_id、scope、timestamp

这种设计让我可以清晰地回答“谁做了什么操作”，而不是像以前那样面对一堆匿名 API 调用头疼。

Agent 身份管理常见错误

我总结的几个最容易犯的错误：

第一个是令牌的粒度太粗。我见过一个系统让所有 Agent 共享 admin 权限，理由是“简化配置”。结果是某个 Agent 被入侵后，整个系统沦陷。

第二个是忽视了 token 轮换。Agent 缓存了旧 token，但服务端已经吊销。建议在 token 有效期过半时主动刷新。

第三个是没考虑跨租户场景。如果你的 Agent 服务多租户，必须在 token 中加入 tenant_id 并用它做隔离，否则 A 租户的 Agent 可能访问到 B 租户的数据。

最后，我强烈建议配合 mTLS 使用。OIDC 解决的是身份声明的信任问题，而 mTLS 解决的是传输通道的信任问题。两者结合，才能让 Agent 通信真正安全。

下一步实践建议

理解了 OIDC 基础后，可以考虑引入 SPIFFE/SPIRE 做更细粒度的身份绑定，或者使用 ABAC（基于属性的访问控制）配合 OIDC claims 实现动态权限决策。这些进阶方案可以在后续实践中逐步引入，先从基础的 client_credentials 模式跑通再说。