有效密钥为何挡不住智能体误删生产:Sagar Batchu 谈授权控制
原题A Valid Key Let an AI Agent Delete Production - Sagar Batchu, Speakeasy
推荐理由有效密钥仍可能执行未经授权的动作,这场分享给出逐请求策略与审计路径,帮助明确凭证之外还需要哪些控制。
看前速览
Sagar Batchu 认为,有效凭证不代表有效意图;智能体还需要独立身份、权限交集约束和可追溯的操作记录。
凭证给出权限上限,不能替代意图判断
不能因为密钥允许,就把修复预发的请求变成删除生产环境。
区分智能体、操作人和授权人
记录应说明谁执行、谁驱动操作,以及谁为最初的凭证设置负责。
求取实时权限交集,先记录再操作
每次请求同时受凭证范围、智能体策略和负责人权限限制,撤权应在下一次调用生效。
结合用途判断敏感数据风险
个人信息控制应考虑发送目的地和动作,一律拦截可能让企业工作流无法运转。
完整摘要
Sagar Batchu 重建了一起智能体误删生产数据库的事件,说明仅持有有效密钥不足以证明操作已获授权。他提出连接、检查、决策、记录的治理路径:为智能体建立独立身份,区分操作人和凭证授权人,并把权限限制在凭证上限、智能体策略与负责人当前权限的交集中。策略应在每次请求时重算,决策记录应先于实际动作。演讲还涉及密钥拦截、设备管理分发和审计要求。问答中,他反对对敏感数据一律封堵,主张结合后续用途判断风险,并介绍客户自控部署与加密选项。这套架构较具体,但事故细节、采用比例、延迟目标与厂商能力均未提供独立验证。
章节
文字稿
简要说明Brief Description
一把有效密钥让 AI 代理删除了生产环境——Sagar Batchu,SpeakeasyA Valid Key Let an AI Agent Delete Production - Sagar Batchu, Speakeasy
目录Table of Contents
- 简介Intro
- 删除生产环境的代理The agent that deleted production
- 这在整个行业中的发展情况How this is playing out across the industry
- 我们对人们已有的期待What we already expect from people
- 智能体的控制层A control layer for agents
- 连接、检查、决策、记录Connect, inspect, decide, record
- 记录事件经过以满足合规要求Recording what happened for compliance
- 总结:有效凭证不代表意图有效Summary: valid credentials aren't valid intent
- 问答Q&A
简介Intro
大家好。感谢大家今天到场。我叫萨加尔。Hey everyone. Thanks for coming today. My name is Sagar.
我是 Speakeasy 的首席执行官兼联合创始人。我们是一个 AI 控制平面,帮助企业安全地扩大 AI 的应用规模。也就是说,我们帮助你梳理现有的所有 AI,让它们在受治理的路径上运行,并帮助你授权它们执行的所有操作。I'm CEO and co-founder of Speakeasy. We are an AI control plane that helps you securely scale AI within your business. So what this means is we we help take all the AI you have, put it on a governed path, and help you authorize all the actions it's taking.
今天我来这里和大家谈谈,我们如何有意识地授权智能体执行操作。我会重现几个月前的一起新闻事件,并借此讨论如何授权操作、防止类似事件再次发生。如今,智能体是否有能力完成某项任务,早已不是问题。I'm I'm here today to talk to you about how we can actually intentionally authorize agent actions. I'm going to recreate a little incident that was in the news a couple months ago, use that to talk to kind of the scenario of how you can authorize actions and prevent prevent such an incident. The question of whether agents are capable at a task is long gone today.
大多数企业真正关注的是,其中某个人做了某件事时会发生什么。在大多数受监管行业中,每项操作都必须归因于某个人或某个事物,而且还要归因于某种身份。所以这就是我想在这里谈的核心内容。The real focus in most businesses is what happens when one of them does something. In most regulated industries, every action has to be has to be attributed to someone or something and and some identity. So that's really the the core of what I wanted to talk here.
让我先快速播放一段我制作的小动画,展示一下我刚才提到的那起事件。Let me first do a quick little animation I put together of the incident that I was talking about.
那个删除了生产环境的智能体The agent that deleted production
如果你还记得四月份那件事,我就不点名了:有家初创公司的创始人以为自己在修复预发布环境,结果不小心删掉了生产数据库。我做了这个漏斗动画,算是提醒你一下那件事。简单来说,就像我刚才说的,开发者让一个编码代理修复预发布环境中的凭证问题。If you remember back in April, I won't name names, but there was a startup founder at the startup who thought he was fixing a staging environment but accidentally deleted his production database. I've got this funnel animation to kind of remind you of that story. The summary of the story goes as I said, the developer asks a coding agent to fix a credential issue in staging.
这是一个相当普通的请求,一个平常的下午。智能体先读取工作区,并在一个无关文件中发现了一个数据库访问令牌。这是一个拥有完全访问权限的基础设施令牌。This is a pretty ordinary request, ordinary afternoon. The agent starts by reading the workspace and in an unrelated file, it finds a database access token. This is an infrastructure token with full access.
它判断修复办法是删除该卷并重新创建。但它能访问的那个卷并不属于预发布环境,而这个猜测与 API 之间也没有任何阻隔:调用没有身份标识,没有策略,没有审批,实际上也完全没有记录。It decides the fix is to delete the volume and recreate it. Except the volume it has access to is not staging and nothing is standing between that guess and the API. There's no identity on the call, no policy, no approval and really no record at all.
所以,我们一举删除了生产环境及其备份,而这些都处于同一个网络边界内。于是,一瞬间全都没了。大约只花了 10 秒钟,就彻底摧毁了这家初创公司的整个数据库和备份。So in one fell swoop we've deleted production, it's back up and all of that lived within the same network boundary. So it's all gone in one instant. Took about 10 seconds to kind of completely bring down the startups whole database and and their backup.
在我们进入这场演讲的下一部分时,我想留给你们的一点是:这个智能体拥有有效凭证,但其意图并不正当。这才是这种情况下对与错的真正区别。因此,我想在这里提出的观点是:未经制衡的权限才是真正的失误所在。Now what I want to leave you with as we kind of go on to the next part of this presentation is that the agent had valid credentials but it didn't have valid intent. That's the real difference between the kind of right and wrong in the situation. So my argument I'm going to make to you here is that the unchecked authority is the real failure.
智能体可能会出错,也可能会遗漏上下文。如今大家对此都很清楚,你知道,我们以前都遇到过这种情况。但你在那个场景中没看到的是:那里没有漏洞利用,没有越狱,也没有提示注入。An agent can be wrong, it can miss context. It's pretty well understood now, you know, we've all been in that situation before. But what you didn't see in that scenario is that there was no exploit, there was no jailbreak, no prompt injection.
实际上并没有恶意行为者。没有人故意做什么来损害系统或公司。有效密钥做的正是有效密钥会做的事,对吧?There was really no malicious actor. There was nothing that anyone was doing intentionally to kind of harm the system or harm the company. The valid key did exactly what valid keys do, right?
代理按照它认为应该做的去做了。因此,对于受监管业务来说,问题不在于错误发生了,而在于代理的判断与 API 之间没有任何屏障。根本没有真正的护栏。The agent did what it thought it should do. So the failure for regulated business is that not not that the mistake happened but nothing stood between the agent and its judgment and the API. So there were no real guardrails in place.
这在整个行业中是如何展开的How this is playing out across the industry
在深入探讨我们如何改进的蓝图之前,我想先给你们三个数字,看看这在我们这个行业里是如何体现出来的。第一个数字是82%:所有组织中,已经在使用AI代理的比例。这个结果大概不会让任何人感到意外。另一个数字是32%:已经制定AI治理政策的组织比例。考虑到这两个数字之间的差距,这个结果可能更令人意外。Before we get into kind of the blueprint of how we can do better here, I wanted to give you three numbers that represent how this is playing out in our industry. The first 82% of all organizations already run AI agents, no surprise probably to anyone. 32% had an AI governance policy in place. So probably more surprising given the difference between the two.
最后,一旦发生数据泄露——这要归咎于某种影子 AI——平均损失通常估算在 500 万美元左右。所以,这算是个挺有意思的数据。不过基本上,我们可以得出结论:AI 的普及是普遍的,但控制层实际上并不存在,显然也谈不上普及。Um and then finally, when a breach does happen, thanks to Shadow AI of some kind, uh the average cost is usually calculated to be about $5 million or so. So, that that that's a fun stat. Um but essentially, we can conclude that um air adoption is universal, but the control layer doesn't really exist and it's definitely not universal.
嗯,在我们开始探讨这种情境下智能体的控制层可能是什么之前,嗯,不如先从我们一直以来要求员工做的事情说起。只要有软件,或者说任何形式的 SaaS 软件以来,我们就一直用这样的标准要求员工。Um before we go to looking at what a control layer for agents could be in the scenario, um what let's actually just start at what we've asked people our employees to do uh for as long as we've known. We've held people to this kind of standard as long as there's been software or you know, SaaS software of any kind.
我们对人们已有的期待What we already expect from people
嗯,我们对人员的要求包括:必须使用自己的账号登录。我们要求所有人不要共享任何类型的密码或密钥,而且你不能批准自己的权限提升或权限变更。我们还要求系统记录所有变更。Um the the things that we hold people to are you have to sign in as yourself. Uh we ask nobody we ask everyone to you know, not share passwords or keys of any kind uh and you can't approve your own escalation or changing permissions. And we expect systems to keep track of all changes.
这很常见,对吧?如今的软件都是这样。这也是我们所期待的。That's pretty standard, right? That's all software today. That's what we expect.
嗯,问题是,如果你在受监管行业接受审计,别人会问的不是模型够不够聪明、你的智能体够不够聪明,或者是不是用了最新版本,而是:是谁采取了行动,谁批准了这件事,然后把事情经过的记录给我看。Um the question uh if you're being audited in a regulated industry, the question that will be asked is, you know, not is the model smart enough is your agent smart enough or using the latest release, but it'll just be who acted, who allowed it, and then show me the record of what happened.
智能体的控制层A control layer for agents
所以,如果我们要把这套做法应用到智能体上,我首先要说的是,我们不想阻止智能体,对吧?我们不想设置一道障碍,结果团队会想办法绕过去。智能体也会绕过去。So, if we're going to apply this to agents, the first thing I'll say is we don't want to stop agents, right? We don't want to uh create a block that teams are going to find a way to route around. Agents will work around.
我们知道,封堵其实行不通。呃,答案是创造一条有意义的行动路径,而且比不受治理的做法容易得多。所以,我们希望受治理的行动实际上比不受治理的行动更容易实现。We know that blocks don't really work. Uh the answer is creating a path to action that is meaningful and uh much easier than the ungoverned one. So, we want the governed action to actually be easier than the ungoverned action.
嗯,我再用另一个有趣的动画给你展示一下:对于一个真正受治理的操作,端到端的流程可能是什么样的。想象一下,你有一个真正的控制层,也就是某种神奇的系统,能够管理运行在你的机器上和云端的智能体。嗯,你最关心的第一件事,就是它开箱即用。Um let me show you with another fun animation what that path end to end could look like for a truly governed action. So, imagine you had a true control layer, you know, a magical system of some kind that governed agents on your machine and in the cloud. Um the first thing that you really care about is that it works just out of the box.
所以,你加入公司,完成入职流程,并希望落实所有这些策略。嗯,在动画的第一步中,我们展示的是:在你入职这家公司的第一天,这些内容就已经预装在你的笔记本电脑上了。嗯,关于哪些事情应该做、哪些不应该做的策略,只需在中央统一编写一次。So, you join the company, you onboard, and you want all of these policies in place. Um so, in this kind of first step of the animation, we're we're showing that it's something that comes out of the box installed on your laptop the first day you start at this company. Um the policy of what should happen or not happen is written once centrally.
呃,这不是开发者需要在自己的智能体或运行框架中编写的东西。呃,它只需编写一次,之后就会在公司层面统一强制执行。呃,针对这个,我们来想一个简单的例子吧。Uh it's not something a developer needs to write on their agent or their own harness. Uh it's written once and now kind of enforced at the at the company level. Uh for this one, let's think of a simple one.
我们选择关注用户提示和工具请求中的机密信息。我们希望采取的操作是阻止或隔离。嗯,我们再用之前那个场景,也就是开发人员意外删除数据库的情形。We'll go with secrets on user prompts and tool requests. And the action that we want is block or a quarantine. Um we'll take the same scenario again um of kind of what we did earlier, uh you know, from the developer accidentally deleting the database.
呃,在这种情况下,嗯,用户正在输入 AWS 密钥。嗯,也可能是从另一个代理那里传来的。模型看到它之前,会触发一个钩子,而这一切都发生在 harness 运行时。Uh in this case, um the user's putting in AWS key in. Um or it might even be coming from another agent. Before the model ever sees it, a hook fires, and um this happens all in the harness runtime.
所以,它检测到有一个密钥正在被发送,嗯,而提示词被控制层评估的一项策略拦截了。呃,该策略由一个检测器强制执行,其中一个检测器匹配到了 AWS 密钥。因此,这里有一种拦截的概念,嗯,而且在拦截发生的同时,也会生成一个决策。So, it detects that there's a key that's being sent, um and the prompt is caught by a policy that's evaluated by the control layer. Uh the policy is enforced by a detector, and one of them matches the AWS key. So, there's there is a concept of like an interception that happens, um and then as that happens, there's also a decision that's created.
而这一切都发生在——你知道,理想情况下,我们希望控制在100毫秒以内。我们希望……我们不想让智能体或人真正改变他们当前的路径。嗯,所以这一切发生得非常快。And all of that happens in, you know, ideally we want it to be like 100 milliseconds or less. We want We don't want the agent or the human to really change the the path that they're on. Um so, it happens very quickly.
最后,嗯,你知道,一旦发生拦截,系统就会记录下来,并对这次事件进行审计。所以,秘密信息经过检查、拦截和记录,实际上从未离开过这台机器。在这个案例中,开发者唯一损失的不过是一个糟糕的提示词。嗯,我们从概念上简化一下这里发生的事情。And then finally, um you know, once the interception happens, that's logged, and now there's an audit of that event that's happened. So, inspected, blocked, and logged, the secret never really left the machine, and in this case the developer lost nothing but just a bad prompt. Um let's simplify this kind of conceptually into what's happened.
嗯,我们将把它视为四个步骤,公司可以围绕这些步骤构建治理架构。Um we will look at this as four steps that a company can model a governance architecture around.
连接、检查、决策、记录Connect, inspect, decide, record
嗯,第一点我喜欢称之为 connect。嗯,这是创建一个入口,而不是设置几十个不同的集成点。代理连接外部系统时发出的所有调用,都应该汇集到一个地方,比如一个 MCB 网关。Uh the first I like to call connect. Um this is creating a one creating a door instead of, you know, having dozens of different integration points. All of the calls that an agent does when it connects to external systems should go to one place, something like an MCB gateway.
我们很多人都用过这些,也很了解它们。嗯,第二点是,这些调用需要被解析到一个具名代理,或者背后的真人。嗯,没有身份信息,策略评估就无法真正发挥作用。A lot of us have used those and understand those well. Um the second is that the calls need to be resolved to a named agent or a human behind it. Um policy evaluation doesn't really work without identity.
嗯,这也必须是所有企业软件所分配到的同一个身份,这样才能确保整个组织内的一致性。嗯,第三步是做出决策:你可以允许、拒绝、隔离,或者升级处理。有时,仅仅向用户发出警告就足够了。Um this has to be the same identity all of the enterprise software is assigned to as well, so it's consistent across your organization. Um Third, there's a decide step where you either allow, deny, quarantine, or you escalate the decision. Um and then sometimes even just warning a user is sufficient.
最后,这个决策会在实际采取任何行动之前被记录下来。接下来我们会更详细地探讨其中几个方面,这样我就能为你提供更好的蓝图,帮助你在自己的产品或公司中实现这一点。首先是身份。And then finally that decision is recorded um before, you know, any action is actually taken. Um we're going to dive into couple of these in a little bit more detail so I can give you a better blueprint of how to do this uh for your own product or your own company. The first is uh identity.
那么,谁参加了这次通话,谁实际执行了这个请求?嗯,如果我们看眼前这种屏幕,它分为两部分。左侧是我们提出的事件。So, who was on the call, who actually executed uh this request? Um if we look at this uh kind of screen in front of us, there are two sides to it. The left side is the incident that we posed.
这就是此次事件的日志。文件上发现了一把密钥,但是,没有记录执行者,也没有人批准过这项操作。嗯,所以,如果你以审计员的身份来看这件事,你会想知道究竟是谁采取了行动,谁该对此负责。That's the log from the incident. A key was found on the file, but no, there's no actor and there's nobody who approved it. Uh so, if you're looking at this as, you know, uh an auditor, you're wondering who actually took the action, who's responsible.
嗯,这些……说实话,这就是如今大多数系统的默认状态。嗯,直到今年早些时候,我们的系统也还是如此。每个主体、每个代理、每个用户,嗯,都是借用某个人的身份。Um these And to be honest, this is the default state of most systems today. Um it was even ours you know, until earlier this year. Every principal, every agent, every user, um it's all borrowed based on a person's identity.
如今,大多数运行智能体的公司都普遍存在这种情况。即使是后台作业,也会关联到某个用户,或者创建一个匿名的系统角色。甚至 Slack 助手通常也是以用户权限运行的。This is pretty common in most companies today running agents. Even a background job is mapped to a user or there's just a anonymous kind of system role that's created. Even Slack assistants or tend to be running as like user permissions.
它们不一定拥有自己的身份。右侧是同一个提示词,只不过现在是从控制层的视角来建模。智能体本身就是一个主体,因此拥有自己的身份。They don't necessarily have their own identity. On the right is that same prompt now modeled to the lens of a control layer. The agent is a principal in its own right, so it has its own identity.
下面你可以看到,有一名、一名操作员执行了这项操作。那么,实际上是谁在实时与那个、与那个智能体交互呢?这种情况下是我。Below that you see there is an an operator who drove the action. So who is actually interacting with that with that agent in real time. In this case it's me.
嗯,这会被记录下来用于归因。它绝不会被用来实时扩大访问权限。最后,还有授权者。Um and that's recorded for attribution. It's never used to like widen access in real time. And then finally there's the authorizer.
因此,这里显示的是批准为该代理进行初始凭据设置的人。本例中是我们的 CISO Thomas。此信息在凭据的整个生命周期内保持不变。So this is the human who approved the original credential setup for the agent. In this case it says Thomas who's our CISO. This is fixed for credentials lifetime.
所以,右边这张卡片才是我们真正需要的合规记录。它如实记录了实际发生的事情,以及我们如何对其建模。嗯,下一张主要是讲给观众中那些集合论爱好者听的,不过它展示了如何实时判断调用是成功还是失败。So the right hand card is what we really want for compliance. This is a true log of what actually happened and how we could model it. Um the next one is for kind of the set theory nerds in the audience, but it's how you actually decide in real time whether the call succeeds or fails.
嗯,这个大致分成三个部分。第一个是左边这个。我们的凭证。Um let's the kind of three parts to this. The first is the one on the left. Our credentials.
这是人在签发密钥时设定的权限上限。因此,这同样是永远不会被扩大的东西。它存在于凭证中,是你无法超越的上限。This is the ceiling of what a human put down when they issued the key. So this again is the thing that never gets widened. It lives in the credential and it's something you can't escalate past.
第二个我们称之为 A。它是智能体自身的策略,不能拥有管理员权限,也不能拥有任何仅限人类使用的权限范围。The second is we call it A. It's the agent's own policy. It can't hold an admin privilege or any or any kind of human only scope.
最后,O 是所有者当前的策略。因此,代理所能做的绝不会超出对它负有责任、并实际驱动它的那个人。在这个例子中,那个人就是我。And then finally O is the owner's live policy. So an agent can never do more than the person accountable for it who who's actually driving the agent. So in this case it was me.
嗯,这样建模有意思的地方在于,你知道,第二个和第三个 A 和 O 会在每次调用时读取。如果你移除一项权限,嗯,它在下一次请求时就会消失。所以,系统会重新评估。Um what's interesting about modeling it this way is that you know, the second and third A and O are read on every call. If you remove a permission, um, it's gone on the next request. So, it's re-evaluated.
嗯,如果回到我们一开始讨论的数据库场景,即使所有者有权删除生产环境,一个权限范围仅限于暂存环境的代理也做不到。而且,如果有人给代理设置了更宽泛的策略,它也无法超越一个从未拥有生产环境权限的所有者。所以,无论从哪个角度看,你都能受到保护。Um, and if we go back to that database scenario that we started with, even if the owner could delete production, an agent scoped to just staging can't. And if someone gave the agent a broader policy, it can't exceed an owner who never had production rights. So, in kind of both directions, you're protected.
嗯,无论哪种情况,调用都会停止。呃,最后还有一点很重要:如果所有者离开了公司,由于这与企业身份系统关联,你的 IDP 会撤销其权限,之后代理发出的每个请求都会被拒绝。Um, either way the call would stop. Uh, and then finally, an important note, you know, if an if an owner would leave a company, um, since it's connected with your enterprise identity, your IDP de-provisions them, and every request that agents make is now denied going forward.
记录事件经过以满足合规要求Recording what happened for compliance
呃,这个概念流程中的最后一步,是记录实际发生了什么。嗯,左边再次展示了这一场景的展开过程。嗯,右边则是它实际留下的内容,因为现在我们有办法对已经发生的步骤进行建模。Uh, the last step in that conceptual flow is is recording what actually happened. Um, so, on the left is again that scenario playing out. Um, on the right is what it actually leaves behind, now that we have a way to kind of model the steps that have happened.
嗯,我们可以在这个流程中看到,随着你逐步完成不同的步骤,会出现一个拒绝步骤;同时也有明确说明的意图:代理本来想在 staging 环境中执行操作,但实际却在 production 环境中执行了。嗯,策略会同时看到这两方面的信息。因此,合规框架如今普遍采用的就是这种做法。Uh, we can see kind of in this flow, as you go through the different steps, there's a denial step that happens, uh, and there's a stated intent, which was that, uh, the agent wanted to act on staging, but the action was done on production. Um, the policy sees both sides of that. So, this is where compliance frameworks have generally landed today.
嗯,每个非读取操作都会依据策略进行评估;该策略会考虑智能体声明的意图,而不只是实际发生的操作。嗯,在大多数控制系统中,评估结果恰好会是五种决策中的一种。正如之前提到的,可以是允许、拒绝、修改,或升级交由人工处理。嗯,每个经过评估的操作都会生成一条记录,记录发生了什么;而且在很多系统中,这条记录通常会以加密方式绑定到智能体的身份。Um, every non-read action is evaluated against policy uh, that considers the agent's stated intent, uh, not just the action that actually happened. Um, in most control systems, there's exactly one of kind of five decisions that comes out of this, uh, like we mentioned earlier, it's either allowing, denying, modifying, or escalating up to a human. Um, every evaluated action produces this kind of record of what's happened, and then in generally, in a lot of systems, it's cryptographically bound to the agent identity.
所以,我只有一张幻灯片,会带大家了解我们在 Speakeasy 是如何构建这一切的。我就只讲这一部分。嗯,正如我之前提到的,我们——我们 Speakeasy 是一个 AI 控制平面。So, I have only one slide that's going to actually take you through how we built this at Speakeasy. So, I'll keep it limited to that. Um, as I mentioned earlier, we we Speakeasy were an AI control plane.
呃,我们实际上把我们的产品放在代理和它们能够访问的系统之间;人们会使用这些代理,或者让它们自主运行。嗯,所以身份……身份基线来自你的 IDP,也就是 Okta 或其他身份提供商。Uh, we actually put our product in between agents uh, that people use or using autonomously, and the systems that they have access to. Um so the identity comes the identity baseline comes from your IDP. Uh so Okta or another identity provider.
嗯,然后操作策略实际上是在我们的产品或控制平面上进行评估的。因此,每一次调用——包括被我们拒绝的调用——都会经过我们。然后我们会为客户写入审计日志。Uh and then the policies of action is actually evaluated on our product or our control plane. So every call um includes the ones including the ones that we deny all go through us. And so we write out the audit log for for our customers.
在这种架构中,有三项关键决策。呃,第一项正如你所看到的,是我们处于关键路径之中,而不是在关键路径旁边。呃,记录必须反映实际发生的事情。There's kind of three kind of critical decisions in this architecture. Uh the first as you can see is that we sit in the critical path not beside it. Uh the record has to be of what actually happened.
嗯,这不是代理报告的内容。其次,我们会采用某种一等身份,而不是在系统中到处使用用户登录信息。最后,我们会将其部署到 MDM。嗯,所以这一切都是开箱即用的。Uh not what the agent reported and two we use kind of first class identity uh instead of using user logins everywhere to the system. And then finally we'd actually distribute to MDM. Uh so all of this comes working out of the box.
对于用户来说,他们不必在自己那边重新定义这些策略。无论是刚加入公司,还是开始使用智能体,这些策略都会立即生效。这就是我关于 Speakeasy 的唯一一张幻灯片,不过之后我很乐意再和你们详细聊聊。For a user they don't have to go redefine these policies on their end. It's something that just works the moment they start uh at the company or start using an agent. So that's my only slide about Speakeasy but I'm happy to talk to you more about that later.
总结:有效的凭据不代表有效的意图Summary: valid credentials aren't valid intent
嗯,那么,概括一下我们刚才讲的内容:在受监管行业中,行动许可通常意味着,对于每个智能体或智能体采取的每项行动,都必须证明三件事:行动者是谁、哪些政策允许该行动,以及记录由谁签署。Um So that's the to kind of summarize what we went through. Uh in a regulated industry permission to act usually means kind of three things have to be shown for every agent or every agent action that is taken. Um who the actor was, what policies allowed it uh and the signing of the record.
所以,既然我们确切知道这件事确实发生过。嗯,这一直以来都是我们要求企业员工做的事,而现在我们也要求智能体这么做。嗯,凭证有效,不代表意图正当。So knowing for a fact that this actually happened. Um this is what we've always kind of asked employees to do at a business and it's what we ask agents to do now. Um valid credentials are not valid intent.
这一点非常重要,务必要记住。解决办法不是简单地说我们有一个更智能的模型或更好的智能体,而是要把身份、策略以及每一项正在发生的操作记录整合起来。嗯,今天我想和你聊的内容大概就是这些。That's something that's really important to remember and the fix is not you know just saying we have a smarter model or a better agent. Uh it's actually putting together identity policy and record of every action that's that's happening. So that's uh kind of everything I wanted to talk to you about today.
嗯,最后还想告诉大家,我们今晚会和 Tailscale 的朋友们一起举办一场活动,推出一项合作:将你的 MCP 网关部署到私有网络上。欢迎在现场的朋友来参加。好了,也很乐意回答大家的问题。Um I'll also leave you with um we're doing an event tonight with our friends here at Tailscale um launching a partnership around private put taking your MCP gateway and putting it on a private network. Join us if if you're here. And yeah, happy to take questions.
问答Q&A
主持人:开始吧,摄像机。嘉宾:我有一个问题,假设你使用的智能体受我们正在谈论的那个星球的伦理准则约束,而你不同意它做出的拒绝该行动的决定。你会……你会如何设计一项政策?Host: Go ahead, camera. Guest: I had one question on say you're using an agent that is being governed by the ethics of the planet we're talking about and disagree with the decision that it came to to deny that that action. What would you How would you design a policy?
主持人:是的,这是个好问题。我觉得,嗯,你知道,可能最重要的第一件事是,你确实要有办法查看做出了哪些决策。所以,在如今大多数公司里,当人们使用——比如说 Anthropic 的 Claude,并将它连接到所有系统时,它访问这些系统的过程中,实际上并没有记录它做出的那些决策。Host: Yeah, that's a that's a good question. I think um the you know, if probably the first most important thing is that you do have a way to see what decisions were taken. So, in most companies today when people are using you know, just let's just say Claude from Anthropic and connected to all the systems, as it's accessing these systems, there's really no record of those decisions taken.
所以,即便你不同意“嘿,这个用户本不该访问你的 CRM”这种说法,你也无法回头确认这件事确实发生过。其次,你确实需要一种方式,在这种情况发生时将用户升级处理,这样你才能决定是否放行。因此,我认为这些算是更根本的缺失环节。And so, even if you disagree that hey, this user shouldn't have been able to access, let's say your CRM, you can't go back and actually say that has happened for sure. Secondly, you do want a way to escalate your user when that happens so you can actually decide if you want that to be passed or not. So, those I would say they're kind of more fundamental missing pieces.
如果你已经有了这个,就可以随时去更新一项政策,让这件事真正成为可能。好,请继续。主持人:在那 56% 没有相关政策的人中,我很好奇,哪些是因为监管机构强制要求才购买,哪些是因为出了问题才购买。If you have that in place, you can always go update a policy to actually allow that to happen. Yeah, go ahead. Host: Out of the 56% without policies, I'm curious who's buying because regulators force them versus something broke.
比如说,是什么因素会影响预算?嘉宾:是啊,这是个好问题,也是我们经常思考的事情。Like, what moves the budget? Guest: Yeah, that's a good question. Something we think about a lot.
我想说,合规确实是促使人们考虑部署解决方案的一个很好的驱动力。但我想留给大家的一点是,你不一定要为了满足合规要求而购买产品;你首先需要做的,是了解自己的业务中实际发生了什么。所以我会说,合规是推动预算投入的一个很好的因素。一旦发生事故,通常就会提高这类事项的优先级。I would say compliance is a really good driver for people to think about getting a solution in place, but I think the the reason what I want to leave you with is that it you don't necessarily you know, buying a product is to fulfill compliance, but the first thing you need to do is kind of understand what is actually happening in your business first. So, I would say compliance is a great driver of budget. When there is an incident that that often, you know, raises the priority of something like this.
请继续。主持人:你们会对 PII 进行脱敏吗?比如那些经过你们控制平面的日志?嘉宾:会的。Go ahead. Host: Do you mask PII or like the logs that come through your control plane? Guest: We do.
我们做的事情包括拦截、屏蔽以及对 PII 进行脱敏。嗯,我们发现,在大多数企业中,一旦开启可观测性,查看所有经由智能体处理的内容,就会发现其中有大量 PII。所以,如果你打算把 PII 一概拦截,很可能会让业务陷入停摆,对吧?We do everything from kind of blocking, masking to redacting PII. Um, what we've found in most businesses when you turn on observability and you look at everything going through the agents, there's a ton of PII going through. So, if you are going to kind of block on PII, you'll probably grind your business to a halt, right?
只是人们很难避免让智能体使用 PII。我认为更重要的是关注这些 PII 会被如何处理。比如说,这个智能体的用途是什么?It's just it's hard for people to not use the agents with PII. I think the more important thing to look at is what is happening to that PII. So, like what's the intent for the agent?
它会把内容发布到公开的 Slack 频道、通过电子邮件发送,还是放回到某个工具中并调用另一个系统?我们建议人们用可观测性来制定这类策略,而不是一味地封锁或删除所有个人身份信息。我想问这个问题,是因为如果发生了事件,我会向控制平面调取我们的日志,了解究竟发生了什么,对吧?Is it going to post it in a public Slack channel, send it by email, put it back into a tool called to another system? Those are the kind of policies we try to recommend people to, you know, use observability to define rather than just kind of blocking or redacting all PII together altogether. Host: I guess I'm asking that question because it's like if there is an incident, I'd ask the control plane for like our logs and to understand what happened, right?
获得授权了吗?客人:是的。主持人:你得把那些日志给我,对吧?With authorization? Guest: Yes. Host: You would have to like give those logs to me, right?
不过,我一开始为什么要把数据给你呢?因为这些数据是专有的,是我们的独门秘方。嘉宾:是啊。But, why should I give you like the data in the first place? Like because it's proprietary and it's our secret sauce. Guest: Yeah.
主持人:那么,像这种情况,它的信任模型是什么样的? 嘉宾:嗯,我是说,这就有点涉及我们如何部署的细节了。不过,我们确实有几种不同的软件部署方式。比如,我们提供一种数据平面选项,可以在你自己的 VPC 中运行,这样数据就会留在你那里。Host: So, like what's the trust model with that? Guest: Yeah, I mean, that's kind of it's getting a little into the details of how we deploy, but like we do deploy our software in a few different ways. Like we do offer kind of a data plane option where it runs in your own VPC, so data stays with you.
不过,客户更常见的做法是自带加密密钥,对吧?我们确实会对数据进行加密,但客户可以自带密钥,以便自行管理。是的,客户通常会进入我们的产品,查看其中涉及的所有个人身份信息(PII);至少会查看所有发现项,即使他们不查看经过脱敏的数据本身。But, the more common option that customers do is they bring their own encryption keys, right? So, we do encrypt the data, but you bring your own keys for so you can govern it yourself. And yeah, customers often will go into kind of our product and look at what is all the PII at that happened at least look at from the perspective of like all the findings even if they're not looking at the redacted data itself.