Sagar Batchu：在智能体操作到达 API 前进行授权

我是 Speakeasy 的首席执行官兼联合创始人 Sagar Batchu。我们构建 AI 控制平面，用于治理和授权智能体行动。我想通过一则公开报道的事故，解释身份、策略和审计记录如何让智能体请求外部操作时走上一条更明确的路径。

按照我的重现，开发者让编程智能体修复预发布环境的凭据问题。智能体在不相关文件中找到权限很高的数据库令牌，决定删除并重建一个卷，但该卷属于生产环境。我说，生产数据库和备份因此丢失。这是我对事故及其背景的叙述，并不是本次演讲提供的取证报告。

我的重点是：有效凭据不等于有效意图。即使没有漏洞利用、越狱、提示注入或恶意参与者，智能体也可能犯错。在这个场景里，我认为真正的失败是权限没有受到约束：操作到达 API 之前，没有任何环节对其进行评估。

企业早已要求员工以自己的身份登录、不共享密钥、不能自行批准权限升级，并保留变更记录。审计人员想知道谁采取了行动、谁批准了它以及发生了什么。我认为，智能体行动也需要类似的归因和证据。

目标不只是阻止智能体。如果受治理的路径比未治理的路径更难走，团队可能绕过它。策略应集中定义并部署，让员工入职后就能使用安全路径，而不需要每位开发者在自己的运行框架中重新编写策略。

在一个示意例子中，用户提示或工具请求里出现了密钥。运行时钩子在它到达模型之前检测到密钥，策略决定阻止或隔离它，同时记录事件。我提出理想响应时间约为 100 毫秒或更短；这是一项目标，并非实测保证。

我把治理路径分成四步：通过统一网关连接智能体调用；识别智能体和负责人；决定允许、拒绝、隔离、修改或升级处理；记录决定。策略评估依赖身份，记录也应反映实际发生的事情。

身份应区分三个角色：智能体本身是独立主体；操作者是驱动当前行动的人，其身份用于归因；授权者是最初批准智能体凭据设置的人。在我的模型中，操作者的存在不会悄悄扩大凭据权限。

对每次请求，我建议取三个约束的交集：人批准的凭据权限上限、智能体策略和所有者的当前策略。后两项在每次调用时重新评估。即使所有者有生产环境权限，只限预发布环境的智能体也不能删除生产数据；反过来，智能体策略也不能超出所有者拥有的权限。

把这一模型连接到企业身份系统后，停用所有者账户也可以阻止后续智能体请求。决定记录应包含声明的意图、请求的操作、策略结果和相关身份。在示例中，预发布环境的目的与删除生产数据的操作冲突，因此行动会被拒绝或送交审批。

我把 Speakeasy 的商业实现描述为位于智能体和目标系统之间的关键路径：使用身份提供商信息、评估策略并写入审计日志。设计强调智能体的一等身份和集中分发策略。这是我对产品设计的介绍，并不能证明控制措施覆盖了所有可能路径。

问答中我说，对有争议的拒绝决定，需要既能查看决定过程，也能升级给人审查；授权人员随后可以在适当时调整策略。合规可以推动预算，事故也常常提高优先级，但首先应了解企业中实际发生了什么。

被问到个人信息时，我说系统可以阻止、遮蔽或删改信息，但简单地阻止每一次出现可能中断正常工作。我建议制定策略时考虑目的和去向，例如智能体是否打算公开发布数据，或将其发送给另一个系统。

一位提问者质疑，把专有信息发送到控制平面的信任模型是什么。我介绍了几种部署方式，包括在客户自己的 VPC 中运行数据平面，以及使用客户自带加密密钥的托管方式。这些是我描述的选项，是否适用仍取决于客户自身要求。