身份验证确认你是谁；授权决定你可以做什么。越来越多的 AI 驱动的应用在登录时验证一次用户身份，然后在整个会话期间允许底层的智能体对任何资源进行操作，这实际上是给了它一张“空白支票”。这种设计为意外的数据泄露、不想要的电子邮件甚至破坏性的数据库更新打开了大门，而且每当 AI 助手能够以毫秒级延迟调用多个工具时，这种风险就会增加。

为什么错误会不断发生

大多数 AI 开发人员将登录界面视为唯一的安全关口。代码要求输入密码或令牌，将会话标记为“已验证”，然后便假设随后的任何请求都是安全的。在传统的 Web 应用中，人类用户缓慢的点击提供了一个天然的节流点；人类在点击“删除”之前会停顿。然而，AI 智能体可以在几秒钟内发出数十次工具调用。如果平台只询问“用户是否已登录？”，那么每次调用都会继承相同的无限制权限。

根本原因是便利性。团队通常为整个应用程序配置单个长效服务账号，这样代码就不必管理多个令牌或作用域。该账号通常在所有项目中都拥有广泛的权限——读取、写入、删除。当 AI 助手在该会话中运行时，它会自动继承这些权利，无论当前任务是否真的需要这些权限。

风险所在

  • 数据泄露 – 一个在用户登录后可以读取任何文件的智能体，可能会在随后分享到组织外部的响应中，无意中提取机密文档。
  • 非预期操作 – 支持工程师的 AI 助手可能会对生产数据库执行原始 SQL 查询，仅仅因为工程师的会话仍然处于活动状态，即使该查询与正在处理的工单无关。
  • 合规性 – 许多数据保护规则要求访问权限必须限制在最小必要范围内。宽泛的权限模型可能会违反这些原则，并引发审计或罚款。
  • 运维成本 – 删除或修改记录的错误会迫使团队回滚更改、调查根本原因并重建用户信任——所有这些都会浪费时间和金钱。

缺失的一步：基于动作的授权

授权应该在系统内部的每一个“门”处进行评估，而不仅仅是在大门口。问题从“这是谁？”变成了“现在是否允许对这个特定资源执行这个特定动作？”实现这种检查并不需要彻底的重新设计；它只需要从单一的会话标志转向短效的、带作用域的令牌。

实际操作流程

  1. 请求具有定义作用域的令牌 – 当 AI 智能体需要调用工具时，它首先获取一个列出所需确切权限的令牌（例如，read:ticket、execute:sql_query）。
  2. 为每次调用验证令牌 – 在工具运行之前，服务会检查令牌是否包含所需的作用域，以及令牌是否已过期。
  3. 将资源与作用域匹配 – 如果请求针对特定的项目或数据库，令牌必须明确授予对该标识符的访问权限。
  4. 拒绝或允许 – 如果任何检查失败，调用将被拒绝，智能体将收到一个可以向用户展示的错误。

代码层面的差异非常直观。一种“错误”的做法可能如下所示：

if session.is_authenticated():
    tool.run(params)

一种“正确”的做法扩展了检查逻辑：

token = get_scoped_token(user, required_scope)
if token.is_valid() and token.allows(required_scope, resource_id):
    tool.run(params)
else:
    raise PermissionError

第二种模式虽然多增加了几行代码，但它迫使系统在每次操作时都提出正确的问题。

让开发更简单的标准

OAuth 2.0 作用域已经提供了一种被广泛采用的方法来限制令牌可以执行的操作。通过发布编码了诸如 project:1234:write 或 email:send 等作用域的短效访问令牌，开发人员可以依靠现有的库来执行验证步骤。

较新的富授权请求 (Rich Authorization Requests, RFC 9396) 扩展了这一理念，允许客户端在运行时请求细粒度的权限，而不是预定义一个静态列表。当 AI 工作流可能需要根据用户意图动态添加或删除功能时，这种灵活性非常有用。

反论：简单性与安全性之间的权衡

一些团队认为，针对每次操作的检查会增加延迟和代码复杂度，尤其是当 AI 助手必须连续快速调用多个工具时。他们指出，使用单一会话令牌（session token）可以避免为每次调用获取和验证新令牌的开销。然而，这种做法的代价是面临极高的误用风险。现代令牌验证服务的运行速度是以微秒计的，额外的网络往返可以通过批处理或缓存来处理，且不会牺牲最小权限原则。在数据完整性和合规性不容妥协的环境中，降低风险所带来的收益远大于微小的性能成本。

后续关注点

  • AI SDK 中作用域令牌（scoped tokens）的采用 – 密切关注主流 AI 平台工具包的更新；许多工具包已开始提供基于 OAuth 作用域的辅助函数。
  • 策略即代码（Policy-as-code）框架 – 新兴的解决方案允许团队在声明式文件中定义授权规则，并在运行时自动执行。
  • 呈现单次操作决策的审计日志 – 随着越来越多的平台记录每一次授权检查，组织将能够清晰地看到哪些 AI 操作被允许或拦截，从而为未来的策略调整提供依据。

核心总结

将登录会话视为拥有任何权限的凭证，是导致意外后果的诱因。通过将授权决策从登录时刻转移到每一次单独的工具调用中，并利用短效的作用域令牌，AI 应用可以在保持自主代理便利性的同时，保护数据、遵守法规并避免代价高昂的失误。对于一个在每次尝试操作时都能提出正确问题的系统来说，多出的几行代码只是微小的代价。