Sandboxing AI Agents: The One Control That Actually Matters Transcript, AI Summary & Key Points

00:07 An AI agent does not need to get hacked to wreck your day. It just needs to read the wrong thing. A poison dependency, a malicious comment buried in a file, a web page it fetches while doing perfectly ordinary work. The moment it reads instructions, somebody hid in there, it follows them with your permissions, your credentials on your machine. And here's the part that changes how you should think about all of this.

00:36 There is no patch for prompt injection. It isn't a bug someone's about to fix. It's how these models work. So the real question was never how do I stop this from happening. It's when it happens, how much damage can it actually do? That's what sandboxing is really about. Not trusting the agent. So, in this video, I will walk through the ways people actually run coding agents.

01:04 One agent you're watching, one agent you walked away from, and a whole swarm of them running at once. Each one comes with a different security bill. What you lock down, how hard, and what it cost you to do it. Get it wrong in any of them and the damage is bigger than you think. Get it right and you can walk away from an agent and still sleep at night.

01:28 Everything we are about to get into like sandboxing agents locking down eress containing the blast radius quietly assumes one thing that you're already handing real work to AI in the first place. Worrying about how much damage an agent can do is honestly a great problem to have because it means you've got agents doing enough to be worth worrying about.

01:52 But if you're not quite there yet, if AI still feels like a chatbot you ask for occasional questions, that's where the sponsor of this video comes in. Outskill runs a two-day AI mastermind, a weekend workshop that takes you from poking at the chat box to actually building with AI. Over 16 hours with expert mentors, you go hands-on with 10 plus AI tools, deep research, building your own agents, automating the boring parts of your week, generating images and videos, and getting into clo code itself.

02:26 The training normally costs $895, but the sponsor is giving away thousand free seeds to viewers of this channel and over 10 million people have already been through it. You can grab a free seat through the link in the description. Scan the QR code on the screen somewhere and join the WhatsApp community before the seats run out. Big thanks to Outskill for sponsoring this video.

02:52 And now, let's get back to boxing in our agents. Let's start with the simplest way anyone runs a coding agent. One agent on your machine and you're sitting right there over there watching it and approving all or at least some of its operations. Run this command. Yeah, edit that file. Go ahead. You are in the loop and you're the one making the calls.

03:21 This is where most people start and the tools for it are everywhere. Cloode code and open code both work this way out of the box. Cursor Geminina CLI GitHub Scopilot agent same idea, right? They pause, they ask, and you approve. That approval prompt is doing the real work here. Now, you could lock this down a lot harder if you if you really wanted to, and it's worth knowing what's on the menu.

03:45 So, let's go through it. You could switch on the sandbox that ships inside the agent itself. Clode and Codex both have one of those, right? They're built on operating system features like Mac OS seat belt and Linux bubble wrap and they fence off what the agent is allowed to write and where it's allowed to connect. Now you could go a step further and run the whole thing inside the container so it's playing in its own little isolated copy of an environment instead of directly on your system.

04:15 You could go further still and put it in a virtual machine or one of the lightweight micro virtual machines which hands it its own kernel and real hardware boundary between it and and your host. You could give it an entire dedicated machine physically separate from the one you actually work on. And on top of all of those, you could clamp down the network, an allow list of the domains it's allowed to reach, a proxy sitting in front of it, DNS filtering, so it cannot just phone anywhere it likes.

04:45 And I will happily admit the obvious. Every single one of those makes you more secure. Not just in this mode, in in any mode. More resolution is more isolation. Easy. So why am I about to tell you not to bother with any of it? Well, because in this mode, in this particular mode, you are the authority. You're approving its operations as they happen. You're already deciding in real time what's okay and what isn't.

05:12 Bolting a sandbox on top of that is doing the same job twice. Think about what a sandbox actually is. A hardness that decides what the agent may or may not do. That's exactly exactly what you are doing by hand every time you hit approve over there. If you trust that hardness enough to let it make those calls, why are you sitting there approving everything?

05:37 Why? If you don't trust it, why is it your hardness in the first place? You can't have it both ways. It's like a manager who stands up and says, "I completely trust my team." And then it micromanages every single thing each of them does. Pick one. Now control can absolutely be a tool and for plenty of people it should be. It just cannot be a tool and you at the same time both of you doing the same job or you're wasting your own time.

06:08 If you want the machinery to be the authority then take your hands off the wheel and let it run without you. That's a real and legitimate choice. And one more point and it's a blunt one. When you're the person approving, whatever the agent does is on you, not the model, not the vendor, not the tool. You watched it happen and you said yes. So when something goes wrong in this mode, there is no honest way to point a finger at the AI because your hand was on the button.

06:45 The moment you let an agent run unsupervised and walk away, the job you're doing decided what it can and cannot do falls to the hardness around it. And a hardness you don't fully trust is worse than none because it lets you feel safe while you aren't. So assume the worst. Fed had a poison file or a booby trapped web page. The agent will eventually try something you would never allow.

07:10 And with you gone, nothing stops it unless you built something that does. Ah, let's start from the beginning. The most important thing, the network. And there is a reason why most people get that part backwards. Think about what a compromised agent wants. Your keys, your source, your data. Grabbing that is the easy part. And you mostly cannot even prevent it.

07:37 The agent runs on your machine. So, of course, it can read what's on it. Picture walking into the louver and lifting Mona off the wall. That's not the hard part. The hard part, the thing that actually stops the haste is getting it out of the building. Your agent is no different. It can grab whatever it likes. But if it cannot carry anything off the machine, the theft is worthless.

08:03 And the way out is the network. lock the exits and it stops mattering what the agent picked up because none of it leaves. That's why the network is the first thing to control. So what does controlling the network actually look like? The simplest version is a domain allow list. You run a proxy, route all of the agents traffic through it and set it to default deny.

08:28 Nothing leaves except a short list of destinations you explicitly permit. your package registry, your git host, the API your model sits behind and not much else. Cloth code ships this out of the box and other agents are adding their own versions. A proxy running outside the sandbox that checks every connection against an allow list or you build your own.

08:52 A connect only proxy like let's say squid with a dozen or so urls on the list turns out to be plenty for real work. Now, there's a catch though, and it's a big one. A plain domain allow list checks the host name the client claims it's dialing. It never looks inside the encrypted traffic. So, it's by possible and not in some theoretical way. With domain fronting, traffic rides out under an allowed name while actually heading somewhere else entirely.

09:24 or the agent simply resolves a block domain, takes its row IP address and connects straight to that, walking right past a filter that only knows about names. And it really, really happens. There was, for example, a bugging cloth. It was live for five or six months and there was a host name with a hidden null bite in it that slipped past the allow list check, but connected only to the attacker's domain.

09:53 Someone built a full exploit out of it. Poisoned repo content, prompt injections, steal the credentials, ship them out. It got quietly patched by Antropic later. And now the point isn't that one agent is uniquely bad. Every agent that does host name allow listing has the same class of weakness. The point is that this boundary is loadbearing. It's a wall holding weight and walls holding weight get attacked.

10:24 There are two more traps. I mean there are more than two but two I want to talk about that people fall into. First, if your whole control is setting an HTTP proxy environment variable and trusting the agent to honor it, that's that's not enforcement. It's a polite request. An agent with shell access can unset that variable or wipe the environment for subprocesses and your proxy is gone.

10:49 Real enforcement lives at the network layer where the kernel forces every packet through the proxy and the agent has no way around it. Not in a setting it can edit or anywhere else. Second, DNS. If an agent can fire lookups at any resolver it likes, it can smuggle data out inside the lookups themselves one query at a time. Now, that's slower than the scary headline suggest, but it works.

11:16 So, you force DNS through a resolver you control as well. Now, if you want to go further than names, you terminate the TLS. The proxy decrypts the traffic, actually reads what's inside, and scans for things that look like secrets walking out the door, like an AWS key, a GitHub token, a private key, and so on and so forth. Is the only way to inspect what's in the request rather than just where it's headed.

11:45 Now, the cost cost is real, though. You are now running a man in the middle on your own agent, installing a certificate into its trust store and dealing with everything that breaks when you do. It's hard to maintain those things. And for that reason, plenty of setups decide it's more trouble than it's worth and stay with host name allow listing knowing it it leaks.

12:09 then that's a legitimate call as long as you know that's the trade you're making. Next credentials and here the bind is unavoidable to do anything useful. The agent needs secrets. It needs it. It has to push to your git host pull from a private registry maybe deploy something. But those secrets are the exact crown jewels you're trying to stop it from stealing.

12:36 The floor is simple. Never keep credentials in files on disk. Read them from an external store into environment variables that live only for the session. But even that isn't enough once you walked away because a compromised agent can read its own environment as easily as it reads a file and now nobody's watching when it does. So you change the goal.

12:58 Instead of trying to hide a secret the agent can plainly reach, you make the secret barely worth stealing. That's what short-lived tokens are for. Rather than a permanent key, you give the agent a credential that's minted on demand, scope down to one narrow thing it needs and set to expire in minutes. Steal it and you've stolen something that's already dead or dies before you can do much with it.

13:25 You can't take it home and reuse it tomorrow. So, where did those tokens come from? Well, something has to issue them and it cannot be you doing it by hand. It it cannot be that. The whole point of this mode is that you walked away. An agent running on its own for hours needs a fresh credential every time it decides to act and you're not there to hand one over.

13:49 Mint a single longived key up front and leave it on the machine and you're right back to a durable secret sitting there to be stolen. So the issuing has to be automated and short-lived, which rises the real question, automated by what? If the answer is the agent itself holding a key that mints tokens on demand, you've solved nothing, that minting key becomes the crown jewel.

14:17 The tokens it prints are disposable, but the key that prints them isn't. And stealing it lets an attacker print for forever. The fix is to have no minting secret at all with workload identity. The right to get a token is tied to proof of what the workload is attested by the platform, not to a secret on the machine. The platform confirms this is your agent in your environment and hands back a short live credential.

14:45 You cannot copy and carry off what the workload is the way you can do it with a key. So there's nothing durable left to steal on a cloud. That's uh the provider's token service and workload identity federation. Off a cloud uh spiffy and spire or vault and many others uh are doing it for you. They provide dynamic secrets and yeah they're they're all doing more or less the same job.

15:12 All that still leaves the practical question. If the credential lives outside the agent, how does the agent get anything done? Two ways. The lighter one is to inject the freshly minted shortlived token into the agent's environment so it can make its calls. The agent does hold the credential but only a disposable expiring narrowly scoped one never the durable authority that means them.

15:36 The stronger one, the stronger option is capability separation. The agent never sees a credential at all. A broker sits outside it and when the agent makes an outbound request, the broker attaches the credential on the way past. The agent gets its work done and the request goes out authenticated, but the secret was added beyond the agent's reach. There's nothing on the box for a compromised agent to steal and nothing for it to mint.

16:04 That also settles the longunning case. Your agent might run for hours or days, far longer than a token that lasts minutes, and you're not going to reuse them by hand. A sidecar does it. Reattesting continuously and rotating in fresh credentials as the old ones. Spire does this. A vault agent does this. A cloud instance identity does this. They all do it.

16:28 You wire the agent to that identity once and it draws a steady supply of short-lived credentials for as long as it keeps proving is the workload it claims to be. The moment it stops, the credentials stop with it. A machine or a pod with an identity attached gives you this almost for free. And now the blunt part because some of this is a force field.

16:50 Short-lived scoped credentials stop someone stealing a reusable key. True. They do nothing to stop a compromised agent from misusing that key while it's alive and within reach. Picture a gun that's loaded but chained to wall. Nobody can walk off with it. But anyone standing in the room can still pull the trigger. That splits the danger in two. If the agent turns destructive, deleting the resources it's allowed to delete, corrupting a database it can write to, pushing poison code to a branch it can reach, no credential

17:27 trick and no network filter stops it because the damage never leaves the blast radius. Only tight scope and real isolation bound that. If instead it wants to read your data and get it out, that's that's the lure again and eress control is what stands in the way which is the whole thread over here. Shortlive tokens shrink the time window. Scope shrinks the reach.

17:50 A broker removes the takeable secret. Egress stops the exfiltration and isolation cups the blast radius. Miss one of those and a class of damage walks straight through. credentials are one of the walls, not the whole building. The last piece is isolation. Not where the agent runs, but how tightly it's boxed in on whatever machine it's on. And there are two questions really.

18:20 What can it touch? And if it breaks out of whatever you put it in, how far does it get? The cheap everyday answer to the first one is file system scoping. You confine the agents rights to its working directory and nothing else. That alone stops a whole category of mischief because it cannot reach out and plan something that out leaves the session. No editing your shell profile.

18:48 No slipping a hook into your git config. No rewriting the agents own instructions so it misbehaves next time. The built-in sandboxes, cloud codes, and others do this by default, and it costs you nothing. The second question is how far a breakout gets. And it comes down to how strong a wall you put around the agent is. Start at the bottom, right? No wall at all.

19:15 The agent running loose on your own machine with everything you've got. While you're supervising, that's perfectly fine because you are that wall left to itself. It's reckless. An unsupervised agent running straight on your daily driver is like setting off fireworks inside your apartment is dangerous enough on their own and doing it in the room where you live only makes sense if the plan is to burn the place down and collect the insurance.

19:43 So once you walk away running it bare on your own machine is off the table and you start then you start climbing the ladder. The first real rung is a container and it comes with catch word understanding. Containers are what most software already runs in and for normal workloads they're completely fine because you know what's inside. It's your code doing what you told it to do.

20:10 An agent breaks that assumption. You don't actually know what is going to run. And a container shares your machine's kernel, which never mattered while you trusted the workload, but matters a great deal now because a hostile process only needs one kernel bug to climb out of the container and onto the host. So, a container gives an agent a neat self-contained environment, but it is not a real security boundary against something actively trying to escape.

20:42 From there the wall gets thicker, right? Something like G Visor slides a thin softer kernel in between catching the agent system calls before they reach the the real one. Stronger still are microVMs like Firecracker and Kata. You know the usual names which give the agent its own kernel behind the hardware boundary. So a breakout lands it in a throwaway virtual machine rather than on your own box.

21:08 Now at the very very top of the ladder, you drop the software tricks altogether and just use a different computer, a whole separate physical machine isolated the old-fashioned way by not being the same box you work on. If the agent burns that one down, it burns down something that isn't your machine. That's the strongest isolation there is. So how high do you climb?

21:37 You don't go always to the top. The rung you need really tracks one thing. How far you stepped back from watching. Are you hitting enter key and staying right there all the time ready to step in the second it does something dumb? Or did you kick it off and walk away letting it rip on its own while you go and lay down for a while? I live in Spain so let's call that what it is.

22:02 You take a siesta, right? It isn't that you're deliberately running dangerous code. You almost never are. It's that the less you're watching, the longer a prompt injected agent can act without nobody there to stop it. Glance at it now and then and the container is a is a fair middle, right? It's cheap and easy as long as you don't mistake it for for a hard wall.

22:25 now walk away completely for hours at a time and the wall has to get real because there's no one left to catch anything. That's the point where microVMs or a separate box stops being paranoia and becomes sensible default. So when something goes wrong with an unsupervised agent and now and then it will the fault isn't AIS, it's hardness which means it belongs to whomever built the hardness.

22:56 It could be you or the platform team that built one for you, right? Somebody did it. Knowing that is the price of walking away. That being said, that's not the reason to refuse to walk away. You should walk away. you should let it do his stuff because think of an unsupervised agent like a self-driving car. The first time you see that empty driver seat, it's it's it's unnerving.

23:21 But the answer was never to refuse to get in and keep doing all the driving yourself. It's to make the car safe enough to trust, then let it drive while you spend the trip on something better. That's what every control in this section is for. An unsupervised agent isn't reckless because it's unsupervised. It's reckless when it's unsupervised and unharnessed.

23:50 Build the hardness and stepping back stops being a gamble and turns into time you get back. Now run many agent at once instead of one. And and here's the good news first. Most of what you would do to secure a swarm is exactly what you already know. You isolate each agent, put each one behind its own aggress rules, scope each one's credentials. None of that is new.

24:19 Is the single agent playbook run once per agent plus the ordinary discipline of keeping any two workloads apart? If you want to hold on to some plausible deniability to not know that you're wrong in thinking that, you can skip the rest of this uh section right here because that isn't the whole story. And what's missing is exactly the part that that can bite you easily.

24:44 So, what is the part that bites? There's one thing a swarm does that a single agent simply cannot do. The agents talk to each other. They hand work back and forth, share a memory, read from the same repository, post to the same message bus, and so on and so forth. And the moment they do, isolating each one stops being enough because the danger no longer comes from an agent breaking out of its box.

25:11 It comes from the channels between the boxes. And once you wired up on purpose, it was never really about the number of agents. It's about those agents communicating and sharing state. The first and the most striking of those is contagion. Ped the prompt injection to just one agent in the fleet. And it doesn't stop there. That agent passes the poisoned instructions along in its normal messages to the others.

25:38 Each of them does the same. And the compromise spreads across the whole swarm on its own like a like a worm with the attacker having touched only one agent. And researchers have already watched this propagate through entire populations of agents in a handful of message rounds. And it's it's it's a mechanism that simply cannot exist when there is only a single agent to infect.

26:04 And it goes further than the agents just chatting. They call on each other to get work done. So, picture one agent working on your front end that realizes it needs a change to the backends API before it can finish. It doesn't stop and wait for you. It hands the task off to or spins up an agent that owns the back end, which makes the change and reports back.

26:30 And and here's the important part. That's generally useful. It's often the entire reason you would run a swarm in the first place. But look at what it means. Your fleet isn't a fixed set of boxes you you draw some boundary around it. It grows. It reaches across projects on its own. And the communication you're relying on to make all of that work is the exact same communication an attacker rides.

26:55 A compromised agent doesn't even need existing peers to infect. It can spin up its own or reach across into another project to do whatever it was turned to do. There is a second twist as well, and it's almost more unsettling. Agents don't treat each other with the suspicion they would aim at you. An agent that would flatly refuse a shady instruction from a stranger will often carry out the same instruction when it comes from a fellow agent because it reads a peer's message as a colleagueu's plan, not as untrusted input.

27:30 It's like a like a junior developer walking up to a senior one, the person who actually calls the production access and saying the CEO needs this done right now. The senior can do it because it trusts that the request came from inside and it does it. It's the same thing with your agents. A single compromised one, even a lowprivileged one, can talk a more trusted, more capable agent into the damage it cannot do itself.

28:00 It doesn't attack the stronger agent. It just asks it to do something. And notice what none of that is stopped by. You can put every agent in its own microVM, lock down each one's cigress, scope each one's credentials, and a poison message still travels from agent to agent to agent along the channels you opened on purpose. Pair agent isolation, it's necessary, but against contagion and borrowed trust, it's almost besides the point because the attack just rise the communication, not the breakout, just the communication.

28:39 The controls that help here are of of a different kind like treat messages from other agents as untrusted input rather than trusted plans. Keep the shared surfaces small, the shared memory, the shared repo, the message bus and keep the number of agents that can talk to anyone uh agent low since every extra connection is another pot and affection can travel.

29:05 And it's worth knowing this is this is newer. This is shakier ground than the single agent controls. Anyone selling you a solved answer here is is overselling. And when when a swarm turns on you, the accountability is the same as it's been all along, just with more rope. You wire the agent together. You decided they could talk what they would share, who was allowed to spin up whom.

29:33 Nobody. Nobody handed you that topology. You designed it. And a swarm that eats itself is a swarm you connected badly. The model didn't choose to let one poisoned agent reach 40 others. You did when you build a graph. Before you go and wrap every agent in in an armor, let me give you the the honest cons because sandboxing bites back as well. The first thing you will hit is that it it breaks your flows.

30:02 A task dies halfway through because it needed a domain you didn't allow list. A right silently fails because it landed outside the workspace and the agent has no idea why. So it keeps going and makes things worse. Then there's allow all fatigue makes someone approve every single connection and every single bright and within a day they're just you know hammering allow to get their work done which which quietly defeats the entire point.

30:34 And here's the big one. No sandbox is airtight. We already saw the null bite bug. Add the domain fronting. SNI spoofing connecting straight to row IP DNS over HTTPS encrypted client. Hello. And there we go. Every one of those is a way out. Containment shrinks the blast radius. It never never makes the agent truly trustworthy. And here's the thread that's been running under every section.

31:02 Even those failures are yours. You picked a containment with known holes or you trained yourself to click allow all. The limits were written down. Ignoring them was a decision and it was it was your decision, not AI's decision. So, let me pull the whole thing into into one picture. Three modes, one agent you're watching, one agent you walked away from, and a swarm of them running at once.

31:26 Across all three, you're really turning the same three dials. what the agent can reach on the network, what credentials it's holding and how tightly it's boxed in. When you're sitting there, you know, watching, you're the hardness and you can leave these dials pretty loose. The further you step back, the more each one has to tighten. Walk away from an agent for hours and you want short-lived scope credentials, default deny egress, and a real wall like a microVM or a separate machine.

31:59 Put a swarm on top and you inherit two problems. No pair agent control touches. Contagion and the borrowed thrust agents extend to each other. And which mode you're in isn't some permanent choice you make once it shifts through a normal week. Some tasks you babysit, start to finish. Some you kick off and walk away from. Sometimes it's a handful of them at once.

32:24 The controls move with the situation, not not the other way around. If you do nothing else, do one thing. Control the eress. Here's the here's the rule of thumb. File system scoping stops an agent wrecking your machine. Egress control stops it robbing you. And hard resolution stops it escaping onto the host. Each one maps to a little more trust you're placing in code you never read.

32:47 But if you only got time for one, lock the exits because a thief who can't carry anything out goes goes home empty-handed. Now, now the trap on the other side and honestly is is the one I I worry about much more. The easiest safest looking move is to lock lock everything down so hard that nobody can do anything. Companies have done exactly that for decades and then they wondered why nothing ships.

33:15 Agents can hand you an enormous jump in productivity, but not if you burying them under the same lockdown or something even heavier. oversee secure and you get the worst of both worlds. People route around you. They click allow all. They disable the sandbox. So you end up with no real safety and no speed either and nobody sees any of the upsides. The most secure system is the one nobody can touch and nothing can deploy to.

33:41 It's also completely useless. The goal was never to maximize security. It's to have enough security to safely capture the productivity. It's the same lesson as a self-driving car. Make it safe enough to ride, not so safe it never leaves the garage. Thank you for watching. See you in the next one. Cheers.