1.000 tarefas de agentes em um sandbox: o que falha quando LLMs executam código — Kevin Orellana, AWS

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: 1,000 Agent Tasks in a Sandbox: What Breaks When LLMs Run Code — Kevin Orellana, AWS · Canal: AI Engineer · 15:16 · Assistir no YouTube

Tópicos: Agentes de IA, Avaliação e benchmarks de IA, Cibersegurança e segurança de software, Infraestrutura e hardware de IA

Resumo

Kevin Orellana descreve como usou um agent de programação para executar mil workflows em um ambiente de sandbox na nuvem e testar a plataforma da equipe. Os testes revelaram falhas tanto na camada MCP quanto nos próprios sandboxes, incluindo problemas de codificação, permissões de arquivos e falta de memória. O argumento central é que as restrições e os componentes de baixo nível do ambiente podem afetar diretamente a capacidade de agents de concluir tarefas. Para encontrar esses problemas, ele recomenda testar os agents remotamente com uma ampla variedade de workflows, além de testá-los localmente.

Pontos-chave

Um agent de programação foi instruído a executar mil testes em dez domínios, representando workflows que clientes poderiam realizar.
Um servidor MCP forneceu uma interface para o agent interagir com o ambiente e a plataforma de sandbox na nuvem.
Os resultados foram armazenados em um banco de dados SQLite para facilitar a execução concorrente e a análise de muitos testes.
As falhas observadas foram separadas entre problemas na interface e problemas na camada de sandbox.
Aplicações diferentes, como um sandbox de código e um navegador na nuvem, têm requisitos distintos de recursos e comportamento.
Limites de memória, permissões, sistemas de arquivos persistentes ou efêmeros e capacidades do kernel podem impedir a conclusão de tarefas.
Testes amplos e variados ajudam a revelar falhas que testes unitários ou de integração podem não detectar.
Agents executados remotamente podem não ter acesso às mesmas ferramentas e aplicações disponíveis em uma estação de trabalho local.
A recomendação final é testar agents em sandboxes remotos com uma ampla gama de workflows, além de testá-los localmente.

Capítulos

Início	Capítulo	Resumo
00:01	O experimento com mil testes	O palestrante apresenta a plataforma e explica como criou uma interface MCP para executar testes de agents no ambiente de sandbox.
03:09	Arquitetura e workflows testados	Os resultados são armazenados no SQLite, enquanto os testes abrangem tarefas como operações de arquivos, desenvolvimento de software e automação de navegador.
05:13	Falhas na interface e no sandbox	Exemplos de arquivos alterados na transferência, valores inesperados e problemas de acesso a diretórios mostram falhas em camadas diferentes.
08:54	Primitivas do ambiente e impacto nos agents	O palestrante relaciona permissões, memória, sistemas de arquivos e controles do kernel à capacidade dos agents de completar tarefas.
11:01	Testes amplos e sandboxes remotos	A palestra defende o uso de muitos workflows para expor falhas e observa que os recursos locais podem diferir dos disponíveis remotamente.
13:35	Ambientes afetam o desempenho	Estudos citados ilustram como controles adequados ou ferramentas defeituosas podem alterar os resultados, e a recomendação final é testar os agents remotamente.

Citações

Apontei um agent de programação para o ambiente de sandbox na nuvem da minha equipe e disse: tente quebrá-lo. — 00:31

Mil testes era um número bastante arbitrário; a ideia era lançar uma rede ampla e ver o que aparecia. — 02:39

Todas essas restrições têm implicações enormes para a capacidade dos agents de resolver esses problemas. — 07:17

Teste localmente, mas também faça fuzzy testing remotamente com testes de vários domínios. — 14:38

Conceitos e entidades

Kevin Orellana (pessoa): Palestrante que relata os testes de workloads de agents em ambientes de sandbox.
Amazon Bedrock AgentCore (ferramenta): Plataforma mencionada por Orellana para criar e hospedar agents na nuvem, com recursos como ambientes de execução e sandboxes.
AWS (empresa): Empresa associada à plataforma e ao trabalho apresentado na palestra.
MCP (conceito): Protocolo usado para expor ao agent acesso ao ambiente e à plataforma de sandbox.
SQLite (ferramenta): Banco de dados usado para armazenar os resultados dos testes.
UC Berkeley (empresa): Universidade citada em uma pesquisa sobre como os controles do ambiente podem influenciar o desempenho em benchmarks.
fuzzy testing (conceito): Abordagem de teste que avalia agents com muitos workflows e condições variadas para revelar modos de falha.
sandbox (conceito): Ambiente isolado de execução cujas restrições de recursos, permissões e sistema de arquivos podem afetar o trabalho de um agent.

Tradução completa (pt-BR)

00:01 [música] Olá, pessoal. Acho que podemos começar. Então, alguns meses atrás, fiz algo um pouco, digamos, absurdo. Peguei um agente de programação, apontei para o ambiente de hospedagem de sandbox na nuvem da minha equipe e disse

00:31 para tentar quebrá-lo, e deixei isso rodando durante a noite. Esta palestra é um pouco sobre o que descobrimos. Meu nome é Kevin. Trabalho no Amazon Bedrock Agent Core. É uma plataforma, um ambiente de hospedagem de sandbox. E fazemos mais do que isso. Oferecemos agents, identidade, memória, ambientes de execução, sandboxes, gateways, tudo o que você quiser usar para criar e hospedar seus agents na nuvem. Então, tudo começou basicamente

01:04 com uma análise cuidadosa de como os clientes usam nossa plataforma e, cada vez mais, acho que muitos de nós no setor percebemos que muitos componentes de plataformas na internet são simplesmente agents e, cada vez mais, também são hospedados em sandboxes. Acho que as palestras de hoje talvez apresentem todas as arquiteturas possíveis em ambientes de sandbox hospedados na nuvem. E isso me fez pensar: como posso talvez imitar, simular o cliente e também testar o serviço da

01:35 mesma forma que os agents usam nossa plataforma? Então, a primeira coisa que nos propusemos a fazer foi criar uma abstração ou interface que permita que agents de programação, assim como aplicações com agents, interajam com nosso serviço de uma maneira bastante natural para eles. Hoje sabemos que os modelos de fronteira conhecem muito bem o protocolo MCP. Então passamos um ou dois dias criando um servidor MCP para expor o acesso ao nosso ambiente e à nossa plataforma, só para que pudesse começar

02:07 bem rápido. A segunda parte foi aprimorar isso. Passamos algum tempo identificando as ferramentas que poderiam ser disponibilizadas e fazendo testes básicos, entre outras coisas. Alguns dos testes que fizemos manualmente foram, por exemplo, escrever um arquivo de código Python e executá-lo, ou pegar um arquivo Python e convertê-lo para Java. Depois, percebemos que queríamos simplesmente ampliar os domínios de teste aos quais submeteríamos os agents de programação. Então, pedimos que escrevessem, pura e simplesmente, mil testes em dez domínios. E mil testes, nesse caso, foi um número bastante arbitrário. Foi só para abranger uma gama ampla e ver o que apareceria.

02:39 Isso exigiu alguns ajustes, porque sabíamos que mil testes levariam algumas horas e consumiriam muitos tokens. Então, fizemos coisas como gerenciar e injetar credenciais, verificar o que acontece quando um teste falha: é um problema do serviço? É um problema da camada MCP? Esse é o tipo de coisa que deixamos o agent descobrir. Então, a arquitetura é, sinceramente, muito simples, mas também muito poderosa, e acho que muitos de nós provavelmente já vimos algo assim no nosso dia a dia de desenvolvimento.

03:09 Temos nosso agent de programação no canto superior esquerdo. Temos um servidor MCP que basicamente encapsula nosso ambiente de sandbox na nuvem, e todas as descobertas são enviadas de volta para nós. Armazenamos tudo em um banco de dados SQLite porque, como alguns de vocês talvez tenham percebido, agents tendem a escrever arquivos Markdown, mas isso não escala muito bem quando você tem mil testes para executar. E isso nos permitiu aproveitar a concorrência: podemos ter vários subagents rodando localmente, executando os testes e armazenando os resultados também localmente.

03:40 Agora, acho que é fácil simplesmente dizer “mil testes”, mas, na verdade, cada ponto na tela representa um workflow que um cliente realmente executaria. Fizemos coisas como testar o ciclo de vida do sandbox. Qual é a confiabilidade dele quando submetido a estresse? Também testamos operações de E/S do sistema de arquivos: o que acontece quando você envia um arquivo e o baixa do sandbox?

04:10 Testamos o desempenho. Testamos alguns ciclos de desenvolvimento de software, como, por exemplo, escrever pacotes Python, pacotes Java e coisas do tipo. Para dar uma ideia do que um desses pontos pode representar, pode ser um programa completo de treinamento de machine learning, de ponta a ponta. Pode ser gerar um relatório em PDF. Também pode ser algo tão simples quanto abrir uma página da web. E logo percebemos que nossa plataforma, que na época

04:42 hospedava duas aplicações importantes — uma era um sandbox de código e a outra, um navegador na nuvem —, teria testes diferentes, com níveis de importância diferentes para os sandboxes em que elas eram hospedadas. Por exemplo, no navegador, pedimos ao agent que criasse várias abas e tentasse extrair conteúdo de todas elas e resumi-lo, talvez tirar algumas capturas de tela, baixá-las, talvez preencher um formulário e automatizar um workflow de login. Mas o ponto é que essas aplicações hospedadas em sandboxes tendem a passar por workflows diferentes, que exigem requisitos diferentes do

05:13 sandbox. Então, executamos os testes e quero falar de apenas três falhas que, acho, mostram alguns dos padrões que observamos nessas aplicações hospedadas em sandboxes. Uma falha simples foi quando enviamos uma imagem, baixamos e queríamos verificar se recebíamos de volta exatamente o que havíamos enviado. E, para nossa surpresa, não foi o caso. Investigamos um pouco mais a fundo e descobrimos que a camada de codificação na camada MCP estava incorreta.

05:44 A segunda falha também foi um pouco interessante: um byte nulo. Ele simplesmente atrapalhou nossos testes. Um byte nulo pode ser zero. Também pode ser um marcador em algumas linguagens de programação que significa que a string está completa. Agora, uma falha interessante, específica da camada do sandbox, ocorreu quando gravamos arquivos em um diretório específico no sandbox e, ao tentar recuperá-los, eles simplesmente não estavam disponíveis. Então, começamos a separar os

06:14 padrões e as falhas em duas camadas. Uma era a interface e a outra, a camada do sandbox. Acho importante fazer essa distinção porque, quando começamos a hospedar aplicações em sandboxes, elas se afastam um pouco do padrão típico de serviços de API, em que há um serviço de longa duração que expõe uma API; você envia uma solicitação e recebe uma saída com um formato razoavelmente previsível, e sabe mais ou menos o que o serviço de backend faz. Mas, obviamente, no mundo de hoje, já não temos tantos aplicativos de longa duração; em vez disso, temos

06:45 agents especializados que usam um sandbox e um ambiente aos quais expomos acesso por meio de um gateway, e as exigências que eles têm em relação ao ambiente computacional vão variar bastante. Sabemos disso, e acho que muitos de nós podemos se identificar com esta experiência: você está desenvolvendo algo localmente e começa a ver seu agent — seja o Cursor, o Claude Code, o Codex ou qualquer outro — fazendo coisas engraçadas, como baixar um pacote que você não esperava, ou converter um arquivo CSV para JSON e depois para PDF, sem motivo aparente. E todos esses workflows que seus agents vão querer executar vão exigir coisas diferentes do seu ambiente.

07:17 Por exemplo, a quantidade de memória ou CPU que o sandbox tem e as permissões disponíveis para seus processos e sistemas de arquivos. Acho que, em muitas das palestras de hoje, veremos diversas arquiteturas possíveis para seus sandboxes. E o ponto mais amplo aqui, acho eu, é que todas essas restrições têm implicações enormes para a capacidade dos seus agents de resolver esses problemas.

07:51 E, só para visualizar isso, estas são algumas das falhas que observamos ao comparar duas aplicações diferentes hospedadas em sandboxes. Na parte de cima temos o sandbox de código e, na parte de baixo, o navegador na nuvem. No canto inferior direito estão destacados em vermelho os modos de falha, que indicam quantas vezes o sandbox efetivamente parou de funcionar. Nesse caso, sabemos que, como navegadores na nuvem consomem bastante memória sempre que abrimos abas, muitos dos nossos testes falharam simplesmente por causa de limitações de memória. E essa não foi realmente uma falha que observamos no

08:23 …ambiente de interpretação de código. E, quando os organizamos de uma maneira um pouco diferente, começamos a perceber que os modos de falha se agrupam em torno das primitivas do sandbox. Sabemos que alguns dos componentes relacionados aos sistemas de arquivos tendem a ser as permissões do sistema de arquivos, os sistemas de arquivos montados, as permissões para ler, gravar e executar arquivos, e se o sistema de arquivos é persistente ou efêmero. E os testes eram bem implacáveis. Por exemplo, no canto inferior direito, temos os testes do navegador.

08:54 Eles simplesmente deixam as sessões e os sandboxes sem memória e sinalizam isso como uma falha total. E acho que o ponto mais amplo aqui é que, quando hospedamos esses aplicativos em sandboxes e esperamos que nossos clientes consigam criar cargas de trabalho bastante arbitrárias neles, precisamos ter muito cuidado, pois as restrições do sandbox têm enormes implicações para a capacidade desses agents de resolver esses problemas. Agora, se olharmos um pouco mais de perto — e este slide está bem carregado na segunda coluna —, temos muitas das primitivas

09:24 usadas para compor a aparência de um contêiner de sandbox. Podemos chegar até recursos do kernel, como interceptadores do kernel e esses chamados programas eBPF estendidos, que permitem executar módulos do kernel e interceptar programas na camada do Python. Eles podem controlar como seu agent pode fazer chamadas de saída, talvez fazer uma chamada a uma API interna dos serviços internos da sua empresa.

09:59 Se representarmos isso em um diagrama, teremos uma visão geral, em alto nível, de como os componentes do sandbox podem afetar a capacidade da sua carga de trabalho de fazer o que precisa. Por exemplo, acho que em palestras anteriores falamos sobre computação segura, que controla os programas de controle do sistema que seus aplicativos podem querer executar. Digamos, por exemplo, que eu tenha um pacote de machine learning que precisa iniciar um processo. Meu processo ou contêiner sequer tem a capacidade de iniciar um novo processo?

10:31 Talvez eu tenha uma tarefa de interpretação de código que precisa baixar um pacote Python para um módulo específico, para que o kernel do Python consiga encontrá-lo, ou talvez os binários Rust precisem estar no local certo para que o coding agent possa executar um programa. Todas essas coisas bem pequenas acabam se somando e afetam a capacidade dos seus agents de resolver o problema de negócio. Agora, dando um passo atrás, acho que isso

11:01 foi interessante: a ideia de usar um LLM para gerar basicamente testes unitários. Acho que todos já fizemos isso. Não sei se alguém ainda escreve testes unitários à mão. E, de forma parecida, se subirmos um nível para os testes de integração, podemos esperar que os agents sejam bastante bons em entender o espaço do problema e escrever testes para ele. Mas, à medida que hospedamos cada vez mais aplicativos que são simplesmente agents em sandboxes, começamos a ver as limitações do modelo

11:32 — isto é, essas primitivas e esses controles de nível muito baixo podem, na verdade, prejudicar a capacidade dos seus agents de atingir o objetivo. O que esperávamos mostrar aqui é uma maneira muito eficaz de revelar esses modos de falha, que para nós são bastante sutis: basta fazer testes fuzz no sandbox do seu agent, pedindo que ele conclua, neste caso, talvez mil workflows, e observando os resultados. E, só para tornar isso um pouco

12:02 mais concreto, muitos de nós aqui somos desenvolvedores e estamos muito acostumados a executar coding agents localmente. Talvez você tenha o Codex ou o Claude rodando localmente. E, à medida que expandimos e criamos mais espaços de trabalho, rapidamente impomos uma limitação ao nosso laptop. Então, suas equipes querem colocar esses coding agents em sandboxes remotos para poder escalar a quantidade de pull requests do GitHub que vocês conseguem processar e coisas do tipo. Mas, como provavelmente já perceberam, as ferramentas disponíveis na sua estação de trabalho local, suas ferramentas MCP e os aplicativos que rodam localmente

12:34 podem não ser iguais aos que você tem em um sandbox remoto. E um breve destaque para o AgentCore. Esse é um dos problemas que nos interessam muito, porque reconhecemos que os clientes querem escalar seus coding agents e a forma como executam os ciclos de vida de desenvolvimento de software. Uma das funcionalidades que lançamos recentemente permite que os clientes acessem o sandbox por SSH para ver o que está acontecendo. E, claro, já não é realmente uma pessoa acessando o sandbox por SSH

13:04 — pode ser também um coding agent com o qual você está desenvolvendo. Mas a ideia é essa: entrar no sandbox, investigar e descobrir quais problemas estão impedindo seu coding agent ou seu aplicativo de funcionar sem problemas é uma necessidade de negócio bastante clara para nós, e estamos tentando solucioná-la para os clientes. E, se olharmos um pouco para a academia, um exemplo interessante que acho que muitos de nós provavelmente consideram importante é o que acontece quando saem modelos de ponta.

13:35 A primeira coisa que olhamos é o relatório do benchmark SWE-bench: este modelo obteve XYZ por cento neste benchmark, em comparação com outro. Houve um estudo recente feito por pesquisadores da UC Berkeley que mostrou que, com os controles de ambiente adequados e um agent de exploração, eles conseguiram superar os três benchmarks, chegando a 100%. Por outro lado, houve outro estudo em que pesquisadores tentaram apresentar a um agent um amplo conjunto de problemas de negócio usando ferramentas com defeito. E, claro, a

14:07 eficácia desse agent caiu bastante. Então, acho que é principalmente nisso que quero focar hoje: à medida que os aplicativos que criamos se tornam cada vez mais agentic e deixam de se limitar a um serviço de API REST que desenvolvemos para os clientes, passando a ser agents arbitrários executados dentro de um sandbox, fica realmente muito difícil encontrar todos os pontos problemáticos em que as primitivas do sandbox

14:38 levam a uma capacidade menos eficiente de os seus agents resolverem o problema. Então, meu desafio para vocês hoje é: se estão pensando em hospedar seus agents em sandboxes, claro, testem localmente, mas também façam testes fuzz remotamente, com um amplo conjunto de testes de domínio. Obrigado. [aplausos]

15:16 [música]

Transcrição original

[00:01] [music] Hello everyone. I think we can get started. So, a few months ago, I did something that was um a bit slightly absurd. I took a coding agent. I pointed it at my team’s uh cloud sandbox hosting environment and it said

[00:31] try to break it and I let that run overnight. And this talk is a bit about what we found. Uh my name is Kevin. I work at Amazon Bedrock Agent Core. It’s a sandbox hosting environment or platform. And we do more than that. We provide agents, identity, memory, um, runtime environments, sandboxes, gateways, anything you want to use to build and host your agents on agents on the cloud. So the way this started was basically

[01:04] with me taking a hard look at how um customers use our platform and increasingly I think a lot of us in the industry see that uh a lot of platform components on the internet are just agents and increasingly they’re also sandbox hosted. I think today’s talks will maybe walk you through all the architectures that can exist in cloud hosted uh sandbox environments. And so this kind of got me thinking how can I perhaps emulate simulate the customer and also test the service the

[01:35] same way agents use our platform. So the first thing I think we we set out to do was create an abstraction or interface that allows coding agents as well as agent applications to interact with our service uh in a way that’s pretty native to them. And today we know that Frontier models know the MCP protocol pretty well. So we spent a day or two just creating an MCP server to expose access to our environment and platform um just so it can get started

[02:07] pretty quickly. The second piece was polishing that. Uh we spent some time in finding the tools that can be made accessible and uh smoke testing some runs and and things like that. So some of the tests we ran just by hand was uh for example write a Python code file and execute it or take a Python file and uh convert into Java. And then we realized we wanted to just expand the test domains that we we were going to set the coding agents to do. So we asked to just plainly write a thousand tests across 10 domains. And a

[02:39] thousand tests here was pretty arbitrary. It was just to cast a wide net and see what caught back. This took a bit of polishing because we knew that a thousand tests would take a few hours and was going to be a little tokenheavy. So we um did things like credential management credential management injection um what happens when a test fails. Is it a service issue? Is it a MCP layer issue? Uh those are the kind of things we we let the agent um figure out. So the architecture is honestly very simple but it’s also very powerful and I

[03:09] think a lot of us have probably seen this in our day-to-day uh development. So we have our coding agent on top left. We have an MCP server that basically wraps our cloud sandbox environment and all the findings get sent back to us. We store them in a SQLite database just because as some of you might have seen u agents are pretty prone to write markdown files but that doesn’t really scale when you have a thousand tests that you want to run and this allowed us to tap into concurrency or you can have

[03:40] multiple sub aents running locally and running and executing their tests and storing those results uh locally. Now, a thousand tests I think is kind of easy to just say out loud, but really every single dot on the screen kind of represents a workflow that a customer would actually run. So, we did things like testing the sandbox uh life cycle. How reliable is it when you put it under stress? Um things like file system IO, what happens when you upload a file and download it from the sandbox?

[04:10] Uh tested performance. We tested some software development life cycles like uh for example writing Python packages, Java packages um and the like. So to give you a perspective of what one of these dots could represent, it could be an end toend machine learning training uh program. It could be generating a PDF report. Uh it could also just be um as simple as opening a web page. And we re quickly realized that our platform which at the

[04:42] time was hosting two uh major applications, one was a code sandbox, the other was a cloud browser would have different tests that mattered differently to the sandboxes that they were hosted in. So for example, here in the browser, we asked the agent to create a bunch of uh tabs and try to scrape them all and summarize them, maybe take some screenshots, download them, maybe fill out a form, automate a login workflow. But the point here is these sandbox hosted applications uh tend to go through different workflows that demand different requirements from

[05:13] the sandbox. So we ran through the tests and I want to talk about just three failures that I think um showcase some of the patterns we saw uh from these uh sandbox hosted applications. So a simple one was we uploaded an image, we downloaded it and we wanted to see if the same thing that we put up uh we got back when we asked to download it and lo and behold that was not the case. Uh we deep dived a bit into it and we found that the encoding layer at the MCP layer was incorrect.

[05:44] The second one was a bit interesting too which was a no bite. It just threw off off our tests. Um a no bite can be a zero. It could also be a marker in some coding languages that just mean that means that the string is is uh complete. Now an interesting one that was particular the sandbox layer is one where we actually wrote files to a specific directory in the sandbox and when we try to get it back it just wouldn’t be available. So now we started to segregate the

[06:14] patterns uh and failures into two layers. One was at the interface and the other one was at the sandbox layer. And it’s important I think to draw the distinction because uh when we start to host applications in sandboxes we they deviate a little bit from the typical API service pattern where you have a long running service that has exposes an API uh and you you know send a request you get an output that’s reasonably um shaped and you you kind of know what your backend service does. But obviously in today’s world we we no longer have as

[06:45] many long running applications rather we have specialized agents that are uh sandbox and environment we expose access to them through a gateway and the demands that they have on their let’s say computer environment are going to differ greatly. We know that and this is an experience I think a lot of us can relate to which is you are developing something locally and you just start to see your agent uh either a curo cloud codeex whatever it might be do funny things like it might uh download a package you might not have expected or it might translate a CSV

[07:17] file to JSON to PDF for whatever reason and all of these workflows that your agents will want to do are going to demand uh different things from your environment. So things for example like how much memory or CPU your sandbox has the permissions that are available to your processes and file systems. I think in a lot of the talks we’ll see today there are a lot of different architectures that your sandboxes can have. And the wider point here I think is all these constraints have pretty massive implications for your agents ability to solve these problems.

[07:51] And just to kind of visualize that, these are some of the faults that we saw when we compared two different applications hosted in sandboxes. So at the top we have the code sandbox and the bottom we have the cloud browser. At the bottom right we have the failure modes that are highlighted in red which signify how many times the sandbox actually uh perished. In this case, because cloud browsers, we know that whenever we open up tabs, they’re pretty memory heavy. And so, a lot of our tests fail just due to memory constraints. And that wasn’t really a fault we saw in the

[08:23] uh code interpret environment. And when we map them out a little bit differently, we start to see that the failure modes coales around sandbox primitives. So we know some of the components around file systems tend to be file system permissions uh mounted file systems uh permissions to read, write, execute files, um whether or not the file system uh is persistent or uh ephemeral. Um and the tests were pretty unforgiving. Um for example, in the bottom right we have uh the browser

[08:54] tests just starving the the sessions and sandboxes out of memory and signaling that as a complete failure. And I think the wider point here is as we host these applications in sandboxes and we expect our customers to be able to build uh pretty arbitrary workloads in these sandboxes, we have to be pretty careful that the sandbox constraints have massive implications as to those agents ability to complete those problems. Now if we look a little bit closely and this slide is pretty heavy on the second column we have a lot of the primitives

[09:24] used to compose what a sandbox container um might look like. So we can go as deep as kernel capabilities, things like kernel interceptors, um these things called extended BP BPF programs which allow you to run kernel modules and intercept programs at the at the Python layer. Um those might uh control how your agent actually can make some egress calls, maybe make a internal API call to um your internal company services.

[09:59] If we diagram this out, this is kind of what a very high level overview of how the components in the sandbox might uh affect your um workload’s ability to do its job. So here for example, I think earlier in our talks, we spoke about uh security secure compute which controls the system control programs that your applications might want to run. So for example, say I have a machine learning package that needs to spawn a process. Does my process or container even have the ability to start a new process? Um

[10:31] perhaps I have a code interpreter uh task that needs to download a Python rep Python package into a very specific module for uh the Python kernel to be able to pick it up or are the Rust binaries in the right location for when the coding agent is able to um run or execute a program. All these very very small things tend to add up into your agents ability to uh execute the business problem. Now just taking a step back I think this

[11:01] was kind of interesting uh which was the idea of like using an NLM to generate basically unit test. I think we’ve all done it. We I don’t know if anyone writes unit tests by hand anymore. Uh and similarly if we go up up a layer integration tests uh we we we can anticipate agents to be pretty good at understanding the problem space and writing tests for them. But as we move towards hosting more and more applications which are just agents uh in sandboxes, we start to see the cracks in the model

[11:32] which is um these very low-level primitives and controls um might actually hamper your agents ability to do its state of goal. Um, and what we were hoping to relay here is a a very strong way to actually surface these failure modes that are that are pretty innocuous to us is just through fuzzy testing your agent sandbox asking it to complete perhaps in this case a thousand workflows and seeing what results you get. And just to also make it a little bit

[12:02] more tangible, um, a lot of us here developers, we are very used to running coding agents locally. You might have your, you know, your your codeex or your cloud running locally. And as we expand and create more workspaces, you quickly put a constraint on your laptop and now, you know, your teams want to put these coding agents in remote sandboxes so you can scale how many GitHub PRs you you work through and the like. But as you’ve probably seen, the tools that you have in your local workstation, your MCP tools, your locally running applications

[12:34] might not match what you have in a remote sandbox. And just a small shout out to uh agent core. This is actually one of the problems that we’re very keen on because we recognize that customers want to scale their coding agents um and how customers are actually running these uh software development life cycles. So one of the releases we recently did was grant the ability to customers to SSH into their um sandbox just to see what’s going on. And of course it’s not really a human who is SSH into your sandbox

[13:04] anymore. or it’s a coding agent who you’re developing with uh as well. But the idea is there uh bridging into the sandbox and poking around and seeing what problems are causing your coding agent or your application to not run as smoothly is a pretty um stated business problem for us and one that we’re trying to solve for customers. And if you look a little bit uh if you look a little bit at academia uh one interesting example I think a lot of us probably care about is whenever frontier

[13:35] models come out the first thing we look at is the sweet benchmark report which is okay this model got XYZ percentage on this three benchmark versus another and there was a recent study made by some researchers at UC Berkeley where they found that given the right environment controls and an exploit agent they actually beat the three benchmarks like reaching up to 100%. And in inversely uh there was another study where um researchers were trying to give a wide set of business problems to an agent with broken tools. Uh and of course the

[14:07] effectiveness of that agent uh went down greatly. So I think this is uh mostly where I want to aim to leave today which is as these applications that we build today are more and more agentic and they’re not constrained to a rest API service that you you build for customers but rather uh an arbitrary agent running inside of sandbox it’s really really um uh challenging to find all the sharp edges where the sandbox primitives uh

[14:38] lead to you know a less efficient uh ability for your agents to complete that problem. So my challenge here for you today is uh if you’re looking to host your agents on sandboxes, sure test it locally, but also fuzzy test it with a wide set of domain tests um remotely. Yeah, thank you. [applause]

[15:16] >> [music]