Robert Brennan, co-founder and CEO of OpenHands, argues that coding agents should run in sandboxes following the principle of least privilege, since running agents locally with skipped permissions exposes every file, secret, and credential the user can access. He traces the evolution of AI-driven development from ChatGPT snippets to local and cloud agents, then compares four sandboxing strategies: Docker on a laptop, Claude Code in GitHub Actions, a dedicated VM or Mac Mini, and a Kubernetes pod per session — rating each on local vs remote operation, scale, isolation, persistence, and triggers. He covers why sandboxes are not a cure-all (including container escapes) and closes with a look at OpenHands Agent Canvas. Recorded at AI Engineer World's Fair 2026, San Francisco. # Video Identity Observations: "Sandboxes Aren't Optional: 4 Ways to Isolate Coding Agents — Robert Brennan, OpenHands" ## Speaker & Self-Description - **Explicit identity claim**: The speaker introduces himself directly: *"my name is Robert Brennan. Uh I'm the CEO at Open Hands"* — a founder-led, first-person presentation. - **Company origin story as stated by the creator**: *"co-founded it a little over 2 years ago, really with the vision of bringing uh coding agents to the community... really giving software developers a say in the gigantic change that's happening to our jobs."* - **Product scope claim (creator's own framing)**: OpenHands began as *"an MIT licensed coding agent"* and has *"evolved really to a a platform for running coding agents. Everything from the harness to the infrastructure to the control plane to actually like monitor these agents at scale."* - **Product promotion demonstrated**: The talk ends with a direct product plug: *"a quick plug for Open Hands Agent Canvas"* — positioned as a way to toggle between Docker, VM, and Kubernetes sandboxing *"with one quick toggle."* ## Intended Audience (observable from content and address) - **Professional software developers and engineering organizations**, evidenced by: - Assumed familiarity with tools: *"Who here runs Claude code on their laptop or code acts or open hands"* — with live audience hand-raising. - Escalating audience framing from individual developers (*"most developers today are still... running something like Claude code... as a pair programmer model"*) to organizations: *"The leap that we're seeing organizations make over the course of 2026."* - **Practitioner-level technical depth**: Uses unexplained jargon freely (Kubernetes pods, MCP servers, cron jobs, webhooks, `rm -rf`, `dangerously skip permissions`), implying an expert audience rather than a general one. - **Conference setting**: Audience applause, Q&A offer (*"happy to to take questions from the audience"*), and interactive polls confirm a live developer-conference context. ## Claimed Scope (creator's own framing) - The talk claims a **practical engineering taxonomy**, not a product pitch alone: four sandboxing strategies compared — *"running inside of Docker containers on their laptop"*, *"glue together Cloud Code and GitHub Actions"*, *"a separate computer, you know, a virtual machine in the cloud or maybe a Mac mini"*, and *"Kubernetes or some other... highly scalable environment that's ephemeral."* - Explicit evaluation criteria offered for the audience: *"is it local or is it remote... What kind of scale... Level of isolation... level of persistence... what kinds of triggers."* - Includes **caveated, non-absolute claims**: *"sandboxing is not a panacea... There are container escape attacks out there"* — with a reference to an Anthropic test where an instance *"managed to break out of its sandbox."* ## Distinguishing Claims from Demonstrated Patterns | Type | Evidence | |---|---| | **Creator claim** | OpenHands is a full platform ("harness to... control plane") | | **Creator claim** | Kubernetes is "the most robust strategy" | | **Demonstrated pattern** | Balances vendor-neutral framework (principle of least privilege) with product promotion | | **Demonstrated pattern** | Historical narrative framing (chatbots → IDEs → agents → cloud agents → multi-agent → "full SDLC automation") | ## Notes for Channel-Level Synthesis - This is **thought-leadership content with a soft commercial close** — the bulk is educational, with the product plug reserved for the final minutes. - The speaker positions the channel/brand as an **authority on agent infrastructure and security practices**, not merely a product vendor. - Claims about the future ("full SDLC automation where... humans aren't even looking at the source code") are explicitly speculative framing by the creator, not demonstrated fact. # Delivery Observation: Robert Brennan — "Sandboxes Aren't Optional" ## Tone & Register - **Conversational and explanatory**, closer to a walkthrough than a formal lecture. Sentences often trail into relaxed clarifications: *"And that's kind of where we're at today."* - **Frequent hedging softeners** shape the delivery: *"like," "you know," "kind of," "really,"* appear throughout — e.g., *"this is kind of where we're at today," "the end game is really this full SDLC automation."* - Uses **audience-directed humor and asides**, e.g., the laptop anecdote: *"If you've ever been like biking home with your laptop open cuz you didn't want Claude code to shut down, this is a great reason to start moving your agents to the cloud."* ## Vocabulary - **Security and infrastructure framing dominates**: *"blast radius," "principle of least privilege," "ephemeral," "sandbox," "isolated environments," "container escape attacks."* - **Trade-off language is a signature move**: *"this is good and bad, right?", "the big trade-off when running agents locally," "it's nice because... but this doesn't really scale very well."* - Repeated **risk-scenario imagery**: the agent might *"delete a file you really care about or access your production database,"* agents *"step on each other's toes,"* agents *"run wild."* ## Recurring Phrases & Habits - **Tag question "right?"** is the most frequent verbal tic, used to invite agreement after nearly every claim: *"bringing coding agents to the community, right?", "It has built-in, uh, secrets registry... you get these nice isolated environments. And what's really cool is now you can run them on a schedule, right?"* - **Enumerated structure**: strategies are numbered explicitly ("first strategy... next strategy... fourth and really the most robust strategy"), and the comparison is framed as *"I'll just go down the the things that I look at."* - **Balanced pros/cons pattern per option**: each of the four strategies is introduced, praised ("what's nice is that..."), then qualified ("But you're locked in to GitHub actions, right?"). ## Teaching Habits - **Historical progression framing**: opens with an evolution arc — chatbot snippets → AI IDEs → agents → cloud agents — anchoring the current problem in a timeline (*"I remember the first time I typed in a ChatGPT... and it just like one-shotted it and I was blown away."*). - **Live audience checks**: *"Who here runs Claude code on their laptop...? All right. Fewer than I would expect. Keep your hand raised if you use dangerously skip permissions. Yeah, okay. Somehow more hands than before."* - **Grounding abstract concepts in a known prior concept**: maps sandboxing onto *"the principle of least privilege... a paradigm that we actually know well from pre-agent security days."* - **Concrete, tactile examples** over abstractions: *"every Monday morning at 9:00 a.m. and updates your dependencies," "runs rm -rf and deletes everything, you just kill the container."* - **Closes with a product tie-in plus explicit caveats**: acknowledges limits before pitching (*"sandboxing is not a panacea... it's not perfect"*) — a hedged, credibility-preserving promotional move. ## Uncertainty - The transcript shows **audience laughter/snorting cues** ([snorts] at [35], [492], [581]) but the actual joke content is not visible, so humor style can't be characterized beyond the one laptop anecdote. - The **"right?" tag** is clearly frequent, but exact counts are unreliable given transcription artifacts; it is described here as a dominant habit, not a measured frequency. - Single-occurrence moves (the Anthropic/Mythos anecdote, the bike-home story) are noted as isolated moments, not stable patterns. # Observation Record: Sandboxes Aren't Optional — 4 Ways to Isolate Coding Agents **Speaker:** Robert Brennan, CEO at OpenHands (self-identified in transcript) **Source basis:** Verbatim transcript only. --- ## Speaker Background (as stated) - Self-described CEO and co-founder of OpenHands, founded "a little over 2 years ago" - Started as an MIT-licensed coding agent; has "evolved really to a platform for running coding agents" — harness, infrastructure, and control plane for monitoring agents at scale - Framed mission: giving software developers "a say in the gigantic change that's happening to our jobs" --- ## Stated Trajectory of AI-Driven Development Brennan presented a staged history (explicitly framed as his view of where things are going): 1. **Chatbot code snippets** — e.g., asking ChatGPT to "write a SQL query"; he described his early copy/paste-into-IDE workflow as "kind of dumb" 2. **AI-powered IDEs** (Cursor, GitHub Copilot) — autocomplete with codebase context 3. **Agents** (the "big leap in beginning of 2024") — AI that runs code it writes, reads errors, Googles them; most developers today run local agents (Claude Code, OpenHands, Codex) as pair programmers 4. **Cloud agents (2026 transition)** — agents running in the cloud, requiring sandboxing for both workspace provisioning and access control ("there's not necessarily going to be a human there to babysit them") 5. **Multi-agent teams** — agents interacting (one opens a PR, another reviews) 6. **"End game": full SDLC automation** — "humans aren't even looking at the source code anymore" --- ## Core Security Argument - **The local trade-off:** either manually approve every action ("yes, yes, yes") or use `dangerously skip permissions` and trust the agent - **Local exposure in skip-permissions mode:** the agent has access to "basically everything that you have access to" — full file system, environment variable secrets, home-directory secrets, production databases, Kubernetes clusters - **Governing principle:** *principle of least privilege* — "both agents and humans should only have access to the things that they need in order to do their job" - **Rationale:** limiting access limits the "**blast radius**" of a prompt injection attack or agent error --- ## The Four Isolation Strategies (with stated pros/cons) ### 1. Docker containers on a laptop - How OpenHands originally launched: new container per conversation - **Pros:** ephemeral (an `rm -rf` just means restarting the container); selective mounting of repos, ports, secrets, MCP servers; agent works on your local copy of the code - **Cons:** limited container count; laptop can't listen for external events (Slack, DataDog) ### 2. Claude Code + GitHub Actions - **Pros:** scale limited only by willingness to pay; built-in secrets registry; schedulable (weekly dependency updates, PR-review-on-open automation) - **Cons:** "locked in to GitHub actions" — a "proprietary standard" that can't be ported and can only respond to GitHub events, not Slack or DataDog webhooks ### 3. Dedicated machine / VM (described in the context of the "OpenClaw craze") - A VM or Mac mini hosting all agents - **Pros:** long-lived environment with persistence; agents can run on schedule and listen for webhooks (Twilio, Slack, DataDog, GitHub) - **Cons:** persistence "good and bad" — machines can get into a bad state requiring debugging; **co-location problem**: all agents share access, e.g., "the code review agent now for some reason has access to DataDog" and "can even edit the memory for the DataDog bot" ### 4. Kubernetes / ephemeral scalable environments (called "the most robust strategy") - One pod per agent session; spins up, runs, opens a PR, spins down - **Pros:** no long-lived state degradation; "an infinite amount of scale" (cloud scale); per-agent isolation; cron scheduling; responds to HTTP events (Slack, GitHub, Jira) — "fully automatic" operation --- ## Comparison Criteria (Brennan's stated evaluation axes) | Axis | Range described | |---|---| | Local vs. remote | Laptop/local copy vs. cloning code remotely | | Scale | "Ones of agents" locally vs. "thousands" on Kubernetes | | Isolation | "Nothing" (local skip-permissions) → co-located VM agents can "step on each other's toes" → per-agent workspaces on Kubernetes | | Persistence | Default on laptop/VM; obtainable elsewhere via external systems | | Triggers | Manual prompting locally; schedules and events in the cloud | > Anecdote (self-reported): "If you've ever like been biking home with your laptop open cuz you didn't want Claude code to shut down, this is a great reason to start moving your agents to the cloud." --- ## Stated Caveat: Sandboxing Is Not a Panacea - Brennan explicitly qualified his advocacy: "**sandboxing is not a panacea**" - Cited an Anthropic test of "Mythos" in which "one of the Mythos instances actually managed to break out of its sandbox, gain internet access or doing other things" - Noted known container escape attacks, especially on old Docker versions - Conclusion drawn: "It's not perfect. You still have to be a little bit careful. But it is at least a good first pass at keeping agents limited to what they should be doing." --- ## Product Plug (self-acknowledged as a plug) - **OpenHands Agent Canvas:** designed to switch between sandbox types via toggles — local skip-permissions by default, then Docker, remote VM, or Kubernetes - Stated rationale: sometimes you want local iterative development; sometimes you want autonomous background runs in Kubernetes or a VM — "pick the right environment for the job" --- ## Observations on Tensions in the Talk - Brennan advocates strongly for sandboxing and Kubernetes isolation while **simultaneously qualifying** that sandbox escapes occur and that his own product defaults to local `dangerously skip permissions` mode - The least-privilege principle is presented as well-established ("paradigm that we actually know well from pre-agent security days") yet all four strategies described fall short of it in some way per his own analysis # Speaker & Provenance Record — Video `01a15ca6-9f0c-7870-a0ba-40378ff098aa` ## Title **"Sandboxes Aren't Optional: 4 Ways to Isolate Coding Agents — Robert Brennan, OpenHands"** ## Speakers & Roles | Speaker | Role | Basis | |---|---|---| | **Robert Brennan** | **Creator / Presenter** — self-identified as "CEO at Open Hands" | Explicit in transcript: *"my name is Robert Brennan... I'm the CEO at Open Hands"* | | Audience | Third party — unnamed, present via Q&A invitation and raised-hand moments | Transcript notes applause and audience hand-raising; **no audience questions are captured** in the supplied transcript | - Single-speaker talk; the transcript's `\>\>` markers denote speaker turns but **no second named speaker appears**. - Off-microphone audience reactions (`[snorts]`, `[applause]`) are noted but contain no attributable content. ## Speaker Self-Description (first-person claims, unverified) - CEO and co-founder of Open Hands, co-founded *"a little over 2 years ago"* - Open Hands began as an **MIT-licensed coding agent** and has evolved into a platform (harness, infrastructure, control plane) ## Referenced Sources & Third-Party Claims All claims below originate from the speaker; no cited documents, papers, or external data sources are given. - **Anthropic / "Mythos"**: Speaker claims that during Anthropic's testing, *"one of the Mythos instances actually managed to break out of its sandbox, gain internet access"* — no citation or source provided. - **Container escape attacks**: Stated to exist, particularly on *"an old version of Docker"* — generic claim, no specific CVE named. - **Named tools/products mentioned**: ChatGPT, Cursor, GitHub Copilot, Claude Code, Codex ("code acts" / "Code X" per transcript), GitHub Actions, Docker, Kubernetes, Slack, DataDog, GitHub, Jira, Twilio, Open Hands Agent Canvas. - **Audience polls**: Informal raised-hand polls about running local agents and using "dangerously skip permissions" mode — anecdotal, no data recorded. ## Promotional Segments — ⚠️ Flagged - **Explicit promotion of Open Hands Agent Canvas** in the closing section: the speaker self-identifies it as *"a quick plug"* — a product pitch for toggling between Docker, VM, and Kubernetes sandbox environments. - Ongoing soft promotion of OpenHands throughout (company history, product positioning as MIT-licensed and community-oriented). ## Availability & Interaction Limits - Speaker invites audience questions (*"happy to take questions"*), but **no Q&A content is included** in the transcript. - No metadata supplied regarding comments, transcripts in other languages, or chapter markers. ## Uncertainty Notes - "Mythos" claim could not be verified from the transcript alone; recorded as speaker assertion only. - Transcript contains speech-to-text artifacts (e.g., "open claw," "code acts," "Code X") — likely referring to OpenClaw/Claude and Codex; flagged as transcription ambiguity, not speaker error. \>\> Uh my name is Robert Brennan. Uh I'm the CEO at Open Hands. Uh and I want to talk to you a little bit about today about uh sandboxing coding agents. Uh why this is a really important pattern and uh different ways to actually get this done. Uh a little bit about me. Um like I said, I'm the I'm the CEO of Open Hands, uh co-founded it a little over 2 years ago, really with the vision of bringing uh coding agents to the community, right? Uh really giving software developers a say in the gigantic change that's happening to our jobs. \>\> \[snorts\] \>\> Uh and we started Open Hands as an MIT licensed coding agent. Uh and I would say now we've we've evolved really to a a platform for running coding agents. Everything from the harness to the infrastructure to the control plane to actually like monitor these agents at scale. Uh a little bit about the history of AI-driven development and how we got to where we are today and, you know, where I think things are going in the future. Uh we really started with like uh code snippets being generated by a chatbot, right? I remember the first time I typed in a ChatGPT like, "Write a SQL query that does X." and it just like one-shotted it and I was blown away. Uh that feels very um antiquated today. Um but uh you know, my my original workflow was a lot of like type in a ChatGPT, paste something into my IDE, hit enter, paste an error message back in a ChatGPT. And it's pretty quick that I realized like, "Hey, this is kind of dumb. I can just like wire some APIs together." Uh and very quickly we got uh these AI-powered IDEs, stuff like Cursor and GitHub Copilot, doing things like autocomplete, right? Where now you have the context of the code base, you're not just generating code snippets inside of a chat window, you're actually modifying the code itself. You can see the variable names that are available there. So, the AI gets a little bit smarter, a little bit more context-aware. And then the big leap in like beginning of 2024 uh was this leap to agents. So AI that wasn't just writing code, but was actually running the code that it wrote, right? Actually like looking at the error messages, Googling them, really doing that entire loop of development on top of the LLM. And that's kind of where we're at today. I would say most developers today are still they're running something like Claude code or open hands or code acts on their laptop. As a kind of a pair programmer model, right? They're manually prompting this thing. The leap that we're seeing organizations make over the course of 2026 is really to agents that run in the cloud. And this is really where sandboxing comes into play. One because you know, it needs a place to work in the cloud, right? You need to give this agent a terminal, a file system, etc. But two because you're really you're able to do a lot more once you've got these agents in the cloud, right? And you need to make sure that they have access only to the things that they're they're allowed to access cuz there's not necessarily going to be a human there to babysit them, right? Going forward from there, I think the more we get agents running in the cloud, running autonomously, running you know, in response to events coming out of systems like GitHub and DataDog and Slack rather than being manually prompted, you're going to get these interactions between agents where like one agent opens a PR, another's doing code review and they're going back and forth. We see these multi-agent teams emerging. And then I think the end game is really this full SDLC automation where you know, humans aren't even looking at the source code anymore. But the really thing I really want to talk today about is how do we make this leap from from number three where we're running agents on our machine to number four where we've got agents running in the cloud? Let's talk a little bit about running locally. Who here runs Claude code on their laptop or code acts or open hands, something some local agent? All right. Fewer than I would expect. Keep your hand raised if you use dangerously skip permissions. Yeah, okay. Somehow more hands than before. So that the is the big trade-off when running agents locally, right? Is you can either sit there and hit like yes, yes, yes, you're allowed to do that over and over again and babysit the agent while it works, or you can go into dangerously dangerous to skip permissions mode and just like trust that the agent isn't going to delete a file you really care about or access your production database or anything like that, right? Um, so running locally, you you are kind of limited by those those two options. Uh, and if you do run locally and you run with dangerously skip permissions, uh, the agent does have access to a lot of things, right? It has access to your whole local file system, uh, it has access access to any secrets that are in your environment variables, uh, it has access to any secrets that are in like in your in your home directory, uh, if you're connected to like a production database or a production Kubernetes cluster, the agent can get in there. It has access basically to everything that you have access to, right? Um, so super important that you, uh, either sit there and babysit it and watch what it's doing or you find a way to cut off its access and really only give it access to the things that it needs. And this is a this is a paradigm that we actually know well from, you know, pre-agent security days is the principle of least privilege, right? The idea is that both agents and humans should only have access to the things that they need in order to do their job, right? So the agent shouldn't have access to every secret on your system, it shouldn't have access to every file on your system, should only have access to the GitHub repo that it's editing and maybe a couple secrets that it needs to access a local database, something like that. Um, so it's important when we start to sandbox these agents that we're looking at what exactly does this agent need in order to do its job? And then we can create a sandbox that has just exactly those things. And then we know that the the blast radius of a prompt injection attack, uh, or the agent getting confused, anything that could go wrong, like we we limit the blast radius by limiting how much the agent has access to. So the first strategy that folks tend to experiment with is running inside of Docker containers on their laptop. This is actually the way we originally launched Open Hands was as an interface where every time you started a new conversation with the agent, we'd spin up a brand new Docker container. The agent would get its own its own container. And this this works really nicely for several things, right? One, it's ephemeral. So, the agent can do kind of whatever it wants. If it runs rm -rf and deletes everything, you just kill the container and start again, right? It's It's a very nice The agent can can just kind of run wild. You don't have to worry too much about what it's going to do. And because it's running locally on your laptop, you can also mount in things selectively from your local file system, you know, like a Git repo. You can mount ports so that the agent can run out an application and you can view it in your browser. You can mount specific secrets and environment variables for the agent. You can have MCP servers either running locally on your laptop or inside the Docker container. And it's nice because the agent is still working with like your local copy of the code, right? It's similar to how you're used to working where you've got like a copy of the code on your workstation. And instead of you editing it, the agent's editing it now and you're deciding when to get pushed and all that. But this doesn't really scale very well. There's only so many Docker containers you can get running on a laptop. Your laptop can't like listen for events coming out of like Slack and DataDog, etc. So, this this is pretty limited in terms of what you can do here. The next strategy we see folks taking is starting to like glue together Cloud Code and GitHub Actions. This is definitely different from like running Docker containers on your computer. Now you're no longer working with your local copy of the code base. You're now, you know, having this this agent inside of a like an ephemeral environment somewhere inside of GitHub Actions, cloning the repo, doing stuff, you know, and then like shipping it off and then everything everything goes away once that action spins down. But what's nice is that, you know, you can run as many GitHub Actions as you're willing to pay for. Right? It has built-in in for things like a secrets registry. So, you get these nice these nice isolated environments. And what's really cool is now you can run them on a schedule, right? You can just have a GitHub action that spins up an agent, you know, every Monday morning at 9:00 a.m. and updates your dependencies, right? You can have a GitHub action that anytime a PR gets opened is going to use an agent to do code review. So, you can start to get some automation in place now that the agents are are off your laptop and in the cloud. But you're locked in to GitHub actions, right? This is a proprietary standard. You're not going to be able to really port this. It's only able to respond to events coming out of GitHub, right? You can't respond to like a Slack webhook or a DataDog webhook. So, you're you're kind of limited in terms of what you can do by just like gluing things together with GitHub actions. \>\> \[snorts\] \>\> The next strategy we saw folks take was kind of in the open claw craze where you actually get a separate computer, you know, a virtual machine in the cloud or maybe a Mac mini and just put all your agents on that, right? This is different from GitHub actions in that now you've got a long-lived environment. You've got persistence, right? Which is good and bad, right? You you your agents can modify the system and know it's going to be that way again when they run, you know, 2 days from now. But your machine could get into a bad state as well and you might have to go and debug and figure out what's going on. You can again you can just like in GitHub actions you can run agents on a schedule. Now since if you're on a running on a VM you can actually listen for webhooks coming in from you know, Twilio if you want to listen for text messages from Slack. You can listen for incidents coming out of DataDog, events coming out of GitHub. So, you get agents running automatically now. But you still have this principle of least privilege problem, right? Where all of your agents are now like co-located in this virtual machine and they all have access to the same stuff. So, you might have like a a code review agent in there alongside of you know, a DataDog triage like incident triage bot and the code review agent now for some reason has access to DataDog and there's just a lot more possibility for things to go wrong, right? The code review bot can even like you know, edit the the memory for the DataDog bot. So, like there's this co-locating problem quickly runs into issues where agents have access to way more than they necessarily need in order to do their job. So, way more opportunities for things to go wrong when all these agents are bumping into each other. \>\> \[snorts\] \>\> The fourth and and really like the most robust strategy here, I would say is to use Kubernetes or some other like, you know, highly scalable environment that's ephemeral, right? And now you're getting, you know, with Kubernetes say you get a pod for every agent session you want to run. Spins up, the agent runs, does its work, you know, maybe working on a local copy of the of the repo. Then it spins down and all that environment goes away, you know, the agent has opened up a pull request or something like that, right? This is really nice because you don't have to worry about like the long-term state of this thing the way you do with a VM. You don't have to worry about it getting into a bad state because every time an agent runs, you're you're basically killing the environment and starting fresh. And you get like an infinite amount of scale, right? You're you have cloud scale at this point. You can run as many agents as you want as long as you're again willing to pay for the memory and CPU to run them. And again, because it's it's Kubernetes, it's running in the cloud. You can respond to You can run things on a schedule using cron jobs. You can run things in response to HTTP events coming out of, you know, Slack and GitHub and Jira. You can basically run agents fully automatically. A little kind of like quick comparison here. I'll just go down the the the things that I look at when I'm comparing these different strategies. One is is it local or is it remote, right? Is it on your on your laptop working with your copy of the code base or is it running somewhere else that has to like clone in the code itself or with its own copy. Those are two very different ways of working. What kind of scale can you get out of this thing, right? If you're if you're running locally on your laptop, you can maybe run ones of agents before things start getting uncomfortable. If you're in Kubernetes, you can run thousands. Level of isolation, right? If you're not running if you're running like dangerously skip permissions on your laptop, you've got nothing. Uh, if you've got all your agents like co-located in a VM, they're separated from your environment, but they can still step on each other's toes. But something like Kubernetes, uh, every agent has its own workspace, you know, it's it's doing its own thing. Uh, level of persistence. Um, you know, you can you can always get some persistence by saving files out or like writing to external systems. Uh, but when you're working on your laptop or you're working in a VM, you do get just like persistence by default, right? That system is long-lived. Um, and then what kinds of triggers can actually cause these agents to run, right? If you're running locally on your laptop, it's typically just going to be a manual, you're typing in a prompt. Uh, once you get into the cloud, you can start to run things on a schedule or run things in response to events. Uh, if you've ever like, uh, been like biking home with your laptop open cuz you didn't want Claude code to shut down, this is a great reason to start moving your agents to the cloud. Uh, I did want to, uh, touch on the fact that sandboxing is not a panacea. Um, there is, uh, evidence of agents escaping their sandboxes. Um, you know, here we we saw during, uh, one when Anthropic was te- testing Mythos, uh, one of the Mythos instances actually managed to break out of its sandbox, gain internet access or doing other things. There are container escape attacks out there. Um, some of them are known if you're running an old version of Docker, say. Um, so it's not it's not perfect. You still have to be a little bit careful. Um, but it is it is at least a a good first pass at keeping agents limited to, uh, what they're what they should be doing. Um, last I'll give a quick plug for Open Hands Agent Canvas. Um, this is a way, you know, really to run, uh, with any type of sandbox. You can run it with Claude code or Code X or the Open Hands harness. Um, but we've designed it really to, you know, by default if you saw it on your laptop, it's like running Claude code with dangerously skip permissions. But with one quick toggle, you can start running things in Docker containers. Another toggle, you can start running it in a remote VM. Another toggle, you can run it inside of Kubernetes. Um so, it's a really great way to like pick the right environment for the job. Right? Sometimes you really do want to be working with your local copy of the code base. You want to be doing that quick iterative development back and forth with an agent where you're looking at the code locally. Sometimes you really just want to fire off events that, you know, let agents run autonomously in the background for a few hours. Um you really want it running inside of Kubernetes or inside of a VM. Um so, this is a a great way to kind of move between these different types of environments. Uh that's all I've got, but I'm happy to to take questions from the audience. \>\> \[applause\]