Sandboxes não são opcionais: 4 maneiras de isolar agentes de programação — Robert Brennan, OpenHands

Ver no idioma original →

Autoria: AI Engineer · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: Sandboxes Aren’t Optional: 4 Ways to Isolate Coding Agents — Robert Brennan, OpenHands · Canal: AI Engineer · 13:58 · Assistir no YouTube

Tópicos: Agentes de IA, Engenharia de software com IA, Infraestrutura e hardware de IA, Segurança de IA

Resumo

Robert Brennan explica por que o isolamento é essencial quando agentes de programação passam a trabalhar na nuvem, sem supervisão humana constante. Ele compara quatro abordagens: contêineres Docker locais, GitHub Actions, máquinas virtuais persistentes e ambientes efêmeros como Kubernetes. Cada opção oferece diferentes níveis de isolamento, persistência, escala e suporte a gatilhos automáticos. Sandboxing não elimina todos os riscos, mas ajuda a aplicar o princípio do menor privilégio; o OpenHands Agent Canvas facilita alternar entre ambientes.

Pontos-chave

• Agentes que atuam autonomamente na nuvem precisam de acesso limitado aos recursos necessários para cada tarefa.
• O princípio do menor privilégio reduz o impacto de ataques de prompt injection e de erros do agente.
• Contêineres Docker locais oferecem ambientes efêmeros e acesso seletivo a arquivos e recursos, mas têm escala limitada.
• GitHub Actions permite automações programadas e acionadas por eventos do GitHub, mas restringe a integração a esse ecossistema.
• Máquinas virtuais persistentes podem receber eventos de vários serviços, mas agentes compartilhando o mesmo ambiente podem acessar recursos uns dos outros.
• Kubernetes permite criar um ambiente efêmero e separado para cada sessão de agente, com alta capacidade de escala.
• Sandboxing não é infalível: agentes podem escapar de ambientes isolados, portanto ainda é necessário ter cautela.
• O OpenHands Agent Canvas permite alternar entre execução local, Docker, máquinas virtuais remotas e Kubernetes.

Capítulos

Início	Capítulo	Resumo
00:01	A evolução dos agentes de programação	Robert Brennan apresenta a trajetória das ferramentas de IA para programação e a migração de agentes locais para agentes na nuvem.
03:37	O risco de executar agentes localmente	O palestrante explica que agentes locais podem ter acesso amplo ao sistema e defende limitar esse acesso pelo princípio do menor privilégio.
05:40	Quatro estratégias de isolamento	A palestra compara contêineres Docker locais, GitHub Actions, máquinas virtuais persistentes e ambientes efêmeros em Kubernetes.
10:51	Comparação e limites do sandboxing	Brennan compara escala, isolamento, persistência e gatilhos, e ressalta que sandboxes não impedem todas as formas de escape.
12:56	OpenHands Agent Canvas	O palestrante apresenta uma ferramenta para alternar entre diferentes ambientes e conclui a apresentação.

Citações

Tanto agentes quanto pessoas devem ter acesso apenas às coisas de que precisam para fazer seu trabalho. — 04:38

Podemos criar um sandbox que tenha exatamente essas coisas. — 05:09

Sandboxing não é uma panaceia. — 12:25

Às vezes você realmente quer trabalhar com sua cópia local do código. — 13:27

Conceitos e entidades

• sandboxing (conceito): Isolamento de agentes em ambientes delimitados para restringir seu acesso a arquivos, segredos e outros recursos.
• principle of least privilege (conceito): Princípio de segurança segundo o qual agentes e pessoas devem ter acesso apenas aos recursos necessários para realizar seu trabalho.
• coding agents (conceito): Agentes que executam tarefas de desenvolvimento, como modificar código, rodá-lo e reagir a erros.
• Docker (ferramenta): Tecnologia usada para executar agentes em contêineres isolados e descartáveis.
• GitHub Actions (ferramenta): Serviço usado para executar agentes em ambientes efêmeros, com automações programadas ou acionadas por eventos do GitHub.
• Kubernetes (ferramenta): Plataforma que pode criar um pod isolado e efêmero para cada sessão de agente, com capacidade de escala na nuvem.
• OpenHands (empresa): Organização cofundada por Robert Brennan que desenvolve agentes e uma plataforma para executá-los.
• OpenHands Agent Canvas (ferramenta): Ferramenta apresentada para alternar entre diferentes ambientes de execução de agentes, incluindo Docker, máquinas virtuais remotas e Kubernetes.
• Robert Brennan (pessoa): CEO e cofundador da OpenHands, que apresenta abordagens para isolar agentes de programação.
• Claude Code (ferramenta): Agente de programação citado como exemplo de ferramenta que pode ser executada localmente ou em ambientes isolados.

Tradução completa (pt-BR)

00:01 [música] >> Meu nome é Robert Brennan. Sou CEO da Open Hands. E hoje quero falar um pouco sobre sandboxing de agentes de programação: por que esse é um padrão muito importante e diferentes maneiras de colocá-lo em prática. Um pouco sobre mim. Como eu disse, sou CEO da Open Hands, que cofundei há pouco mais de dois anos

00:33 atrás, com a visão de levar agentes de programação à comunidade, certo? Queríamos mesmo dar aos desenvolvedores de software voz na enorme transformação que está acontecendo no nosso trabalho. >> [fungada] >> Começamos a Open Hands como um agente de programação licenciado sob a licença MIT. E eu diria que agora evoluímos para uma plataforma para executar agentes de programação. Tudo, desde o harness até a infraestrutura e o plano de controle, além do monitoramento desses agentes em escala. Um pouco sobre a história do desenvolvimento impulsionado por IA, como chegamos até

01:03 aqui e para onde acho que as coisas vão no futuro. Começamos com trechos de código gerados por um chatbot, certo? Lembro da primeira vez que digitei no ChatGPT algo como: “Escreva uma consulta SQL que faça X”, e ele resolveu de primeira. Fiquei impressionado. Hoje isso parece bem ultrapassado. Mas meu fluxo de trabalho original consistia muito em digitar algo no ChatGPT, colar no meu IDE, apertar Enter e colar uma mensagem de erro de volta no ChatGPT. E logo percebi: “Ei, isso é meio idiota. Posso simplesmente conectar algumas APIs.”

01:34 E muito rapidamente surgiram IDEs com IA, como Cursor e GitHub Copilot, fazendo coisas como preenchimento automático, certo? Agora, eles têm o contexto da base de código. Você não está apenas gerando trechos de código em uma janela de conversa: está modificando o próprio código. É possível ver os nomes das variáveis disponíveis ali. Assim, a IA fica um pouco mais inteligente e um pouco mais consciente do contexto. Então, a grande mudança, no início de 2024, foi a transição para agents. Uma IA que não apenas escrevia código, mas também executava o código que escrevia,

02:05 certo? Ela realmente examinava as mensagens de erro, pesquisava na internet e fazia todo esse ciclo de desenvolvimento usando o LLM. E é mais ou menos onde estamos hoje. Eu diria que a maioria dos desenvolvedores ainda executa algo como Claude Code, OpenHands ou Codex no próprio laptop, num modelo de programação em dupla, certo? Eles dão prompts manualmente para a ferramenta. A mudança que estamos vendo as organizações fazerem ao longo de 2026 é migrar para agents executados na nuvem. E é aí que o sandboxing entra em cena.

02:36 Primeiro, porque é preciso ter um lugar para trabalhar na nuvem, certo? É preciso dar a esse agent um terminal, um sistema de arquivos e assim por diante. Segundo, porque é possível fazer muito mais quando esses agents estão na nuvem, certo? E é preciso garantir que eles só tenham acesso às coisas a que têm permissão, porque talvez não haja uma pessoa ali para ficar supervisionando, certo? Daí em diante, acho que, quanto mais agents executarmos na nuvem de forma autônoma, reagindo a eventos vindos de sistemas como GitHub, DataDog e Slack, em vez de receberem prompts manualmente,

03:07 teremos interações entre agents: um agent abre um PR, outro faz a revisão de código, e eles vão trocando informações. Estamos vendo equipes multi-agent surgir. E acho que o objetivo final é automatizar todo o SDLC, de modo que os humanos nem sequer olhem mais para o código-fonte. Mas o que realmente quero discutir hoje é como fazemos essa transição do número três, em que executamos agents na nossa máquina, para o número quatro, em que temos agents sendo executados na nuvem. Vamos falar um pouco sobre a execução local. Quem aqui usa Claude Code no

03:37 laptop, ou Codex, ou OpenHands, algum agent local? Certo. Menos gente do que eu esperava. Mantenham a mão levantada se vocês usam a opção de ignorar permissões perigosamente. É, certo, de algum modo há mais mãos do que antes. Essa é a grande desvantagem de executar agents localmente, certo? Ou você fica ali apertando “sim, sim, sim, pode fazer isso”, repetidamente, e supervisiona o agent enquanto ele trabalha, ou ativa o modo de ignorar permissões de forma perigosa e simplesmente confia que o agent não vai apagar um

04:08 arquivo importante para você nem acessar seu banco de dados de produção ou algo assim, certo? Então, ao executar localmente, você fica meio limitado a essas duas opções. E, se executar localmente com a opção de ignorar permissões perigosamente ativada, o agent terá acesso a muitas coisas, certo? Ele terá acesso a todo o sistema de arquivos local, a quaisquer segredos nas variáveis de ambiente, a quaisquer segredos no seu diretório pessoal e, se você estiver conectado a um banco de dados de produção ou a um cluster Kubernetes de produção, o agent poderá entrar

04:38 nele. Basicamente, ele tem acesso a tudo a que você tem acesso, certo? Então, é muito importante que você fique ali supervisionando e observando o que ele está fazendo, ou encontre uma maneira de restringir o acesso dele e dar acesso somente às coisas de que precisa. Esse é um princípio que conhecemos bem desde antes da era dos agents: o princípio do menor privilégio, certo? A ideia é que tanto agents quanto humanos só devem ter acesso às coisas de que precisam para fazer seu trabalho, certo? Portanto, o agent não deve ter acesso a todos os

05:09 segredos do seu sistema, nem a todos os arquivos; deve ter acesso somente ao repo do GitHub que está editando e talvez a alguns segredos necessários para acessar um banco de dados local, algo assim. Então, quando começamos a colocar esses agents em sandbox, é importante avaliar exatamente do que esse agent precisa para fazer seu trabalho. Depois, podemos criar um sandbox que contenha exatamente essas coisas. Assim, sabemos que limitamos o raio de impacto de um ataque de injeção de prompt, de o agent ficar confuso ou de qualquer outra coisa que possa dar errado, restringindo o acesso do agent.

05:40 A primeira estratégia que as pessoas costumam experimentar é executar os agents em contêineres Docker no laptop. Foi assim, na verdade, que lançamos originalmente a OpenHands: como uma interface em que, sempre que você iniciava uma nova conversa com o agent, iniciávamos um novo contêiner Docker. O agent ganhava seu próprio contêiner. E isso funciona muito bem para várias coisas, certo? Primeiro, o contêiner é efêmero. Assim, o agent pode fazer basicamente o que quiser. Se executar rm -rf e apagar tudo, basta encerrar o contêiner e começar de novo, certo?

06:11 É uma solução muito boa. O agent pode simplesmente agir sem muitas restrições. Você não precisa se preocupar tanto com o que ele vai fazer. E, como ele está sendo executado localmente no seu laptop, você também pode montar seletivamente itens do seu sistema de arquivos local, como um repo Git. Pode encaminhar portas para que o agent execute uma aplicação e você possa visualizá-la no navegador. Pode disponibilizar segredos específicos e variáveis de ambiente para o agent. Pode ter servidores MCP em execução localmente no laptop ou dentro do contêiner Docker. E isso é bom porque o agent continua trabalhando com a sua cópia local do código, certo? É parecido com a maneira como você

06:42 costumava trabalhar tendo, digamos, uma cópia do código na sua estação de trabalho. E, em vez de você editar o código, agora o agent faz isso, e você decide quando enviar as alterações e tudo mais. Mas isso não escala muito bem. Há um limite para quantos contêineres Docker você consegue executar em um laptop. Seu laptop não consegue, por exemplo, ouvir eventos vindos do Slack e do DataDog etc. Então, isso é bastante limitado em termos do que você pode fazer aqui. A próxima estratégia que vemos as pessoas adotarem é começar a integrar o Cloud Code e o GitHub Actions. Isso é

07:13 definitivamente diferente de executar contêineres Docker no seu computador. Agora você não está mais trabalhando com sua cópia local do código-fonte. Você tem esse agent dentro de um ambiente efêmero em algum lugar do GitHub Actions, clonando o repo, fazendo coisas e depois enviando o resultado; então, tudo desaparece quando essa action é encerrada. Mas o bom é que você pode executar quantas GitHub Actions estiver disposto a pagar. Certo? Ele já vem com recursos integrados, como um registro de secrets. Assim, você tem esses ambientes isolados bem convenientes.

07:44 E o mais legal é que agora você pode executá-los em uma programação, certo? Você pode simplesmente ter uma GitHub Action que inicia um agent toda segunda-feira de manhã, às 9h, para atualizar suas dependências, certo? Você pode ter uma GitHub Action que, sempre que uma PR é aberta, usa um agent para fazer uma revisão de código. Assim, agora você pode começar a implementar alguma automação, com os agents fora do seu laptop e na nuvem. Mas você fica preso ao GitHub Actions, certo? Esse é um padrão proprietário. Você não vai conseguir realmente portar isso. Ele só consegue responder a eventos vindos do GitHub, certo? Não consegue responder, por exemplo, a um webhook do Slack ou do DataDog.

08:15 Então, você fica meio limitado no que pode fazer se simplesmente integrar coisas com o GitHub Actions. >> [fungada] >> A próxima estratégia que vimos as pessoas adotarem surgiu mais ou menos na onda de popularidade do OpenClaw: na verdade, você pega um computador separado, uma máquina virtual na nuvem ou talvez um Mac mini, e coloca todos os seus agents nele, certo? Isso é diferente do GitHub Actions porque agora você tem um ambiente de longa duração. Há persistência, certo? O que é bom e ruim, certo? Seus agents podem modificar o sistema e saber que ele continuará assim quando forem executados de novo, digamos, dois dias depois. Mas sua máquina também pode entrar em um estado ruim, e talvez você tenha que investigar e descobrir o que está acontecendo.

08:47 De novo, assim como no GitHub Actions, você pode executar agents em uma programação. Agora, como você está executando em uma VM, pode realmente ouvir webhooks recebidos do Twilio, se quiser ouvir mensagens de texto, do Slack. Pode ouvir incidentes vindos do DataDog e eventos vindos do GitHub. Então, agora você tem agents sendo executados automaticamente. Mas ainda existe o problema do princípio do menor privilégio, certo? Todos os seus agents estão juntos nessa máquina virtual e

09:17 todos têm acesso às mesmas coisas. Então, você pode ter, por exemplo, um agent de revisão de código ali junto com um bot de triagem de incidentes do DataDog, e, por algum motivo, o agent de revisão de código agora tem acesso ao DataDog. Há muito mais possibilidades de algo dar errado, certo? O bot de revisão de código pode até editar a memória do bot do DataDog. Essa questão de colocar tudo junto logo começa a causar problemas, porque os agents têm acesso a muito mais do que necessariamente precisam para fazer seu trabalho. Há muito mais oportunidades para algo dar errado quando todos esses agents esbarram

09:48 uns nos outros. >> [fungada] >> A quarta estratégia, e realmente a mais robusta, eu diria, é usar Kubernetes ou algum outro ambiente altamente escalável e efêmero, certo? Com o Kubernetes, por exemplo, você obtém um pod para cada sessão de agent que quiser executar. Ele é iniciado, o agent executa e faz seu trabalho, talvez trabalhando em uma cópia local do repo. Depois, ele é encerrado e todo o ambiente desaparece; o agent abriu uma pull request ou algo assim, certo? Isso é muito bom porque você não

10:19 precisa se preocupar com o estado de longo prazo desse ambiente, como acontece com uma VM. Não precisa se preocupar com ele entrar em um estado ruim, porque toda vez que um agent é executado, você basicamente encerra o ambiente e começa do zero. E você tem uma capacidade de escala praticamente infinita, certo? Nesse ponto, você tem escala de nuvem. Pode executar quantos agents quiser, desde que esteja disposto a pagar pela memória e pela CPU para executá-los. E, de novo, como é Kubernetes, está sendo executado na nuvem. Você pode responder a… Pode executar coisas em uma programação usando cron jobs. Pode executar

10:51 coisas em resposta a eventos HTTP vindos do Slack, do GitHub e do Jira. Basicamente, você pode executar agents de forma totalmente automática. Aqui vai uma comparação rápida. Vou simplesmente passar pelos aspectos que considero ao comparar essas diferentes estratégias. Um deles é: é local ou remoto, certo? Está no seu laptop, trabalhando com sua cópia do código-fonte, ou está sendo executado em outro lugar, onde precisa clonar o código, ou tem sua própria cópia? Essas são duas formas bem diferentes de trabalhar. Que nível de escala você consegue obter com

11:22 isso, certo? Se você estiver executando localmente no seu laptop, talvez consiga executar alguns agents antes que as coisas comecem a ficar desconfortáveis. Se estiver no Kubernetes, pode executar milhares. Nível de isolamento, certo? Se você estiver executando no seu laptop com permissões de ignorar verificações de segurança ativadas, não tem isolamento nenhum. Se todos os seus agents estiverem juntos em uma VM, estarão separados do seu ambiente, mas ainda poderão atrapalhar uns aos outros. Mas, com algo como Kubernetes, cada agent tem seu próprio espaço de trabalho e faz suas próprias coisas. Nível de persistência. Você sempre consegue alguma persistência salvando arquivos ou gravando em sistemas externos. Mas, quando você está trabalhando no seu laptop ou em uma VM, a persistência já vem por padrão, certo? Esse sistema existe por bastante tempo. E que tipos de gatilhos podem fazer esses agents serem executados, certo? Se estiver executando localmente no seu laptop, normalmente será algo manual: você digita um prompt. Quando você passa a usar a nuvem, pode começar a executar coisas em uma programação ou em resposta a eventos. Se você já foi de bicicleta para casa com o laptop aberto porque não queria que o Claude Code parasse, esse é um ótimo motivo para começar a mover seus agents para a nuvem.

11:53 escrever em sistemas externos. Mas, quando você está trabalhando no seu laptop ou em uma VM, você tem persistência por padrão, certo? Esse sistema é de longa duração. E que tipos de gatilhos podem, de fato, fazer esses agents serem executados? Se você está executando localmente no seu laptop, normalmente será algo manual: você digita um prompt. Quando passa para a nuvem, pode começar a executar coisas em um cronograma ou em resposta a eventos. Se você já voltou para casa de bicicleta com o laptop aberto porque não queria que o Claude Code desligasse, esse é um ótimo motivo para começar a mover seus agents para a nuvem.

12:25 Eu queria falar também sobre o fato de que o sandbox não é uma solução para tudo. Há evidências de agents escapando dos seus sandboxes. Aqui vimos que, durante um dos testes do Mythos feitos pela Anthropic, uma das instâncias do Mythos conseguiu escapar do seu sandbox, obter acesso à internet e fazer outras coisas. Existem ataques de fuga de contêiner. Alguns deles são conhecidos, por exemplo, se você estiver executando uma versão antiga do Docker. Então, não é perfeito. Ainda é preciso tomar um pouco

12:56 de cuidado. Mas, pelo menos, é uma boa primeira medida para manter os agents limitados ao que deveriam fazer. Para terminar, vou fazer uma breve divulgação do Open Hands Agent Canvas. É uma forma de executar com qualquer tipo de sandbox. Você pode executá-lo com Claude Code, Codex ou o harness do Open Hands. Mas nós o projetamos para que, por padrão, se você o visse no seu laptop, fosse como executar o Claude Code com as permissões de ignorar verificações de segurança ativadas. Mas, com um simples botão, você pode começar a executar as coisas no Docker

13:27 contêineres. Com outra opção, você pode começar a executá-lo em uma VM remota. Com mais uma opção, pode executá-lo dentro do Kubernetes. Então, é uma ótima maneira de escolher o ambiente certo para cada tarefa. Certo? Às vezes, você realmente quer trabalhar com sua cópia local da base de código. Quer fazer aquele desenvolvimento iterativo rápido, indo e voltando com um agent enquanto olha o código localmente. Às vezes, você só quer disparar eventos que permitam aos agents executar tarefas autonomamente em segundo plano por algumas horas. Você realmente quer que isso seja executado dentro do Kubernetes ou de uma VM. Então, essa é uma ótima maneira de alternar entre esses diferentes tipos de ambiente.

13:58 É só isso que eu tinha para apresentar, mas fico feliz em responder às perguntas da plateia. >> [aplausos] [música]

Transcrição original

[00:01] [music] >> 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

[00:33] 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

[01:03] 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

[01:34] 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,

[02:05] 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.

[02:36] 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

[03:07] 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

[03:37] 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

[04:08] 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

[04:38] 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

[05:09] 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

[05:40] 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?

[06:11] 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

[06:42] 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

[07:13] 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

[07:44] 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.

[08:15] 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

[08:47] 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

[09:17] 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

[09:48] 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

[10:19] 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

[10:51] 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

[11:22] 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

[11:53] 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.

[12:25] 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

[12:56] 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

[13:27] 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.

[13:58] Uh that’s all I’ve got, but I’m happy to to take questions from the audience. >> [applause] [music]