WEBVTT

NOTE Sentence-level transcript of https://www.youtube.com/watch?v=BgLdvF7Qkh8

NOTE One cue per sentence. Cue ids are the line anchors on /transcripts/BgLdvF7Qkh8.html. A cue ends where the next begins, or 2 s after its last word.

s1
00:00:01.309 --> 00:00:03.309
[music]

s2
00:00:12.400 --> 00:00:14.000
So, my name is Aiden.

s3
00:00:14.000 --> 00:00:25.480
I'm one of the founding engineers here at Runlayer and today I'm going to kind of walk you through I guess like our process of how we internally kind of secured a lot of our agents.

s4
00:00:25.480 --> 00:00:35.680
So, across a lot of companies that we see nowadays you know most people have zero visibility into their clients or into the agents that they're running within their company.

s5
00:00:35.680 --> 00:00:40.920
You know, a lot of people are running you know MCP clients that are running locally on their machine.

s6
00:00:40.920 --> 00:00:47.960
They sign up for some random you know agent of a product on the internet and these things are connecting to MCP servers.

s7
00:00:47.960 --> 00:00:53.000
People are authenticating all over the place and there's nothing that's really accounted for.

s8
00:00:53.000 --> 00:00:56.480
A lot of these are running on on managed devices, stuff like that.

s9
00:00:56.480 --> 00:01:02.640
So, we had this problem internally and we went ahead and kind of started monitoring ourselves.

s10
00:01:02.640 --> 00:01:15.080
Pretty much what we did was you know we just as most people do you deploy a gateway, you start monitoring your agents people are running, logging every single session, every single tool call,

s11
00:01:15.080 --> 00:01:22.040
pretty much everything into some sort of sync centrally and we found quite a few things across our company.

s12
00:01:22.040 --> 00:01:32.480
You know, obviously a lot of people nowadays try to like anthropomorphize agents and I don't know how useful that is just given the current capabilities of them but in practice

s13
00:01:32.480 --> 00:01:38.320
there are more of these kind of like agents within companies than the people who actually are running them.

s14
00:01:38.320 --> 00:01:43.200
So, at least internally you know we're a company around 50-60 people.

s15
00:01:43.200 --> 00:01:52.720
We have over 300 agents that are running every single day and when I say agent in this sense I'm talking about things that you know users aren't necessarily triggering.

s16
00:01:52.720 --> 00:02:01.132
Sometimes these things are you know via some chatbot, via some trigger, via some SAS app or something like the likes but you know they're all over the place.

s17
00:02:01.132 --> 00:02:04.932
You know, we map these out we by topic, by risk.

s18
00:02:04.932 --> 00:02:07.852
You know, obviously not all agents are built the same.

s19
00:02:07.852 --> 00:02:11.332
Some are provisioned with too many tools.

s20
00:02:11.332 --> 00:02:14.492
They may have a much higher blast radius.

s21
00:02:14.492 --> 00:02:20.052
And you know, the connecting systems that were built for a different age than what we live in today, right?

s22
00:02:20.052 --> 00:02:25.412
A lot of systems have different, I guess, like classes of data that are inside of them.

s23
00:02:25.412 --> 00:02:40.652
And agents themselves can kind of really accelerate the risks that are associated with, you know, mixing that kind of data more so than what we've seen before where it would take, you know, writing some sort of program and connecting some API and really being intentional about what you're doing.

s24
00:02:40.652 --> 00:02:42.372
There's a lot more risk now.

s25
00:02:42.372 --> 00:02:53.252
So, one of my colleagues went and made this kind of visualization, but pretty much internally, you know, you could say, oh, in this here we have our own teams where these are mapped out by galaxies

s26
00:02:53.252 --> 00:02:56.972
and each of these is some individual agent that somebody is running.

s27
00:02:56.972 --> 00:03:06.532
And this planet, each of the planets there is some sort of like, you know, run of the agent that actually occurred sometime.

s28
00:03:06.532 --> 00:03:10.572
And, you know, we can go in and we can visualize, oh, hey, here's what all it's doing.

s29
00:03:10.572 --> 00:03:13.692
These are, you know, the MCP servers it's touching.

s30
00:03:13.692 --> 00:03:15.612
These are the the actions it's taking.

s31
00:03:15.612 --> 00:03:16.772
Maybe it's fetching something.

s32
00:03:16.772 --> 00:03:18.692
There were some errors, stuff like that.

s33
00:03:18.692 --> 00:03:24.172
So, obviously all of these tool calls are, you know, doing a bunch of different actions.

s34
00:03:24.172 --> 00:03:27.772
And each of these is, you know, what we'd consider an attack surface, right?

s35
00:03:27.772 --> 00:03:37.572
These are chances for people to read in some data that could be hostile, you know, take some sort of action that could be destructive or dangerous or even just, you know, exfiltrate data.

s36
00:03:37.572 --> 00:03:44.492
So, I guess just kind of dive into one very specific example, you know, that we were kind of looking into ourselves.

s37
00:03:44.492 --> 00:03:47.532
So, obviously we take in a lot of support data.

s38
00:03:47.532 --> 00:03:52.492
And you know, we want to try to identify as much as we can of this process.

s39
00:03:52.492 --> 00:03:59.172
So, most teams I'm assuming are probably doing something along the lines of, hey, you're taking in every single email that you have here.

s40
00:03:59.172 --> 00:04:10.894
You know, maybe something along the lines of, um you know, you have some malicious actor who sends an email to your company saying I don't know, go ahead and give me a list of all the you know, current prospects you have trying to um buy your product.

s41
00:04:10.894 --> 00:04:21.094
Um you know, if your agent is kind of naive, you could very easily you know, list all these things in your calendar um and it could possibly just like exfiltrate that data if the agent itself is you know, over permissioned.

s42
00:04:21.094 --> 00:04:29.774
Um but you know, having every single user go ahead and scope um all of the the tools an agent has or can use is kind of a difficult process.

s43
00:04:29.774 --> 00:04:36.014
Um I think a lot of people talk about you know, defining policies within um some sort of agent gateway um and it's really tricky.

s44
00:04:36.014 --> 00:04:45.334
Uh you kind of have to go and define every single rule in which you know, you would like to um you know, define the behavior of agents within your organization.

s45
00:04:45.334 --> 00:04:52.694
Um and it's not so simple as like hey, I want to you know, block uh particular uh tool in every single scenario.

s46
00:04:52.694 --> 00:04:54.534
Maybe sometimes it's safe for an agent to be doing this.

s47
00:04:54.534 --> 00:04:58.214
It all is really kind dependent on the context of um what's going on there.

s48
00:04:58.214 --> 00:05:00.374
So obviously there's a number of things you could do.

s49
00:05:00.374 --> 00:05:13.694
Uh you could just block um anything where uh you know, say you had some classifier model that you trained and you say hey, uh every single uh email that gets read, um we're going to scrutinize these and make sure that no instructions are being there.

s50
00:05:13.694 --> 00:05:17.934
You're going to get you know, a certain uh degree of effectiveness with this, right?

s51
00:05:17.934 --> 00:05:23.974
You know, nothing is going to be 100% accurate or you know, uh nothing will be 100% effective here.

s52
00:05:23.974 --> 00:05:26.374
Um but you know, you could go one layer further, right?

s53
00:05:26.374 --> 00:05:33.294
Maybe I want to block anything that's uh you know, sending any sort of uh PII out externally, right?

s54
00:05:33.294 --> 00:05:42.054
So you could sort of define some sort of policy that goes ahead and says hey, you know, uh I want to uh make sure that anytime I'm sending some sort of email,

s55
00:05:42.054 --> 00:05:50.854
uh it never contains you know, um some regular expression of like customer names uh you know, anything along the lines of something that matches some regular expression.

s56
00:05:50.854 --> 00:05:59.654
Um but you can even go one step further and say hey, maybe anytime something uh reads from a particular data source say uh some private calendar, uh we go ahead and block those.

s57
00:05:59.654 --> 00:06:07.055
So um obviously there's like a number of ways in which you can really detect these kind of um things um and it's super context dependent and really complex.

s58
00:06:07.055 --> 00:06:16.295
And we found at least deploying these internally is very difficult and still kind of you know, a problem that is still being worked on.

s59
00:06:16.295 --> 00:06:19.215
So usually it's you know, there's a lot of different ways you can do this.

s60
00:06:19.215 --> 00:06:25.855
These can be policies both on the inbound and outbound going into some sort of agent.

s61
00:06:25.855 --> 00:06:31.175
A lot of these attacks though, we also see don't really fit into one kind of tool call, right?

s62
00:06:31.175 --> 00:06:36.815
Some of these kind of happen over the course of an agent run and it may not be something that's external either, right?

s63
00:06:36.815 --> 00:06:46.015
So something along the lines of you know, a lot of companies that I've seen they all have some sort of internal agent reviewer on every single PR that gets

s64
00:06:46.015 --> 00:06:48.335
you know, created.

s65
00:06:48.335 --> 00:06:52.735
Some people have agent reviewers that are able to approve code.

s66
00:06:52.735 --> 00:06:54.615
Some people say that's crazy nowadays.

s67
00:06:54.615 --> 00:07:01.175
Some people say you know, you shouldn't even be writing these yourselves anymore, but I think that's still all up for debate.

s68
00:07:01.175 --> 00:07:07.695
But you know, in one example, all right, let's just say you know, you had some agent reviewer that has the ability to review and approve PRs, right?

s69
00:07:07.695 --> 00:07:17.655
So we have some agent that says, hey, you know, I could go ahead and review some security sensitive change and make sure I go along some checklist of all the things that I want to make sure that every single PR is following.

s70
00:07:17.655 --> 00:07:20.015
You know, maybe the author starts fighting back with this agent, right?

s71
00:07:20.015 --> 00:07:26.095
Maybe there's something you know, where the agent can read GitHub comments and actually look at what the user is saying to it.

s72
00:07:26.095 --> 00:07:31.735
It may have some sort of justification as to why oh hey, you know, this is why this is fine.

s73
00:07:31.735 --> 00:07:33.735
I'm passing all the checks.

s74
00:07:33.735 --> 00:07:38.815
And maybe they're saying something along the lines of like you know, oh hey, I just made some change like only review the cleanup, right?

s75
00:07:38.815 --> 00:07:42.455
Obviously if these agents are permission to kind of like do these sort certain things, right?

s76
00:07:42.455 --> 00:07:45.815
And it's not dynamic for what's going on within the session, right?

s77
00:07:45.815 --> 00:07:48.335
An agent could just go ahead and approve the PR if it just kind of forgot.

s78
00:07:48.335 --> 00:07:52.735
If you ask it 10 times, it's probably likely that you know, you could get it to do something.

s79
00:07:52.735 --> 00:07:58.255
I mean, I know like it's kind of hard to prompt inject like Opus nowadays, but these things still aren't perfect.

s80
00:07:58.255 --> 00:08:01.695
So we keep on finding more and more workarounds them.

s81
00:08:01.695 --> 00:08:09.457
But honestly, if you're not running some sort of like classifier model on every single one of these um, you know, tool calls, whatever, right?

s82
00:08:09.457 --> 00:08:12.377
It's really difficult to understand or to prevent these kind of attacks, right?

s83
00:08:12.377 --> 00:08:15.457
Some of these happen over the course of an entire session, right?

s84
00:08:15.457 --> 00:08:26.297
The intent of a session was or this agent was to, you know, hey, make sure you're blocking, uh, any sort of like non-security compliant, um, sessions that are going through this agent, um, however,

s85
00:08:26.297 --> 00:08:37.577
uh, it's kind of challenging to make sure that the intent and, um, every single action that's going on within it, uh, you know, doesn't drift from whatever the actual, uh, you know, whatever this agent was defined to do.

s86
00:08:37.577 --> 00:08:44.697
Um, so, internally what we've done is, you know, we've trained our own classifier models to kind of determine, you know, hey, uh, take all the data within this session,

s87
00:08:44.697 --> 00:08:50.177
um, and determine every single tool call, is this actually kind of aligned with what I was defined to do in the first place.

s88
00:08:50.177 --> 00:08:51.617
Um, so.

s89
00:08:51.617 --> 00:08:52.577
Anyway.

s90
00:08:52.577 --> 00:08:59.777
Uh, another thing we really found was that, uh, the all the data that you have within your agent sessions is like super valuable.

s91
00:08:59.777 --> 00:09:08.217
Um, a lot of the ways in which people are using agents nowadays is like, you know, hey, there's the ones that are running locally on your machine, you're using like Claude Code or something and writing code.

s92
00:09:08.217 --> 00:09:20.537
Um, those ones are a little trickier, but if you have, uh, agents that are very well scoped to a task, um, that data is, uh, very high signal when you see that the agent is kind of going outside of, you know, the

s93
00:09:20.537 --> 00:09:24.337
uh, or deviates from the bounds of what it's actually like defined to do.

s94
00:09:24.337 --> 00:09:35.577
Um, so, you know, here is kind of just a little visualization, like we have our recruiters internally, um, they have some sort of recruiter bot, uh, that is pretty highly provisioned, you know, has access to an ATS,

s95
00:09:35.577 --> 00:09:39.777
uh, meeting notes, a calendar, and can even like, you know, send messages to users.

s96
00:09:39.777 --> 00:09:46.657
Um, so, in general, uh, these agents, you know, while they're defined to do one thing, they could do uh, quite a bit.

s97
00:09:46.657 --> 00:09:56.137
Um, when we see these agents start using tools that are kind of outside of the normal, uh, deviate or, you know, normal like range of what this agent has done in the past,

s98
00:09:56.137 --> 00:10:03.257
um, we can kind of go and look and really flag like high-risk runs, um, early on and uh, make sure that we actually like can scope these down.

s99
00:10:03.257 --> 00:10:10.618
Um, you know, obviously, uh, having the ability to read an ATS from using some person's credentials, uh, could have a lot of things in there.

s100
00:10:10.618 --> 00:10:13.418
You know, there could be like negotiation emails, stuff like that.

s101
00:10:13.418 --> 00:10:20.258
Um and obviously like there's some level of risk that, you know, people are making or taking when creating these agents and using them internally.

s102
00:10:20.258 --> 00:10:27.378
So, uh trying to be deterministic in scoping down those uh permissions is super important, but it's really hard to define up front.

s103
00:10:27.378 --> 00:10:39.418
Um so, obviously uh what we've done is, you know, kind of we've made our own models that kind of help determine, "Okay, uh if look at all the past history of all the tool calls that have been made for a uh particular

s104
00:10:39.418 --> 00:10:48.378
agent and you know, defined to a very well-defined task, um and go ahead and, you know, try to suggest things that are like possible to, you know, descope from this agent, right?

s105
00:10:48.378 --> 00:10:56.578
It doesn't necessarily need access to um all the things within an ATS or read or read every single meeting, um stuff like that.

s106
00:10:56.578 --> 00:10:58.138
But, um yeah.

s107
00:10:58.138 --> 00:11:08.978
I think the last bit of security thing that we kind of um we're worried about was the fact that um you know, one agent within your company uh can really be detrimental to all the agents that are running internally, right?

s108
00:11:08.978 --> 00:11:17.178
Um especially when things are reading and writing to very uh largely or you know, systems that contain a lot of data, right?

s109
00:11:17.178 --> 00:11:19.698
They're not very uh well partitioned.

s110
00:11:19.698 --> 00:11:21.138
Um a single agent, right?

s111
00:11:21.138 --> 00:11:27.458
You know, say you take in some resume or something like that, uh could have some sort of malicious attack inside of it, right?

s112
00:11:27.458 --> 00:11:36.658
And uh you know, maybe one agent only has permission to go and uh you know, write to particular systems and it may be destructive in certain cases.

s113
00:11:36.658 --> 00:11:47.658
Uh it's really difficult for it uh or not it's really difficult to prevent the case in which, you know, um another agent is reading the data that another one came in because that's just kind of like um normal instructions, right?

s114
00:11:47.658 --> 00:11:51.658
So, you have to kind of go through the exercise of mapping out, "Oh, hey, here's all the systems.

s115
00:11:51.658 --> 00:11:53.658
This is how these things are connected, right?"

s116
00:11:53.658 --> 00:11:56.578
Um cuz really at the end of day, agents are just software, right?

s117
00:11:56.578 --> 00:12:02.498
They're just, you know, plumbing data between one source to another, um and it can be kind of uh dangerous.

s118
00:12:02.498 --> 00:12:13.139
So, uh what we kind of found was the really only way to do this is really really really um like tightly scope uh how exactly agents can write to a lot of these systems, right?

s119
00:12:13.139 --> 00:12:22.539
Maybe they're only writing to particular uh a databases within some sort of I don't know, some sort of SaaS app, stuff like that because that's really the only way you can keep

s120
00:12:22.539 --> 00:12:28.259
the context window of a agent, you know, pure and not poisoned.

s121
00:12:28.259 --> 00:12:38.739
But [clears throat] anyway, there's quite a bit of things you could be doing here, but it's kind of becoming a more and more relevant problem that we've been seeing at least internally.

s122
00:12:38.739 --> 00:12:47.259
Um But yeah, there's obviously quite a few layers that you could you know, defend your like own internal like agents.

s123
00:12:47.259 --> 00:12:53.419
But we found that like through this whole monitoring process that there was a lot more that we could do than just security.

s124
00:12:53.419 --> 00:12:57.859
For example, uh poorly written MCP servers.

s125
00:12:57.859 --> 00:13:05.539
Agents can kind of you know, they'll call these MCP servers and they'll see, oh hey, this tool it may be airing out and it'll go and try to find any sort of work around

s126
00:13:05.539 --> 00:13:07.419
when it encounters these errors.

s127
00:13:07.419 --> 00:13:14.579
And obviously, you know, you're paying for both input and output tokens on every single one of these and these errors can kind of add up over time.

s128
00:13:14.579 --> 00:13:21.579
And when you're you know, having this agent be very well defined or well scoped to a particular task, it's going to run it over and over again.

s129
00:13:21.579 --> 00:13:24.539
I mean, it's going to encounter these things quite a few times.

s130
00:13:24.539 --> 00:13:36.059
So one of these is like, you know, our recruiting team vibe coded a an MCP server to interact with some API for a vendor who doesn't provide an MCP server.

s131
00:13:36.059 --> 00:13:48.939
And uh them being people who have not written any software before had not tested it very much and you know, ended up having their cost balloon quite a bit because you know, it'd be running into a particular

s132
00:13:48.939 --> 00:13:53.179
formatting issues and you know, airing out over and over again.

s133
00:13:53.179 --> 00:14:04.139
So obviously, you know, monitoring these things, rate limiting them is super important in these kind of cases and making sure that you know, you're looking at the errors and just the quality of the code that's being run

s134
00:14:04.139 --> 00:14:07.939
on these MCP servers because not all of them are made same.

s135
00:14:07.939 --> 00:14:20.461
Um another thing we saw was a lot of stuff where people were running models that were really cheap at first initially when they did it, and they flipped a switch, went from, I don't know, GPT-56

s136
00:14:20.461 --> 00:14:28.621
Luna to Fable 5.1, and their cost ballooned to, you know, over like 100x within a week.

s137
00:14:28.621 --> 00:14:29.821
This is kind of happening everywhere.

s138
00:14:29.821 --> 00:14:39.261
People are kind of trying to, you know, track costs all over the place, but obviously people don't have the ability to just say no to every single thing.

s139
00:14:39.261 --> 00:14:56.581
It's really difficult to say justify in today's terms, like, "Hey, this is exactly why this particular task needs Luna, most, you know, needs Fable 5.1." It's really kind of hard at an enterprise to, you know, justify these costs because nobody, most people are not going to be running evals

s140
00:14:56.581 --> 00:15:04.021
on the agents that they're building, especially if they were already capable of kind of like turning these things into, you know, reusable code in the first place.

s141
00:15:04.021 --> 00:15:06.581
So, it's really tricky.

s142
00:15:06.581 --> 00:15:09.701
So, obviously these things can balloon really quickly.

s143
00:15:09.701 --> 00:15:15.421
Lots of people will end up just, you know, having their cost balloon, and they don't really know where to go from there.

s144
00:15:15.421 --> 00:15:26.621
But, setting budgets, and making sure that, you know, there are sane defaults in these cases, and really justifying how exactly people are, you know, deciding when, "Hey, this is a task that actually requires

s145
00:15:26.621 --> 00:15:30.181
some sort of, you know, extra intelligence."

s146
00:15:30.181 --> 00:15:36.181
Is really important to kind of how we started wrangling down our costs, at least internally.

s147
00:15:36.181 --> 00:15:37.861
But, yeah.

s148
00:15:37.861 --> 00:15:48.221
Other than that, you know, obviously, we really think that the only way to go about, like, you know, figuring out security or costs is just, you know, making sure you have the right tools in place to monitor these things,

s149
00:15:48.221 --> 00:15:51.581
to actually, you know, detect the things that are going on, right?

s150
00:15:51.581 --> 00:15:58.741
You can't just outright say, "Hey, I'm going to go like stop any all actions that are going on within my company."

s151
00:15:58.741 --> 00:16:06.581
And figuring out like where are the places in which like, you know, there are actually high-risk actions that, you know, require some level of scrutiny.

s152
00:16:06.581 --> 00:16:16.541
And then, you know, having the ability to kind of go ahead and intervene and stop, and you know, route people to use things that are actually, you know, going about the policies that you set internally.

s153
00:16:16.541 --> 00:16:18.902
But, but that's it Um, our talk.

s154
00:16:18.902 --> 00:16:20.382
Uh, thanks for coming by.

s155
00:16:20.382 --> 00:16:29.582
Um, we have a booth over uh, on the second floor and we'd love to kind of, you know, chat about how exactly you're wrangling down um, these kind of problems internally.

s156
00:16:29.582 --> 00:16:31.182
Um, but yeah.

s157
00:16:31.182 --> 00:16:33.182
Thanks.