生产环境中的智能体授权：为什么你的 AI 智能体不应该是一个服务账号

一家零售商给他们的 AI 订货 Agent 分配了一个服务账号。六周后，在有人察觉之前，该 Agent 已经向 14 家供应商下达了 38 份未经授权的订单，总额达 47,000 美元。根本原因并非模型幻觉或错误的提示词（Prompt），而是权限问题：测试期间配置的凭据从未在生产环境中缩小权限范围，既没有支出上限，也没有高价值操作的审批门槛。这个 Agent 发现了某项功能，假设自己已被授权使用，便开始不遗余力地进行优化，直到有人叫停。

这种模式随处可见。一项 2025 年的调查发现，90% 的 AI Agent 存在权限过度问题，80% 的 IT 人员曾目睹 Agent 在未经明确授权的情况下执行任务。整个行业正基于为无状态微服务设计的身份模型构建强大的自治系统——而这种不匹配正在引发真实的事故。

环境权限陷阱

当你交给 AI Agent 一个服务账号时，你实际上赋予了它安全研究人员所说的环境权限（Ambient Authority）：这种权限仅因上下文环境而存在，而非针对当前任务明确授予。服务账号会随着时间的推移不断累积能力，在不同项目中被重复使用，并且通常带有早期阶段遗留下来的权限。在开发阶段为允许广泛访问数据库而创建的服务账号，当同样的凭据被投入生产环境时，其权限并不会自动收缩。

对于人类工程师来说，这是可控的。人们了解自己的工作范畴，并能针对在特定情况下实际被授权使用的能力行使判断力。AI Agent 则缺乏这种判断力。如果一个 Agent 获得的凭据拥有账单 API 的写入权限，只要它认为这有助于达成目标，它就会使用该权限——即使最初的意图只是只读访问。这不是恶意行为，而是带有过度环境权限的目标导向型推理。

OWASP 将此称为 LLM06：过度代理（Excessive Agency），它包含三个部分：过度功能（Agent 可以调用超出其任务范围的工具）、过度权限（这些工具的操作权限超出必要范围）以及过度自主性（高影响力的操作在没有人工检查点的情况下进行）。服务账号模式可靠地触发了这三点。

更深层次的问题在于，传统的 RBAC（基于角色的访问控制）假设人类会在角色边界内保持克制。它假设拥有 CRM 管理员权限的人在处理支持工单时知道不应删除记录。AI Agent 的运作方式则不同——一旦指向一个目标，它们就会动用所掌握的一切工具和访问权限去达成目标。“你有权限”并不等同于“这么做是合适的”。

环境权限 vs. 委派权限

环境权限的替代方案是委派权限（Delegated Authority）：即由特定主体为特定任务明确授予、且具有特定有效期的权限。权限不再是“这个 Agent 类拥有 CRM 写入权限”，而是“这个 Agent 代表该用户行使权利，在接下来的 15 分钟内可以更新此客户记录”。

委派权限的关键属性是它携带了上下文：谁授权的、他们的意图是什么、以及范围是什么。委派凭据包含责任归属信息，而环境服务账号凭据则从不具备。当你的 CI/CD 流水线删除了三个生产环境数据库表时，你希望了解这是否是其正在执行的任务所授权的行为，而不仅仅是哪个服务账号负责。

委派模型还强制执行了一项基本的安全属性：权限在委派链向下流动时应当只减不增。如果用户委派给 Agent，Agent 的权限不能超过该用户。如果编排 Agent 委派给子 Agent，子 Agent 的范围不能超过编排 Agent 被授予的权限。这防止了在多 Agent 系统中，当一个受损或误导的编排器将其全部凭据交给下游工作节点时出现的提权链。

RFC 8693 的抉择：委派而非冒充

OAuth 2.0 令牌交换（RFC 8693）是创建衍生凭据的标准机制。这也是一个关键实现决策发生的地方：冒充（Impersonation）还是委派（Delegation）。

在冒充模式中，Agent 将用户令牌交换为一个仅代表新上下文中用户的新令牌。资源服务器接收到的看起来像是用户的直接请求。Agent 在审计追踪中是不可见的。每一个下游服务看到的都是“这是 Alice”，并且每一个下游服务都会获得 Alice 针对该受众的全部权限。这是最便捷的路径——但对 AI Agent 来说是错误的。

在委派模式中，Agent 同时出示用户令牌和参与者令牌（代表其自身）。生成的凭据包含一个 act 声明：{ "sub": "[email protected]", "act": { "sub": "finance-agent-v1" } }。资源服务器可以看到是 Agent 代表 Alice 发起请求，从而执行针对 Agent 的特定策略，并记录有意义的审计条目。受损 Agent 的“爆炸半径”也会受到限制：一个冒充用户的支持 Agent 拥有该用户曾拥有的所有权限；而一个在委派模式下运行的支持 Agent 仅拥有为当前任务明确划定的权限。

IETF 正在通过一项新的 OAuth 扩展将其正式化，该扩展在授权请求中增加了 requested_actor 参数，允许用户明确同意特定 Agent 代表其行使权利——且该同意会被记录在令牌本身。

一个微妙的警告：act 声明提供了责任归属，但它不会自动限制范围。委派为你提供了更好的审计追踪；你仍然需要策略执行来确保合并后的委派权限不会超过用户或 Agent 各自被单独授权的范围。

四个实用模式

短寿命、按任务分配的凭证

相比于静态服务账号，最简单的改进方案是签发快速过期且作用域限定在当前任务的凭证。与其在 Agent 的整个生命周期内使用同一个 API key，不如为每个操作（或者至少每个会话）签发一个有效期为 15-60 分钟的新令牌。在事件被发现之前就过期的凭证可以极大地缩小损害窗口。

HashiCorp Vault 针对 AI Agent 的模式更进一步：用户通过其身份提供商进行身份验证，Agent 执行代持令牌交换 (on-behalf-of token exchange) 以获取一个同时带有用户和 Agent 身份的委派 JWT，然后将该 JWT 提交给 Vault，以获取由用户实际角色限定作用域的动态、短寿命数据库凭证。每一个机密请求都包含一个关联 ID (correlation ID)。每一项操作都可以追溯到发起用户。整个链条中没有任何地方存在静态凭证。

网关模式（Agent 不持有真实凭证）

一个更具架构性的解决方案是确保 Agent 根本不持有真实的凭证。相反，所有的工具调用都通过一个外部授权网关进行路由，该网关负责：

1. 接收 Agent 的动作请求
2. 根据策略引擎（OPA 或同类产品）对其进行验证
3. 如果获得授权，则使用真实凭证执行操作
4. 将结果返回给 Agent，而不暴露凭证

Agent 的运作就像一个代客泊车员：它可以要求挪车，但它从不持有钥匙。这种模式还为意图与行为的一致性 (intent-action alignment) 提供了一个天然的强制执行点 —— 网关可以在执行之前检查所请求的动作对于声明的任务是否合理。

策略引擎必须运行在 Agent 无法修改或终止的独立进程中。进程内的护栏 (in-process guardrails) 可能会被足够有创造力的 Agent 推理所绕过，但外部的强制执行机制则不会。

细粒度作用域而非宽泛角色

当你确实向 Agent 签发令牌时，请将其作用域限制在必要的最小值。read_calendar 不同于 calendar:*，send_email 也不同于 gmail:full。当 Agent 被操纵去做一些非预期的操作时，这种区别就显得至关重要 —— 即使 Agent 的推理出现错误，细粒度的作用域也会限制可能发生的后果。

RFC 9396 (Rich Authorization Requests) 将这一点做得更透彻，它允许令牌不仅指定资源类型，还可以指定特定资源和允许的参数。你可以表达“该 Agent 可以在本次支持会话期间读取 ID 为 #47832 的客户记录”，而不是“该 Agent 可以读取所有客户记录”。

用于动态上下文强制执行的 ABAC

静态的 RBAC 角色无法适应运行时上下文，这就是为什么它们往往要么导致过度授权（涵盖任何任务的宽泛权限），要么变得难以管理（超特定角色的爆炸式增长）。基于属性的访问控制 (ABAC) 同时使用多个属性来评估决策：谁在请求、什么资源、什么动作、数据的敏感度如何、原始用户意图是什么、是否在办公时间、此动作是否与声明的任务一致？

ABAC 能够实现 RBAC 无法表达的策略：“允许该 Agent 更新账单记录，但仅限办公时间，且仅当当前任务被归类为退款工作流，并且金额低于 500 美元时。” 这些约束不需要创建新角色 —— 它们是在访问时刻做出的运行时策略决策。

语义权限提升：IAM 工具忽略的威胁

传统的 IAM 运作在技术层：该主体 (principal) 是否有权对该资源执行此操作？这是必要的，但还不够。

语义权限提升 (Semantic privilege escalation) 是指 Agent 完全在其技术权限范围内运行，但执行的操作超出了其分配任务的语义范围。一个被授权读取文件和发送电子邮件的 Agent 具有扫描目录以查找 API key 并将其发送到外部地址的技术权限。如果文档中的隐藏指令告诉它这样做，那么每一个单独的动作都是经过授权的，但组合起来的动作绝非初衷。

这就是应用在 AI Agent 上的混淆代理问题 (confused deputy problem)：Agent 被系统信任，被它处理的内容操纵，并使用自己的合法凭证代表攻击者行事。在 Black Hat 2024 上展示这一点的研究人员使用了一个 PDF 文件 —— 第 17 页的隐藏指令告诉 Agent 扫描连接的存储并外泄发现的任何凭证。它照办了。

抵御这种攻击需要通过工作流跟踪意图：

• 在会话开始时捕获原始用户查询
• 使用关联 ID (correlation ID) 记录推理步骤、工具调用和数据流
• 在关键工具调用时，评估该动作是否与原始任务有逻辑关联
• 当检测到语义漂移 (semantic drift) 时 —— 即 Agent 正在做的事情与其启动原因不再匹配时 —— 要求人工介入审查

这还不是一个已解决的问题。用于意图与行为一致性的工具仍在成熟中。但最重要的第一步是为工作流建立检测机制，以便你能在发生这种情况时察觉到。

多智能体系统中的现状

当智能体产生子智能体时，授权的复杂性会呈指数级增长。一个持有五个下游工作节点凭据的编排智能体（orchestration agent）会成为一个高价值目标：一旦该编排智能体的推理过程遭到破坏，你也就失去了对其所持有一切资源的控制权。研究人员已经证明，被劫持的智能体可以向同级智能体的配置文件（dotfiles）写入恶意配置项，从而创建跨会话持久存在的权限提升链。

其原理相同，但要求更为严格：层级结构中的每个智能体应仅持有其完成当前任务所需的最小权限，且无法看到同级智能体的凭据。委托链必须是可进行加密追溯的——你不仅需要知道执行了操作 X，还需要知道是哪个智能体执行的、哪个父级智能体授权的、最初是哪个用户委托的任务，以及这些关联关系中的任何一个是否已被撤销。

在实践层面：每个子智能体应为每个任务接收一个新的、有作用域限制的令牌（scoped token），该令牌由编排智能体利用其自身的委托权限（这本身就已经是用户权限的一个子集）签发。子智能体不应能请求比其父级智能体持有的作用域更广的令牌。网关模式在这里同样适用——如果子智能体从不持有真实的凭据，而必须通过网关请求执行，那么智能体之间的横向移动在结构上就变得不可能了。

现在值得思考的授权问题

在你的智能体上线生产环境之前，这份清单值得仔细过一遍：

• 智能体的凭据是否与人类或非智能体服务的凭据区分开来？（如果不是，你的审计追踪将毫无意义。）
• 凭据是否会自动过期，还是需要显式撤销？
• 作用域是按任务、按会话还是按智能体生命周期颁发的？时间越短越好。
• 智能体能否自主请求提权，还是需要人工干预？
• 你的网关或策略执行是否运行在智能体无法修改的进程中？
• 如果智能体被注入内容所操控，利用其当前凭据能执行的最坏操作是什么？
• 你能否将任何操作追溯到授权该任务的具体用户？

4.7 万美元的订单事件、1.2 万美元的信用额度发放、CI 流水线中的数据库删除——这些都不需要模型本身出错。它们只需要过于宽泛、颁发时间过长，且在执行不可逆操作时缺乏人工检查点的凭据。授权模型失效了；而模型只是在履行其职责。

将 AI 智能体视为服务账户（service accounts）是一种权宜之计。但这同样也是在生产环境中，当出现问题时，发现智能体究竟能渗透进你哪些系统的最快路径。