You Gotta Keep the Dogs Away: YOLO Developer Workflows with a Coding Agent in a Box | Kevin Wittek

In this talk, Kevin Wittek, a staff engineer at Docker, discusses the use of AI-augmented development with a focus on agent workflows and security. He introduces the concept of Yolo developer workflows, which allow agents to operate with fewer constraints for enhanced productivity while still ensuring safety through sandboxing techniques. The speaker contrasts the human-agent interaction dynamic with the metaphor of a centaur, advocating for a partnership where technology supports human developers. Wittek explains different levels of AI adoption and the infrastructure needed to manage agents effectively. Additionally, he presents Docker's new sandboxing solution, aimed at facilitating secure agent operations without compromising isolation or security when working with sensitive data.

[music] >> Welcome everyone. Happy you are still attending the last talk of the conference I guess for you and then afterwards it will be off home and I hope you had a good conference and enjoyable conference. Here is a QR code for the Slido for this room. So scan it and put your questions during the talk in there and at the end we will try to find

some time to answer those. So um we of course it's the say I track right I I is a very hype thing very important but especially here in Germany in Europe we always have some healthy skepticism also on AI and those kind of topics but I'm ending now the conference with a lot of optimism towards AI I guess and thinking how it can how it might how

it maybe should in which way it should change our industry. So I hope you will leave this talk also with some excitement about ways how you might try out yourself getting more into this AI driven or AI augmented development agent augmented development. The name of the talk is called you got to keep the dogs away and why I will show in the next slide. >> [snorts] >>

And it's all about Yolo developer workflows and using the agent in a box or putting the agent in a box to make it Yolo but also make it safe. So who here heard of the band Thor? Does anyone know the band Thor? It's a heavy metal band a Canadian heavy metal band from the 70s and I used to play in the probably only ever existing Thor cover

band for a couple of years German a cover band of the heavy metal band Thor and yeah we played festivals or whatever. And um the first album they had was called Keep the Dogs Away. Uh and uh I don't know. It sometimes it somehow uh reminded me of uh like how we sometimes work with those kind of agents, right? We have all the different agents uh that

are struggling pulling us into different directions, and we have to stay in control of them. And uh yeah, maybe putting them in a box is a way to keep more sane while working with them. Yeah, who who am I? My name is uh Kevin Wittek. I'm currently a staff engineer at Docker. Again, finally. So, I'm very happy I'm back to being an engineer because I had a

stint of being a manager for the last years. And uh then I saw basically this AI revolution or whatever happen. And I was like, "Hmm, okay. I think I don't want to miss it while it happens on the ground. So, maybe it's now now is a really good time to going back into engineering and uh yeah, it's the most fun I I had uh for a long

time. Maybe also because being a manager wasn't that much fun at all. And uh I'm I'm working on the team at Docker leading the team that is working on agent sandboxes. It's a new product also based on some new technologies, but with a lot of Docker DNA. And we will talk a little bit about this product later, see some demos, but also talk about the general concepts

and ideas why uh why it might make sense to use agents within a sandbox. Um I'm also uh the maintainer or one of the maintainers of the Testcontainers project. Maybe some of you use this in other contexts. It's very traditional software, right? Testcontainers Java or Testcontainers in other languages. And uh some years ago we decided to make a startup based on Testcontainers. That one was called Atomicjar.

And then Docker decided to acquire us. That's how I ended up there. Uh but before before this I also like was a little bit into academic research. I tried to do a PhD in blockchain, another very hyped topic, right? And it didn't end up anywhere, but I did some cool stuff next to it with my wife, who was doing her PhD in behavioral research, and we were

working there on pigeons and on a concept called Skinner boxes, and that's the topic I want to talk a little bit in this session as well, because a lot of what we see with agents and how people use agent reminds me of what I've seen back then in this behavioral psychology So, when I'm speaking with people about using AI-augmented development, using agents for programming, I tend to

get very different reactions. Also at this conference, I get very, very different reactions. So, some developers love it. They say it's the best tool ever. They can't think of going back. And others say like, "Oh, it's terrible. It's a mess. It just creates noise. It's useless for me. Um it creates more work for me than it actually solves." Uh and it's a good question why. Why are

is the perception so different between people? So, maybe a show of hands. Who here is in group developer A? AI AI tools agents are the best tool I've ever used. Okay, not that bad. And who here is in in group B? Like more Yeah, not not 50/50, but like So, pretty mixed, right? So, this hypothesis is true, right? People get very different experiences, very different perceptions with

this. So, and why is this? Why is this? Good question. So, I like a concept from someone called Cory Doctorow, and he is a writer writing about technology topics, and he came up with a symbol with this metaphor of a centaur and a reverse centaur in the context of technology. And in the context of technology, a centaur is a human being that is assisted by machine. And

here we see Chiron and Achilles together, right? A very traditional centaur. So, it's like the real centaur, obviously, is the uh the horse body with the uh human upper body, right? And uh the way also Steve Jobs talks about computers or talked about computers, the bicycle for the mind. That's how we want to use technology. That's what how we want to use machines, right? We as humans

want to be assisted by the machine. But uh sometimes technology has a way to take the wrong turn, and then we end up with a reverse centaur. So, that would be a human body with a horse head, maybe, right? And the reverse centaur is a machine that uses is it a human being as its assistant, maybe to do certain things the machine cannot do by itself. And

then interesting example in the context not of programming, but in the context of writing was uh what happened uh at the Chicago Sun-Times last year. And um so, they published a summer reading list of books like various different reading lists, right? And in total, that was a 64-page insert that went out, and uh the um uh the the interesting part of it that a lot of the

books on this reading list were just hallucinated. They didn't exist, right? And it just went out into press. And like, okay, how could this happen? How could this not be caught in any of those processes? So, um there was then someone looking into this uh media outlet researching what happened there, and they found out like all these lists were basically authored by one single freelancer. So, he

did everything. And what he ended up doing was like, okay, just having uh having AI do everything. and like also he didn't really fact check, right? Uh and it still worked out as intended to a certain degree because as what was his job in the end? Not creating this content in a meaningful way, but just being the accountability sync. Just saying like, "Okay, this went wrong. Why?"

Ah, there was a human in the loop and they made a mistake because they didn't really double-check. And I think depending on where we are in the AI adoption scale and and how we are using it in process when you are faced as a team or as an individual with this stream of AI authored PRs that you go through and you do a LGTM, looks good to

me, okay, approve, approve, approve. You sometimes might end up just feeling like the accountability sync, right? So, what are you contributing here as a human in the loop? In the end, you're just providing your accountability in case something goes wrong. And that's of course not a nice experience. That's like this reverse Santa Claus part of why we also end up in such situations, I believe has to

do with the way uh agents are set up in the default mode and people explore um people um observe them or like encounter them in in their first when they when they first start working with agents. So, um who here has has heard of something called a Skinner box? So, a skin a Skinner box is a comes from uh behavioral science from experiments. It's where you put

an animal into a box and there are certain stimuli it gets, maybe a light pops up or whatever. Then the animal can press a button and depending on various conditions, it gets a reward which is often a food pellet, right? And depending on the experiment they want to set up, uh it's a variable ratio reward, meaning sometimes you get more, sometimes you get less. Right? Sometimes it

works out, sometimes you get nothing. And what various various researchers found and actually one of the papers I was involved with with my wife that's called decreased key packing in response to reward uncertainty and surprising delay extension in pigeons. So what people find out that and animals, mammals, also humans be more motivated if they are unsure of the reward they are getting when performing a certain action.

Right? So you can say, "Okay, whenever the pigeon presses a button, it gets one food pellet." But then then it will just it will of course also peck peck peck, right? But if you say, "Okay, sometimes the pigeon gets a food pellet, sometimes it doesn't." That will motivate the pigeon to do more pecking. And it also explains a lot of what we see in in gambling addiction

behavior in humans, right? So we are also animals in the end, so we are affected by this. what happens now when we start to run a coding agent in its default mode where it tends to ask you for permission to do certain things. We are putting us basically on this variable ratio schedule. So it asks us if it should perform a command and sometimes it will produce

great result, sometimes it will break something, sometimes it will work as expected, sometimes it doesn't. But it puts you in this constant loop and you continue pecking, right? So and if you do this for an hour or whatever, like are you reading the stream of things where it asks you, "Should I do this? Should I do this? Should I do this?" I don't think like anyone will

honestly after I don't know, even 10 minutes, I continue really reading every prompt. Because if you do this, you're also not operating at a high speed, right? So it becomes just a reflex to press this. And at this moment you're just an accountability sink. And then the model providers can say like, "Oh no, we built the safety in our agent harness because we asked the user for

consent." And of course you're consented. So, in the end you then becoming the pigeon. And you sometimes get a good reward, sometimes bad one. And you always pull the lever. You always press the button. Uh and there's another experiment where we did where we put a helmet on the pigeon, shut a helmet, and like we would check how different information gathered by different eyes is is received

in different parts of the brain. And depending on this it was also pecking a button, right? So, that's the >> [laughter] >> that's the thing you always do this in behavioral psychology. So, there is this interesting concept by Steve Yegge. Um someone that is very vocal and very extreme in in ways of using AI in in various ways. And that are the eight levels of AI adoption.

And the first level is okay, you're not using AI at all. The second level is you're using a coding agent. Now this is already adoption with coding agents, right? This is not talking about a co-pilot tap tap tap experience. It's already using coding agents. But the second level is you're using a coding agent in your IDE most likely, and you tend to approve everything you have because

you have permissions on. And I believe the magic [snorts] starts to happen on level three. And that also changes a lot of paradigm. level three is you run the agent, but now you run it in Yolo mode. That means in case of cloud code for example, running in dangerously approve all permissions. And once you start this, it feels very different. Because suddenly, if you do your prompting

right and the context is right, agents can go out for an extended period of time on a bigger task and self-iterate on it against its own validation loop, which I maybe some acceptance criteria or whatever. It runs those acceptance criteria in the form of end-to-end test all the time, and it slowly by itself can converge to a solution. But since you don't necessarily know the path to

the solution, you have to give the agent the ability to choose which tools to use, to choose which commands to run, right? And that that where the magic starts to happen. So then you give the command, and you let it run for 15 minutes, and you I don't know, you go out for a small walk or whatever. That's the idea. Um so on level four, we stop

to actually read the code the agent produces. We just keep track of the conversations, so even higher abstraction level. layer layer five, we are just prompting all the time the agent, and maybe at the end we still look through things in the IDE. And once you start doing this, you realize, "Okay, actually after I set up such a prompt, and then I have to wait 10 minutes

or longer, depending on how good my task is, what I do in between? Or maybe I just spawn another agent to also start doing work." So you start using multiple agents at the same time. So you're starting to multiplex. And you do this for some time, and like I personally feel I can do like this maybe with four agents. Some do more, 10 agents, but one time

it doesn't scale anymore as well, because you're still managing them by hand, and you cannot keep the context in your brain anymore, and then you need your own orchestrator. But we're not there yet, right? So people experimenting building those agent orchestration layers. Uh town guest town is such an example. In practice, they tend to not really work yet, because the models are not fully there. That's the

current assumption, but maybe next year we are we are going there. what we are talking about now is very much from level three and onwards, right? But it gives you gives you security to start really with level three and maybe asking around here who working basically on a level three so running agents in Yolo mode. Quite some. Who of the people running agents in Yolo mode are

just running them on the host directly? Yeah, some. It's okay, right? You can do this. I also do this from time to time. Who here running an agent in Yolo mode are running them in some kind of sandbox, some kind of isolation, virtual machine, container, anything? Okay, most. Who here is at a level that they would use already agent orchestration? Oh, so some. Cool. Very good. So,

especially the ones that are then already on level three, right? I want to show you our sandboxing technology and maybe it's something you just can adopt and say like, "Oh, cool. That makes my custom solution little bit of solid and I can just converge on on something else and then I don't have to care maintaining my custom solution. And to the others that are not yet on

level three, maybe using such a ready-to-use gives you a better confidence to start out working on level three. Right. So, yeah, at at this level where we let agents run in Yolo mode and then especially where we stop monitoring it's really really helpful if you have the infrastructure in place so that you don't end up as the default accountability thing, right? So, the infrastructure ideally helps protecting

you from the worst things that might Because of course all the time you hear on on Twitter and on other places like what is happening that we have prompt injection attacks against those agents. We have agents just dropping production databases, agents just deleting various files on the file system, or just like churning through a lot of tokens, right? So, that's the reality we have. And yeah, we

have to admit the model vendors and the people building the agent harnesses, they are also getting better in building the security in, right? So, that's what I saw what I saw when I prepared the demo for later. It gets increasingly hard to like do trivial security issues that would exploit an agent because the models just get better at protecting also the users. Okay, but so if you're

not choosing to use a sandbox, your own or something someone else built in the community, what do you have at disposal for doing certain things? So, prompt injection, you just have to be like running an approval mode and just read everything that is happening very very careful. So, then you're super reversing tower. That's not very enjoyable. If you have a sandbox that has network isolation, you're already

restricting what an agent can access, naturally. Um we have of course now tons of supply chain attacks every week a new pretty severe one severe one pops up. yeah, if there is a known CVE, you might be lucky that the static scanner catches this before executing your palm or whatever. Um but in case you have the sandbox, uh it's set up in a way that the secrets

are not even within the sandbox not accessible to the agent. And because you have configurable network policies, they can also not go out through an egress. Yeah, what happens if an agent decides to run RM on arbitrary data that it's not supposed to delete, which sometimes happens, right? Uh you can try to tell this in your cloud MD, "Never delete my root directory." Which sometimes works until

it doesn't. Better you have a sandbox that contains a blast radius to what is actually available to the sandbox. And um yeah, similarly other files that might be sensitive and available on your if you trust your agent and you want to run your agent in full uh YOLO mode, it might accidentally access them, maliciously or not, right? That doesn't matter. If they are not even available in

the sandbox, you have a much easier time thinking about this. Right, and then um when you do your own custom solution based on containers or whatever, it's of course also fine, but you uh still have to think about um at least kernel-level exploits or whatever. If you put them additionally in a VM, you have an even stronger security boundary. But in general, containers are also fine, right?

It's not that containers are a bad isolation So, putting something in a defined environment with defined set of features available, it sounds very, very similar to something that already occurred. The first time we had the I would say the container revolution in the industry, It sounds very similar than dev containers. And I think some people use dev containers for exactly this purpose. Anyone using here dev containers

for isolating their agents? Some, yeah. So, it generally works, right? It generally works. It's a solution that's out there for solving this environment parity problem in development also for a long time, but for one reason or another, it never found real critical adoption. I'm not really sure why. I always thought like 5 years ago, 6 years ago, I thought like, "Okay, at one point everyone will transition

to something like dev containers, and they might transparently run locally or in the cloud." But no, somehow it didn't I believe to some degree it's because modifying the the state of the dev is a little bit awkward because then it like has to rebuild itself and then sometimes glitchy depending on how you use VS Code. So, I'm I guess that could play into this, but I'm not

really really sure what is the reason here. and basically what we are now doing with the sandboxes is so especially we are stuck with our Docker sandboxes, we are trying the same thing again. But now we have a different uh use case in mind and and a different audience and more the agent, right? We're not catering for the human developer, we're catering for an agent. And the

difference is so if you drop a user in a dev container and it's missing important dependencies, then the user has to solve it and that's a pain in the ass. But if you drop an agent in a dev container and it's missing the JDK version it needs, it will just install it. It can just figure this stuff out. So, certain problems you had with dev containers, they

are not that relevant anymore once you have a agent running in such an environment because agents are just very good at figuring this stuff out and getting it working and if you don't care what mess the agent creates in this environment because it's isolated, then the better. right. okay, so what did we do at Docker for the agent? We tried a couple of different things and if

you like followed what we were doing at Docker, you might have noticed that what we offered changed over the last months. So, middle of of last year when I started this project with my team, we started working on a plugin in Docker Desktop Docker Docker Desktop that was called Docker sandboxes. In its first iteration, it was just uh spawning normal containers in the context of your Docker

Desktop and they were would look a little bit opinionated with regards to image and availability of stuff and so on, but it was just the normal And that worked kind of okay, right? As good as you would imagine, but getting a secure networking egress firewall in place there, bit awkward with the existing Docker Desktop architecture. And also, what happens when your agent, when your processes within the

sandbox need to have access to a Docker daemon? So, now we could with Docker Desktop just go ahead and mount in the Docker socket, but then you're breaking all your isolation guarantees, basically. You have to somehow work around this as well. Uh since then all those sandboxes also would live in the same virtual machine next to each other, right? So, we saw, oh, no, that's that's maybe

not the best Then we changed our approach, and uh the if you're now using Docker sandboxes in uh Docker Desktop, you will find the variant I'm now talking about. We used the technology we have in Docker Desktop for spawning the virtual machine across the various operating systems, Windows, Mac, right? It's a Linux virtual machine hosting all those containers. So, we used that technology to then spawn a

new virtual machine. And in this virtual machine, similar story, we would spawn an we would spawn a container, and then it's already isolated with a VM. Just the issue, this approach took like, I don't know, 30 seconds or longer on Windows for spawning the virtual That's because the technology stack we we had there, and the hypervisor technologies we are using, the virtual machine manager technologies we were

using were a little bit heavyweight, were not optimized for uh fast virtual machine creation and startup times. So, luckily, in a different part of the organization, people were exploring, rethinking what Docker could be, what Docker could be on different operating systems. And they built a completely new stack uh that launches micro VMs, right? Very, very fast launching micro VMs with our own custom new virtual machine manager

optimized for each platform. And in this one, we would then spawn a Docker container without any Docker daemon involved, right? We would use a technology called Nerd Box that is also open source. You can check it out. Uh use basically container D directly to spawn a container in there. Uh and that makes it everything like very very lightweight, very very fast. Um so, now on Windows it

creates such a virtual machine such an environment in a couple of seconds, right? Like 1 to 2 seconds. Great great improvement. so, since we now had all this new technology, we could also wire up some egress proxies and so on. So, everything became a much much more modern and optimized architecture for this kind of use case. And that's how it looks like, right? So, when you run

this new uh sandbox command, the utility is called SBX, uh what it will do, it will create a new In this, it will spawn an agent container. That one would likely run your code or whatever process. It will effectively bind mount a working directory into it. So, changes are uh synchronized bidirectional. Why? Because maybe you still want to continue inspecting the state of things from your host

programs, like from your IDEs running on the host and so on, right? That's more to cater for the the level three workflows that still are interested in inspecting uh the state with a traditional IDEs. And then we spawn its own Docker daemon within this container as well, right? So, its own exclusive Docker daemon. And then we have an egress proxy that can be used to configure all

kind of network policies, so which kind of URLs you're allowed to access. And then also importantly, secrets, for example, the tokens to access and traffic, GitHub, or whatever, they never end up within those sandbox environment. they are injected into the HTTP request as part of our egress proxy, so giving you even further security of an agent not accidentally or maliciously exfiltrating secrets. Uh yeah, so it's available

for free already, like it came out I think a month ago. So, you can just brew install it on Mac OS, we can get installed it on Windows. On Linux, it's also available for Ubuntu, for for Rocky Linux, maybe also for Red Hat, I'm not sure. And just install it, try it out. It requires a Docker login with your Docker account for reasons. Not for technical reasons,

for reasons you need to login. And then you can you get the CLI and you can do a SBX run cloud, for example. And that will create a new sandbox or use the existing one for the directory in which you are running. Uh there are a couple of more commands, very very similar to what you use from the Docker CLI, I guess. We also have a generic

sandbox you can run, that's the shell one that just drops you in an empty Ubuntu, and there you can do what you want. Um you can stop sandboxes, remove them, whatever. So, so crud stuff, right? You can exec from the side into already running sandboxes, as you would do with a Docker exec. most importantly, since this version that released this week, if there are changes that were

made within the file system of the sandbox, like your agent installed dependencies or whatever, you can run a SBX template save command to save it out into a new Docker image, and then you can reuse it for um new temp for new sandbox runs, right? Or you could share it across your organization, so you have your default templates with all the stuff you you need for your

development your project, then you can like set secrets for services. So, there are a couple of pre-configured services that you set like this like Entropic, GitHub, whatever, or you can set secrets for custom URLs and in this case the injection happens. You can set those secrets specifically for individual sandboxes or globally for all sandboxes. And then we have these policy subcommands that allow you to um to

configure uh the network list, right? And there is also um uh if you're a bigger organization that says like, "Oh, we have to have a more centralized way to govern those allow lists." There is a way to um uh wire this up with like a governance server offering, right? Where it's a central administrator configuring this these. And there's also a tool we that I show later in

the demo. And uh yeah, so if you then [snorts] run an agent like this, the the cool thing is all those potentially sensitive information and the I think it's not visible really well, right? But so, basically what it says is all those secrets or whatever SSH keys they are available on the host, but they would not become available in the sandbox. So, an additional security. >> So,

let's check the demos and hope they work. Uh first I want to show uh an an malicious Maven project like a pseudo supply chain attack, right? Where when you just build the Maven project, it would uh send exfiltrate various secrets from your machine to an attacker server. And we'll show how the sandbox helps And then I will also show how within the the sandbox you can run

test containers based tests because many sandboxing technologies out there don't really allow this. Like also if you use for example the native cloud sandbox, right? Or Kodak sandbox, they they allow sandboxing mode and they use uh OS level sandboxing, but they would not give you access to a Docker daemon because that would break the isolation. So, it might break your existing workflows, your existing projects. And since

I'm like a Testcontainers guy, right, I very much insisted, "No, I want sandboxing solution that out of the box works with Testcontainers-based testing as well." Okay. So, now here in uh terminal, I'm starting the attacker server. It's just a Python server uh listening on localhost. And in my ETC host, I I configure a custom domain uh for the DNS resolution. Maybe let's show cat ETC Right. So,

here you see I I configured this telemetry helpful build tools example to point at my localhost just for making this demo look a little bit better. Uh because accessing localhost from within the sandbox is a bit quirky, right? And then the demo would look weird. Mhm. Right. Uh I now have the attacker server listening on the left. Now, I have here a Spring Boot project. Uh this

is a Spring Boot project, and it's it does nothing, right? It's a it's a empty Spring Boot But, it has an interesting thing here in the pom.xml. It uses some build plugin uh that is uh available here already as a jar. So, think about this might have been a supply chain attack. Someone published a jar somewhere, right? maybe this would do normally something clever. Let's see what

happens now. Okay. So, now I'm starting my cloud in Yeah, I'm just starting the cloud normally here. Okay, I'm now going into the mode where I have to approve every command. And then I just say uh build this project using Maven verify. And then it asked me, do you want to run this? And I say yes, and that will fail because I don't have Maven installed, and

it will say, uh, maybe you want to run Maven runner. Yes. Yeah, run it. Okay, now on the left I received the payload, so the uh attack triggered. And it still runs the Maven build right nicely. these are actually my my real keys here, But I masked them a bit. But what is cool about the recent uh or the newest uh models [snorts] from Claude, they're getting

better in keeping you safe. So, that's why I had to do like this strict the first variant. I just had a plain Maven XX sending something, and then Claude would ask, do you really want to run it? It looks like it might exfiltrate your sensitive data. So, now what it does, it executes everything, but then it at least tells you, oh, this went out to a like

weird domain, maybe we just exfiltrated your secrets. So, it's the models are getting more helpful, right? But the damage is already done to some degree. At least now you can tell your uh you can rotate your secrets or whatever. Um okay-dokey. So, that was this And now I'm doing the same, just running SPX run Claude. And now it creates a new uh and it's there, and now

I have the Claude running here in this new virtual Now I say the same, uh and you see already we default to bypass permissions on, so running in YOLO mode. Build this >> It's already a little bit nicer. It doesn't didn't ask me to run the wrong Maven command first to then fail. It figured out the the right one. So, as soon as you let them run

Yolo mode, they just behave a bit better those agents. And it runs it. And like nothing bad's happen happening, right? I'm not getting any payload here. Why? A, the secrets are not in the sandbox in the first place. B, if we look at this TUI. So, if you just run SBX, you get this TUI. Then, you can see here we blocked we blocked this URL because it's

not in the default allow list. So, when you first time start SBX, it asked you like, "Okay, what domains do you want to allow?" We have a have a set of policies like open, everything allowed, balanced where we allow list a lot of known domains used in software developments like Maven and Docker Hub, GitHub. Um or you can say deny all, right? I'm now having the balanced

profile and this arbitrary URL is in this case um then not allowed, so it will get blocked. Um okay. So, we've seen this. We've seen this works as expected. And now, just for fun, let's see the test containers example. So, I have here another Spring Boot app that does like nothing useful even using like deprecated test containers method, but it's in the end it's just launching a

Postgres using test containers, right? And like does something with a with this uh person repository, right? Nonsense test. What we want to show is that test containers can run in the sandbox. So, SBX run cloud. Creating again a new sandbox. And I'm in there. And now I say build this project. Build and and test this project. Run all the tests. Run all the tests. Yeah, again tries

to run Maven. Maven is not there, but doesn't bother me, right? I don't want to be bothered. May I run Maven? May I run Maven W? No, come on. And yeah, so now it's running. And you see actually here in the logs, you see test containers related logs popping up. a container is starting here. A container is starting here. It's pulling the layers and um afterwards if

we run a Docker image ls we will you will see now images available, images being pulled. Right. So so it works. If you have existing personal as best test, put them in a sandbox, they continue to work. All right. Cool. I try to wrap up the rest quickly so that we can see remaining questions. Um okay, so in addition we said uh what happens if you now

wanting to multiplex, run multiple agents? So there are two ways that's already built into SBX directly. If you just run using SBX you will work on the bind mounted directory, but we also have this branch argument and that will then automatically branch off into a work tree within the same working directory, but in a sub directory, right? And if you then point your IDE at the root,

it normally, like IntelliJ, VS Code, they are normally able to follow other work trees, and you just see the changes pop up there directly. Um right, and then uh the shape of the sandbox, we call it templates right now, it's just a Dockerfile, or it's a Docker image, right? And like a a built Docker image based on a Dockerfile, for example. So, you can just build your

own. And something we plan to release next week is, I think, a very, very important capability. It's something we call kits. Kits will allow you to declaratively modify the default um sandbox experience. So, you can, for have uh I don't know, a Java Java kit, right? You can say, "Run Run Claude with a Java kit." And the Java kit would then, like, either use a different default

image, or would maybe run certain commands at start, copy in certain files, right? You might have in your organization, you might to copy in your own CA certs, because you're maybe using a custom CA, right? Then you could have your own uh custom custom kit in your organization that uh puts those files you need to access your internal services. And also, these kits will allow you to

more conveniently bundle up default policies and default secret injection mappings, right? So, you could have my company kit that says, "I have all these internal domains allow-listed, and these are the mappings between domains and secrets." And then it's already wired up. And uh what we also do, I haven't demoed this, but uh when you trigger an OAuth flow from within a sandbox, the OAuth flow will actually

execute on the host and be terminated on the host so that the host in our proxy is able to gain those tokens that they don't end up in the sandbox. Then we just inject dummy values in the sandbox so they can only replaced and injected then at request That you need for example if you authenticate MCP servers from within the sandbox. Uh what happened here? I have

by the way I use cloud design to generate the slides so I'm not sure what happened here. But they look cool. They look so different than my normal slides would look, right? Uh but I wanted to give it a try. okie dokie. Yeah, so uh just a fun slide, right? So give it a try. Give it a try. Let us know how it works. Uh give us

feedback in our uh Docker Slack channel. We have a Docker community Slack, right? We have an SBX channel there. Come find me there. Give me feedback. Give us feedback on uh on Twitter or LinkedIn, whatever. I'm very interested if you want to try if you're trying it out. You find things work, things don't work. Uh SBX-releases so docker/sbx-releases uh is where we host the binaries and we

also have a public issue tracker there. Um maybe not always doing the best job uh being that responsive, right? But I try to be better. Uh you can also give feedback there and uh yeah, thank you. Thank you very much. Maybe there are questions which I would check now in Slido. Wow, yes. Okay, so we have nearly 5 minutes left so let's try to do this. And

no votes there so I just go from top to bottom. The first question by anonymous, is the Docker engine inside SBX fully isolated or do image downloads bill over from to the host? So the answer is it's fully isolated for better and worse, right? That means you don't benefit from a image caching across which is maybe something that would be nice. But so we I don't know,

for now we opted for isolation and against convenience in this case because if you're using something like sandboxes, you're likely more interested in isolation over convenience in the first place. So it's fully isolated. Uh does Docker sandboxes support open code AI? Yes, so it supports open code AI, it supports Copilot CLI. Although uh the current Copilot variant is broken in the current version since the Copilot CLI

changed how it validates its own uh token, right? And so we inject this dummy value for the token and now Copilot CLI will say like, "Oh, that doesn't look like a Copilot token. I don't want to use this." So uh the next release that will come out, I don't know, this week, next week has this patch. So we now uh look more according to what Copilot expects.

And like we're reaching out to the Copilot folks to maybe find a cleaner way to integrate there. So there are various that are already supported. And then once we release the ability to define custom kits, which are just YAMLs, basically just YAMLs and Docker images, it will be very very easy to just roll your own for whatever flavor you prefer. Uh what if I need additional files

mounted for configuring Maven mirrors? Yes, so um we support multiple bind mounts. By default, we only bind mount uh the working directory, but you can specify additional bind mounts also as read-only bind mounts. Um it's very in practice a little bit quirky, right? So give it a try and see how it feels. Um again, another alternative would be potentially a kit here as well that just copies

those in on sandbox creation time. Uh does it mount the current directory in the sandbox? Yes, we bind mount the current directory. how much load it brings to the developer laptop? Some, right? So, it's the load is more on the sense that it takes some um RAM mostly, right? Some memory because it runs its own virtual machine. It's not for free, definitely not. But we try to

keep it lightweight. And regarding performance difference between running on the host, so uh some use cases are considerably faster on the host right now because we had to make certain to avoid certain issues like file system corruption that uh file system performance worse, right? But we are now working with the other teams at Docker to getting things on par as good as possible, right? It has to

do with the word IO file system and the caching configuration and so on. Some lower-level stuff, so we are throwing all the clothes at it to make it better. Um but so, I I've seen reports from colleagues at Docker that say SBX running just generic tasks in SBX performs already better than Docker than within a Docker Desktop We don't know why besides that we now use this

new tech stack, right? But it's something someone shared with me today, so that's cool. Uh will there be Kotlin kit? Yeah, of course. Like anyone can do a Kotlin Kotlin kit that does this or just use a uh template. The question is what goes in there, right? I I wouldn't know. Do you need anything besides what is written in your Maven or or Gradle and the JDK?

I don't think so, right? So, it should just work. Um what is the difference of Docker Sandbox to Open Shell from Nvidia? So, Open Shell, I think has a different target. So, I'm not an expert on them, right? But they are very much based on running on Kubernetes and this kind of things. So, we are very, very lightweight. We are targeting a developers running this just locally

for their own use cases or developers just thinking about how to orchestrate this in their context, right? Maybe those sandboxes as part of their CI and so on. So, it's a small uh focused solution, I would say. And Open Shell from Nvidia, I haven't tried myself, right? But the whole approach, very Kubernetes based, looks like something that you're already supposed to deploy and operate more on an

enterprise scale. So, I think the target scale is a different one there. Uh how communications between agents could look like? So, between agents in different sandboxes, I don't know. We're not thinking about this at the moment. Um and I never used it like this, to be honest. So, I only am really interested agents communicating with each other as spawned from one authoritative agent, so to say, right?

So, if I, for example, enable in Claude Code the agent team team mode, then Claude will spawn the agents as child process, and they will run in the same sandbox. I don't have to think uh communications. It just works. Um or if I want Claude to talk with Codex, then I just have to be sure Claude and Codex are both installed in the same sandbox, and then

just Claude will call Codex, and they will communicate with each other. So, that's what we in SBX think about agent communication, right? Just within the sandbox, then have all the agents in the sandbox that should communicate with That's all. yeah. Please. >> For an enterprise, is all the settings overridden by policy? >> Yeah, so the question is, for an enterprise, are all the like how overridable are

settings as set by an enterprise, right? So, that depends how it's configured in the enterprise. So, for example, if you would say in the enterprise just deny all, right? You can configure this in your governance setting, then if a developer would try to allow anything, it would like affect nothing, right? There's another way to configure, okay, we basically deny everything unless the developer opted in into this.

That's another default people like to use. But, there are organizations that like like to put the trust actually into the developers, right? Not all organizations might be like this, but some say, "No, if a developer wants to open it because developers else will find a way around this after all, right? Let them do it." So, there are different ways to to set this up. Yeah, yeah, so

enterprise is authoritative. But, it depends on how you configure it, right? You can also configure it in a way where the local selectively overrides the enterprise deny for a subset or whatever, yeah. Yes. Oh, yeah, there. This one? Okey-dokey. No. >> No. So, no reason. I forgot to write them about it. So, my my colleague Edu that maintains Saturn as Java, he was like when Juni CLI

came out, "Oh, we should also support this." I said like, "Great idea. What should we do?" Then I asked someone and I said like, "Oh, write this person an email and we wire it up." And then I forgot it. So, it could work, right? Especially when we when we release the new uh the ability to uh do kids next week, anyone could do it themselves and it

would likely be quite trivial to wire it up. Uh but, as soon as we would take the time or prioritize, we would also bundle it in, right? Mhm? Yeah, you could you could for example the shell one, right? And just install Junichiro line there. And it would work. Yeah. And then you'd save the template out as my Juni template and then you use it, That already works.

Uh, you IDE support? Uh, no, we don't get wired up with the IDEs. we should be able to wire it up with ACP, right? We haven't done it yet. Uh, there are also some people that tried basically, uh, um, launching the the the dev server within the sandbox and then connecting from the IDE, which both support, right? IntelliJ supports this model, VS Code supports this, so that

should already work since you can, um, publish ports from the sandbox from the outside of it, yeah. So, you want for example something, uh, connecting to a blocked URL, right? Uh, so we don't have a mechanism for this, right? I guess it's technically should be possible since we see in the proxy when the request happens there, uh, but it's not wired out or anything right now, yeah.

Yes. Yes. Yes. Yes. Yes. I think you you could like maybe if you observe the logs on debug level, it would appear there and then you could like wire up something against this, right? But, Okay, so I'm getting told everything's over. So, you finished it. The conference is over. Have fun, everyone. Thank you. >> [applause]