最小足迹原则：自主 AI 智能体的最小权限设计

某零售采购智能体在"初始测试期间"继承了供应商 API 凭证，却没有人在系统投产前对其加以限制。当一个差一错误触发后，该智能体拥有完全的下单权限——永久生效，毫无限制。等财务部门察觉时，已有价值 47,000 美元的未授权供应商订单发出。代码没有问题，模型也按设计运行。造成如此大破坏的，是权限问题。

这就是最小足迹原则：智能体应仅请求当前任务所需的权限，避免在任务范围之外持久化敏感数据，清理临时资源，并将工具访问权限限定于当前意图。这是 Unix 最小权限原则在新时代的延伸——在这个时代，代码会在运行时自主决定下一步需要做什么。

团队之所以在这里屡屡犯错，并非出于疏忽，而是概念错误：他们把智能体权限当作设计时的工作，而智能体 AI 使其成为了运行时问题。

为何传统最小权限原则对智能体失效

最小权限作为安全原则已有五十年历史，实现方式简单：弄清进程需要什么，精确授予，绝不多给。这背后隐含的假设是，你能提前确定进程的需求。

自主智能体打破了这一假设。一个智能体读取用户日历，发现冲突，查询 CRM 获取与会者联系方式，再起草邮件——访问模式由运行时的任务决定，而非工程师在部署时预先设定。你无法编写一条静态 IAM 策略来涵盖"该智能体在本次会话中所需的全部权限"。

面对这一问题，团队往往以最糟糕的方式应对：提前配置宽泛权限。智能体获得日历读写、CRM 读写、邮件发送和文件系统访问——因为"也许都会用到"。而当 90% 的运行只需要日历读取时，其余权限就这样悬在那里，等待任何漏洞、注入或配置错误来利用。

2024 年的 Slack AI 事件展示了现实中的样子。Slack 的 AI 助手可以通过频道内容中的间接提示注入被操控，从攻击者无法直接访问的私有频道中提取消息。助手拥有宽泛的环境访问权限，唯一缺失的不过是一个畸形的检索上下文。权限使攻击成为可能，AI 使其自动化。

导致智能体权限过度的反模式

这些事件有共同的特征，识别这些模式是打破它们的第一步。

环境凭证是最常见的失败。智能体在任务早期步骤中获得凭证——比如迁移时的数据库连接——而此后这些凭证从未被缩减。后续的验证步骤继承了完整的 DDL 访问权限。一个环境变量配置错误导致智能体删除生产表，造成四小时的服务中断。按照其权限，智能体什么都没做错。

继承用户身份是第二种失败模式。智能体以已认证用户身份运行，拥有用户的全部访问权限，而非作为独立身份持有任务范围的凭证。这绕过了组织已建立的自然访问控制边界。处理工单的支持机器人不应继承队列管理员对计费系统的写入权限。

权限惰性累积更难察觉。随着新功能的添加，权限不断叠加。移除权限感觉有风险——万一智能体需要呢？——于是它们永远不会被移除。权限面单调增长，而实际访问模式却保持狭窄。在一项企业 AI 部署调查中，80% 的 IT 领导者报告智能体行为超出预期；其中大多数事件与权限相关，而非模型问题。

缺少会话边界是结构性根源。当凭证永久有效、权限静态授予时，一次会话被攻破就意味着永久、宽泛的访问权限。任务完成时没有自然的作用域来终止。

运行时执行模型

正确的心智模型将权限视为动态配置和撤销的基础设施，而非静态授予后置之不理的东西。

核心模式是在智能体与其能够影响的一切之间设置身份网关。网关评估上下文（用户是谁、智能体声明在做什么、当前时间、本次会话已完成什么），应用策略（在 Open Policy Agent 等工具中编码），并铸造一个具有最短可行 TTL 的任务范围令牌。任务结束时，令牌过期。如果任务在三十秒内成功，凭证存活三十秒。如果会话在第二十九秒被攻破，攻击者继承的凭证一秒后就会过期。

这与 OAuth 2.0 访问令牌类似，这一类比是有意为之的。智能体获得自己的 OAuth 客户端 ID 和访问令牌。细粒度作用域（read_calendar、send_email、view_contacts）取代整体凭证。令牌永远不会出现在 LLM 的上下文中；后端服务在执行时附加它。令牌过期后，智能体必须为下一步骤请求具有适当作用域的新令牌。

短期令牌显著降低了凭证盗窃风险。Okta 2025 年的基准测试发现，从 24 小时令牌切换到 300 秒令牌后，凭证盗窃事件减少了 92%。逻辑很简单：缩小凭证窗口就是缩小攻击窗口。

策略层值得强调。存在于应用代码中的授权规则是不可见、不可测试、无法审计的。以声明式格式编码的策略——OPA 的 Rego 或等效形式——是可读、可版本控制、可测试的。你可以编写测试来验证智能体不允许在生产环境中运行破坏性数据库操作。你可以将每一个授权决策追溯到特定的策略规则。事故发生时，你有审计线索来解释什么被允许以及原因。

能力配置而非凭证配置

最小足迹最优雅的实例化是意图感知访问配置：不是授予凭证，而是授予与声明意图匹配的能力。

不是给智能体一个具有宽泛权限的单一"授权访问"工具，而是暴露狭窄的、特定用途的工具：检查用户是否已有访问权限、评估请求操作的审批要求、自动应用时间限制、撤销授权。智能体从这些原语组装工作流。每个原语都有明确定义的作用域。智能体从不直接接触凭证。

这直接对应于将请求操作的内容（智能体，不受信任）与执行操作的位置（隔离的、受策略管控的环境）分离的原则。智能体描述其意图；控制平面决定为该意图铸造什么访问权限；执行发生在任务完成后即销毁的临时上下文中。

AWS 在其生成式 AI 框架中描述了这一模式：创建专用的智能体执行角色，在各工作流上定义权限边界，指定目标资源 ARN 而非通配符权限，并应用条件语句将操作限制为可信流量。临时运行器模式进一步延伸：为任务创建 Kubernetes 命名空间，在其中执行，无论任务成功或失败都删除该命名空间。没有孤立资源，没有残留凭证，没有持续到下一会话的环境访问权限。

从一开始就为最小足迹设计

将最小足迹改造到现有智能体部署上是痛苦的。正确的时机是在编写第一个工具定义之前就进行设计。

从一开始就将智能体身份与用户身份分离。 每个智能体都应有自己的身份和访问配置文件。当智能体需要代表用户行动时，使用令牌交换模式（OAuth 2.0 的代表流程）来铸造一个代表智能体为该用户行动的有作用域令牌——而不是用户的完整身份被智能体假定。

以最窄可能的作用域设计工具。 文件读取工具不应因为实现更简单而拥有写入权限。日历查询工具不应因为同一 API 客户端同时处理两者而能够发送邮件。工具作用域蔓延就是权限作用域蔓延。每个工具定义都是一个授权决策。

使清理显式化，而非可选。 创建临时文件、启动子进程或分配外部资源的智能体应有显式的清理步骤。不要依赖垃圾回收或基于超时的过期。当任务作用域结束时，清理就会运行——无论任务成功还是失败。这是 RAII 的智能体版本：资源获取与显式释放相匹配。

对授权决策而非仅对操作进行监控。 大多数智能体可观测性记录智能体做了什么。更有价值的数据是智能体被允许做什么与实际做了什么。如果你有权限请求和授予的日志，可以识别从未使用的权限面并加以收紧。如果没有授权日志，你对已部署智能体的风险状况就是盲目的。

定义分层审批模型。 并非每个操作都需要人工审核，但有些需要。关键是使层级明确而非隐式。对非敏感数据的只读操作可以自动审批。可逆的写入操作可以自动审批并记录日志。破坏性操作、外部通信或任何跨越信任边界的操作都应需要明确审批。这些层级应编码在策略中，而非通过在截止日期压力下会消蚀的文化规范来执行。

组织层面的问题

技术模式是必要的，但不充分。破坏最小足迹的组织模式是审批疲劳：安全机制变得如此繁琐，以至于团队构建绕过方式。他们实现 --skip-permissions 标志。他们授予宽泛的开发权限，却忘记为生产环境加以限制。他们继承原本是临时的凭证。

解决方案是使安全路径成为便利路径。自动配置和撤销的临时凭证比需要手动轮换的静态凭证摩擦更小。可以进行版本控制的声明式策略比在 AWS 控制台中做出的临时 IAM 决策摩擦更小。以不可见方式处理授权的控制平面比开发者手动管理每次部署的权限作用域摩擦更小。

88% 的组织报告在过去一年中出现了已确认或疑似的 AI 智能体安全或隐私事件。在普通企业中，非人类身份已以 50:1 的比例超过人类。权限问题并非理论上的；它正在生产规模上产生真实事件。

最小足迹原则不需要新的安全理念。它需要将我们已知的内容——最小权限是正确的，静态权限对动态系统不足，清理不是可选项——应用于自主智能体的特定约束。从独立身份开始，添加临时凭证，将策略编码为代码，并对授权层进行监控。任何单个智能体故障的破坏半径都受其权限作用域限制。保持该作用域最小化，是使智能体系统能够安全大规模运营的工程纪律。