Docker and Sandboxing AI Agents

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 https://www.docker.com/ recently announced Docker Sandboxes, which give 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 Cavage https://x.com/mcavage 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 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. Sponsorship inquiries: [email protected] mailto:[email protected] The post Docker and Sandboxing AI Agents https://softwareengineeringdaily.com/podcasts/docker-and-sandboxing-ai-agents/ appeared first on Software Engineering Daily https://softwareengineeringdaily.com.

• 0:00Speaker 00

  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 Cabbage is the president and COO of Docker, and he previously worked at companies including Stripe, AWS, and Oracle.

• 0:44Speaker 00

  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 Van 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 at van.hk or on LinkedIn.

• 1:35Speaker 01

  Hello and welcome to Software Engineering Daily. My guest today is Mark Cabbage. Thank you for coming on today, Mark.

• 1:41Speaker 02

  Yeah, thanks for having me. It's great to be here.

• 1:43Speaker 01

  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?

• 2:07Speaker 02

  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'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 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 had 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.

• 2:50Speaker 01

  Yeah, let's start with Docker is, and then actually you might just kind of pull back for a second after that. But yeah, what is Docker, full stop, for those that don't know?

• 2:57Speaker 02

  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 I, 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.

• 3:42Speaker 02

  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 the technology. There's Docker Hub as well, which is the ecosystem where people produce all kinds of packages. We Docker see 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,

• 4:27Speaker 02

  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.

• 4:50Speaker 01

  No, no, there is never such a thing as a too long an answer I see daily. So 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. And like, but a container really is that. Like, I think it's such a great metaphor or thing, which is like, you have this portable, literal container, like, think of container ships, that you can move it from ship to ship. And, and it's the same system. And like, that was always the kind of the thesis here, right?

• 5:18Speaker 02

  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, you know, there's 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 I failed in prod because there's some variances across whatever the kernel is and whatever the operating system is and whatever Glib C is there. And 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

• 6:00Speaker 02

  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. So.

• 6:08Speaker 01

  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 product suite? If you like nowadays, like 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.

• 6:36Speaker 02

  Absolutely. And what we, what we definitely spend the majority of time, I think, talking about AI. As you might imagine, this is 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 assistants 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, we'll call it the hardened image space. So, you know, again, we have in Docker Hub, again, this hosting package manager for the ecosystem.

• 7:14Speaker 02

  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 debit 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, we also, 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.

• 7:59Speaker 02

  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, you know, year or two, year and a half has been really Docker hardened images. Cause 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 all 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.

• 8:21Speaker 01

  Yeah, the hardened containers piece is 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 then only increasing is what we see. So, yeah.

• 8:34Speaker 02

  At this point, I think the funny thing, everybody goes through these, the industry 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, 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, you know, six months of attacks, they practically speaking, all started with got access to GitHub Actions or got access to laptop.

• 9:16Speaker 02

  And then basically, once there, got credentials and the world's your oyster. So.

• 9:21Speaker 01

  Yeah, it's kind of scary what we've seen over the last, especially a couple of years, just the, 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 trying to 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?

• 9:56Speaker 02

  Great question. We get this all the time in particular, because Docker, being such an 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.

• 10:38Speaker 02

  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 SBX run Gemini, whatever you want, open claw. 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.

• 11:19Speaker 02

  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, you know, that people run something like Kubernetes and they'll look at, 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 like redeploy the world. The problem is that's not how agents work at all. You run Claude code or open claw or whatever you want. The very first thing it wants to do is like, oh, thanks, Mark, thanks for that great question.

• 11:59Speaker 02

  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. 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.

• 12:40Speaker 02

  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

• 13:25Speaker 02

  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, 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 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

• 14:09Speaker 02

  and ease, but it runs in that bounded way that you can then observe and control. So.

• 14:15Speaker 01

  What I would like to just to sort of pick on there is, is, is actually the, the micro VM versus VM. So obviously we're talking about virtual machine, just for anyone not familiar with the acronym. Micro VMs and sort of my world have just been, you know, exploded in the sense like I work, people know I work at Superbase and Superbase, we interact with a lot of companies who want to have these agents doing things and running things. And micro VM has just become this exploded term. What exactly, 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 Distinction, I mean, in the word there is micro, perhaps.

• 14:52Speaker 02

  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, 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 it can be, 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 architectures, 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. Like 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.

• 15:36Speaker 02

  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, I run VM where 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, 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.

• 16:10Speaker 01

  Yeah, diet VM.

• 16:11Speaker 02

  Yeah, diet VM.

• 16:12Speaker 01

  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 that exactly that takes up all this memory. But then a micro VM, as it sounds, sort of super optimized.

• 16:24Speaker 02

  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.

• 16:44Speaker 01

  Yeah.

• 16:46Speaker 03

  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, SOC 2 Type 2-attest it and trusted by teams like Sky from Comcast, Bitcoin, and Brain Trust AI. Get started with $50 in free credits at warpbuild.com/sed. You're shipping faster than ever with AI coding agents. But those agents don't vet the packages they pull in,

• 17:29Speaker 03

  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 six times faster fixes. Free for developers. Get started at www-endorlabs.com/auri.

• 17:58Speaker 00

  Think about 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, multi-layered 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.

• 18:43Speaker 00

  Secure your mobile applications today. Go to guardsquare.com to learn more.

• 18:50Speaker 01

  That's quite a nice segue into what makes, I think Docker sandboxes different, which is the idea that you do actually get, like your, 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?

• 19:08Speaker 02

  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's, 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 a shell and do whatever you want. Now in that, you get a network proxy and an HTTP proxy where we are able, and I/O 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, et cetera. 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, inspect it, whatever. That's what you want. More

• 19:52Speaker 02

  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. The 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 will end up with something like an allow list or denial list and just block bad things versus common things and allow things that are for their company. And then there's the

• 20:36Speaker 02

  credential injection. So along with it is leverages an OS keychain and you put something like your Anthropic key or your GitHub key or your Docker hub token and so on, so forth in a vault. And then inject it 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.

• 21:17Speaker 02

  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 Claude code or pie 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 pie agent now. I've come to love this thing. And mine is this like crazy setup where I'm forked 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.

• 21:59Speaker 02

  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. So.

• 22:05Speaker 01

  Yeah. And yeah, as you say, threat model is something that's super interesting. And we will definitely sort of get onto that.

• 22:12Speaker 02

  I had a feeling you might ask.

• 22:13Speaker 01

  Yeah, you 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 that 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:33Speaker 02

  Yeah. So the thing I, 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 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 Damon, sorry, to run anywhere. Kubernetes clusters, your environments, et cetera.

• 23:14Speaker 02

  So 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 when you take your laptop case, this in mind, what doesn't matter if it's Mac or Windows, that 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 and what's in it, like what skills, what agent, et cetera. And then it will create a new virtual machine for you, or you can attach, you can obviously

• 23:59Speaker 02

  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 Claude Code interface and you can just now type to it the way you would. And you, you as the human, your workflow is unchanged from using Claude Code or Open Code or anything else on your laptops, 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 wifi 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

• 24:44Speaker 02

  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 workflows that need to go happen. So 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, 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

• 25:27Speaker 02

  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 and 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 airing and overloaded at the moment and whatever does. So 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. So.

• 25:59Speaker 01

  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:14Speaker 02

  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 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. 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

• 26:58Speaker 02

  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. So.

• 27:26Speaker 01

  Yeah, that makes sense. And this is like 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:38Speaker 02

  I often joke all the time, I keep seeing everybody like in the world, there's like this Mac mini shortage for buying open claws.

• 27:43Speaker 01

  Yes.

• 27:43Speaker 02

  You can put them in a little virtual machine thing, you can 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, not, 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 harness, 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 is like, oh, everybody's on cursor, and then Claude Code came out, and then we changed that. And then the Open Claw Multibook 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:28Speaker 01

  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:49Speaker 02

  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 then 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, well, 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, et cetera. 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.

• 29:33Speaker 02

  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 out 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 an Eric wants 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?" 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.

• 30:17Speaker 02

  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. Two is similarly, the other big case you get is network. The threat model there across his 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 agents 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.

• 30:54Speaker 02

  Cause 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. It 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.

• 31:39Speaker 02

  And so along with this, we have, you know, sort of the commercial, the SPX, I've 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. Agents and on what people can do. And so if you're a platform or an IT or a security team or something, well, 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,

• 32:21Speaker 02

  or the same threat models just applied at scale. The one additional one that comes with it, and we are working, we are working on making this available for everybody, just today it's enterprise only, is actually MC richer controls are on 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, an 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

• 33:06Speaker 02

  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 is 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 Hanson, and I was sitting there trying to live hack and break out of the SPX session, like on every five minutes was like, oh, I 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 threat, 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:46Speaker 01

  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. So we'll get on to 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:09Speaker 02

  I'll be very precise in terms of at the moment, because there's stuff we're working on. Like, 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 agent 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 like the wrong, I mean, I'm in all these workspaces and 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 I can and can't do. But what I really want is

• 34:53Speaker 02

  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 who writes, really, I like the open claw forums and nano claw forums and stuff. And there's somebody in open call on Reddit that was like, ah, this thing has been amazing for me. It's been

• 35:36Speaker 02

  buying my groceries for four months until last week, and then it bought 50 pounds of garlic. Whenever it had gone off and you know, 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 from my agent ever doing anything. Like, well, we can help. We can give you a very

• 36:20Speaker 02

  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 for 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:36Speaker 01

  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, really stupid stuff. So.

• 36:49Speaker 02

  Yeah, we can't solve everything. So yeah, exactly. I think that's exactly the right term. And 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:59Speaker 01

  Yeah, absolutely. One thing you touched on a bit earlier, but 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 solution here, but how does sort of knowing that credentials aren't somehow being stored somewhere or repurposed or anything like that?

• 37:19Speaker 02

  It's hard without, 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 will swap out your, for example, if you put a secret in as like your anthropic API

• 38:03Speaker 02

  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 that 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 man in the middle in a healthy way. Now, the threat, so the good thing is your secret can never be leaked. Nobody, you could never take that secret and send it out. You can't take your AWS keys. You can't take your bank account

• 38:46Speaker 02

  keys. You can't, the agent could never take them and go post them to Pay spent 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. So.

• 39:24Speaker 01

  Yeah. One thing I haven't, I guess, asked or touched on is, I guess, all of SPX is, is that all open source as well? Is that something, is like?

• 39:32Speaker 02

  It is a lot of open source. It is not 100% open source. So the core VM 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've had others on the podcast, it's like, we might be hypothetically speaking drowning in AI pull requests from everywhere else across the industry on the, on the.

• 39:59Speaker 01

  Yeah, yeah, we are hearing a lot of that. Yeah.

• 40:01Speaker 02

  Yeah. And so we're trying to go fast. We're trying to solve a lot of problems. We're 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, I want to say this, Docker is a very open source friendly company. We're an 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. So.

• 40:29Speaker 01

  Yeah, no, that's amazing. Let's, let's talk about this dog footing.

• 40:33Speaker 02

  Yeah.

• 40:33Speaker 01

  Thing like it was, 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, but which sort of explains, but maybe you could sort of semi summarize like, what is this? How I guess is Docker, dog footing that term of like, Trying your own products, basically, when in this case, like, I think, stress testing it. How has that actually worked?

• 40:53Speaker 02

  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 in 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 food 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 for our customers to do. But the better question, besides me, to ask this question to is actually our CISO, who I think is like elated

• 41:39Speaker 02

  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. There, 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.

• 42:21Speaker 02

  We're probably like everybody else, where most of the engineers like Claude code the best. Some people love open code, some people love Codex. Some, 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. Today, we're not all the way to the point where we're letting a lot of things through without a human review.

• 43:04Speaker 02

  Because mostly we have a security product where the contract is deterministic. So we kind of philosophically don't do that. We do go 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 one we're working on, actually kind of aggressively, is actually getting our go-to-market and our G and A teams working with the same stack and dog fooding. 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

• 43:46Speaker 02

  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. So.

• 44:00Speaker 01

  Yeah, so that's a very holistic approach to dog fooding, from what you've just described. So 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, like the sort of the hosted piece to this, because that was going to be one of my first questions, like, 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 like, what would be the reasons, I guess, for offering a fully hosted version of this?

• 44:30Speaker 02

  I'm not terribly secretive with our roadmap, because I think it's honestly, I always kind of 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 remocal. 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, again,

• 45:12Speaker 02

  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.

• 45:24Speaker 02

  Or whatever it is. That's like a big one. We're really working on the sort of one 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 kind of 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 acts to how agents can do kind of do what's called a computer use is I think one of the bigger things we're working on. We are, 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

• 46:05Speaker 02

  allowing 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.

• 46:10Speaker 01

  Definitely.

• 46:11Speaker 02

  Yeah, I think that's incredibly important. And then again, a huge focus for us that 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's identity works and like delegated ways and stepped on 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 the low 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

• 46:51Speaker 02

  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 our, for us, the part of the goal is great. We have Docker. We have probably a billion people running Docker somewhere, somehow across the, 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

• 47:35Speaker 02

  for the companies that are having real pain points on, I mean, everybody's scrambling, right? It's like, oh, well, I was told I need to roll out Claude, but either because the people in my company are screaming at me that they need it, or because, you know, 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 like risk the business and so on? Our whole lot of our 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. So.

• 48:06Speaker 01

  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 like 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:29Speaker 02

  Isn't in the next quarter? No. We've talked about, it comes up, we're Docker, it's a ubiquitous runtime that runs everywhere. We get asked for everything, like it asks you to put on thermostats, you get asked to put on cell phones. Like, 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 we're 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 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

• 49:13Speaker 02

  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:27Speaker 01

  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 Lukay 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 know, you've got to be very, very clear on that one. That is a roadmap effectively.

• 49:42Speaker 02

  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. So.

• 49:50Speaker 01

  Yeah. Well, just to recap, yeah, where's the sort of best place for a developer to go get up and running with SPX?

• 49:58Speaker 02

  I mean, easy one as well. You should go to docker.com and there's docker.com/standboxes. But if you're on Mac, you can do brew install SPX and win get on Windows. And so your Linux distribution of choice for your installers. So, but I'd 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:20Speaker 01

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

• 50:30Speaker 02

  That'd be great. Thanks for having me.

• 50:32Speaker 01

  Thank you.