--- id: "JxNCuXkSWyQ" title: "一把有效密钥让 AI 智能体删掉了生产环境｜Sagar Batchu，Speakeasy" channel: "AI Engineer" host: [] guests: ["Sagar Batchu"] date: "2026-11-02" updated: "2026-11-03" duration: "20:39" duration_seconds: 1239 source_type: "youtube" youtube: "https://www.youtube.com/watch?v=JxNCuXkSWyQ" canonical: "https://pod-exp.pages.dev/JxNCuXkSWyQ/" transcript_jsonl: "https://pod-exp.pages.dev/JxNCuXkSWyQ/transcript.jsonl" language: "zh-CN" translation: true translated_from: "en" timestamp_precision: "block" topics: ["AI 安全","AI 智能体","AI 基础设施","企业软件"] series: ["AI 基础设施"] --- # 一把有效密钥让 AI 智能体删掉了生产环境｜Sagar Batchu，Speakeasy > 中文译文，由英文原音字幕翻译整理，不是官方逐字稿；引用原话请核对英文原视频。说话人标签由整理者依上下文标注，带「未确认 / 未标注 / 不确定」等字样的标签不可靠。时间戳一般为块级（所在时间块的起点），不是逐句时间；正文自带 [hh:mm:ss] 的段落除外。 **内容提要：** Speakeasy 联合创始人兼 CEO Sagar Batchu 以一场智能体误删生产数据库及备份的事故为例，指出“有有效凭证”不代表“操作意图正确”。在企业部署 AI 智能体时，封堵往往会被绕过，关键是建立易用的治理路径：集中制定策略，让外部调用经过统一控制层，绑定智能体、操作者和授权人的身份，实时检查权限并记录决策。系统应确保智能体权限不超过凭证上限和所有者权限，并能审计实际发生的操作。问答进一步讨论策略申诉、合规预算、PII 处理，以及通过私有 VPC 或客户自带密钥保护数据。 ## [0:15] 开场 · YouTube **Sagar Batchu：** 大家好，感谢各位今天来参加。我叫 Sagar，是 Speakeasy 的 CEO，也是联合创始人。我们做的是一套 AI 控制平面，帮助企业安全地扩展 AI 的应用。具体来说，我们把企业里所有的 AI 都接入一条受治理的路径，并帮助企业授权 AI 正在执行的各项操作。 我今天想谈的是，怎样有意识地为智能体的操作授权。我会重现几个月前上过新闻的一起小事故，借这个案例聊聊怎样授权操作、避免类似事故。如今，智能体能不能胜任某项任务，早已不是大家关注的重点。大多数企业真正关心的是：它们做了某件事之后会发生什么？在多数受监管行业，每项操作都必须归属到某个人或某个实体，并对应一个身份。这就是我今天想讲的核心。 先看一段我做的小动画，快速回顾刚才提到的那起事故。如果你还记得，事情发生在…… ## [1:22] 那个删掉生产环境的智能体 · YouTube **Sagar Batchu：** 四月，我不点名，但有一家初创公司的创始人当时以为自己在修复暂存环境，结果误删了生产数据库。我准备了这个漏斗动画，帮大家回忆那件事。事情大致是这样：开发者让一个编程智能体修复暂存环境里的凭证问题。这是个再普通不过的请求，发生在一个平常的下午。智能体先读取工作区，然后在一个不相关的文件里发现了数据库访问令牌。这是一个拥有完整权限的基础设施令牌。 它判断，解决问题的办法是删掉数据卷再重新创建。可它能访问的数据卷并不是暂存环境里的，也没有任何东西挡在它的猜测和 API 之间。调用没有绑定身份，没有策略检查，没有审批，实际上也没有留下任何记录。 就这么一下，生产环境被删掉了，随后又恢复了；所有这些资源都处在同一个网络边界内，所以顷刻之间全没了。大约十秒钟，初创公司的整个数据库连同备份就被彻底摧毁。 接下来我想请大家记住的是：智能体拿着有效凭证，却没有正确的意图。这才是这件事里对与错的真正区别。接下来我要论证的是，真正的故障在于权力没有受到约束。智能体可能会犯错，也可能漏掉上下文，这一点大家已经很清楚了，我们都遇到过。但在那个案例里，你们没看到漏洞利用、越狱或提示注入，也没有恶意行为者。没有人故意要破坏系统或伤害公司。 有效密钥只是做了有效密钥会做的事，对吧？智能体也只是做了它认为自己该做的事。对受监管企业来说，问题不在于错误发生了，而在于智能体的判断和 API 之间什么都没有，没有真正的护栏。接下来我们谈谈这套蓝图…… ## [3:44] 行业现状 · YouTube **Sagar Batchu：** ……有哪些办法能让情况变得更好。我想先给大家三个数字，看看行业现在是什么状况。第一，82% 的组织已经在运行 AI 智能体，这大概不出大家意料。只有 32% 的组织制定了 AI 治理政策。考虑到两者差距这么大，这个数字可能更让人意外。最后，一旦发生数据泄露，往往和某种影子 AI 有关，平均损失通常估算在 500 万美元左右。这个数据听着还真挺“有意思”的。 总的来说，AI 的采用已经很普遍，但相应的控制层还不存在，更谈不上普及。我们先别急着看智能体控制层在这个场景里应该是什么样，不如先从我们一直要求员工做到的事情说起。只要有软件，或者说有 SaaS 软件以来，我们就一直要求人们遵守这样的标准。我们要求人们做到的…… ## [4:49] 我们对人的基本要求 · YouTube **Sagar Batchu：** 人必须用自己的身份登录。我们要求每个人都不要分享密码或任何密钥，也不能自己批准权限提升或权限变更。我们还要求系统记录所有变更。这很标准，对吧？现在的软件都应该做到这些，这就是我们的期待。 如果你在受监管行业接受审计，审计员会问的不是模型够不够聪明、智能体够不够聪明，或者是不是用了最新版本，而是：谁采取了行动？谁批准了？然后，把事情经过的记录拿给我看。 ## [5:28] 为智能体建立控制层 · YouTube **Sagar Batchu：** 如果要把这些要求应用到智能体上，我首先想说，我们不想把智能体拦下来，对吧？也不想设置一道障碍，逼得团队想办法绕过去。智能体总会找办法绕过，光靠封堵行不通。正确的做法，是提供一条真正有用的行动路径，让它比不受治理的路径容易得多。我们希望受治理的操作实际用起来更顺手。 我再用一段有趣的动画，展示一条完整的、真正受治理的操作路径可能是什么样。 设想有一个真正的控制层——某种神奇的系统，能管理你本机和云端的智能体。首先你会希望它开箱即用。你加入公司、完成入职，就应该已经有这些策略在位。动画第一步展示的就是：你入职第一天，笔记本电脑上就预装了这套东西。 关于什么该做、什么不该做的策略，只需要在中央统一编写一次。开发者不必在自己的智能体或运行框架里重复编写；策略集中定义一次，然后在公司层面强制执行。 我们用一个简单例子：用户提示和工具请求中出现秘密信息时，系统应该拦截或隔离。还是用刚才开发者误删数据库的场景。这次，用户把 AWS 密钥输入提示里，也可能是另一个智能体传来的。在模型看到它之前，运行框架里就会触发一个钩子，识别出正在发送的密钥。控制层会评估策略并捕获这条提示；检测器负责执行策略，其中一个检测器识别出了 AWS 密钥。 这里的概念是先拦截，再生成一个决策。理想情况下整个流程在 100 毫秒内完成。我们不希望智能体或人因此偏离原本的工作路径，所以这一切要非常快。 拦截发生后，系统会记录下来，形成这次事件的审计记录。也就是说，检查、拦截、记录；秘密信息根本没有离开本机。对开发者来说，唯一的损失只是写了一条不合适的提示。 我们再从概念上简化一下刚才发生的事。可以把它看成四个步骤，公司能以此为基础搭建治理架构。 ## [8:26] 接入、检查、决策、记录 · YouTube **Sagar Batchu：** 第一步我叫它“接入”（connect）。要做的是建立一扇统一的门，而不是弄出几十个不同的集成入口。智能体连接外部系统时发出的调用，都应该汇到同一个地方，比如 MCP 网关。很多人都用过这类网关，也很熟悉它。 第二，调用必须能追溯到一个有名字的智能体，或它背后的人。没有身份，策略评估就无从谈起。这个身份还必须和分配给企业软件的身份保持一致，这样全公司才统一。 第三步是“决策”（decide）：允许、拒绝、隔离，或者升级审批。有时只要提醒用户就够了。最后，要在真正采取任何行动之前把决策记录下来。 我接下来会详细讲其中几步，给大家一份能用于自己产品或公司的蓝图。首先是身份：是谁发起调用，究竟是谁执行了这个请求？看看眼前这张图，它分成两边。左边是我们设想的那起事故的日志：文件里发现了密钥，却没有记录行动者，也没人批准。如果你是审计员，就会想知道究竟是谁采取了行动、谁该负责。说实话，这就是如今大多数系统的默认状态。今年早些时候以前，我们自己的系统也是如此。每个主体、每个智能体、每个用户，都借用某个人的身份。这在现在运行智能体的大多数公司里很常见。甚至后台任务也会映射到某个用户，或者只创建一个匿名的系统角色。Slack 助手之类的东西也往往以用户权限运行，不一定拥有自己的身份。 右边是用控制层的视角重新建模后的同一条提示。智能体本身就是一个主体，因此有自己的身份。下面还有一个推动操作的操作者：实时与智能体交互的到底是谁？这个例子里是我。操作者信息会被记录下来用于追责，但绝不会被用来实时扩大访问权限。 最后是授权人，也就是最初批准为智能体配置凭证的人。这个例子里写的是 Thomas，他是我们的首席信息安全官（CISO）。授权人会在凭证的整个生命周期内固定不变。右边这张卡才是我们真正希望用于合规的：它如实记录了发生的事情，以及我们如何建模。 接下来这部分是讲给集合论爱好者听的：系统到底如何实时判断一次调用成功还是失败？这里有三个组成部分。左边是凭证权限，也就是人签发密钥时设定的权限上限。权限永远不会被扩大：它写在凭证里，不能被提升到更高等级。 第二部分记作 A，是智能体自身的策略。它不能持有管理员权限，也不能拥有任何仅限人类使用的权限范围。最后，O 代表所有者的实时策略。智能体绝不能比对它负责、实际操控它的人拥有更大的权限。这个例子里，那个人就是我。 这种建模方式有个有意思的地方：第二和第三部分，也就是 A 和 O，会在每次调用时重新读取。你一旦撤销某项权限，下一个请求就用不到它了；系统会重新评估。回到一开始的数据库案例：即便所有者有权删除生产环境，一个权限只限于暂存环境的智能体也不能删。如果有人给了智能体更宽泛的策略，它也不能超过那个所有者…… ## [12:28] 接入、检查、决策、记录（续） · YouTube **Sagar Batchu：** ……从来没有生产环境的权限。这样无论从哪一边看，你都受到保护；这两种情况下，调用都会被拦下来。 最后提醒一点：如果所有者离开公司，由于他的身份接入了企业身份系统，也就是 IDP，系统会撤销他的账户。之后，智能体发出的每一个请求都会被拒绝。 ## [12:53] 记录发生了什么，以满足合规要求 · YouTube **Sagar Batchu：** 这个概念流程的最后一步，是记录实际发生的事情。左边还是刚才那个场景；右边则是现在这套做法留下的记录，因为我们能把每一步都建模出来。沿着流程看，会发生一次拒绝，同时系统会记录智能体声称的意图：它想操作暂存环境，实际操作的却是生产环境。策略能同时看到这两方面。 这大体上就是如今合规框架的发展方向：除读取之外的每项操作，都会依据策略进行评估；策略考虑的是智能体声称的意图，而不只是实际发生的操作。在很多控制系统里，评估会得出五种决策之一，比如允许、拒绝、修改，或者升级给人工处理。每项经过评估的操作都会生成一条事件记录；很多系统还会用密码学方式把记录绑定到智能体身份上。 我只准备了一页幻灯片，介绍 Speakeasy 是怎么搭建这套系统的，就讲这一页。前面提到过，Speakeasy 是一套 AI 控制平面。我们的产品位于人们使用的智能体——包括自主运行的智能体——和它们能访问的系统之间。身份基线来自你的 IDP，比如 Okta 或其他身份提供商。操作策略则由我们的产品，也就是控制平面来评估。所有调用都经过我们，包括被拒绝的调用。因此，我们会为客户写下审计日志。 这套架构有三个关键决定。第一，我们处在关键路径上，而不是旁边。记录必须反映实际发生的事情，而不是智能体自己报告的内容。第二，我们把身份作为系统中的一等对象，而不是到处借用用户登录身份。第三，我们通过 MDM 进行分发。整套方案开箱即用，用户不必自己重新定义这些策略；无论是刚入职，还是开始使用智能体时，它都能直接运行。 关于 Speakeasy，我就讲这一页；之后也很乐意继续聊。总结一下刚才的内容…… ## [15:21] 总结：有效凭证不等于正确意图 · YouTube **Sagar Batchu：** 刚才我们讲了这些内容。在受监管行业里，要证明智能体有权采取某项行动，通常必须对每个智能体或每项智能体操作说明三件事：行动者是谁、哪些策略允许了这项操作，以及这条记录的签名——也就是确认这件事确实发生过。这些要求一直以来都是企业对员工的要求，现在也应该用来要求智能体。 有效凭证不等于正确意图，这一点非常重要。解决办法不是说我们换个更聪明的模型或更好的智能体，而是要为每项操作配上身份、策略和记录。 今天我想讲的就是这些。最后告诉大家一声：今晚我们会和 Tailscale 的朋友举办活动，宣布一项合作，把 MCP 网关放进私有网络。人在现场的话，欢迎来参加。好了，很乐意回答大家的问题。 ## [16:37] 问答 · YouTube **Sagar Batchu：** 来，摄像机这边请。 **现场提问：** 我想问一下，假设你用的智能体受我们刚才讨论的那套策略约束，但你不同意它拒绝这项操作的决定。你会怎么设计策略？ **Sagar Batchu：** 好问题。我觉得最重要的第一步，是要能看到系统做出了哪些决定。现在很多公司里，人们用 Claude（Anthropic）之类的工具，并把它接入各种系统。智能体访问这些系统时，实际上没有记录它做过哪些决定。所以，即使你觉得某个用户不该访问你的 CRM，也没办法回头确定这件事到底有没有发生。 第二，你需要一种在这种情况下向用户升级处理的办法，这样你就能决定是否要放行。我认为这两项是更基础、目前缺失的能力。只要有了它们，你随时都能更新策略，让这类操作获准。 **Sagar Batchu：** 好，来。 **现场提问：** 在那 56% 没有治理政策的组织里，我很好奇，哪些公司是因为监管机构要求才采购，哪些是出了问题才采购？到底是什么推动了预算？ **Sagar Batchu：** 好问题，这也是我们经常思考的事。我会说，合规确实是促使企业考虑部署解决方案的一个重要动力。不过我想让大家记住的是，买产品满足合规要求固然重要，但第一步应该是先弄清楚自己的业务里实际发生了什么。所以，合规是很好的预算推动因素；一旦出了事故，这类方案的优先级往往就会提高。 **Sagar Batchu：** 来，请问。 **现场提问：** 经过你们控制平面的日志里，个人身份信息（PII）会做掩码处理吗？ **Sagar Batchu：** 会。我们可以拦截、掩码处理，也可以对 PII 做脱敏。在多数企业里，我们发现一旦开启可观测性，查看所有经过智能体的内容，就会看到大量 PII。如果一遇到 PII 就拦截，业务可能会彻底停摆，对吧？大家很难做到完全不让智能体处理 PII。 我觉得更重要的是看这些 PII 被怎么处理。比如，智能体打算把它发到公开的 Slack 频道、通过邮件发出去，还是放回一个工具，再由工具调用另一个系统？我们建议大家利用可观测性来制定这类策略，而不是把所有 PII 一概拦截或脱敏。 **现场提问：** 我问这个，是因为如果出了事故，我会向控制平面调取日志，弄清楚发生了什么，对吧？要经过授权？ **Sagar Batchu：** 对。 **现场提问：** 也就是说，你得把这些日志给我看，对吧？可我为什么要把数据交给你？这些是我们的专有数据，是我们的核心机密。 **Sagar Batchu：** 对。 **现场提问：** 所以，这里的信任模型是什么？ **Sagar Batchu：** 这就涉及一些部署细节了。我们的软件有几种不同的部署方式。我们提供数据平面部署选项，可以在你自己的 VPC 里运行，数据就留在你那里。更常见的做法是客户自带加密密钥。我们会加密数据，但密钥由你提供，这样你自己就能管控数据。 客户通常会进入我们的产品查看有哪些 PII，至少可以查看发现项；即使不查看经过脱敏处理的数据本身，也能了解相关情况。