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