AI Agent 访问内部 API：如何做认证与审计？

当越来越多的 AI Agent 开始直接调用企业内部 API，一个现实问题浮出水面：如何确认是哪个 Agent 访问了什么数据？这个问题在 Reddit 上引发了讨论——「How do you know which agent accessed what? (auth / audit for agents hitting internal APIs)」。提问者关心的不是 Agent 能不能跑起来，而是当它跑起来之后，权限和审计链条是否还站得住。

这个问题的背后，是传统 API 安全模型正在被 Agent 的使用方式撕开一道口子。过去，一个 API Token 通常对应一个人或一个服务；现在，一个 Token 可能被多个 Agent、多个会话、甚至多个自动化任务共享。一旦出问题，日志里只有 Token 的调用记录，却很难回答「是谁在什么上下文中调用了它」。

为什么传统认证方式对 Agent 不够用

传统的 API Key 或 OAuth Token 设计，默认调用方是相对稳定的主体。但 Agent 的行为模式不同：它可能临时生成、动态编排工具调用、在多个服务之间跳转，甚至在一次任务中代表不同用户行事。如果仍然沿用「一个服务一个 Token」的做法，审计日志会退化成流水账，无法追溯到具体 Agent 实例。

更麻烦的是，Agent 往往由框架调度，调用链中夹着中间层。请求从 Agent 到编排器、再到工具网关、最后才落到内部 API，每一层都可能丢失身份信息。等到安全团队想复盘一次异常访问时，发现链条上缺了关键一环——这正是 Reddit 提问者所面临的困境。

OAuth Token 是一种授权凭证，通常由授权服务器签发，包含主体标识、权限范围（scope）和有效期等声明（claims）。在传统模型中，Token 的 subject 字段对应一个人或一个服务账号，资源服务器据此判断调用方身份与权限。当 Agent 复用同一 Token 时，所有调用共享同一 subject，OAuth 的授权粒度便无法区分具体 Agent 实例，审计日志中也只能看到 Token 层面的主体，而非真实调用者。

认证层：给每个 Agent 一个可追溯的身份

解决思路的第一层，是让 Agent 拥有独立且可验证的身份，而不是复用人类用户或通用服务的凭证。常见做法包括为每个 Agent 实例签发短期凭证，或在 OAuth 流程中把 Agent 标识写入 token 的声明字段。这样即使多个 Agent 共享同一套底层权限，日志里也能区分出具体是哪一个。

另一个关键点是「代表谁」。Agent 常常是代替某个用户执行操作，此时凭证需要同时携带 Agent 身份和用户身份，形成双重主体。否则审计时只能看到「某个 Agent 访问了数据」，却不知道这次访问是否获得了用户授权。Reddit 讨论中这一点被反复提及：认证不只是证明「你是谁」，还要证明「你代表谁」。

双重主体（dual subject）凭证指同一凭证中同时携带两个身份声明：一个是被授权执行操作的 Agent 身份，另一个是 Agent 所代表的用户身份。OAuth 2.0 的 Token Exchange（RFC 8693）规范支持通过 act（actor）声明表达代理关系，即“谁代表谁行事”。这样资源服务器既能校验用户授权范围，也能在审计中记录实际执行者，避免将 Agent 行为与用户行为混为一谈。

审计层：让调用链可还原

仅有身份还不够，审计需要把一次 Agent 任务的完整调用链串起来。实践中可以从两个方向入手：一是给每次任务分配关联 ID，让 Agent 框架在调用下游 API 时透传该 ID；二是在 API 网关层记录请求的元数据，包括 Agent 标识、关联 ID、访问的资源以及时间戳。

这些记录的价值在于事后可还原。当出现数据异常访问时，团队可以通过关联 ID 把散落在各个服务里的日志拼成一条完整路径，回答「哪个 Agent、在哪个任务中、访问了哪些资源」。相比只记录 IP 和 Token，这种粒度的审计更贴近 Agent 的实际行为。

关联 ID（Correlation ID）是分布式系统中用于串联一次请求跨多个服务调用的唯一标识。在 Agent 场景中，它通常由发起任务的框架生成，并通过 HTTP 头（如 X-Correlation-ID 或 W3C Trace Context 的 traceparent）逐层透传。API 网关在入口处记录该 ID 及请求元数据，下游服务在日志中一并输出，事后即可用该 ID 聚合所有相关日志，还原完整调用路径。

落地时的现实取舍

理想方案听起来清晰，落地却要面对工程复杂度。为每个 Agent 签发短期凭证意味着要维护签发和轮换机制；透传关联 ID 要求框架层和网关层配合改造；双重主体凭证则可能让权限模型变得更绕。对于已经在跑内部 API 的团队，这些改动不是一蹴而就的。

一个务实的起点是先补齐日志中的 Agent 标识字段，哪怕暂时做不到短期凭证轮换，至少让审计记录能区分调用来源。然后逐步把关联 ID 透传纳入框架规范，再考虑凭证粒度的收紧。Reddit 上的讨论也反映出这种渐进思路——大家更关心「能不能先让日志说清楚」，而不是一步到位建成完整体系。

短期凭证（short-lived credential）指有效期很短（通常几分钟到几小时）且可自动轮换的访问凭证，常见实现包括 OAuth 的 client credentials 流配合短 TTL，或基于 SPIFFE/SPIRE 等 workload identity 框架签发的 SVID。相比长期有效的静态 API Key，短期凭证能缩小泄露后的攻击窗口，并迫使每次签发都绑定具体 Agent 实例，从而在日志中天然留下可追溯的身份痕迹。

常见问题

Agent 复用同一个服务 Token 有什么风险？ 审计日志无法区分具体 Agent 实例，异常访问难以追溯到责任主体，权限回收也会波及所有共用该 Token 的 Agent。

关联 ID 应该由谁生成？ 通常由发起任务的 Agent 框架生成，并在调用下游服务时透传，API 网关负责记录，确保链路两端能对上。

小团队需要做到什么程度？ 至少保证日志中包含 Agent 标识和任务关联信息，能回答「哪个 Agent 在什么时候访问了什么」，再根据实际风险逐步加强凭证管理。