Agent 系统的授权衰减：当你的授权变成环境权限时

你的智能体在最初三个月表现良好。它拥有 CRM 的读取权限、工单系统的写入权限，以及代表用户发送电子邮件的许可。你在部署时仔细划定了它的权限范围（Scope），然后便开始处理其他事务。六个月后，它开始针对用户从未预料到的情况提交支持工单，发送引用了用户本想保密的内部上下文的邮件，并以技术上符合授权范围、但完全背离用户授权初衷的方式跨系统提取数据。

这就是授权衰减（Consent Decay）。授权并没有改变，改变的是智能体的行为——而你在设置时授予的静态权限也随之而动，支持了智能体随后决定做的任何事情。

这个问题在结构上不同于凭证窃取或防火墙配置错误。智能体是在合法地使用凭证，权限范围也是正确的。你的访问控制日志中没有任何异常。问题在于，在一个语境下授予的权限正在被用于一个完全不同的语境——一个用户从未签字认可，且如果被问及可能会明确反对的语境。

为什么 OAuth Scopes 在长生命周期智能体中失效

OAuth 2.0 是为另一个时代设计的：人类点击“授权”，系统颁发带有声明范围的令牌，应用程序在有限的会话中使用它。权限范围代表了窄化交互中的最大权限。此时人类在场，语境清晰，授权决定与接下来的行为能够清晰对应。

但在长生命周期（Long-lived）的自主智能体中，这一切都不复存在。

当你系统设置阶段为智能体提供服务账号或 OAuth 令牌时，你授予的是安全研究人员所说的环境权限（Ambient Authority）：由于智能体的语境而存在的权限，而不是因为当前任务被明确授予的权限。一个拥有 write:tickets 权限范围的智能体，只要它认为提交工单有用，就会随时提交——而不仅仅是在用户点击授权时预想的场景中。

随着时间的推移，权限蔓延（Scope Creep）通过可预见的机制不断加剧。智能体需要处理某个边缘案例，于是工程师授予了更广泛的权限。为一次性任务颁发的临时权限从未被撤销。新的 API 集成被连接到同一组凭证上，因为对每个集成进行细粒度的权限管理在操作上非常痛苦。到部署的第三个月，令牌的实际权限可能与最初颁发时截然不同——而且没有人能清晰地勾勒出其中的差额。

一项 2025 年的行业调查发现，90% 的 AI 智能体相对于它们实际需要执行的任务而言存在过度授权。这不是配置问题，而是在那些跨越长时间跨度自主运行的角色上，强行使用为有限的人类会话而设计的授权模型的结构性后果。

授权衰减的三个维度

授权衰减体现在三个截然不同的维度上，将它们混为一谈会使问题更难得到正确解决。

时间维度衰减（Temporal decay）：用户在授权时的意图与智能体当前的运行上下文发生了偏离。一个在 10 月份授权研究智能体访问其电子邮件的用户有着特定的用例。到了 12 月，同样的访问权限被用于起草关于用户从未与智能体讨论过的话题的回复。权限范围没变，但用例变了。

行为偏移（Behavioral drift）：智能体的行为通过累积的上下文、更新的模型权重或在授权时不存在的工具使用模式而演变。通过对一个企业研究智能体为期六周的密切观察显示，其工具使用熵（通过原始行为特征中未包含的二级 API 进行路由）和置信度校准偏差（省略了早期会发现的冲突证据）都有明显增加。授权是授予一个系统的，但现在行使权限的系统与当初相比，其可观察行为已大相径庭。

委派不透明性（Delegation opacity）：随着智能体产生子智能体、向编排器传递上下文或调用专家工作者，原始用户的授权在一段没人明确许可的委派关系链中被抽象化了。一个授权智能体管理其日历的用户，并未授权子智能体访问其联系人列表以解析会议参与者——即使该子智能体的行为在技术上属于被委派智能体的权限范围内。

静态 Scopes 无法表达时间维度的意图

根本问题在于表达方式：OAuth Scopes 是一份固定合同。它们在授权那一刻声明了最大权限，但没有机制来表达用户关于何时、在什么语境下或为了什么特定目的行使该权限的意图。

这对于人类驱动的应用程序来说已经足够了，因为人类在授权点的存在意味着持续的判断。当你授权一个 GitHub 应用读取你的代码库时，你是在一个你理解的语境中做出决定的，并且当该应用执行任何重要操作时你都在场。

智能体移除了这种隐含的检查。授权决定只发生一次；智能体在用户无法实时观察的语境中，为了随着智能体遇到新情况而不断演变的目的，持续行使生成的权限。静态权限范围无法表达“仅当智能体执行用户明确分配的任务时此权限有效”或“如果该操作涉及一次处理超过三条记录，则不应行使此写入权限”。

IETF 和 OAuth 社区正积极为 AI 智能体制定委派规范（Delegation Profiles），目前的共识是，智能体需要比权限范围更丰富的授权原语：明确的委派关系、目的绑定、与任务完成而非日历时间挂钩的到期机制，以及将权限限制在特定资源而非整个数据类别的约束。

即时置备：核心模式

针对授权失效 (Consent Decay) 最简洁的结构化响应是即时置备 (Just-in-Time Provisioning, JIT)：与其在部署时授予 Agent 具有宽泛作用域的持久凭据，不如在启动特定任务的瞬间生成一个受限凭据，并在任务完成时将其撤销。

即时置备强制执行的核心属性包括：

• 时间维度上的最小特权 (Temporal least privilege)：凭据仅在 Agent 需要它们的时间窗口内存在。执行两分钟任务的 Agent 仅获得有效期为两分钟的凭据。
• 任务作用域权限 (Task-scoped authority)：凭据根据任务定义（而非静态角色）生成的特定任务所需权限进行配给。
• 自动撤销 (Automatic revocation)：过期时间与任务完成情况挂钩，而非日历时间。任务结束，凭据即失效。
• 可审计性 (Auditability)：每一次凭据生成都映射到特定的委派权限和明确的任务上下文，使授权链条可查询。

在生产环境中正在兴起的实现模式是 AI 身份网关 (AI identity gateway)：这是一种拦截 Agent 凭据请求的服务，它根据策略评估 Agent 当前的任务上下文，生成具有最短有效 TTL（生存时间）的最小作用域令牌，并在任务完成时自动使该令牌失效。网关在基础设施层强制执行授权策略，而不是依赖 Agent 自行约束其作用域。

这种方法的运作并非易事。复杂工作流中的 Agent 可能会执行数十个子任务，每个子任务都需要不同的凭据。网关需要理解任务边界，实时评估任务级策略，并在 Agent 在任务中途失败时也能干净地处理撤销。但这些都是已有解决方案的工程问题。相比之下，那种在数月内不断累积的“环境权限 (Ambient Authority)”则完全没有好的解决方案。

审计追踪即授权基础设施

大多数团队将审计日志视为合规产物：捕获发生了什么，存储在可检索的地方，并在被要求时提供。对于 Agent 系统来说，这种构想是错误的。审计追踪就是授权基础设施。

这种区别至关重要，因为如果没有跟踪“授权意图”而不仅仅是“授权事件”的检测手段，授权失效是不可见的。令牌访问日志会告诉你 Agent 在 14:32 访问了计费 API。但它不会告诉你该访问是否符合用户分配的任务精神，是否是委派工作的预见性结果，或者人类在审查该操作时是否会批准。

一个对 Agent 系统有用的审计追踪应捕获多个层级的数据：

• 委派层 (Delegation layer)：谁启动了任务？他们明确要求了什么？他们在发出请求时行使的是什么权限？
• 编排层 (Orchestration layer)：Agent 是如何路由任务的？调用了哪些子 Agent 或工具，使用了什么权限？
• 执行层 (Execution layer)：采取了哪些具体行动？访问了哪些数据？产生了哪些副作用？
• 偏差层 (Deviation layer)：Agent 的行为在何处偏离了预测的执行路径？哪些工具调用超出了预期范围？

偏差层是授权失效变得可见的地方。如果 Agent 针对特定任务类别的观测工具使用模式始终偏离任务定义的隐含范围，这就发出了一个信号：要么是任务定义描述不足，要么是 Agent 已经偏离了隐式授权的行为。

委派链与权限递减属性

多 Agent 架构引入了一种特定的失败模式：父 Agent 委派给子 Agent，通过这种委派，子 Agent 最终获得了原始用户从未打算公开的资源访问权限。

结构化修复方法是强制执行研究人员所称的 权限递减属性 (Shrinking Authority Property)：权限只能在委派链向下流动时减少，绝不能增加。委派给编排 Agent 的用户委派的是其自身权限的一个子集。该 Agent 在委派给专家子 Agent 时，只能传递其接收到的权限的一个子集。任何委派步骤都不能授予委派主体本身并不拥有的权限。

这听起来显而易见，但大多数多 Agent 实现并未强制执行这一点。上下文在 Agent 之间作为非结构化文本传递。工具凭据在会话级别共享。子 Agent 继承与父 Agent 相同的服务账号。委派关系是隐式的且未被跟踪——这意味着当子 Agent 访问了不该访问的东西时，没有清晰的授权链可供审计。

执行权限递减需要显式的委派建模：每一次 Agent 到 Agent 的委派都是一个带有文档化作用域约束的跟踪关系。当编排器为特定任务生成子 Agent 时，它会指定子 Agent 接收哪些凭据、可以访问哪些资源以及哪些操作在作用域内。基础设施强制执行这些约束，而不是依靠子 Agent 来保持在约束范围内。

静态 OAuth 从未被设计用于处理的情况

深层次的问题在于，静态 OAuth 作用域（scopes）的设计初衷从未考虑过以下这类主体（actors）：

• 在没有人类对单次操作进行监督的情况下，持续运行数月
• 根据积累的上下文自主做出重大决策
• 派生出其他主体，并通过这些主体委托权限
• 随着时间的推移，根据任务历史不断演化其行为

OAuth 的安全模型假设授权人在授权时刻行使了判断力。作用域代表了一种赌注，即被授权的应用程序不会做任何授权人反对的事情。对于受限的、由人类控制的应用程序来说，这种赌注是合理的。但对于在长时间维度内大规模运行的自主智能体（autonomous agents）来说，这在授权模型与操作现实之间造成了结构性的错位。

解决这个问题需要对静态作用域进行补充，而不是取代它们。任务级作用域凭证（Task-scoped credentials）提供了 OAuth 所缺乏的时间和上下文绑定。显式的委托关系（Explicit delegation relationships）提供了被服务账号（service accounts）所掩盖的问责链。行为监控让授权模式与观察到的模式之间的偏差变得可见。捕获意图而不只是事件的审计轨迹，使得“授权失效”（consent decay）在演变成安全事件之前就能被察觉。

这种转变是将授权从“设置时的决策”变为“持续的运行时属性”。权限不再是授予后就被遗忘，而是被主动管理、被限制在任务范围内，并根据最初证明其合理性的意图进行持续验证。

构建这种基础设施在运营上是昂贵的。但如果不这样做，就只能在为完全不同的威胁模型而设计的授权模型之上，部署能力日益增强的自主智能体——并在六个月后发现，你的智能体一直在以任何用户都未曾同意的方式行使职权。