为 AI 智能体定义 Auth：从任务上下文决定访问权限

今年早些时候，一个 AI 编程代理在执行一项常规任务时，开始寻找修复某个问题的方法：暂存环境中的凭据不匹配。它在一个无关文件中发现了一个 Railway API 令牌，并用它在九秒内删除了一个生产数据库卷，包括备份。

这个代理在做代理本该做的事。它遇到了问题，四处查看，找到了一条没人预料到的路径。令牌完全按设计工作。只是它的权限范围远远超出了任务所需，而 Railway 那边无法分辨删除生产环境与修复暂存环境毫无关系。

这起事件暴露了几乎所有认证系统所基于的假设：谁持有凭据，谁就能做该凭据允许的任何事。当持有者是一个人或者一个执行单一可预测任务的服务时，这个假设还站得住脚，但面对代理就崩溃了。如果我们想让代理运营我们的公司、我们的软件流水线以及更多日常生活，认证必须改变。

每个操作都必须映射到其意图

计算领域的每一次转变，从 Web 到云，都需要新的身份和访问模型。在那之前，没人敢把重要的事情托付给新平台。代理是下一次转变。代理在行动过程中决定要做什么，往往无人监督。

这样的代理需要广泛的能力来独立完成真正的工作，常常要在数小时或数天内跨多个任务。 只有当从意图到操作再到访问之间存在一条直线时，广泛的能力才是安全的。每个操作都服务于代理的任务，并且只获得该任务所需的访问权限，且仅在需要的时间内。

以一个全天候运行的事件代理为例。凌晨 2 点，结账错误激增，它需要读取结账服务的日志。一小时后，一台构建服务器磁盘空间耗尽，它需要该服务器的指标。下一个警报可能是代理从未见过的东西，因此无法提前列出它需要访问什么。

一个宽泛到足以覆盖代理可能需要的所有内容的静态角色，覆盖的范围远远过大。相反，访问权限必须根据它面前的每个任务动态授予。目标是为组织运行的每个代理实现这一点，无论是自建还是采购的，是由人提示还是由事件唤醒的。

代理的认证归结为两件事：

1. 根据任务的完整上下文决定代理的访问权限：它代表谁行动、任务需要什么，以及组织允许什么。
2. 在工作发生时执行访问控制，覆盖每个代理及其接触的每个系统，并在代理需要更多权限时让人重新介入。

根据任务的完整上下文决定访问权限

当那个编程代理发送删除请求时，Railway 只看到一个有效令牌，别的什么也看不到。该请求需要表达的含义要窄得多：

这个代理，代表它自己或把工作交给它的人，在这个任务上，现在可以做这一件事。

这些信息大部分已经存在于代理周围。提示或触发器说明了它代表谁行动以及它要做什么。一旦工作变成附带令牌的 API 调用，所有这些信息就消失了。我们称这种丢失为上下文缺口，弥合它是代理认证的核心。

谁在行动，以及工作如何到达他们手中

大多数人认为智能体的认证是代表某个人行事，但越来越多的情况下，智能体是代表自己或其他智能体行事。没有人告诉事故处理智能体该做什么。一个告警将它唤醒，从那时起它便以自己的身份工作。如果它把日志分析交给另一个智能体，那个日志智能体可以代表事故处理智能体读取日志，并且只获得完成该任务所需的访问权限。

随着团队越来越依赖多智能体委派，每次交接背后的上下文都必须追溯到最初的触发源或交接工作的人。它不能来自智能体对自己任务的描述，否则智能体可能通过巧言令色获取更多访问权限。该上下文也会成为审计追踪，这样当出现问题时，你可以追溯到是哪个智能体、为谁、在什么任务上采取了行动，以及是谁批准的。

如今，每个智能体通常都有自己的服务凭证，但它们是静态的，不考虑手头的任务。在数千个智能体之间，这就变成了一张常设访问权限的网，没人能追溯到具体某项工作。相反，每次交接都应只传递新工作所需的内容。

智能体能做什么，以及这项任务需要什么

一个为处理告警而构建的事故处理智能体，无权翻转功能开关或发放退款。在它自己的工作范围内，正确的答案仍然取决于任务。当陈旧数据导致告警时，清除结账缓存是正确的做法，而在另一个团队正在对同一服务进行迁移时这样做则是一场灾难。智能体、团队和操作都相同，只是工作变了。

组织绝不允许的事

有些规则完全不取决于任务。任何智能体都不得删除生产卷，任何超过 10,000 美元的采购都需要二次审批，任何智能体都不得从 HIPAA 范围之外的环境读取患者记录。仅第一条规则就足以阻止 Railway 删除事件。这类规则存在于智能体之外的政策中，智能体说什么都无法改变它们。正如Agent Baseline所说：“写在提示词中的边界是指令。由环境强制执行的边界是控制。”

访问范围是智能体凭借其权限能做的事与任务所需之事的交集，且全部处于组织允许的界限之内：

一个标有“组织允许的范围”的方框内的维恩图：一个圆是智能体能做的事，另一个圆是任务需要的事，它们的重叠部分就是此任务的访问权限。

因此，智能体的认证必须：

• 利用任务的完整上下文，为每个操作做出决策。
• 在每次交接时重新评估访问权限，这可能意味着拒绝访问，或将其收窄到接收智能体能做的事及其新任务所需的范围。
• 将硬性限制作为政策强制执行，无论绕过它们的理由多么充分。

在工作进行时执行访问控制

知道智能体应该被允许做什么，如果它所接触的系统无法执行，那也是徒劳。如今大多数系统做不到，因此执行归结为按任务发放访问权限，并弥合现有系统之间的差距。

发放任务范围的访问权限

智能体不应拥有常设访问权限，而应被授予与其身份和任务绑定的短期、任务范围的凭证。任务结束时访问权限过期，一旦出现问题即可撤销。当事故处理智能体解决了结账告警并接手磁盘满告警时，它对结账日志的访问权限结束，新凭证让它转而获得服务器指标。

有时工作需要超出任务所允许的范围。在释放磁盘空间的过程中，智能体可能会发现需要将旧的构建产物移动到另一个团队拥有的 S3 存储桶中。智能体无法自行扩大访问权限，因此该请求默认会被拒绝。策略可以允许升级，这可能表现为一条发送给拥有该 S3 存储桶的团队的 Slack 消息。然后有人可以批准该请求、拒绝它，或更改工作内容。批准会为该任务授予另一个短期凭证，而不是对智能体能力的永久升级。升级应该是例外，而不是规则，因为把每个请求都转给一个人只会造成审批疲劳，而疲惫的审核者会批准一切。

今天桥接，明天联邦

单个任务可能让智能体穿越多个系统，每个系统都有不同的接口：静态 API 密钥、半成品的 OAuth 集成、数据库密码和云 IAM 角色。这些都不是为智能体而构建的。即使是具有细粒度作用域的系统，也不知道智能体正在执行什么任务，而且每个系统只保护自身，而智能体却要穿越所有这些系统。

像 token exchange 和 Cross-App Access 这样的协议已经在系统之间携带了一些上下文片段，而像 AAuth 这样的新协议正在出现以携带更多内容。然而，它们都尚未完全部署或广泛采用，如今很少有系统能以这种方式强制执行访问控制。

随着时间的推移，智能体将推动这一切走向通用标准。目前，答案是弥合差距：在那些不理解任务上下文的系统面前，代理现有凭证并执行决策。这与沙箱或虚拟机的理念相同，只是应用于智能体可以触及的你的所有系统。

每种智能体实现这一目标的方式略有不同：

• 能够通过浏览器、shell 或网络触及任何东西的智能体，比如编码智能体，运行在沙箱中。它们唯一的出路是出口代理。机密不会进入上下文窗口，也不会落入智能体手中。智能体在文件中找到的令牌不会改变它被允许做的事情。
• 你购买的托管智能体通过它们前面的网关访问你的系统。MCP 网关是一个起点，但它们只能看到 MCP 流量。大多数网关不会将访问与任务绑定，也不会为你提供一个统一的地方来注册智能体、管理其身份，并在出现问题时撤销访问。
• 基于任务感知工具构建的智能体可以携带自己的作用域凭证。
• 有些系统根本无法接受任务上下文。对于这些系统，网关会将决策转换为它们能理解的东西，比如短期 OAuth 令牌或针对某个模式的数据库登录。

大多数组织会同时运行所有这些。这就是为什么它们需要在底层有一个智能体认证系统，在每条路径上以相同方式决定访问权限。

因此，智能体的身份验证还必须：

• 为每个智能体赋予一个稳定的身份，使其在所有活动位置都能被统一禁用。
• 为每项任务授予短期的、与身份绑定的访问权限，并在任务结束或出现异常时撤销该权限。
• 默认拒绝超出所需权限的请求，仅在策略允许时，向有权授予权限的人升级处理。
• 在智能体无法绕过的环节强制执行访问控制，并使用各系统都能理解的方式表达。
• 记录谁在行动、代表谁、为哪项任务，以及谁批准了该操作，即使下游系统只记录了一个令牌。

当访问权限随工作而变时，会发生什么变化

让智能体变得可预测，从来都不是我们保障其安全的方式，因为寻找意外路径正是其意义所在。真正能让它们足够安全、被广泛采用的是短期的、按任务限定范围的访问权限，这种权限源自任务的完整上下文，并在工作过程中被强制执行。我们认为，这就是智能体身份验证必须达到的标准，也是 Keycard 的构建基础。

一旦访问权限随任务而变，智能体就能承担那些没人有时间监督的工作，比如通宵处理事故，或在我们专注于更高价值工作时编写新软件。到那时，团队就不再问智能体可能会破坏什么，而是开始问接下来该把什么交给它。