Loading summary
Transcript64 lines
- [00:00]
Narrator
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 micro VM while preserving the familiar ergonomics of a container. A standard container shares the host's kernel, but a micro VM emulates hardware and runs its own kernel, giving a stronger security boundary around code that cannot be trusted. Mark Kavage is the President and COO of Docker and he previously worked at companies including Stripe, AWS and Oracle. In this episode, Mark joins Gregor Van for a wide ranging conversation that includes why agents break the immutability assumptions containers were built on, how micro VMs 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 cybersecurity, cyber insurance and general software engineering companies. He is based in Singapore and can be found via his profile@vand, HK or on LinkedIn.
- [01:35]
Gregor Van
Hello and welcome to Software Engineering Daily. My guest today is Mark Cabbage. Thank you for coming on today, Mark.
- [01:42]
Mark Kavage
Yeah, thanks for having me. It's great to be here.
- [01:44]
Gregor Van
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 brief story of how you got all the way to Docker?
- [02:08]
Mark Kavage
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 1 of Amazon Web Services back in 2005.
- [02:17]
Gregor Van
Oh, wow.
- [02:17]
Mark Kavage
And we're all office mates back when AWS was, I don't know, somewhere around 100 to 200 people somewhere in there. I don't time. It 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 was joking, fortunately for Docker, they found us. And so Tuchard 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.
- [02:51]
Gregor Van
Yeah, let's start with 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.
- [02:57]
Mark Kavage
Yeah. Docker is a ubiquitous brand. I think many of us grew up on it over the last decade. Docker equals. Equals 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's many things rolled in one word, but at its root it's containers. And basically it's as I always tell people, if you go back to the very first genesis when Solomon Hikes, 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 like it leverages, 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 like 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. We 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 going 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 a thing 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.
- [04:51]
Gregor Van
No, no, there's never such a thing as too long an answer. 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?
- [05:18]
Mark Kavage
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 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 now I 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. So 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.
- [06:07]
Gregor Van
So yeah, so we're going to get. I mean, today's topic is 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, like, what is the general Docker products 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 our bits to Docker now. So like just before we get into the latest product.
- [06:37]
Mark Kavage
Absolutely. 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 are when they think of Docker today, I think they think, 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, et cetera. The biggest thing I think we've done in the last year, besides the things around that is really what's in the call it the hardened image space again. We have in Docker Hub again this 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, et cetera. 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. So 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 root. We do all the things you'd expect simulator 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 the biggest, I'd 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, you know, I can make it clean, not dirty effectively. So. And then there's AI, which we'll talk about for, I'm sure. Oh, quite a bit.
- [08:21]
Gregor Van
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.
- [08:34]
Mark Kavage
So, yeah, at this point, I think the funny thing everybody goes through the industry has, goes through these trends and like four or five years ago, I swear, if you asked anybody, they'd say, oh, the laptop's Dead. We're all going to use cloud environments, et cetera, et cetera, et cetera. Nobody cared. You couldn't get the time of 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. You could spend two hours talking about all the ins and outs of it, but it's a real problem. And when you 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.
- [09:21]
Gregor Van
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 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. So I think to kind of set the scene though, we're talking about the concept of an agent sandbox in general, this isn't as a concept is not unique to Docker, but so could you maybe just set the scene like what is an Agent sandbox at all, basically?
- [09:56]
Mark Kavage
Great question that we get this all the time. In particular because Docker, being such a ubiquitous word, Docker, 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. So 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 what it does and control all the dependencies it has and control the environment has. So fundamentally it's a virtual machine or a container or something. Now our flavor of it is actually based on micro vm. So it is actually the funny thing we've done is tried to. It's not a 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 micro VM base which 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, sbxrun, Gemini, whatever you want, openclaw, you get a dedicated micro VM per thing that looks, feels, acts, kind of works the same way as a container starts up in a second or less like it's 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 by not necessarily by force, but by convention of immutability. So 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, the people run something like Kubernetes and 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 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 cloud code or openclaw or 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 Asian things that they do. They 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 it 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. So for us, this Docker sandbox or this SBX command Really is a Micro VM with this core very breaking primitive like 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 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, that's 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 four 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. So sandboxing from us and the Docker, A sandboxing, I think is an overloaded word. The computer science definition is it's a place to run untrusted code in the agent's world that practically speaking means sort of VM boundary. For us, this Micro VM 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 repeatedly. 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.
- [14:14]
Gregor Van
So one area I'd like to just pick on there is, is actually the Micro VM versus vm. So obviously we're talking about virtual machine. Just for anyone not familiar with the acronym, Micro vms in my world have just exploded in the sense people know I work at sipabase and sipabase, we interact with companies who want to have these agents doing things and running things. And Micro VM has just become this exploded term. How do you describe a micro VM in comparison to a vm. Because I think a lot of people previously said, well, if I want to run something sort of quote safely, I create a virtual machine and then I do it on that. But what is the distinction? I mean, in the word there is micro perhaps.
- [14:53]
Mark Kavage
At the end of the day, this is where it's like we used to call things unikernels. There's always these words that are for SE daily. It's 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 super optimize 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 is we have many layered. It's a fairly complex architecture, as you might imagine. To do all the things we do on the host, like 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 nine gigs of memory plus two CPUs. Like you just don't do any of that. And it's meant to be. 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 very 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.
- [16:10]
Gregor Van
Yeah, diet vm.
- [16:11]
Mark Kavage
Yeah, diet vm.
- [16:13]
Gregor Van
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 micro VM as it sounds sort of super optimized.
- [16:24]
Mark Kavage
At the end of the day, a virtual machine emulates CPU memory, network IO, which is contrast to 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.
- [16:45]
Gregor Van
Yeah.
- [16:47]
Sponsor/Advertisement Voice
This episode of Software Engineering Daily is brought to you by warp build. AI is writing more code than ever, which means GitHub Actions is running more than ever. Your GitHub Actions bill is now a function of how much AI code you generate, and every engineer knows the feeling. You push a commit and then you wait. Warp build makes GitHub Actions twice as fast at half the cost with a one line change to your workflow. Linux, macOS and Windows runners in Warp Build's cloud or your own Enterprise Ready SoC2 Type 2, attested and trusted by teams like sky, from comcast, bitcoin and braintrust. AI get started with $50 in free credits@warpbuild.com Sed you're shipping faster than ever with AI coding agents, but those agents don't vet the packages they pull in and they don't have security context. Built in ORI by Endor Labs fixes that it plugs directly into your editor via mcp, catching vulnerabilities, blocking malicious packages and flagging exposed secrets in real time. No separate tool to switch to, no dashboard to babysit security that fits how you actually build teams using Ori. See 10 times fewer security tickets and 6 times faster fixes. Free for developers. Get started at www.endorlabs.com Auri Think about
- [17:59]
Narrator
your mobile app source code. Once it hits the App store, it's out in the wild and without the right protection. Decompiling is easy for malicious actors looking to steal your IP or tamper with your software. That's where Guardsquare comes in. Guardsquare provides the highest level of mobile app security for Android and iOS applications and SDKs. Their advanced tools integrate seamlessly into your CI CD pipeline. We're talking polymorphic multilayered code hardening techniques and automated runtime application self protection paired with mobile application security testing and real time threat monitoring to deliver the highest level of mobile app security without compromise. Don't leave your hard work exposed. Secure your mobile applications today. Go to guardsquare.com to learn more.
- [18:50]
Gregor Van
That's quite a nice sort of segue into what makes I think Docker Sandbox is different, which is the idea that you do actually get like rather your agent does actually get its own Docker daemon network and file system inside that sandbox. Could you maybe speak a bit to kind of that architecture?
- [19:08]
Mark Kavage
Yeah, the way it works is you get this micro VM and in that it is a full Blown Linux os. You can root around anything. Like we have a bunch of them built on our Docker hardened images images. You can build them on Ubuntu, you can build them on red hats, build them wherever you want. And by the way, for our agents there is an SPX run shell so you too as a human can just get shell and do whatever you want. Now in that you get a network proxy and an HTTP proxy where we are able and IO proxies where we enforce everything that comes in and out of the machine. So 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 tests it, inspects it, whatever, that's what you want. More commonly you're working in something like a GitHub repo or project or git project, excuse me, and you want to start either a work tree clone or you want to start literally with that project mounted into the file system so 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 you have, on the outside of this, you have an L4 terminating proxy that inspects everything and you get to, 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 wind 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. So 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 injected into the machine is actually a proxy parameter that is not the real credential. So 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. So we'll get into all the threat models and all the rest of what it can and can't do, et cetera. 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 is never shown to this effectively hostile, adversarial, kind of collaborative, cooperative agent. With that, you then get this environment with all those controls around it. And then there's. We've called them kits, which are a way for you to go package up your own flavors of cloud code or PI, or pick whatever you want, you want, and you can run and create and share agents with other people that do what you want. Like, 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, you know, all my skills and my MCPS and everything else, like 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.
- [22:05]
Gregor Van
So, yeah, and yeah, as you say, threat model is something that's super interesting and we will definitely sort of get onto that.
- [22:12]
Mark Kavage
I had a feeling, you might ask.
- [22:13]
Gregor Van
Yeah, definitely get onto 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? You know, 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. So, like, how does that kind of all work?
- [22:34]
Mark Kavage
Yeah, so the thing when we're talking about the architecture, I omitted this. The SPX 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 cloud code. I would like it to be safe and not be dangerous. I'll be optimized for that. That's what it's for. We have this in 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 Dockers, we're doing everything to put the Docker ethos, allow that SBX agent to run or daemon, sorry, to run anywhere. Kubernetes Clusters, your environments, et cetera. So with that as 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 when you 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 Open Claw 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, like what skills, what agent, etc. And then it will create a new virtual machine for you, or you can obviously attach to ones that are running, but it will create a new one for you, boot up into that micro VM and then start that software image as the actual agent and then present to you back as a human. Here's your cloud 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 open code 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, sub 100 milliseconds to get up in practical terms in the human experience time. Like 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. So 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 like very bursty scale out ephemeral transient workloads that need to go happen. So that same runtime is optimized for both of these. The actual SPX 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 codecs 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 Goku 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 air quotes, just work. So it's around a second to go get the human facing one up, which is practically speaking for most people. Okay, so what? So every time I start Claude, it takes it several seconds to go back and forth with the Claude API, which may be erroring and overloaded at the moment, and whatever it does. So for the human, our goal is to get you the machine and get you into the agent, which then operates at the speed of inference and human time, which is very different than something like programmatic scale out time.
- [25:59]
Gregor Van
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?
- [26:14]
Mark Kavage
Yeah, I'm just teasing this. We have a cloud coming soon. The core thesis from us is again, like most people using Docker today, when they think of it, they think of I have Docker desktop or 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 solved the same problem because we got asked over and over and over again, hey, how do I run cloud 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. So 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 it is, yeah, it was very much built around. There's something like the chatbot that you would build for a customer support side or so your quintessential examples you have is 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.
- [27:26]
Gregor Van
So. Yeah, that makes sense. And this is again a sidebar and I disclaimer. I have almost no knowledge of this area, but I'm just curious, the whole Open Claw thing, was that also. Does that apply here at all?
- [27:38]
Mark Kavage
I often joke all the time. I keep seeing everybody. Like when, you know, there's like this Mac mini shortage for buying open clause. Yes, you can put them in a little virtual machine thing. You just put them in that. And so for us, we made it an agnostic machine. What's the ethos of Docker? It's build runs, run anywhere. We're Switzerland. I mean, it's a very. Without getting into geopolitics because, you know, especially as an American, I feel like I can't say anything anymore. But anyway, we're Switzerland and we work with anything. So it's open. Any model, any hardness, any agent, any operating system, any cloud. Like 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 and then we changed that and then the Open Claw multiple thing all happened. And so now I think you have this explosion of a bunch of popular agents and, you know, Open Code is one amongst many. So sorry, Open Claw.
- [28:29]
Gregor Van
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. So 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 like out of scope as well. Because that's every threat model you have to decide what's in and out. So what is in effectively?
- [28:49]
Mark Kavage
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 open code or open claw 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, you know, there's this hack last year of people doing Google Calendar invites that had, you know, 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 per 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 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 in air quotes 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, is it okay to do this? Hey, Gregor, can I do this? Hey, can I do this? Hey, can I do this? Like, Jesus, shut up, just do it. And so the productivity gain you get is great. Now I can actually run a YOLO mode, but it can never, ever, 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. So big threat number one is keep the agent from being runaway and doing bad things to access to the host that's on host 2 is similarly the other big case you get is network the threat model there across the 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 have 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 secret the HTTP proxy firewalls come in and basically allow you to go prevent the agent deterministically from doing something that it can't do. So 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, you know, sort of the commercial, the SPX omitted to say this too. The SPX 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 are a platform or an IT or a security team or something, where 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. So it's kind of the same threat models at scale, or the same threat models just applied at scale. The one 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 then they get 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 at Scott Hanselman who was sitting there trying to live hack and break out of the SBX session. Like every five minutes was like, oh, 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 it for yourself for your own environment, but it gives you a very deterministic, hardened contract around those things I described.
- [33:47]
Gregor Van
Yeah, unfortunately on this podcast we're not live hacking live coding, but I am interested to get onto after this. I believe the way that Docker has been dogfooding this product specifically is super interesting. So we'll get onto that in a second. But yeah, let's round this out as well. So out of scope, what things are you saying? This is just not something that we are considering as protected against at the moment.
- [34:09]
Mark Kavage
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, you know, cloud services too. Like very concrete example is I have my own agents set up to read Slack all the time. Then 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 like the wrong. I mean I'm in all these workspaces, all these other companies, like could you imagine telling one about the other? So I'm like, 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 it 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. Or 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 it have access to. Like I was reading a pretty funny Reddit post I read not too long ago from somebody like really? I like the openclaw forums and Nano Claw 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, it had gone off and hallucinated like a multiple of times 10 or times 100 or something and things like. 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 or actually things get bad very, very quickly. So 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 over promise people and I don't want people to take dependencies on us thinking, ah, you'll keep my bank account safe for my age, never doing anything like, 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. So we are working on 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.
- [36:37]
Sponsor/Advertisement Voice
No.
- [36:37]
Gregor Van
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, really stupid stuff.
- [36:49]
Mark Kavage
Yeah, we can't solve everything. So. 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?
- [36:59]
Gregor Van
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. I think you've mentioned proxies being part of the solution here, but how does knowing that credentials aren't somehow being stored somewhere or repurposed or anything like that, it's hard without.
- [37:21]
Mark Kavage
If we had whiteboards and pictures and stuff, it'd 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. So the threat model there, it's a little bit blurry and it's nuanced. The threat model there is. Well, it's impossible to leak your secret. So 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 colon and then stacks in that key. That's like SK dash blah 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 I'll give it back inside the box. The box is none the wiser. It's a good thing we're literally man in the middle in a healthy way. Now, the threat. So the good thing is your secret can never be leaked. Nobody. 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, you can't. The agent could never take them and go post them to Pastebin 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. So the agent could still go, for example. Well, if it has access to your bank account, it doesn't have your bank account keys, but it could still transfer money for you. By definition, we are not able to stop that, at least not today. So that's kind of the nuance on the threat model there. So, you know, 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.
- [39:25]
Gregor Van
Yeah, one thing I haven't, I guess Astor touched on is I guess all of sbx. Is that all open source as well? Is that something like it is a
- [39:33]
Mark Kavage
lot of open source. It is not 100% open source. So the CoreVM today we've chosen not to for a couple of 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 we actually I'm curious if you have had others on the podcast with this. Like we may be, hypothetically speaking, drowning in AI, pull requests from everywhere else across the industry on the ldl.
- [40:00]
Gregor Van
Yeah, yeah, we are hearing a lot of that. Yeah, yeah.
- [40:02]
Mark Kavage
And so we're trying to go fast. We're trying to solve a lot of problems. I'm not terribly interested right now. And 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, I want to say this. Docker is a very open source friendly company. We're 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.
- [40:29]
Gregor Van
Yeah, no, that's amazing. Let's talk about this dog footing 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 dog footing that term of trying your own product basically, and in this case I think stress testing it, how has that actually worked?
- [40:53]
Mark Kavage
Well one, I philosophically, deeply believe every company should dog food their things. If they don't dog food their things, what are you doing? So the funny thing, the nuance for US is not 100% of the company can dog food because we have a lot of people that work on this core thing itself and putting nested virtualization and gets actually very hard. So we have a funny dichotomy of who can dog food and who cannot on a daily basis. Because by the maybe the definition of dog fooding to me is I want most of the company living their lives in our products and like 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 will find a lot of things before 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 have 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. So 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. So if you think about the way the SDLC works is okay, the human 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 cloud code the best. Some people love open code, some people love codecs. 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 so it can actually be scaled out. So 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 like 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 like reissue a new pull request.
- [43:00]
Narrator
Today.
- [43:01]
Mark Kavage
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 do a back and forth on this all the time, like 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, 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 like 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 dog food 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.
- [44:00]
Gregor Van
Yeah, so that's a very holistic approach to dogfooding from what you've just described. So that's great to hear. As we start to vaguely cruise to the end of the episode, I'm curious about the future of this and you have touched on it a little bit like 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?
- [44:30]
Mark Kavage
I'm not terribly secretive with our roadmap because I think it's honestly I always joke like well if you can't look at a company, write down the roadmap in about 20 minutes of thinking they probably have the wrong roadmap. So for us doing A hosted version and a cloud version is I think incredibly important because again, like 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. We have our term for this is for remote. So our cut on this is well this SPX 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 the again traditional sort of scale out cloud resources for you know, the cases that you'd expect. So 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. We're really working on that sort of one now. Now you're back to like why on the laptop? I think many things actually need access to the laptop that are like oh 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. Like 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 do what's called computer use is I think one of the bigger things we're working on. We are I think have long been the 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 definitely. 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 and like delegated ways and step down ways. Like it's a very rich and complex domain and so most of the customer asks and the usage asks. 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, like, 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 computer 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 our, for us, part of the goal is great. We have Docker, we have probably a billion people running Docker somewhere somehow across, like, 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. It's 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. I mean, I need to roll it out. And it's hard. How do I roll this out with safety? How do I not like 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. So that's the Digest radio safe version of the Roadmap?
- [48:07]
Gregor Van
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 sshed into some other box somewhere. But what do you see on this front?
- [48:29]
Mark Kavage
Is it in the next quarter? No, we've talked about it, because it comes up. We're Docker. It's a ubiquitous runtime that runs everywhere. We get asked for everything. Like it has to be 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 like where, again, where I can give you the. It's actually less about the sandbox and more about the safety. So I think it is in bounds for us to say, well, I'm giving you this portable run runs, run anywhere contract that you can run to 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.
- [49:27]
Gregor Van
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 Lutke say, it's like when you say yes to something, you're effectively saying no to everything else. So what you say yes to, you've got to be very clear on that one. That is a roadmap, effectively.
- [49:43]
Mark Kavage
Yeah. There's a great Steve Jobs quote, is like, 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.
- [49:51]
Gregor Van
Yeah. Well, just to recap, where's this best place for a developer to go get up and running with spx, I mean,
- [49:59]
Mark Kavage
easy one as well. You should go to docker.com and there's docker.com sandboxes. But if you're on Mac, you can do Brew, install SBX and Winget 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.
- [50:21]
Gregor Van
Amazing. Well, Mark, thank you so much. Really appreciate you making the time. And yeah, I think this will definitely be one where we're following along pretty closely and no doubt catch up in a year or two.
- [50:31]
Mark Kavage
That'd be great. Thanks for having me.
- [50:33]
Gregor Van
Thank you.