Talk by Moritz Johner (Form3) on running PatchPilot, an agent built to patch CVEs across thousands of repositories, in production. Covers how a single dependency-bumping PR changed 70,000 lines of code, and why an agent with repository access, CI logs, credentials, and Docker socket access becomes a supply chain actor. Describes their two-layer architecture: a deterministic Go layer holding dangerous powers (GitHub write access, CI triggering) and a separate agent layer that only edits files, with the security boundary capping blast radius on prompt injection. Also covers the Docker socket risk (privileged container breakout) and mitigating it by running inside a firecracker microVM with its own kernel and per-layer network policies. # Video Identity Observations — Patch Pilot Talk (Moritz Johner, Form3) ## Explicit Self-Description Evidence - **Speaker affiliation**: Title attributes the talk to **Moritz Johner, Form3**. The speaker confirms delivering a prepared talk: *"My talk today is about..."* - **Stated talk purpose / thesis**: *"A useful coding agent is a supply chain actor, whether you plan for that or not. That's the thesis of this talk."* - **Framed as a case study, not a product pitch**: *"Now, this is a case study. We built this, we ran it in production. Infosec pushed back in several places. They were right. I just want to present to you what we came up with in the end. It's nothing new, it's nothing fancy."* - **Stated employer context (observable claim)**: References organizational scale — *"at our scale, we have thousands of repositories"* — and notes *"in finance you don't want to share this kind of information"* when redacting a production screenshot, implying a financial-services environment consistent with Form3. ## Intended Audience - **Engineering practitioners** familiar with dependency management basics — the speaker assumes shared experience: *"dependency patching... probably the most glamorous problem in software engineering. I guess everyone did it here at some point in the past."* - **Engineers running or considering AI agents in production**, specifically those concerned with security tradeoffs: *"surely I want to know from you guys how you run agents in production just to learn and to have a discussion."* - **Attendees of a conference with a community/track focus on agent sandboxing** — references a *"dedicated sandbox panel"* the following day and vendor booths on-site. ## Claimed Scope of the Content - **End-to-end architecture walkthrough** of an internal tool called **Patch Pilot**: a deterministic Go orchestrator plus agentic layers for CVE remediation and CI failure remediation. - **Security architecture decisions**, including credential separation (*"the dangerous ones, the GitHub write access and trigger CI is something that we did not give the agent"*) and sandboxing via **Firecracker microVMs**. - **Honest treatment of limitations**: *"prompt injection itself isn't solved and we cannot really solve it. All we can do is just limit the blast radius"*; sandbox tooling is described as *"beta. It's very early in the phase."* - **Community engagement**: closes with an invitation to discuss sandboxing practices collectively. ## Observable Presentation Patterns (Demonstrated, Not Claimed) - **Technical depth**: concrete details on two-tier architecture, prompt steering, end-to-end injection tests ("evals"), network policy via DNS/TCP forwarders and vsocks, and named ecosystem tools (Landlock, bubblewrap, seccomp, Kaniko, BuildKit, Firecracker, micro sandbox project). - **Candid, self-deprecating tone**: humor (*"it really is like vacuuming... everyone loves it"*, agents *"are really dumb"*), and admits personal limits: *"if I were tasked with this kind of task, I probably would have missed that."* - **Balance toward security conservatism**: repeatedly credits Infosec pushback (*"They were right"*) and centers risk reduction over capability maximization. - **References real production artifacts**: shows a (redacted) production PR screenshot and diff, grounding claims in demonstrated operational use. ## Summary Judgment (Observable Only) The video presents Form3, via engineer Moritz Johner, as an organization **operating AI coding agents in production at scale within a financial-services security context**, addressing a practitioner audience, with an emphasis on transparent case-study sharing rather than product promotion. All identity claims above are directly traceable to the title or quoted transcript passages; no private motivation is inferred. # Delivery Observations — Moritz Johner, "We Gave an Agent Production Code Access and Then Tried to Sleep at Night" ## Tone & Overall Style - **Conversational, low-key humor**: Opens with self-deprecating jokes about the topic's glamour: > "dependency patching, which is probably the most glamorous problem in software engineering" > "it really is like vacuuming. Like everyone loves it, can't wait to do do it again next week." - **Dry, understated risk commentary** when discussing serious security issues: > "At that point, it's more or less game over for you" > "so, that's why, you know, we still have to pray a little bit. But at least we don't like build the whole system on on hope." - **Honest, non-salesy framing** of his own work: > "it's nothing new, it's nothing fancy" ## Vocabulary & Recurring Terms - **Repeated key phrases** (appear multiple times): - "blast radius" — e.g., "fundamentally limits the blast radius," "the blast radius of an agent is an architecture decision" - "deterministic" vs. "agentic" — the talk's central architectural split, used dozens of times - "boring" as a positive descriptor: "It's deterministic. It's boring," "That's boring" - "game over" (twice) for the Docker socket risk - **Domain jargon**: CVE, OCI images, manifest, Dockerfile, micro VM, Firecracker, Vsock, seccomp, prompt injection, supply chain actor. ## Teaching Habits & Structure - **Problem → thesis → solution arc**: Establishes the pain (patching backlog), states the thesis explicitly, then walks through the architecture. - **Explicit thesis statement**: > "A useful coding agent is a supply chain actor, whether you plan for that or not. That's the thesis of this talk, basically." - **Audience-addressed signposting**: > "So, let me share a design that we came up with" > "If you take one thing from this, um the blast radius of an agent is an architecture decision." - **Concrete walkthroughs**: Step-by-step end-to-end flow of Patch Pilot; color-coding explained for slides ("the green bits... the yellow ones, that's the agent"). - **Real artifact show-and-tell**: A redacted production screenshot and a diff, with candid self-assessment: > "to be honest, if I were tasked with this kind of task, I probably would have missed that." ## Communication Patterns - **Deliberate scope rejection of extremes**: > "It's not agents are dangerous, or agents are fine." - **Practical recommendation with caveats**, e.g., on the micro sandbox project: recommends it, then notes "We're going to see um if they're able to gather enough traction." - **Closing with community invitation** rather than a hard summary: > "I surely I want to know from you guys how you run agents in production" - **Frequent verbal fillers** ("um," "you know," "like") throughout — consistent with an informal, improvised conference delivery rather than a scripted talk. - **Casual asides to the audience**: > "you can even go down sta- downstairs to the vendor booths and just, you know, talk to the vendors there." ## Stability vs. Isolated Moments - **Stable patterns**: filler-heavy informal delivery, deterministic-vs-agentic framing, humor, pragmatic hedging, concrete examples — all recur across the talk. - **Isolated moments**: the "be sure that you don't, you know, be an idiot" remark to the agent appears once; the diff walkthrough anecdote is a one-off. Insufficient repetition to treat these as habits. ## Uncertainty Notes - No curated metadata was provided, so observations rest solely on the transcript; timing, pacing, and visual delivery cannot be verified. # Position Record: "We Gave an Agent Production Code Access and Then Tried to Sleep at Night" **Speaker:** Moritz Johner (Form3) — sole presenter; all positions below are his unless noted. ## Core Thesis - **"A useful coding agent is a supply chain actor, whether you plan for that or not."** - The moment an agent gets production credentials, it becomes a supply chain actor just like an engineer in the department, and should get similar or the same guardrails. - Explicitly rejects both "agents are dangerous" and "agents are fine" framings. ## The Problem: Dependency Patching at Scale - Form3 has **thousands of repositories**; patching is "a backlog that never empties." - **Dependabot/Renovate are insufficient** because they were built for a manifest-bump world: - CVEs may live in OS packages in a base image, invisible to the manifest. - Dockerfile-pulled binaries with versioned URLs can't be acted on by these tools. - Patches don't happen in isolation — e.g., bumping the Go runtime may require bumping the linter, which introduces new linting rules that invalidate the codebase, leaving "a big mess." - Conclusion: it's not just a patching problem, it's a **reasoning problem** — a tool must understand the full surface of a CVE and what else must move to reach green CI. ## The Solution: Patch Pilot (Two-Layer Architecture) - **Deterministic layer** (a "boring" Go app): discovers vulnerable OCI artifacts, scans images, maps images to repositories, and holds dangerous capabilities. - **Agentic layer**: invoked for reasoning — CI failure diagnosis, remediation. - **CVE remediation agent**: smallest effective change set; only bump to the version that fixes the CVE (not latest) to avoid unnecessary risk; modifies files only — no commit, push, PR creation, or CI watching. - **PR remediation agent**: minimum-effort CI fixes; must be told not to revert its own previous changes (LLM tendency noted by speaker). - Retry loop until a **maximum retry limit**, then escalation to a human for manual remediation. - Deterministic controller vets agent output for "nonsense" (empty files, stray binaries) before committing/pushing. - **Agent retrospectives** after each invocation (what went well/wrong, missing tools/context) — aggregated across PRs to identify fixes; speaker notes agent observability "is still an open issue being built by the community." - Two recurring issue classes observed: **infrastructure failures** (network, permissions) and **repository complexity** (addressed via system prompt or repository-specific instructions). - Example outcome: agent removed two previously pinned packages (libcrypto3/libssl3 fixed by base image bump). Speaker's candid qualification: > "To be honest, if I were tasked with this kind of task, I probably would have missed that." ## Security Model & Prompt Injection - Credentials were granted: GitHub read/write, OCI registry access, runtimes, linters, bash, network — but **dangerous credentials (GitHub write access, CI trigger) were kept out of the agent**, held only by the deterministic layer. - Rationale: a small-looking PR involved **70,000 lines changed**, so attack surface is wide; prompt injection "isn't solved and we cannot really solve it — all we can do is limit the blast radius." - Mitigations: - **Prompt steering**: explicit marking of untrusted directories (vendor dir, CI logs). - **Crafted end-to-end test repo** ("what people call evals today") with deprecated functions and a migration guide attempting to recruit the agent into malicious behavior. - Honest limitation retained: "unknown injection vectors which we aren't aware of yet... we still have to pray a little bit. But at least we don't build the whole system on hope." ## Sandboxing Positions - **Sandboxes "look great on a slide" but break down in practice:** - Agent self-verification needs Docker builds → Docker socket access → "it's more or less game over" (privileged container escape, reading env/memory of other processes, planting SSH keys). - Form3 **ran it that way in production at some point**; "it didn't feel good"; they moved off it. - Linux sandboxing options (landlock, bubble wrap, seccomp, Kaniko, BuildKit, etc.) "don't compose well with containers" and can't contain a Docker daemon. - **Chosen design:** a **Firecracker microVM** containing the agent *and* the Docker socket with its own kernel — everything contained within the VM. - **Split network policies**: deterministic layer gets known, fixed access; the agent's needs vary by language ecosystem (Java vs. Python vs. Go), so traffic flows through a Vsock to a host process applying DNS/TCP/hostname/port rules; optional custom-CA TLS MITM (noted as "really hard," not yet pursued). - On current tools: - Codex/Cloud built-in sandboxes: "worthless" when Docker socket access is given. - Open Code / "Pi": no sandbox (not implemented or not by design). - Sandbox-as-a-service vendors vary; many lack Docker socket containment and network controls. - **micro sandbox** open-source project would be his choice if rebuilding today ("batteries included"), with the caveat it's YC-funded and its sustainability is uncertain. - Overall assessment: **the tools exist but are beta**; gap remains between them and enterprise-ready features and orchestration. Points to the Kubernetes agent sandbox SIG and Open Sandbox as emerging efforts. "It's not there yet." ## Key Takeaway (Speaker's Stated Conclusion) > "The blast radius of an agent is an architecture decision." - The deterministic-vs-agentic split **is** the security model; withholding write credentials from the agent fundamentally limits blast radius under prompt injection. ## Case-Study Framing & Epistemic Humility - Presented explicitly as a case study, not a general solution: "It's nothing new, it's nothing fancy." - **Infosec pushed back in several places — "They were right"** (tension acknowledged, not smoothed). - Ends with an invitation to community discussion (mentions a sandbox panel the next day) and a request to learn how others run agents in production. # Speaker Attribution Record ## Video **Title:** *We Gave an Agent Production Code Access and Then Tried to Sleep at Night — Moritz Johner, Form3* **Video ID:** `01a15ca8-6f3c-7e86-a136-e001e4a08201` ## Speakers | Speaker | Role | Evidence | |---|---|---| | Moritz Johner | **Main presenter / speaker** (Form3 engineer presenting the talk) | Title metadata names him; he delivers the entire talk, says "My talk today is about…" | | Unidentified introducer | **Other (introducer)** | Speaker thanks "everyone for joining… thanks for the great intro, by the way" — introducer's own lines are not in transcript | | Audience | **Audience (non-speaking)** | Applause at end; referenced as "you guys" / invitation to community discussion | No narrator, guest, or promotional host is present. Single-presenter conference talk format. ## Provenance & Referenced Sources - **Internal system described (first-party):** "Patch Pilot" — Form3's CVE remediation tool; two-layer architecture (deterministic Go controller + agentic remediation). - **Third-party tools/products named:** Dependabot, Renovate, Firecracker, Kaniko, BuildKit, landlock, bubble wrap, seccomp, Codex, Cloud (agent sandbox), Open Code, Pi, **micro sandbox project** (open source, YC-funded — speaker notes uncertain long-term viability), Kubernetes agent sandbox SIG, "open sandbox" project. - **Third-party claims:** Infosec team at Form3 "pushed back in several places. They were right" — internal stakeholder, not a speaking role. - **Event references:** Mention of a "sandbox panel" the following day; vendor booths downstairs. ## Promotional Segments - **None flagged.** Speaker mentions vendors and the micro-sandbox project with caveats ("we don't really know how it goes"), stated as personal opinion, not promotion. ## Evidence Channel Limitations - Transcript shows a **redacted production screenshot and diff**; content not visible in transcript (financial data redacted). - **No curated metadata supplied** — no comment availability, channel, or date information recorded. - Transcript contains occasional transcription artifacts and unattributed audience-off-mic moments (e.g., "Can I just go there?"). \>\> Thanks everyone for joining in. Um thanks for the great intro, by the way. Um So, yeah. My talk today is about um so titles we give in Asia production code access and then try to sleep at night. Um so, it's mostly around dependency dependency patching, which is probably the most glamorous problem in software engineering. I guess everyone did it here at some point in the past. Um it really is like vacuuming. Like everyone loves it, can't wait to do do it again next week. Now, at our scale, we have thousands of repositories and it really is a backlog that never empties and you close 10 issues today and you know next week 20 more will arrive and you have to deal with them. So, naturally you think, "Sure. Let's just automate it. Dependabot exists. Renovate exists. Problem solved, right?" It isn't. Cuz these tools were really built for a world where fixing a CVE means um um looking at the manifest in a repository and just now bumping a version to the next version and that's it. Um but our world is much more complicated than that, at least nowadays in our world since we have containers. So, the first problem is that the vulnerable thing isn't necessarily the thing that these tools can see. For instance, the CVE might live in an OS package that you use in your base image. It's not in your Dockerfile. It's just in the base image. Or if your Dockerfile pulls down a binary during the build process, it may see the URL, which might contain a version number, but it has no idea how to act on it. So, they can only look at the manifest, patch the manifest, but everything else is just simply invisible. Now, the second problem is patches never happen in isolation. So, when we look at the Go code base, sometimes you want to bump the Go runtime to the next minor version. When you do that, sometimes you might have to also bump the Go linter cuz the version are just intertwined. You have to bump both of them at at the same time. So, when you bump the linter, that sometimes introduces new linting rules, which then invalidates the code base, and you're left with this big mess. Now, these old tools, quote unquote old tools, Dependabot, well, they just bump the Go runtime version, create a PR, and walk away, and you're just left with this mess, and you need to figure out how to fix that. So, you don't really have a like a patching problem, you also have like a reasoning problem that you um need to address here. You really want to have a tool that looks at the CVE and understands the full surface of it. Where does the CVE actually live? And needs to figure out what else needs to move in order to um get to a green CI. So, that's basically what we did. Um we built Patch Pilot. We pushed to production, and eventually Infosec um came around the corner ask a very reasonable question, is this automation, or is it a supply chain incident waiting to happen? A useful coding agent is a supply chain actor, whether you plan for that or not. That's the thesis of this talk, basically. It's not agents are dangerous, or agents are fine. It's the moment where you give an agent um production credentials in order to like be useful, it really becomes a supply chain actor, just like an engineer in your department. And you should apply similar or the same guardrails uh for the agent just as you do for engineers. Now, this is a case study. We built this, we ran it in production. Infosec pushed back in several places. They were right. Um I just want to present to you what we came up with in the end. Um it's nothing new, it's nothing fancy. Um I just want to share share what we did and then hopefully have a discussion afterwards to see how we all figured this out together. Now, patch pilot has two layers. One, it's a simple go application that is deterministic. It's boring. It just does orchestration. It discovers vulnerable artifacts. So, artifacts that's our OCI images. That's what we have in production. That's what we ship to our customers and that's the thing that we really care about. So, the go app discovers those, scans the images, and figures out which image is built by which repository. Because we need that link in order to later then work on the repositories. And this deterministic part is very boring on purpose. It's very simple. And inside that, we spawn agents. Now, these agents are there for the for the reasoning. For instance, when we see a CI failure, we just tell the agent, "Look, that's a CI failure. Please figure out what else to do in this case." It could be that CI failed because a previous change that we did. It could also be a flaky CI. It could be an infrastructure failure, just a simple timeout that just, you know, caused the CI failure. And then then we would just need to retry and do nothing else in that case. Now, let's have a look at it how it looks end-to-end. So, first and foremost, a little bit of color coding. I hope you can see this. So, the green bits, that's our deterministic part, our go application. And the yellow ones, that's the agent. Um So, first we start with the with the assessment. That's just a simple manifest, a simple JSON file which contains a list of images and the CVEs that it found for these particular images. Um It will then moves on and downloads the repository it's supposed to work on, um clones it into a local directory and creates another directory inside it where it then shoves all the context for the agent inside there. That's a prompt with which has like 2,000 words or so. Um it's the assessment manifest, um a couple of other things for like communicating with the agent. And then simply we simply invoke the CVE remediation agent, which is like the first bit. Um the first agentic part that we invoke, which is supposed to do the the smallest effective change set. And it should only fix the CVEs which are tied to the findings. It shouldn't just, you know, bump the dependencies to the latest and greatest version. That's just that interest introduces unnecessary risk, which we want to avoid. So just bump to the version that actually fixes the CVE and um nothing more. And at the very end, the agent then of course should um just verify its own work. Should ensure that the Dockerfile is able to build, should um rescan the image that it has built, and all of that stuff. Um so the CVE remediation agent actually just modifies files on the file system. It doesn't commit, it doesn't push, it doesn't create a PR, it doesn't watch the CI itself. It just modifies files on the file system. And once it's done, it hands back control to the controller, to the deterministic bit, which then quickly vets the changes for, you know, some nonsense in there in there. For instance, like um empty files or some binaries that the agent might create because agents are really dumb. They mess up, you know, some bash commands that are piped together, which then could um create empty files. Or they just, you know, compile the application and leave the binary inside the repository, which is nonsense. So we got to take care of that. And then we commit it, we push it, we create a PR, um and then we watch CI. And once CI is green, cool, we just send over Slack notifications and we're done. Um in case there's a CI failure, we just move to the next agentic bit, which um should then just remediate the PR failure. To do that, we just give it all the context that it needs. So, CI logs, workflow metadata that we need, and everything else that is needed to work on this on the CI failure. And then we invoke it. And this PR remediation agent just simply should do the minimum effort fixes. It kind of LLMs LLMs kind of tend to just revert the previous changes that it did. So, we got to tell it to not do this. And again, it should just verify its own work. And this then goes on in loop, create and watch the PR, watch CI, fixes the CI failure, and so on and so forth, until we hit like a a maximum retry. And then we send that over to a to a human in case there's like the limit is reached. We then just simply tell the tell the human to take a look at this particular issue. Cuz then that needs manual remediation. There's one more thing that I want to share here, which is that at the end of every agent invocation, we ask the agent to do a very short and simple retrospective. What went well, what went wrong, what tools are missing, and what kind of context would help the next time it would be invoked. And this really helps us to understand what the agent is doing and what is what is missing out. Um Now, the observability for the agent in bits, that's still like an open issue and being built by the community at the moment. That's just how we deal dealt with this with this particular issue. Um So, yeah. That really helps us to understand this at scale because then we can just aggregate all this all that information across the PRs, condense it down, and then we can see um what we need to fix. We usually saw like two kinds of issues. One is an infrastructure-related issue. It could be um network failures, or that the agent didn't have enough permissions in order to like clone a repository, um or it could be some complexity issue related with the repository. Some repositories are just hard to deal with and hard to reason about without having the the context that the agent needs. Then we just need to either modify the system prompt of the agent or we then have repository-specific instructions um that we then just feed um to our agent to work on this issue. I brought a screenshot here with me. Um I had to redact a lot of stuff cuz it's an actual like production kind of screenshot and you know, in finance you don't want to share this kind of information, but um yeah, that's what I what I got out. So, here at the top where the arrow is, that's a very simple bit. We just bump the the base image that we're using from the Go line that simply a dependabot can do. That's boring. At the bottom we can see that the agent uh updated libcrypto3 and libssl3. So, um yeah. I also have like a short diff um that I want to quickly showcase what the agent did. Um you can see here on the left-hand side that it that these um bottom two Can I just go there? Here. That we have these two packages here that it actually removed in the process because these packages um have been pinned previously. It then just removed those because they have been fixed by the actual base image. So, to be honest, if I were tasked with this kind of task, I probably would have missed that. So, I'm like glad that the agent um fixed that and is a good good engineer here. So, and that's it. So, we started with a bunch of CVEs. We scanned artifacts, um remediated remediated this the CVEs and the findings, and now we have a proper working um um PR that then just needs to be reviewed by a human and approved and merged. So, to make that work, um we gave Patch Pilot a couple of things. We gave it GitHub access, um read and write access to clone the repository, to commit, and to push changes, to open up PR, to download the CI logs, and trigger CI. We also gave it OCR registry credentials in order to list images in the in the registry to figure out, you know, what images are available, which are latest. Um we gave it tools like a go run time, python run time, a bunch of linters, static libs, a bash shell, network access, and all of that. Um So, this is what we gave the whole application. But again, we had like two layers, the deterministic part and the agentic part. And we also applied the split for the credentials also for the two different layers. So, here's the thing about the capability list. The dangerous ones, the get up right access, um and trigger UCI is something that we did not give the agent. Instead, we pushed um that functionality out to the deterministic part cuz that's the thing that we can reason about and we can rely on that um you know, it just does these kind of kind of actions and we do not give um the agent these kinds of credentials cuz that then fundamentally fundamentally limits the blast radius of when in case the agent gets um prompt injected prompt injected. So, that boundary really matters for the prompt injection case because you probably didn't see it in the screenshot earlier, but there was like 70,000 lines of code that were changed in that small PR. Um that's really like a lot of changes that come in just by bumping a couple of dependencies. Um and the attack surface is really really really wide. Um So, what we did to mitigate that, I guess like prompt injection itself isn't solved and we cannot really solve it. All we can do is just to limit the blast radius in case that happens. Um what we did is to do a little bit of prompt steering because we know what kind of directories or files contain untrusted um un untrusted um information, untrusted context. We just tell the agent, look, the vendor directory, just don't trust that. Or the CI logs which live in that file or in that subdirectory, you know, be sure that you don't, you know, be an idiot. Um there's another thing that we did um, which worked quite well, which is that we, um, we essentially implemented an end-to-end test where we created a repository and sent patch patch pilot added to just work on it. Um, I guess that's what people call eval's today and then we just, um, ensure that it isn't, um, prompt injected. So, we have like a deprecated function in there in the in our crafted repository which tries to recruit the agent to do some malicious stuff or we have a migration guide where it deprecated function, um, points at and all of that. So, we try to like, you know, remediate these kinds of, um, issues that we know about. But still there um, unknown, um, injection vectors which we aren't aware of yet. Um, so that's why, you know, we still have to pray a little bit. But at least we don't like build the whole system on on hope. Now, that's the bit that kept me awake at night. Um, Now, sandboxes look great on a slide. You just draw a box, put the agent in it and you feel secure, right? So, the problem is that at some point the agent really wants to, um, verify its own work. When it works with Docker files, it wants to build a Docker container. It might also want to run a Docker container in order to figure out what package versions are available and so on. So, naturally you give it that Docker socket. At that point, it's more or less game over for you, um, because the agent can then simply just spawn a privileged container, escape out of it and then, you know, read environment variables of other processes, read the memory of other processes, can plant SSH keys, it's game over for you essentially at this point. We run it like that in production at some point. Um, it didn't feel good. We moved off of that, um, and we evaluated all the other obvious options in like the Linux sphere Linux bubble when it comes to like sandboxing. There's a lot of technologies out there like landlock, bubble wrap, seccomp, u notify, fence, and a lot of functions that we have for unprivileged Docker builds, um Kaniko, uh buildkit, and and what else. But, they don't really compose well with containers, and none of them really can contain a Docker socket or a Docker um demon that runs on a host. So, let me share a design that we came up with, which is still like in its in its infancy. Um It's the same pattern. You just draw a box, but instead of calling it a sandbox, it's just a micro VM. In our case, we're using um using \[clears throat\] Firecracker to have a like a proper isolation mechanism. And then we put the agent in, we put the Docker socket in, and then the Docker socket is powered by its own kernel in this case. Um which is good because that really solves the issue with with the um Docker daemon or the agent trying to escape the sandbox. In this case, everything is just contained within that micro VM, which is good. There's another thing that is um worth mentioning in this case. Again, we have this two-tier architecture, this two layers, the agentic bit and the deterministic bit. And we also want to apply network policies to these two worlds separately. For the deterministic bit, we just know what kind of um um network access it requires in order to function properly. It needs GitHub access and what else. For the agent, we don't really know in advance. It kind of depends off on the kind of repository or language um it works on. When it uses Java, it needs like a completely different ecosystem it works with compared to Python or Go. Um so, that's why we really want to need to apply different network policies. Um so, that's what you can do. You can just set up a DNS and TCP forwarder inside that micro VM. But, other than that, just, you know, cut it completely off from the host system. And then everything has to flow through this um through this Vsock, which then um hands all the network packets to a host process which then applies the network policies to um to all the outgoing packets. And then you can apply, you know, rules based on host names, based on target ports, side ranges, whatever you like. If you really want to go wild, you can just, you know, set up a custom CA, plant it into the micro VM, and then do all sorts of like TLS man-in-the-middle control. Which is really hard to do, especially when it comes to the Docker socket, but um we're not going to dive into this one yet. So, my take on agent sandboxing is this, that the existing agent that we have today with Codex and Cloud, they come with their own sandbox, but in my opinion, it's worthless, especially when you give it um a a Docker socket access. It's just really yeah, it's not going to be able to contain that. Other agents like Open Code or Pi, they just don't have a sandbox because it's not implemented um or it's just not there by design. So, my take is that you really have to create a environment for an agent where you can just put it in and give it everything that it needs, um so it has like all the freedom to work on a particular issue that it's supposed to do. Um but there's still a gap. So, the diagram that I've just shown you isn't something unique. It's just a VM with a little bit of plumbing in there. You can just wipe code, it's not not a big deal, honestly. Um you can even go down sta- downstairs to the vendor booths and just, you know, talk to the vendors there. You have like a lot of sandbox as a service that you can easily consume. Some of which really lack in functionality, especially in that regards to like containing a Docker socket or having a proper network access controls. That's still lacking, but it differs from vendor to vendor. I also recently saw the um micro sandbox project, um which has now run for, I think, like three or four months or so, maybe even longer, um which really is would be my choice if I would build patch pilot today again because it comes with all the batteries included, network access controls, um all of that. So, keep that in mind if you really want to build this. Um it's an open source project. It has It has a community. It's currently funded by YC. Um so, we really don't really know how it how it goes in the next couple of months. We're going to see um if they're able to gather enough traction to to keep the open source project afloat. Let's see. So, the gap isn't the tool doesn't exist. All the tools do exist, but most of them are still in the beta phase. And there's still a big gap to, you know, getting actual enterprise traction and getting all the features, all the bells and whistles that you need in order to deploy it into a proper enterprise environment. And I think that's something that we need to work on. Sure, now we got a sandbox. Cool. That's nice, but we still need like a lot of orchestration on top of it, which is something that you can take from a vendor. There are also like a couple of open source project at the moment which are working on this. There's the Kubernetes um agent sandbox uh special interest group that's working on this. There's um open sandbox which also working on this to integrate these kind of things. So, um keep that in mind if you really want to, you know, contain an agent in a production environment. It's not there yet. It's beta. It's very early in the in the phase. We're going to see how it goes. All right. If you take one thing from this, um the blast radius of an agent is an architecture decision. We didn't um give the agent the credential that it needs um in order to, you know, trigger CI or push to GitHub or open a PR. That's just simply not needed. You can just push that functionality in functionality into a deterministic layer. Um that kind of really limits the blast radius of an agent. So, that choice, what's that what's deterministic and what's agentic, that really is, you know, your security model in this case. All right. Um that was it for me. I just have like one last word, which is just an invitation to the community just to talk about the things that I just mentioned. Um I think tomorrow there's a a dedicated uh sandbox panel where a lot of talks are just around the sandbox thingy. And surely I want to know from you guys how you run agents in production just to learn and to have a discussion about that in order to, you know, bring the community on and just just figure it out um all together. Thank you. \>\> \[applause\]