有效凭据不等于合规意图：AI Agent 行为授权与控制平面

My name is Sagar. 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 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.

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. 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.

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.

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.

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. 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. 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.

Uh the first I like to call connect. Um this is creating a one creating a door instead of, [snorts] 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 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. 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.

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, 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.

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. 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. 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.

So that's uh kind of everything I wanted to talk to you about today. 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.

[applause]

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?

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. 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. If you have that in place, you can always go update a policy to actually allow that to happen.

Yeah, go ahead.

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.

Go ahead.

We do. 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? 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? 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.

Yes.

You would have to like give those logs to me, right? But, why should I give you like the data [snorts] in the first place? Like because it's proprietary and it's our secret sauce.

Yeah.

So, like what's the trust model with that?

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. 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.