AI Agent身份安全：如何堵住自主执行的授权缺口

企业花了很多年加固终端安全，却把真正的爆炸半径留在了无人看管的地方：AI代理调用工具、改动生产数据库、执行代码的那一瞬间。大部分中型企业已经把一批半自主的AI实体接入了核心系统，给了它们权限过高的凭证，却没有给它们原生身份。这不是对齐问题，这是一场AI代理身份安全危机。

什么是AI中的"困惑代理人"问题

困惑代理人（Confused Deputy）问题指的是：一个持有合法凭证的AI代理，被恶意提示词操纵，代表攻击者去执行未授权操作。

当AI代理调用某个工具时，它通常依赖一个预先分配的静态凭证，比如固定的AWS服务账号token。接收请求的系统看到一个有效token，它无法判断这次操作到底是你本意要执行的，还是代理被操控后的结果。

一个客服代理被要求总结工单。那张工单里藏着一段提示注入载荷，命令它把用户数据库导出。因为代理共用着一个权限过宽的数据库凭证，它会照单全执行。等到数据出现在暗网上，你才可能发现。

共享凭证直接违反了最小权限原则，也摧毁了的确如此性。Gartner在其安全预测中估计，相当比例的企业AI泄露事件会利用这一漏洞。机器身份的AI代理需要独立档案，附带绑定到具体任务的、可审计的权限范围。

困惑代理人问题的历史渊源

困惑代理人（Confused Deputy）并非AI时代的新问题，它最早由Norm Hardy于1988年提出，用来描述一种经典的安全漏洞：一个拥有合法权限的程序（即“代理人”）被诱导，替攻击者执行了它本不该执行的操作。传统案例中，一个编译器程序拥有写入计费文件的权限，攻击者通过操纵编译器输出路径，让编译器以自身权限写到敏感文件。核心矛盾在于：系统只验证了“代理人”的身份，却没有验证“委托人”的真实意图。AI代理把这个问题放大了：代理本身就持有凭证，而提示注入使得攻击者可以间接“借用”这些凭证。理解这一历史脉络有助于认识到，AI代理身份安全本质上是经典授权模型在自主实体场景下的延伸，而非全新问题。

用身份机制保护AI代理的工具调用

要保护工具调用，必须签发短暂的、上下文感知的凭证，并严格限定在当前任务范围内，同时用AI代理网关来强制执行零信任策略。

核心思路是把AI代理当作独立实体来对待，不要再给它们人类级别、长期有效的访问权限。

采用OAuth2机器对机器流程。 把静态API密钥换成短期JWT。静态密钥一旦泄露就是长期敞口，短期令牌把风险窗口压到最小。

按任务签发凭证。 编排层启动一个工作流时，应当签发一个任务结束即失效的凭证。即便发生提示注入导致代理被攻陷，破坏范围也被限制在单次任务内。

追踪行为异常。 身份不只是凭证，还包括行为。代理遵循程序化的模式，它们的工具调用是可预测的。如果一个代码生成代理突然试图修改IAM角色，应当立即阻断。

据Ponemon Institute的报告，未受管理的机器身份给企业带来的平均单次事件成本高达数百万美元级别。这件事没有做错的余地。

OAuth2机器对机器流程与短期JWT

OAuth2的机器对机器（M2M）流程，也叫客户端凭证模式（Client Credentials Grant），是专为无用户交互的服务间通信设计的授权方式。AI代理作为客户端，用自身的客户端ID和密钥向授权服务器换取访问令牌（通常是JWT）。与静态API密钥不同，JWT可以内嵌过期时间、受众（audience）、任务范围（scope）等声明，接收方可以独立验证其有效性。在AI代理场景下，编排层可以在每次启动任务时动态签发一个作用域仅限该任务的JWT，任务结束即失效。即使令牌在任务中被泄露，攻击者能利用的窗口也极短。这种“按任务签发、短时有效”的模式，正是把最小权限原则落到执行层的关键机制。

什么是AI代理网关

AI代理网关是位于AI编排层与企业工具之间的专用控制平面，拦截每一个请求，验证身份、执行策略、记录操作。

没有拦截点，就无法保护执行层。原文给出的架构是：用户主体调用代理编排器，编排器发起的每一次工具调用都必须经过网关，网关再转发给企业工具，同时把事件写入不可篡改的审计日志。

每一个AI工具调用都必须流经这个网关。它负责三件事：验证代理的JWT；依据NIST SP 800-207等框架执行策略；根据载荷内容对困惑代理人攻击的风险打分。

传统API网关与AI代理网关的差别很清楚：前者用静态API密钥、全局或服务级范围、没有上下文；后者用短暂JWT、按任务划分范围、携带人类委派上下文。这个对比本身就说明了为什么把老网关直接套到代理场景行不通。

NIST SP 800-207零信任架构

NIST SP 800-207是美国国家标准与技术研究院发布的零信任架构（Zero Trust Architecture）指南，其核心原则是“永不信任，始终验证”。它摒弃了传统的边界防御模型，要求对每一次访问请求都进行身份验证和授权，无论请求来自内网还是外网。在AI代理场景中，零信任意味着网关不能因为请求来自“内部编排器”就放行，而必须逐次校验代理身份、任务上下文和策略合规性。网关正是零信任架构中的策略执行点（PEP），而身份提供方和策略引擎则构成策略决策点（PDP）。将AI代理网关与NIST SP 800-207对齐，可以确保代理的每一次工具调用都符合企业既定的访问控制策略。

在企业环境中治理自主AI代理

治理自主代理的前提是看得见它们。影子AI扩散很快，据Logic42在2026年第二季度的自有遥测数据，12%的"超级采用者"把LangChain这类开源框架直接硬编码进核心业务，完全绕开了IT。这就是代理化AI治理不可回避的原因。

如果看不见，就保护不了。工程上需要几条硬规则。

分析网络流量。 建立出站API流量的基线，从中找出未受管理的编排器。异常的外连模式往往是影子代理留下的痕迹。

部署工具级蜜罐。 设置诱饵API来捕获自主枚举行为。代理会试探它不该碰的接口，蜜罐能提前暴露这一点。

强制注册。 任何想要触碰生产数据库的程序化实体，都必须出示已注册的身份。未签名的请求直接丢弃。

密码学审计与网关绕过防护

AI代理身份安全要求一条不可篡改的审计链路，记录代理ID、被委派的用户、调用的具体工具以及确切的载荷，以保证的确如此性。

普通的日志不够用，太容易被伪造。原文建议采用一个密码学关联的七点审计向量，可以直接接入OpenTelemetry：

1. 代理ID
2. 任务ID
3. 用户主体
4. 工具名称
5. 参数
6. 结果
7. 时间戳

缺少这套拆分，事件响应就会失去基础。

如果自主代理绕过网关会怎样

如果代理试图在网关之外执行工具调用，企业资源——比如数据库或内部API——必须直接拒绝该请求。实现方式是强制双向TLS（mTLS），并确保目标系统只接受来自网关IP、且携带网关密码签名的流量。绕过网关的请求不能有任何被接受的通道。

不可篡改审计与OpenTelemetry

不可篡改审计通常依赖密码学技术，如哈希链或数字签名，使日志一旦写入便无法被悄悄修改。哈希链将每条日志的哈希值与前一条关联，任何篡改都会破坏后续所有哈希。在AI代理场景中，七点审计向量（代理ID、任务ID、用户主体、工具名、参数、结果、时间戳）被打包并签名，形成可验证的事件记录。OpenTelemetry是云原生计算基金会（CNCF）下的可观测性框架，提供统一的API和SDK来采集追踪、指标和日志。将审计向量接入OpenTelemetry，意味着代理行为可以与企业现有的可观测性管道无缝集成，同时借助导出器将签名后的记录写入不可篡改存储，为事件响应提供可信证据链。

结论

与其继续纠结提示词工程，不如先去保护执行载荷。在你把过高的权限从代理身上剥离之前，系统一直在透支安全余量。真正的AI代理身份安全要求每一次动作都被授权、被观察、被记录。

原文还提供了两个可交互的评估工具：一个是针对ISO/IEC 42001:2023 AI管理体系（AIMS）的就绪度诊断，号称3.5分钟给出阶段1阻塞项检测和可下载的董事会PDF；另一个是用于测算前沿MoE模型的HBM3e显存驻留与24个月裸金属回本周期的计算器，均托管在Logic42站点上。