How 60-person Runlayer secured its 300+ daily agents: put a gateway in front of everything, log every session and tool call, then use that data to classify attacks, scope down permissions and control costs — not by blocking everything up front.
Searchable transcript of 300 Agents, 60 People: How We Secured Our Own AI Agents - Aiden Sochowski, Runlayer — AI Engineer (16:38). Search for a phrase, then click its timestamp to jump straight to that moment in the video.
Captions sourced from the original video on YouTube, published by AI Engineer. The video, its captions and all related intellectual property remain the property of their respective owners; AINotes claims no ownership. Provided for research, accessibility and search — see the Transcript Notice and Copyright Policy.
00:01 [music] So, uh, my name is Aiden. I'm one of the founding engineers here at Runlayer. And, uh, today I'm going to kind of walk you through, uh, I guess like our process of how we internally, uh, kind of secured a lot of our agents. So, uh, across a lot of companies that we see now nowadays, um, you know, most people have zero visibility into their clients or into the agents that they're running within their company, um, you know, a lot of people are running, uh, you know, MCP clients that are running locally on their
00:39 machine. Uh, they signed up for some random, uh, you know, agentified product on the internet. Um, and these things are connecting to MCP servers. People are authenticating all over the place. Um, and there's nothing that's really accounted for. Um, a lot of these are running on on unmanaged devices, stuff like that. Um, so we had this problem internally.
00:57 Um, and we went ahead and kind of started monitoring ourselves. Um, pretty much what we did was, you know, we just, uh, as most people do, you know, deploy gateway, you you start monitoring your what, uh, like agents people are running, um, logging every single session, every single tool call, um, pretty much everything into some sort of sync um, centrally.
01:16 Um, and we found, uh, quite a few things across our company. um you know obviously a lot of people nowadays try to like anthropomorphize agents um and I don't know how useful that is just given the current capabilities of them but in practice uh there are more of these kind of like agents uh within companies um than the people who actually are running them um so at least internally you know we're a company around 50 60 people um we have over 300 agents that are running every single day um and when I say agent in this
01:48 sense I'm talking about things that you know users aren't necess necessarily triggering. Um, sometimes these things are, you know, via some chatbot, via some trigger, via some SAS app or something like the likes. Um, but, you know, they're all over the place. Um, you know, we map these out uh by topic, by risk. Um, you know, obviously not all agents are built the same.
02:07 Uh, some are provisioned uh with too many tools. Um, they may have a much higher blast radius. Um, and uh, you know, they're connecting systems that were built for a different age than what we live in today, right? Um, a lot of systems uh have different I guess like classes of data that are inside of them. Um, and agents themselves can kind of uh really accelerate the risks that are associated with you know mixing that kind of data um more so than what we've seen before where it would take you know writing some sort of
02:35 program and connecting some API and really being intentional about what you're doing. Um there's a lot more risk now. So uh one of my colleagues went and uh made this kind of visualization but um pretty much internally you know you could say oh in this here we have our own teams where these are mapped out by galaxies and uh each of these is some individual agent that somebody is running and this planet each of the planets there is some sort of like uh you know um run of the agent that actually occurred um sometime and
03:06 you know we can go in and we can visualize oh hey here's what all it's doing these are you know the MCP P servers it's touching. Uh these are the the actions it's taking. Maybe it was fetching something. There was some error, stuff like that. Um so obviously all of these tool calls are, you know, doing a bunch of different actions. Um and each of these is, you know, what we'd consider an attack surface, right?
03:27 Um these are chances for people to read in some data that could be hostile. Uh you know, take some sort of action that could be destructive or dangerous or even just, you know, exfiltrate data. Um so I guess just kind of dive into one very specific example you know that we were kind of looking into um ourselves. So obviously we take in a lot of support data um and uh you know we want to try to identify as much as we can of this process.
03:51 Um 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. Um, 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.
04:09 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 excfiltrate that data if the agent itself is, you know, over permissioned. 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.
04:29 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. 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. Um, and it's not so simple as like, hey, I want to, you know, block a particular uh tool in every single scenario.
04:51 Maybe sometimes it's safe for an agent to be doing this. It all is really dependent on the context of um what's going on there. So, obviously there's a number of things you could do. 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."
05:12 you're going to get, you know, a certain uh degree of effectiveness with this, right? You know, nothing is going to be 100% accurate or, you know, uh nothing will be 100% effective here. Um but, you know, you could go one layer further, right? Maybe I want to block anything that's uh you know, sending any sort of uh PII out externally, right? So you could sort of define some sort of policy that goes ahead and says, "Hey, you know, uh, I want to make sure that anytime I'm sending some sort of email, uh, it never
05:42 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." Um, but you could 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. 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 and um we found
06:06 at least uh deploying these internally is uh very difficult um and still kind of uh you know a problem that is still being worked on. Um so usually it's you know there's a lot of different ways you can do this. These can be um policies uh both on the inbound and on outbound um going into some sort of agent. Um, a lot of these attacks though we also see don't really fit into one kind of uh tool call, right?
06:29 Uh, some of these kind of happen over the course of an agent run. Um, and it may not be something that's external either, right? So something along the lines of um, 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 um, you know, uh, created. Uh, some people have agent reviewers that are able to approve code.
06:50 Um, some people say that's crazy nowadays. Some people say uh you know you shouldn't even be writing this to yourselves anymore but um I think that's still all up for debate but you know in one example right let's just say you know you had some agent reviewer that has the ability to review and approve PRs right so we have some agent that says hey you know I could go ahead and um 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
07:15 is following um you know maybe the author starts fighting back with this agent right maybe it's something you know where the agent can read GitHub comments um and actually look at what the user is saying to it. It may have some sort of justification as to why, oh hey, you know, this is why um this is fine. Um I'm passing all the checks. Um 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?
07:38 Obviously, if these agents are permission to kind of like do these certain things, right? And it's not dynamic for what's going on within the session, right? An agent could just go ahead and approve the PR if it just kind of forgot. If you ask it 10 times, it's probably likely that, you know, you could get it to do something. I mean, I know like uh it's kind of hard to prompt inject like opus nowadays, but um these things still aren't perfect.
07:57 So, we keep on finding more and more work around them. Um but honestly, if you're not running some sort of like classifier model on every single one of these um you know uh tool calls, whatever, right? It's really difficult to understand or to prevent these kind of attacks, right? Some of these happen over the course of an entire session, right? 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
08:24 agent. Um however, 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. Um so internally what we've done is you know we've trained our own classifier model to kind of determine you know hey take all the data within this session um and determine every single tool call is this actually kind of aligned with what I was defined to do in the first place.
08:50 Um so anyway uh another thing we really found was that uh the all the data that you have within your agent sessions is like super valuable. 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 cloud code or something and writing code 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
09:17 outside of you know the or deviates from the bounds of what it's actually like defined to do. 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 uh meeting notes a calendar and can even like you know send messages to users.
09:38 Um so in general uh these agents you know while they're defined to do one thing they could do uh quite a bit. 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 um we can kind of go and look and really flag like high-risk runs um early on and make sure that we actually like can scope these down.
10:01 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. You know there could be like negotiation emails stuff like that. 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. So uh trying to be deterministic and scoping down those uh permissions is super important but it's really hard to define up front.
10:25 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 particular agent and you know define to a very well- definfined task um and go ahead and you know try to suggest things that are like possible to you know descope from this agent right 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 But um yeah, I
10:56 think the last bit of security thing that we kind of um were 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? Um especially when things are reading and writing to very uh largely or you know systems that contain a lot of data, right? They're not very uh well partitioned.
11:18 Um a single agent, right? you know, say you take in some resume or something like that. Uh could have some sort of malicious attack inside of it, right? 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. 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,
11:45 right? So you have to kind of go through the exercise of mapping out, oh hey, here's all the systems. This is how these things are connected, right? Um because really at the end of the day, agents are just software, right? They're just, you know, plumbing data between one source to another. Um and it can be kind of uh dangerous. 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?
12:11 maybe they're only writing to particular uh databases within some sort of uh I don't know some sort of SAS app, stuff like that. Um because that's really the only way you can keep uh the context window of a agent, you know, pure and not poisoned. Um but [clears throat] anyway, uh there's quite a bit of things you could be doing here, but uh it's kind of becoming a more and more relevant problem uh that we've been seeing at least internally.
12:37 Um but yeah uh there's obviously quite a few layers that you could um you know defend your like own internal like agents. Um but we found that like through this whole monitoring process um that there was a lot more that we could do than just um security. Uh for example uh poorly written MCP servers um agents can kind of you know they'll call these MCP servers and they'll see oh hey this tool it may be erring out um and it'll go and try to find any sort of workound um when it encounters these errors.
13:05 Um, and obviously, you know, you're paying for both input and output tokens on every single one of these. Um, and these errors can kind of add up over time. Um, 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 and it's going to encounter these things uh quite a few times.
13:23 Um, so one of these is like, you know, our uh recruiting team uh vibe coded a an MCP server to interact with some API for a vendor who doesn't provide an MCP server. Um and uh them being people who have not uh written any software before uh had not tested it very much and uh you know ended up uh balloon having their cost balloon quite a bit because you know it'd be running into particular uh formatting issues and um you know erroring out over and over again.
13:51 Um so obviously you know monitoring these things uh rate limiting them um is super important in these kind of cases and making sure that you know uh you're looking at the errors and just the quality of the code that's being run um on these MCP servers because uh not all of them are made the same. Um, another thing we saw was a lot of uh stuff where people were running models um that were really cheap at first um initially when they did it and they flicked a switch went from I don't know uh GPD 56 Luna to Fable 51 um
14:21 and their cost balloon to you know over like or 100x within a week. Um this is kind of happening everywhere. people are kind of trying to uh you know track costs all over the place but um obviously people don't have the ability to uh just say no to every single thing. Um it's really difficult to say justify to in today's terms like hey uh this is exactly why this particular test needs Luna most or you know needs fable 5.1.
14:47 um it's really kind of hard at an enterprise to you know justify these costs because nobody not most people are not going to be running evals on the agents that they're building especially if um they were already capable of kind of like turning these things into you know reusable code in the first place so um it's really tricky um so obviously these things can balloon really quickly um lots of people uh will end up just you know having their cost balloon and they don't really know where to go from there um but setting
15:15 budgets uh ch and making sure that you know there are sane defaults in these cases and really justifying um how exactly people are you know deciding when hey this is a task that actually requires some sort of uh you know extra intelligence um is really important to kind of how we rank started wrangling down our costs um at least internally. Um but yeah uh other than that you know obviously uh we really think that the only way to go about like you know figuring out security or cost is just you know making sure you have
15:44 the right tools in place to monitor these things um to actually you know detect the things that are going on right uh you can't just outright say hey I'm going to go like stop any uh all actions that are going on within my company um and figuring out like where are the places in which like um you know there are actually high-risisk actions that you know require some level scrutiny um and then you know having the ability to kind of go ahead and intervene and stop um and you know route people to use things that are
16:12 actually um you know going about the policies that you set internally. Um but yeah that's it um for our talk. Uh thanks for coming by. 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. Um but yeah thanks