EPISODE 1952

[INTRODUCTION]

[0:00:00] ANNOUNCER: The most useful coding agents can mutate their environments by downloading packages, writing files, and connecting to services across the network. However, that freedom also presents dangers and promises to usher in a new wave of security threats. 

Docker recently announced Docker Sandboxes, which gives each agent its own isolated microVM while preserving the familiar ergonomics of a container. A standard container shares the host's kernel, but a microVM emulates hardware and runs its own kernel, giving a stronger security boundary around code that cannot be trusted. 

Mark Cavage is the President and COO of Docker, and he previously worked at companies including Stripe, AWS, and Oracle. In this episode, Mark joins Gregor Vand for a wide-ranging conversation that includes why agents break the immutability assumptions containers were built on, how microVMs differ from both containers and traditional VMs, and the still unsolved challenge of giving agents scoped trustworthy access to sensitive services and data. 

Gregor Vand is a security-focused technologist having previously been a CTO across cyber security, cyber insurance and general software engineering companies. He is based in Singapore and can be found via his profile at vand.hk or on LinkedIn.

[EPISODE]

[0:01:35] GV: Hello and welcome to Software Engineering Daily. My guest today is Mark Cavage. Thank you for coming on today, Mark. 

[0:01:42] MC: Yeah, thanks for having me. It's great to be here. 

[0:01:44] GV: Yeah. So, super exciting. You're the president at Docker. And Docker, I'm sure a lot of our audience know pretty intimately. We'll get into what Docker is for those that don't know in a second as well. As we like to do, you've had a pretty storied history in the tech world or through tech companies. Could you just give us a kind of a brief story of how you got all the way to Docker? 

[0:02:07] MC: Absolutely. Well, it's a funny story. There's two other characters here, Don and Tushar. We were part of the let's call it generation one of Amazon Web Services back in 2005. And we were all office mates back when AWS was, I don't know, somewhere around 100 to 200 people. Somewhere in there. Time all blurs it together. We've gone off and done different things over the years. We had also gone to Oracle and built Oracle's cloud, which was I always tell people it's a weird thing to do voluntarily, but we did that. 

At some point in the last couple of years, Docker was looking for new leadership. And as I always joke, unfortunately for Docker, they found us. And so Tushar found his way to Docker two and a half years ago, three years ago. And then as the band of merry brothers do, sort of called on his friends and here we are. So then Don and I joined February of last year. 

[0:02:50] GV: Yeah, let's start with what Docker is and then actually might just kind of pull back for a second after that. But yeah, what is Docker full stop for those that don't know. 

[0:02:58] MC: Yeah, Docker is a ubiquitous brand that I think many of us grew up on it over the last decade. Docker==containers is the shortest way to put it. But there's Docker the company, there's Docker the technology, there's almost like Docker the community and ethos. It's like it is many things rolled in one word. But at its root, it's containers. And basically, as I always tell people, if you go back to the very first genesis when Solomon Hykes, who founded Docker, solved a problem. It was the cloud exists. I have code on my laptop. I would like to get my code from my laptop to the cloud. This is really hard. 

Docker is a unification of packaging technologies to go make it easy to build and then ship software reproducibly from one place to the other, as well as a runtime which we'll talk about in a bit, that allows you to run those said containers. And then cleverly packed in there are several interesting primitives. It historically has leveraged OS virtualization in Linux. So you have a container is really at the end of the day a Linux namespace and gives you sort of isolation at the kernel level that's sort of multifaceted packed in there. 

Anyway, there's Docker technology. There's Docker Hub as well which is the ecosystem where people produce all kinds of packages. Docker seed the ecosystem with things like Node.js, and MySQL, and Python, and Postgres, and every other popular open source thing you can think of. And then tens of millions of people go and publish to Docker Hub every day and produce software that other people can depend on and build stacks and so on. 

And so now as you might imagine a decade later there is a very rich and vibrant ecosystem. There's a fascinating stat I had read, it's not ours, I wish it was, where somebody had done a survey and concluded. I think it was like 92% or 93% of every company on Earth at this point runs containers in production somewhere. So, it truly is now this ubiquitous way that people build and run software because it's kind of the lingua franca, it gets you portability, it gets you from laptop to cloud, it gets you from cloud to cloud. It runs everywhere. So, that's maybe a longer answer than you were looking for. 

[0:04:50] GV: No. No. There's never such a thing as too long an answer on SE Daily. Yeah, I mean I think it's one of these in computing we have names for things that we always try and sort of analogize to something in the human world if you want to call it that. But a container really is that. I think it's such a great metaphor or thing which is like you have this portable literal container. Think of container ships that you can move it from ship to ship, and it's the same system. And that was always the kind of the thesis here, right? 

[0:05:18] MC: Yeah. And importantly, you can pack all your stuff into it and it gives you a way to get your thing from point A to point B. And what it lets you do is encode all of your dependencies and take no - you don't need to worry what the host runs. In the old days, I am old, it was always this like protracted system to keep the build system up. And like, "Oh, it worked on my laptop but failed in CI." And then it worked in CI but then it failed in prod because there's some variances across whatever the kernel is, and whatever the operating system is, and whatever glibc is there. I'm dating myself at this point, but these things are all still with us. 

But that problem really has been largely just solved by Docker because it allows you to encode all the dependencies all the way down to effectively the base Linux layer and just not worry about that anymore. You put all your stuff in a container and then you ship it wherever you want on whatever boat you want or whatever crane you want. 

[0:06:09] GV: Yeah. I mean today's topic specifically is a newish product that you guys have produced all around agent sandboxes. We're going to get to that very shortly. Could you maybe just also walk us through what is the general Docker product suite if you like nowadays? I think for those that maybe kind of started with just like a Mac app and then maybe haven't appreciated, there's a whole bunch of other bits to Docker now just before we get into the latest product. 

[0:06:37] MC: Absolutely. I mean we'll definitely spend the majority of time I think talking about AI as you might imagine. That's where a lot of the focus goes. But the company, the core Docker desktop and CI tooling, we've been around for a decade. We have a rich ecosystem of things. 

The biggest thing above and beyond Docker desktop, which I think most people when they think of Docker today, I think they think, "Ah, I downloaded Docker Desktop, and I did my stuff." And there's all kinds of things that are in there around AI assistance called Gordon. There's scout for doing dependency scanning, etc. The biggest thing I think we've done in the last year besides the things around that is really what's in the - I'll call it the hardened image space. 

Again, we have been Docker Hub. Again, the hosting package manager for the ecosystem. We see the ecosystem for the last decade with several hundred images that help people again get started with Java, Python, Node, MySQL, etc. The wonderful thing with open source is everybody can contribute to it. The problem with open source is everybody can contribute to it and then some people contribute malware. And so many companies struggle to manage dependencies and manage their open source dependencies specifically. 

Docker hardened images is a way to go. It's a very opinionated stripped-down Debian and Alpine derived image where the contract from us is we'll never run as rude. We do all the things you'd expect somebody to go do to run software securely. But importantly, there's an SLA available with it where we actually are able to keep CVs out of it and promise you that within seven days of a vulnerability, we're able to go patch it. And so that's probably I would say the biggest thing besides AI that's been new that we've done in the last year to year and a half has been really Docker hardened images. Because it's sort of above and beyond the tooling and the runtime has been sort of the, "Okay, this is the content that really now - I put all my stuff in the container, and now my stuff is actually much safer than being-" I can make it clean not dirty effectively. And then there's AI which we'll talk about for I'm sure quite a bit. 

[0:08:22] GV: Yeah, the hardened containers piece, super interesting. We've done a couple of episodes on that sort of concept. And it's a very interesting space in terms of supply chain attacks and them only increasing is what we see. Yeah.

[0:08:35] MC: At this point, I think the funny thing, everybody goes through these. The industry goes through these trends. And four or five years ago, I swear if you asked anybody, they'd say, "Oh, the laptop's dead. They were all going to use cloud environments." Etc., etc., etc. Nobody cared. You couldn't get the time a day to talk about it. 

And now I think the developer laptop point in fact is the most juicy target for hackers on earth because it's like, "Great. If I get my keys there, I can go get massive distribution through the open source ecosystem." And so yeah, just supply chain security all up. I think it's a very broad and sprawling topic. And you could spend you know two hours talking about all the ins and outs of it, but it's a real problem. And when we look at the last six months of attacks, they practically speaking all started with got access to GitHub actions or got access to laptop. And then basically once there, got credentials, and the world's your oyster. 

[0:09:21] GV: Yeah, it's kind of scary what we've seen over the last especially couple of years. Just some of the sophistication of how people have gotten to others laptops to do such a thing. Today, yeah, we are going to speak a lot about AI. I always like try and time it like how far do you get through an episode before saying AI now? But today's topic is that. And we're going to be talking about Docker Sandboxes. 

I think to kind of set the scene though, we're talking about the concept of an agent sandbox in general. This as a concept is not unique to Docker. Could you maybe just set the scene? What is an agent sandbox at all basically? 

[0:09:56] MC: Great question. We get this all the time in particular because Docker, being such a ubiquitous word, let's call it historic Docker, gets used for a lot of agent sandboxing. But we've clearly done something very different, and I'll explain why. 

At the end of the day, a sandbox is yet another container for lack of a better word that I can put my agent into and bound to what it does and control all the dependencies it has and control the environment it has. Fundamentally, it's a virtual machine or a container or something. 

Now our flavor of it is actually based on microVM. Actually, the funny thing what we've done is tried to - not funny thing, but maybe hopefully we think the clever thing, give it the ergonomics of Docker, but importantly have a different construct on what the runtime is. And the reason this is important is it's full microVM based. What you get every time you run, there's a command line you download off of Docker called - it's in brew and all the obvious places. If you run SBX, our sandbox command, SBX run Claude, SBX run Gemini, whatever you want, OpenClaw, you get a dedicated microVM per thing that looks, feels, acts, kind of works the same way as a container starts up in a second or less. It all feels, "Oh, this feels like a Docker thing." But it is fundamentally a VM. 

Now the reason this is important, Docker containers have been around for a decade, and the ecosystem I think settled very early on in a very key primitive or very key property not necessarily by force but by convention of immutability. When you think about Docker containers, I build my stuff, I put it in the box, and the box now goes from point A to point B, and I get everything about it outside the box. And then there's no logs, there's no nothing. The thing is meant to be immutable. 

And indeed, if you look at the way that people deploy at scale, people run something like Kubernetes and they'll look, they'll actually have drift detection alerts and all the rest. And the moment that the container is different at all or changed from the signature that was deployed, it's considered a problem. And like in many cases, it's just like that's it, shoot it in the head, start over and we'll go redeploy the world. 

The problem is that's not how agents work at all. You run Claude Code or OpenClaw, whatever you want. The very first thing it wants to do is like, "Oh, thanks, Mark. Thanks for that great question. I've got you. You're so right. I'm going to go off and I'm going to go download 17 Python packages and write a bunch of temp files. And I'm going to do all kinds of crazy agent things that they do." Fundamentally, they need to mutate their environment. And I think that starts at a very core place of, well, often they're very good at writing code. And so whether you're a software engineer or not, many times the best way to answer a question to solve the problem is the agent needs to write code. 

But in many cases, as people build more and more and more sophisticated agents, you really can't plan ahead what access and needs to something. It becomes no different than a person, where at runtime you want to do some dynamic decision of what it needs, what it can access and so on. For us, this Docker sandbox or this SBX command really is a microVM with this core, very breaking primitive, it's a very breaking model for what Docker containers have been, is meant to provide the ergonomics, meant to provide sort of the brand and the ethos of everything about Docker but for that agent world. 

And then what it is it's a bounding box, and you get to have deterministic controls over a non-deterministic thing. You keep all your secrets out of it. You can very carefully specify what files and file systems you want in and out of it. And you can manage everything about the network on it. We're doing more things beyond that. But for today, the core shape of it is it's a box that you can observe and you can control. And you can be a god of your own little agent world. And you can keep it from ever seeing anything in a very deterministic way, which is very different than every time I interact with agents and a new update to auto mode or something comes out, I'm like, "Oh, let me go see if I can make it do the thing that it shouldn't do." And it takes me indeed like 4 minutes or less. It's just not that hard to go make them do something that you don't want them to do for the generation of technology we have. And sometimes I think you need determinism to actually help make the non-determinism safe. 

Sandboxing from us and the Docker - sandboxing I think is an overloaded word. The computer science definition is it's a place to run untrusted code. In the agent world, that practically speaking means sort of VM boundary. For us, this microVM technology is something we've taken all the DNA of Docker and all the things we've been doing for decades. We make it work on Mac, Windows, and Linux repeatably. It can work anywhere you want. You get to package up your stuff actually as a Docker container, slightly confusingly, for convenience and ease, but it runs in that bounded way that you can then observe and control. 

[0:14:15] GV: One area I'd like just to sort of pick on there is actually the microVM versus VM. Obviously, we're talking about virtual machine just for anyone not familiar with the acronym. microVMs in sort of my world have just be exploded in the sense. People know I work at Supabase. And Supabase, we interact with a lot of companies who want to have these agents doing things and running things. And microVM has just become this exploded term. How do you describe a microVM in comparison to a VM? Because I think a lot of people previously said, "Well, if I want to run something sort of "safely", I create a virtual machine and then I do on that." But what is the distinction? I mean, in the word there is micro perhaps. 

[0:14:53] MC: At the end of the day, I mean, this is where it's like we used to call things unikernels. There's always these words that are - for SE Daily it's like still kind of half marketing. At the end of the day, it is still a virtual machine but it has some properties of, well, we decide the kernel for you. We pick a bunch of things. And we've super optimized that you can run a lot of them. They run very resource efficiently, and they start up very fast. 

The way to think about it today, we have a many layered, it's a fairly complex architecture as you might imagine to do all the things we do on the host. Systems programming is back in a very exciting way. But the core, core thing of start VM of any type, we can do in under 100 milliseconds just to get the most raw thing up. We don't expose that because it's not terribly useful to the average person that wants to run Claude Code. But that core thing is meant to be super, super lightweight and super-fast. 

And then we do just a bunch of optimizations to make it where historically you think of VMs, and it's like, "Oh, I run VMware Fusion, or Parallels, or something, and allocate 9 gigs of memory plus two CPUs." You just don't do any of that. This is not a terribly technical answer, but it's meant to convey - really, it's a very fast thing where we've made a lot of opinions around the kernel and everything else. So you get an environment that has the properties of a VM, but we've just made it very small and very fast. 

[0:16:11] GV: Yeah. Diet VM. 

[0:16:12] MC: Yeah. Diet VM. 

[0:16:13] GV: That's a great explanation in terms of understanding. A lot of people probably sort of - yeah, exactly. A virtual machine to me is just this big heavy thing. Exactly, that takes up all this memory. But then a microVM, as it sounds, sort of super optimized. 

[0:16:25] MC: At the end of the day, a virtual machine emulates CPU, memory, network, I/O, which is contrast to like something as I was saying at the very beginning with Docker, with OS virtualization, where you have a shared kernel and you're basically emulating that kernel. This is actually full-on I emulate hardware. The contract you get is a hardware interface. And then we just tune a lot of stuff to make it small and fast. 

[0:16:45] GV: Yeah, that's quite a nice sort of segue into what makes I think Docker sandboxes different, which is the idea that you do actually get - rather your agent does actually get its own Docker demon network and file system inside that sandbox. Could you maybe speak a bit to kind of that architecture? 

[0:17:04] MC: Yeah, the way it works is you get this microVM. And in that it is a full-blown Linux OS. You can root on anything. We have a bunch of them built on our Docker hardened images. You can build them on Ubuntus, you can build them on Red Hats, build them wherever you want. And by the way, for our agents, there is an SBX run shell. So you too as a human can just get a shell and do whatever you want. 

Now in that you get a network proxy and an HTTP proxy and I/O proxies where we enforce everything that comes in and out of the machine. By default, you can start this up and it has no access to any host system, file system mounts, etc. Sometimes that's useful. You just want to make a throwaway thing that maybe goes and downloads some shady code off of GitHub and test it, inspects it, whatever, if that's what you want. 

More commonly, you're working in something like a GitHub repo project or Git project, excuse me, and you want to start either a worktree clone or you want to start literally with that project mounted into the file system so that the agent can actually work on your behalf and you can launch many of them. That's thing one. Thing two, you have network controls. So on the outside of this, you have an L4 terminating proxy that inspects everything. And when you start it up, you get to pick the level of security and safety you want. You can be incredibly locked down and say no to every network call ever. 

Again, if you're trying to like, I don't know, introspect some Bitcoin code out of a banned country or something, maybe you should do that. In practical terms, people will end up with something like an allow list or deny list and just block bad things versus common things and allow things for their company. 

And then there's the credential injection. Along with it is it leverages an OS keychain. And you put something like your Anthropic key, or your GitHub key, or your Docker hub token, and so on and so forth in a vault. And then inject it into the machine is actually a proxy parameter that is not the real credential. Inside the box, as long as you're using this correctly, the agent or the software can never see your real credential and everything gets intercepted by either the network proxy or by an HTTP proxy. 

We'll get into all the threat models and all the rest of what it can and can't do, etc. But with those primitives, you have the ability to keep only the things you want in the machine allowed, only the network calls you want to happen. And then you have a bounding perimeter around breach and how hard it is to roll your credentials because your credential was never shown to this effectively hostile adversarial kind of collaborative cooperative agent. 

With that, you then get this environment with all the controls around it. We've called them kits, which are a way for you to go package up your own flavors of Claude Code, or PI, or pick whatever you want. And you can run and create and share agents with other people that do what you want. 

I have my own that I'm a big fan of the PI agent now. I've come to love this thing. And mine is this like crazy setup where I've forked it in a bunch of ways. I've changed a bunch of the hooks and parameters. I have all my skills and my MCPs and everything else loaded into it. And then it's mine, and I can share it to other people inside the company and they can go use it if they want, and people can do the same thing. 

[0:20:01] GV: Yeah. As you say, threat model is something that's super interesting. And we will definitely sort of get on to that. 

[0:20:08] MC: I had a feeling you might ask. 

[0:20:09] GV: Yeah, you definitely get on to that. Just sort of sticking on I guess sort of architecture and that kind of thing for a second. The cold start piece to this, how does it actually work in practice? It's like these things, as they sound, they need to spin up from effectively nothing, but at a speed that you almost don't realize. How does that kind of all work? 

[0:20:29] MC: Yeah. The thing when we're talking about the architecture, I admitted this, the SBX command today that you download off the website is clearly optimized for the laptop case. I'm a human being. I'm using my laptop. I want to run Claude Code. I would like it to be safe and not be dangerous. I've been optimized for that. That's what it's for. 

We have this coming soon to a cloud near you or to a Docker website pricing page near you is a Docker cloud behind that that allows you to then work with those agents behind the scenes. And so you'll get different flavors of it. And we have a flavor working with people to - again, just like Docker. We're doing everything to the Docker ethos. Allow that daemon to run anywhere. Kubernetes clusters, your environments, etc. With that is a thing for us where we're explicitly making a runtime that is secure and cross-platform and has all these controls. 

To your startup question, what literally happens is take your laptop case this in mind, it doesn't matter if it's Mac or Windows. When you want to go launch, say, Claude Code, or OpenClaw, or even a shell, the very first thing it will do is go look at a registry. That registry might be Docker Hub. Look for a name and pull it down if you don't have it locally. If you don't have it locally, it will pull down this kit image that I've described which is in fact just an OCI or a Docker container as the actual bits and packaging of your stuff of what's in it. What skills? What agent? Etc. And then it will create a new virtual machine for you. You can obviously attach the ones that are running, but it will create a new one for you, boot up into that microVM and then start that software image as the actual agent. And then present to you back as a human, "Here's your Claude Code interface." And you can just now type to it the way you would. 

And you as a human, your workflow is unchanged from using Claude Code, or OpenCode, or anything else on your laptop. It's like bit for bit identical. We just literally give you the screen. We give you the screen with a box around it or the logical box around it. Now in terms of the startup time for it, the lowest level primitive is sub-100 milliseconds to get up. 

In practical terms, in the human experience time, I should do this before this call, where it's like, "Okay, I've already downloaded off my laptop." I'm not sitting on my airplane Wi-Fi or something. I have a shell image. A small image that doesn't have an interactive agent starts in around a second or just a little underneath one second. Very fast for the human to get up. 

In the cloud case, it actually is optimized for closer to that 100-millisecond mark because now you're talking about programmatic construction and spin up and spin down, and very bursty scale out ephemeral transient workloads that need to go happen. That same runtime is optimized for both of these. The actual SBX command that you download off the website today is very much optimized around the human laptop case. And so that's closer to a second. Because, well, when you get a Claude Code or a Codex image from us, it's like four or five gigs. Because it's not just Claude. It's like, "Okay, I've packed in the Rust compiler, I've packed in the Go compiler." We've basically packed in a dev box that's useful for the coding agent to go do stuff. You can tune it to your heart's content to change that. 

The one you get from us is meant to "just work". It's around a second to go get the human-facing one up, which is practically speaking for most people, "Okay. So what?" Every time I start Claude, it takes it several seconds to go back and forth with the Claude API which may be erring and overloaded at the moment and whatever it does. For the human, our goal is to get you the machine and get you into the agent, which is then operates at the speed of inference and human time, which is very different than something like programmatic scale out time. 

[0:23:55] GV: Yeah, that's very impressive. I'm just sort of zooming out to a product question, I guess, for a second, which was when this was being conceptualized at Docker. Thinking about Claude Code, that kind of thing, was that always a sort of first-class primitive that had to be part of the product? 

[0:24:10] MC: Yeah. I'm just teasing this. We have a cloud coming soon. The core thesis from us is, again, most people using Docker today when they think of it, they think of I have Docker desktop, or I have a Kubernetes engine, or I have Docker images. And that's how they think about it. But that's what most people associate Docker with. It's a natural thing for us to go do is like, "Okay, I solve the same problem." Because we got asked over and over and over again, "Hey, how do I run Claude Code inside of Docker?" And/or, "Hey, Claude Code is using Docker. What do I do?" And we ourselves use agents everywhere inside the company at this point. 

As we went through the journey ourselves, we're also like, "Well, okay, we're hearing from the market, and we ourselves are trying to do this. We kind of solved the problem for us and for everyone." But yeah, it was very much built around - there's something like the chatbot that you would build for a customer support site. Or so your quintessential examples you have as these agents that run for consumer-facing things that are practically speaking still look like normal software because they have a bunch of stuff to go with them. 

And then there's the human optimized case of trying to work with the coding agent. And so long-winded answer to yes, it was a very deliberate decision to go optimize for the popular common agents that people are trying to run day in and day out. And so I think there's 12 or 15 that we ship. And then a bunch of people have obviously done their own things on top of the ecosystem. 

[0:25:22] GV: Yeah, that makes sense. And this is I guess a sidebar. And disclaimer, I have almost no knowledge of this area but I'm just curious the whole OpenClaw thing. Does that apply here at all? 

[0:25:34] MC: I often joke all the time I keep seeing everybody, there's like this Mac mini shortage for buying OpenClaws. 

[0:25:39] GV: Yes. Yeah. Yeah. 

[0:25:40] MC: You could put them in a little virtual machine thing. You put them in that. And so for us, we made it an agnostic machine. What's the ethos of Docker? It's build once, run anywhere. We're Switzerland. I mean this is very - without getting into geopolitics. Because especially as an American, I feel like I can't say anything anymore. But anyway, we're Switzerland. And we work with anything. It's open to any model, any hardness, any agent, any operating system, any cloud. That's our entire ethos. And I think we're very credible to be the company that keeps that true. 

And so Claude Code and Codex. And if you go back in time last year, it's like, "Oh, everybody's on Cursor." And then Claude Code came out. Then we changed that. And then the OpenClaw, Moltbook thing all happened. And so now I think you have this explosion of a bunch of popular agents. And OpenCode is one amongst many. Sorry. OpenClaw. 

[0:26:24] GV: Yeah, that makes sense. So let's get on to threat model. I think a lot of people would be quite interested in this one. What is it? I mean in terms of what have you had to think through and step through in terms of making this secure? And then we'll get to out of scope as well because that's every threat model you have to decide what's in and out. What is in effectively? 

[0:26:45] MC: Yeah. Well, I think there's two things to this of what's in, which is first the sandbox itself. And then if you were a company or a team of people with multiple people. Because, again, you have multiple problems. But start with just the I'm a single person. I'm running something on my laptop. What am I worried about? 

Again, threat number one, if you're running something like - it doesn't matter if it's Claude, or OpenCode, or OpenClaw, or whatever. It is not terribly hard to go trick the agent into doing something that it shouldn't do regardless of what the permission setting is. And that's true if I'm running something like MCP. And I get managed to like - there's this hack last year of people doing Google calendar invites that had bad prompt injection, etc. Great. I get the agent to do something, read something that is innocuous. It gets injected. The agent says, "Oh, okay, great. I should go do that." And it goes off and reads your keys, reads your files, does whatever. 

Big threat number one is actually protect the agent from the host. And for the thing we talked about at the beginning where the developer environment is now like the juiciest target for supply chain, that's a big one because we've actually just taken all the keys outside of the box. No matter what you tell the agent to go do, no matter what the permissions are set on. By the way, when you run these, I omitted to say this, Claude Code or something run "YOLO mode", where effectively that's the contract of the box, which is it's actually safe to run on a YOLO mode. And it doesn't sit there and nag you every two minutes of like, "Hey, Mark, is it okay to do this? Hey, Gregor, can I do this? Hey, can I do this? Hey, can I do this?" Jesus, shut up. Just do it. 

And so the productivity gain you get is, "Great. Now I can actually run in YOLO mode," but it can never ever go do bad things. It can't read my keys. It can't RMRF my file system. It can't do bad things to my environment that I don't want it to go do. I can very carefully keep things out of it. 

Big threat number one is keep the agent from being runaway and doing bad things to access to the host. That's on host. Two is, similarly, the other big case you get is network. The threat model there crosses secrets and files together I think solve that problem on the host. The threat model on network is, "Well, okay, it's not that hard to go make the agent again." Even if I've constrained it down to the project that I want and I can't access all my things, it almost certainly can still ask something that I care about. Because otherwise what's it doing? 

And so in that case, now you have the other problem of we have exfiltration of, "Okay, I can now get the agent to send something that it legitimately has access to that I must give it access to. I can get it to send something to somewhere else." And this is where the network firewalls and the HTTP proxy firewalls come in and basically allow you to go prevent the agent deterministically from doing something that it can't do. 

The two big threat models by far are keep it from doing bad things on the host, keep it from exfiltrating data. That's the biggest ones from the individual's perspective. We'll talk about what it doesn't do in a second. Now hand-in-hand with that is, okay, you're a company, and you actually have many people. And unfortunately, many people, the bigger the company gets, the less you can trust everybody. 

And so along with this, we have sort of the commercial - the SBX. I'm going to say this too. The SBX product is free for everybody to go download. You can just go use it. It's no strings attached. Go forth and make your life better. Commercially, we have this AI governance package that we sell behind the scenes, which is we go to a company and say, "Okay, I can give you very rich expressive policies and controls on MCPs, on agents, and on what people can do." 

And so if you're a platform, or an IT, or security team, or something, while you're actually trying to manage the threat of your company of who can even use what agents, what tools can they have access to, what are they allowed to let them call, you need to go enforce that for the company. It's kind of the same threat models at scale or the same threat models just applied at scale. 

The additional one that comes with it, and we are working on making this available for everybody, just today it's enterprise only, is actually richer controls around MCP and data exfiltration. I've heard this I don't know how many times now from enterprises of no financial data or people data about my company can ever go to the model provider. I don't ever want that to happen. 

And so we actually can do that from an MCP perspective and a tool calling perspective, but we can have a sidebar at some point on MCP versus CLIs and all that. But we actually can allow organizations to take control of that and actually prevent things like that. And we're working on a whole lot more things there. And clearly, there's no threat model on earth that works like trust but verify. You still need observability and audit and all the rest. And so they can actually get back out of this now. They can set controls. They can enforce these things. And then they get back centralized observability and audit around it. That's what it does and it's in scope at least today. We are working on more stuff, but that's what I would say is on the tin today. 
And I've actually was on somebody else's podcast, and they were literally sitting with Scott Hanson, sitting there trying to live hack and break out of the SBX session. Every five minutes, it was like, "Oh, they tried this, it didn't break out." The VM actually we feel quite confident is very well hardened and very well contained. And then that thread as I've described it is there. Clearly, you have to configure for yourself for your own environment. But it gives you a very deterministic hardened contract around those things I described. I'll pause. 

[0:31:42] GV: Yeah. Unfortunately, on this podcast, we're not live hacking live coding. But I am interested to get on to after this I believe the way that Docker has been dogfooding this product specifically is super interesting. We'll get on to that in a second. But yeah, let's round this out as well. Out of scope, what things are you saying? This is just not something that we are considering as protected against at the moment. 

[0:32:05] MC: I'll be very precise in terms of at the moment because there's stuff we're working on. At the end of the day, I think the hardest problem is when you think about agents, you can't talk about this without talking about the data and the semantics around the data where data could mean cloud services too. 

Very concrete example is I have my own agents set up to read Slack all the time. And they tell me all kinds of useful stuff. It's incredibly helpful. I have a love-hate relationship with Slack. My nightmare scenario is that it ever writes to Slack and starts sending different things to private channels or the wrong - I mean, I'm in all these workspaces with all these other companies. Could you imagine telling one about the other? I have very, very, very hard boundaries that I like basically double check once a week to make sure are still in place around what I can and can't do. 

But what I really want is I want an agent that I can control and say, "Okay, I want you to use Slack." I want to be able to write controls that say you agent can write to this Slack channel to those people with this types of data. That's the actual thing I think that we need to get to as an industry. I don't think anybody has solved this yet. That to me is where we're not all the way there to that point yet. 

Actually, to be clear, this is a software engineering podcast, not a marketing podcast. In terms of what it does at the moment, we don't do that. And so, you still need to apply good judgment in terms of how risky you're willing to be with your agent and what you want to let them have access to. 

I was reading a pretty funny Reddit post I read not too long ago from somebody, really, I like OpenClaw forums and NanoClaw forums and stuff. And there's somebody in OpenClaw on Reddit that was like, "Ah, this thing has been amazing for me. It's been buying my groceries for four months until last week. And then it bought 50 pounds of garlic." Whatever it had done had gone off and hallucinated like a multiple of times 10 or 100 or something. 

And that's a very innocuous example, but you then imagine applying that to like, I don't know, your Bitcoin wallet, or your bank account, or your company's CRM data. Actually, things get bad very, very quickly. This problem of making sure that you are still not doing incorrect or silly things. Letting your agent have access to things that you under common sense wouldn't let it have access to. I think that's still the - I don't want to overpromise people, and I don't want people to take dependencies on us thinking, "Ah, you'll keep my bank account safe for my agent ever doing anything." Well, we can help we can give you a very bounded way. But at the end of the day, you still need to make good choices for the totality of the threat model around your data and your stuff. We are working these things. I think we have a very ambitious roadmap for the next couple of years, I think, for minimum. But it's not there now. I don't think anybody's there now. 

[0:34:32] GV: No. And I mean shared responsibility model is pretty common here And I always like that term. It's just a fancy way of basically saying don't do really stupid stuff, user. We can't be responsible for the really stupid stuff. 

[0:34:45] MC: Yeah, we can't solve everything. Yeah, exactly. I think that's exactly the right term. No matter what we do, there will always be a shared responsibility model. We can do more, but I think that will universally be true. 

[0:34:54] GV: Yeah, absolutely. One thing you touched on a bit earlier and does sort of come into this, I'm just curious to get a little bit more detail on, is the secrets and credentials piece. Again, how does that work? I think you've mentioned proxies being part of the sort of solution here. But how does sort of knowing that credentials aren't somehow being stored somewhere, or repurposed, or anything like that? 

[0:35:16] MC: If we had whiteboards and pictures and stuff, it' be a lot easier. But you'd imagine, think of the things as what goes in the box and what stays out of the box. At the end of the day, what stays out of the box are the secrets and what goes in the box is a placeholder that looks and acts to the thing inside like it's a secret, but it's not a real one. 

The threat model there, it's a little bit blurry and it's nuanced. Well, the threat model there is, well, it's impossible to leak your secret. At least per this contract, the secret is never presented in the box. Nothing in the box can ever get it. However, that placeholder secret still has by definition access to things. What we literally do is we run a proxy on the outside that intercepts traffic and we'll swap out your - for example, if you put a secret in as like your Anthropic API key. What does it literally do? It looks like a bearer token in the authorization header. 

And every time the Claude agent makes a call to anthropic.com, it sets authorization header: and then stacks in that key that's like sk blah-blah-blah-blah-blah. So we put a fake one in and the call will go out, and then we will intercept it. And we'll say, "Ah, you put that key in the box. I'm going to take that key out. I'm going to put the real key in, and I'm going to send it off to Anthropic. And when the call comes back, I will conversely strip and sanitize the things on the backside and now give it back inside the box." The box is none the wiser. It's a good thing. We're literally a man in the middle in a healthy way. 

Now the threat, so the good thing is your secret can never be leaked. You can never take that secret and send it out. You can't take your AWS keys. You can't take your bank account keys. The agent could never take them and go post them to pacebin or something like that. That can't happen. However, the agent does have access to the same service behind the scenes. Because by definition, we're still letting the call through. We're just keeping the secret out. The agent could still go. 

For example, well, if it has case your bank account, it doesn't have your bank account keys but it could still transfer money for you. By definition, we're not able to stop that, at least not today. So that's kind of the nuance on the threat model there. The agent will still have access to the things it has access to. And then mostly, you bound - when you revoke a credential, you will then be able to immediately contain the damage but the damage will still have been done. 

[0:37:20] GV: Yeah. One thing I haven't I guess asked or touched on is I guess all of SBX, is that all open source as well? 

[0:37:28] MC: It is a lot of open source. It is not 100% open source. The core VM today, we've chosen not to for a couple reasons. One, there's competitive and commercial things. But putting that aside, actually we're not right now trying to go get a community of people to go contribute to it. It's very hardcore systems technology. And honestly, I'm curious if you have had others on the podcast with this like we might be hypothetically speaking drowning in AI pull requests from everywhere else across the industry on the - 

[0:37:54] GV: Yeah. Yeah. We are hearing a lot of that. Yeah. 

[0:37:57] MC: Yeah. And so we're trying to go fast. We're trying to solve a lot of problems. I'm not terribly interested right now in dealing with it all. We're already dealing with it in a bunch of the places where - I mean, Docker clearly is - to be clear, when I say this. Docker is a very open source friendly company, where our entire ethos as company. Our intent is to be open source. We are trying to make pragmatic choices as we go around it. But the answer to your question is today it is not 100% open source. It is a lot of open source, but there are parts of it that are not and various reasons why. It is all free, however. 

[0:38:25] GV: Yeah. No, that's amazing. Let's talk about this dogfooding thing. I think it was a blog post by one of your colleagues that sort of went through this a little bit, and it's called the fleet, which sort of explains. But maybe you could sort of semi-summarize what is this? How I guess is Docker dogfooding that term of like trying your own product basically? And in this case, I think stress testing it. How has that actually worked? 

[0:38:49] MC: Well, one, I philosophically deeply believe every company should dogfood their things. If they don't dogfood their things, what are you doing? The funny thing, the nuance for us is not a 100% of the company can dogfood. Because we have a lot of people that work on this core thing itself, and putting nested virtualization in gets actually very hard. We have a funny dichotomy of who can dogfood and who cannot on a daily basis. Because maybe the definition of dogfooding to me is I want most of the company living their lives in our products and they do exactly what our customers do. We have some constraints where it's literally not possible because they're building it. 

But the things that have been incredibly helpful for us because we find a lot of the friction and the same things. We have a lot of things we need to work on that make it better and more usable and all the rest. But typically speaking, we'll find a lot of things for our customers do.

But the better question besides me to ask this question to is actually our CISO, who I think is like elated that we've moved our organization as much as possible to where all things run inside the sandbox for exactly the same reasons that our customers are calling us for. Today we dog food SBX. Most people that are running a coding agent need to do so inside of SBX. Again, there are exceptions. 

As I mentioned, we have an MCP gateway as well that goes hand-in-hand with this. We stand up an internal one for ourselves in enterprise. We run all the things we as a company use as an MCP through that. And then I've mentioned this a little bit, we have a teaser of a cloud and some higher-level products coming. We've got a whole lot of our company actually building our agent orchestration around that. 

If you think about the way the STLC works is okay, the humans sitting there interacting with their Claude Code terminal does their work day in, day out. We're probably like everybody else where most of the engineers like Claude Code the best. Some people love OpenCode, some people love Codex. We let people do what they want on their things of choice. 

But then you have a lot of things that can run in the background and can actually be scaled out. We do have a lot of autonomous agents that run either by because they're tagged in a pull request or they literally run and watch. They're just set up with GitHub triggers or git triggers and watch the repo, look for security scans, look for test coverage patterns, all the common stuff you'd expect. And then they'll go either generate new issues and give things to people, or they'll actually generate all the way to the code and reissue a new pull request. 

Today we're not all the way to the point where we're letting a lot of things through without a human review because mostly we have a security product where the contract is determinism. So we kind of philosophically don't do that. We go back and forth on this all the time on a weekly basis. But that contract looks like then what most of the engineering organization and product organization works with. And then you also have everybody that has automated their life where they have daily reports and this that and the other thing. 

Now on the one we're working on actually kind of aggressively is actually getting our go-to-market and our GNA teams working with the same stack and dogfooding. The product as is is very much - I mean Docker is a developer company. We're built for developers. The product is for developers to go do stuff. But it turns out a whole lot of people are learning to code or learning to - it's this funny thing now. Well, everybody's a developer now. Your definition of developer here. And so what we're actually working through right now is okay, how do we effectively dogfood our own products and our non-engineering and product organizations? That's kind of the last untapped frontier for us in terms of how that's going. 

[0:41:56] GV: Yeah. That's a very holistic approach to dogfooding from what you've just described. That's great to hear. As we sort of start to vaguely sort of cruise to the end of the episode, I'm curious about the future of this. And you have touched on it a little bit the sort of the hosted piece to this, because that was going to be one of my first questions. Is this only going to be local? Or what does it maybe look like in the future? You have touched on a hosted idea without maybe revealing anything you can't today. But what would be the reasons I guess for offering a fully hosted version of this. 

[0:42:26] MC: I'm not terribly secretive with our road map. Because I think, honestly, I always kind of joke, "Well, if you can't look at a company and write down the road map in about 20 minutes of thinking, they probably have the wrong road map." For us, doing a hosted version and a cloud version is I think incredibly important. Because, again, there's many reasons why I need a cloud. So many times I want to work on my laptop. I need access to Excel files. I need access to local things. I want access to local resources. 

And there's many times, well, I want to close my laptop and I want to go to sleep, or I want to be on an airplane and I want stuff to keep going, in which case I need to be able to go back and forth. Our term for this is remocal. Our cut on this is, well, this SBX contract that you have will be able to move portably back and forth from the laptop to the cloud. That's kind of the big thing we're working on, along with again traditional sort of scale out cloud resources for the cases that you'd expect. 

Getting that working I think unlocks just a whole lot of things for people, whether it's background agents, or agent swarms, or whatever it is. That's like a big one. Really working on the sort of what now. Now you're back to wire on the laptop. I think many things actually need access to the laptop that are like, say, the microphone, or the camera, or again Excel files, or whatever else it is. And so really working on how to safely constrain access to host resources above and beyond what we've done. 

We already have a bunch of special things in for GPUs and things like that, but sort of general-purpose access to how agents can kind of do what's called computer use is I think one of the bigger things we're working on. I think I've long been the like top evangelist for open models. And so I think one of the big investments for us will be just making sure this keeps working with allow you to plug in and swap in open models. I think the year of open models is upon us already and it's coming faster. 

[0:44:07] GV: Definitely. Yeah. 

[0:44:08] MC: I think that's incredibly important. And then again, a huge focus for us really is on this team and commercial governance product. And so just doing a whole lot more there around the richness of policy that can be expressed. How exactly agent identity works in ways and step-down ways? It's a very rich and complex domain. And so most of the customer asks and the usage asks that we see in practice beyond, "Hey, I'm trying to work in "Hello, world." Why didn't this agent work?" Really very quickly turn into that, which is, "Okay. Well, I'm trying to roll this out to 1,000, 10,000 people. And I have this very complicated thing. And it needs to talk to that SSO system and that access control system, but I need the agents to do this then now." That's I think what we're - I think we're going to be busy for a while working on that. 

But I think the nice thing is as we build this for the comp as an ethos, making the hard things possible and solving the complex problems in a way that is easy and digestible allows us to I think have a platform that will work for everybody. Because for us, the part of the goal is, "Great. We have Docker." We have probably a billion people running Docker somewhere somehow across - I don't even know. I can't count it all. I think we have a responsibility to make sure that the ecosystem and community of Docker users is able to come forward into the world of AI and making sure that everything we do provides them the same sort of safety uplift and the same sort of convenience uplift is actually important to us is just an ethos. 

We have a ton of work to go do to solve problems for the companies that are having real pain points on. I mean, everybody's scrambling, right? It's like, "Well, I was told I need to roll out Claude either because the people in my company are screaming at me that they need it or because the board is screaming at me. Everybody's screaming at me. I need to roll it out. And it's hard. How do I roll this out with safety? How do I not risk the business and so on?" Our whole lot of a roadmap focuses on enabling that with more and more and more expressive controls. And then making sure it's accessible to everybody. That's the digest radio safe version of the roadmap. 

[0:46:03] GV: Yeah, that's awesome. Something I was just thinking there was is there a world - obviously, I don't expect this to be on the roadmap even in maybe the next year. But is there a world where you could see, for example, Docker sandboxes running on mobile devices as opposed to a laptop? Developers love showing off that they've been doing something on their phone which is currently SSH'd into some other box somewhere. But what do you see on this front? 

[0:46:25] MC: Is it in the next quarter? No. We've talked about - I mean, it comes up. We're Docker. It's a ubiquitous runtime that runs everywhere. We get asked for everything. We get asked to put on thermostats. We get asked to put on cell phones. I don't think it's out of the question. In particular, I think the mobile case. Obviously, the sandboxing primitives, the operating system primitives, everything about that is totally different. 

But having some type of an experience, again where I can give you - it's actually less about the sandbox and more about the safety. I think it is in bounds for us to say, "Well, I'm giving you this portable run anywhere contract that you can run with safety and speed and productivity. Having an answer for that on the mobile phone I think is actually probably inevitable for us. I think it'll probably require us doing a different shape. And it won't look like, "Oh, I brought SBX to the phone as is." I think it'll require us being, "Okay, understand the constraints of the environment, understand the problem they're trying to solve, stick to the ethos, make it as coherent as we possibly can across this." But I would not rule that out. That's for sure. 

[0:47:23] GV: Yeah, that makes sense. Not ruled out, but equally, I love that phrase. I think it was - well, I don't know who said it originally. But I remember hearing Toby Lütke say it's like when you say yes to something you're effectively saying no to everything else. What you say yes to, you got to be very clear on that one. That is a road map effectively. Yeah. Yeah. 

[0:47:38] MC: Yeah, there's a great Steve Jobs quote is focus is not saying yes. Focus is saying no. And so it's not a no forever but it is a no for right now. 

[0:47:46] GV: Yeah. Well, just to recap. Yeah, where's the sort of best place for a developer to go get up and running with the SBX? 

[0:47:54] MC: I mean, easy one as well. You go to docker.com, and there's docker.com/sandboxes. But if you're on Mac, you can do brew install SBX and WindGet on Windows. And so your Linux distribution of choice for your installers. But I would start there. And then it is usually pretty quick to get to "Hello, world," and get to your first agent being up and running. And then it's a world of threat models and virtual machines and agent controls from there. 

[0:48:16] GV: Amazing. Well, Mark, thank you so much. Really appreciate you making the time. And yeah, I think this will definitely one where we're following along pretty closely and no doubt catch up in a year or two. 

[0:48:26] MC: That'd be great. Thanks for having me. 

[0:48:28] GV: Thank you. 

[END]