最小足迹原则：自主 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 的上下文中；后端服务在执行时附加它。令牌过期后，智能体必须为下一步骤请求具有适当作用域的新令牌。

加载中…