A NVIDIA criou um sandbox que sabe quando dizer não (OpenShell)

Ver no idioma original →

Autoria: Better Stack · 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: NVIDIA Just Built a Sandbox That Knows When to Say No (Openshell) · Canal: Better Stack · 07:17 · Assistir no YouTube

Tópicos: Agentes de IA, Cibersegurança e segurança de software, Ferramentas de desenvolvimento com IA, Infraestrutura e hardware de IA, Segurança de IA

Resumo

OpenShell é um sandbox open source da NVIDIA que aplica políticas de acesso a arquivos, processos e conexões de rede para agentes de IA. Um supervisor controla as conexões externas e injeta credenciais apenas em solicitações autorizadas, sem expor as chaves reais ao agente. O vídeo demonstra como as regras podem permitir acesso de leitura à API do GitHub e bloquear a criação de issues. Também aborda a validação de políticas, os dados de telemetria, as limitações da versão inicial e quando alternativas mais simples podem bastar.

Pontos-chave

• OpenShell é um sandbox open source, escrito em Rust e distribuído sob a licença Apache 2.0.
• A arquitetura tem três componentes: gateway, supervisor e sandbox.
• O acesso a arquivos e processos é limitado no nível do kernel, e o agente não pode enfraquecer as regras durante a execução.
• Por padrão, conexões de rede são negadas; as políticas podem autorizar ações específicas de um processo em um endpoint.
• O supervisor injeta credenciais apenas em solicitações autorizadas, evitando que o agente veja as chaves reais.
• As decisões e negações são registradas, e um solver Z3 verifica as mudanças de política antes de entrarem em vigor.
• O OpenShell funciona sobre Docker, Podman, Kubernetes e uma micro VM; no Mac, os sandboxes Linux dependem de configurações específicas do Docker Desktop.
• O vídeo cita telemetria ativada por padrão, falhas em parte das criações de sandbox e a versão 0.1.5 como razões para testar a ferramenta com cautela.
• Para usos mais simples, o runtime de sandbox da Anthropic ou contêineres comuns podem exigir menos configuração.

Capítulos

Início	Capítulo	Resumo
00:00	O problema dos agentes com acesso amplo	O vídeo apresenta o risco de entregar credenciais a agentes e explica por que um contêiner, sozinho, não diferencia ações permitidas.
01:33	Demonstração das políticas do sandbox	A demonstração mostra restrições de arquivos e processos e o bloqueio padrão das conexões de rede.
03:09	Permissões por processo e proteção de credenciais	O acesso de leitura à API do GitHub é permitido, enquanto a criação de uma issue é bloqueada e as credenciais ficam com o supervisor.
04:41	Validação de políticas e dados de uso	O vídeo explica a verificação de políticas com Z3, apresenta números de telemetria da NVIDIA e compara OpenShell a outras opções.
06:17	Limitações e quando usar o OpenShell	São discutidos requisitos no Mac, falhas relatadas, o estágio inicial do projeto e os cenários em que suas regras mais detalhadas podem ser úteis.

Citações

Você escreve uma política para definir o que cada agente pode acessar. — 01:01

Por padrão, o sandbox não consegue acessar nada. — 02:06

A questão não é se ele pode acessar o GitHub, mas o que aquele processo específico pode fazer lá. — 03:09

Ele nunca teve a chave para começar. — 04:11

O que o agente tem permissão para fazer com isso? — 07:17

Conceitos e entidades

• OpenShell (ferramenta): Sandbox open source que aplica políticas de acesso para agentes e registra suas decisões.
• NVIDIA (empresa): Empresa que anunciou o OpenShell e cujos dados de telemetria são citados no vídeo.
• Rust (conceito): Linguagem de programação em que o OpenShell foi escrito.
• Z3 (ferramenta): Solver usado para analisar quais acessos uma mudança de política concederia.
• Docker (ferramenta): Plataforma sobre a qual o OpenShell pode executar seus sandboxes.
• Podman (ferramenta): Plataforma de contêineres compatível com a execução do OpenShell.
• Kubernetes (ferramenta): Plataforma sobre a qual o OpenShell também pode executar sandboxes.
• Anthropic sandbox runtime (ferramenta): Alternativa descrita no vídeo como uma opção mais simples para criar sandboxes.
• GitHub API (ferramenta): API usada na demonstração para ilustrar como políticas podem permitir leitura e bloquear a criação de issues.
• landlock (conceito): Recurso do kernel Linux mencionado como requisito para executar os sandboxes no Mac.

Tradução completa (pt-BR)

00:00 Se colocarmos um agent em um contêiner Docker e dermos a ele um token do GitHub, esse contêiner não consegue saber se o agent está lendo seu repo ou abrindo issues nele. Para o contêiner, tudo é tráfego para o mesmo endereço. A Nvidia acaba de lançar um sandbox open source que consegue notar a diferença. E não, você não precisa de uma GPU Nvidia, porque estou executando isso em um Mac. O problema central é que tantas pessoas

00:30 simplesmente executam agents em qualquer modo, na verdade. Cloud, code, Codex, open code, execute, não aprove nada e vá fazer outra coisa enquanto está rodando. Se queremos que esse agent seja útil, ele precisa dos seus arquivos, pacotes, APIs e credenciais. E hoje muita gente simplesmente entrega tudo a eles, porque é mais fácil. Um contêiner é uma sala trancada. Ele impede que o agent perambule pelo resto da sua máquina. Mas, depois que você entrega uma chave ao agent, bem, ele pode ir aonde quiser. É para isso que serve o Open

01:01 Shell. É open source, licenciado sob Apache 2.0 e escrito em Rust. Você escreve uma política que define o que cada agent pode acessar, e ela verifica cada acesso a arquivo, cada chamada de sistema e cada conexão de rede. Há três partes que fazem tudo isso funcionar de verdade. Um gateway, com o qual você interage; um supervisor, um segurança confiável que toma todas as decisões; e o sandbox onde o agent vive. A única porta do sandbox para o mundo exterior passa pelo segurança, esse supervisor.

01:33 Vou mostrar. Se você gosta de ferramentas de programação que aceleram seu workflow, não deixe de se inscrever. Temos vídeos novos o tempo todo. Certo, inicio o sandbox aqui, depois de instalá-lo, e verifico com sandbox status; em seguida, executo este comando aqui. Logo de cara, dá para ver que ele é executado sem privilégios. Então, quem sou eu? ID, certo? Ele não consegue elevar os próprios privilégios. E o acesso ao sistema de arquivos é bloqueado no nível do kernel. Vou tentar escrever fora dos caminhos que foram permitidos. Posso tocar em um arquivo bem aqui, e o acesso é negado. Ele só pode

02:06 tocar no que a política permite. Então, se eu entrar na pasta temp, que é o diretório de trabalho, isso pode ser permitido. Essas regras do sistema de arquivos e dos processos são fixadas quando o sandbox é iniciado. O próprio agent não pode enfraquecê-las. Agora, vou tentar acessar a API do GitHub de dentro dele, bem aqui, com curl. O que esperamos? Acesso negado. Posso executar isso aqui no terminal dois só para conferir os logs. Por padrão, o sandbox não consegue acessar absolutamente nada; o padrão é negar. Esse é o objetivo. No outro terminal, onde estão meus logs, é

02:38 o que me mostra exatamente o que aconteceu. Posso abrir os logs do Open Shell e ver um rastreamento disso. O curl tentou acessar api.github.com nesta porta e foi bloqueado. Toda negação é registrada, então nada acontece em silêncio. Agora, posso adicionar uma regra. O curl pode acessar a API do GitHub somente para leitura. Não preciso reiniciar nada. Posso executar este comando aqui, openshell policy update, e atualizar tudo. Agora, vamos executar aquele mesmo comando novamente.

03:09 Vou executar o comando curl para acessar o GitHub, e funciona. Agora, a mesma ferramenta, o mesmo endereço, mas desta vez um post para criar uma issue. Vamos enviar um post para criar essa issue e, como não permitimos isso, o acesso é negado. É esse limite que um contêiner não consegue estabelecer. A questão não é se ele pode acessar o GitHub, mas o que aquele processo específico tem permissão para fazer lá. A regra está vinculada ao binário. Um processo diferente não recebe a mesma permissão. E o agent nunca

03:39 vê as credenciais reais. Isso é importante. O Open Shell as injeta somente em solicitações que chegam a um endpoint aprovado. Esse é o ponto de controle de um agent: limites do sistema de arquivos e dos processos aplicados pelo kernel, que não podem ser enfraquecidos durante a execução. Além disso, regras de rede que especificam exatamente qual binário pode fazer o quê em qual endpoint, com um registro de auditoria completo de cada decisão. Um contêiner comum, certo? Não conseguimos estabelecer esses limites nele. Seu agent nunca vê suas credenciais reais. O supervisor as adiciona

04:11 na saída. Então, se alguém fizer uma injeção de prompt no seu agent e disser a ele para vazar sua chave de API, não haverá nada para vazar. Ele nunca teve a chave. O sandbox nem sequer consulta os próprios nomes de domínio. O supervisor resolve o DNS e abre apenas as conexões aprovadas. Por baixo, o Open Shell funciona com Docker, Podman, Kubernetes e uma microVM minúscula. Ele não vai substituir seu contêiner. É simplesmente um conjunto de regras. Depois, há algo que eu esperaria de qualquer sandbox: um aprovador. Antes que uma alteração de política

04:41 entre em vigor, o Open Shell a envia a um solver Z3, um mecanismo matemático, para determinar que novo acesso essa alteração realmente concederia. Arquivos de política com um único curinga que ninguém percebeu. Isso verifica a regra antes de você confiar nela, com um limite de tempo padrão de 10 segundos. Agora, o Open Shell se tornou público em fevereiro. A Nvidia o anunciou na GTC, em março, junto com Cisco, CrowdStrike, Google Cloud e Microsoft Security como parceiras. Nomes importantes. E ele tem pouco mais de 20.000 estrelas no GitHub. A própria telemetria da Nvidia

05:14 informa que, em duas semanas neste verão, foram criados mais de 550.000 sandboxes e 4,2 milhões de ações de agents foram negadas. Em 4,2 milhões de ocasiões, um agent tentou fazer algo que a política proibia. Esses são números da Nvidia, não uma auditoria, mas é muita coisa sendo negada. Então, qual é a diferença em relação ao que já temos? Porque, vamos admitir, há muita coisa por aí, mas nem tudo é igual. Docker, Firecracker e Apple’s container são paredes. O Open Shell funciona por cima

05:45 deles e acrescenta regras por solicitação, injeção de chaves e um registro de auditoria. E o runtime de sandbox da Tropic é a opção leve. Limites de arquivos e de rede por processo, com muito menos configuração. E2B e Daytona são sandboxes hospedados e descartáveis para executar um pouco de código. O Open Shell é auto-hospedado, prioriza políticas e foi criado para agents que funcionam por horas. Mas precisamos analisar algumas coisas primeiro. Para começar, a telemetria vem ativada por padrão. São contagens anônimas e basta uma variável de ambiente para desativá-la. Eu

06:17 desativaria. Depois, em um Mac, os sandboxes continuam sendo Linux. Eles rodam dentro da máquina virtual do Docker Desktop, e essa máquina precisa de um recurso do kernel chamado landlock, além da rede do host ativada, o que vem desativado por padrão. O próprio comando Docker do Open Shell indica que está tudo certo de qualquer forma, então teste antes. Em seguida, a telemetria da própria Nvidia mostra que cerca de 12% das criações de sandbox falharam nesse mesmo período de duas semanas. A publicação no blog chama isso de prévia

06:47 inicial. O readme diz que há lançamentos estáveis semanais, mas a versão é apenas 0.1.5. Acredite no número da versão, então experimente. E, por fim, um sandbox não é uma garantia absoluta. Ele apenas controla o que um agent pode acessar. Lembre-se disso. Você vai usar? Bem, talvez, sim. Se você só quer um sandbox rápido para o Cloud Code no seu laptop, sinceramente, o runtime de sandbox da Anthropic ou contêineres comuns dão muito menos trabalho. Talvez seja melhor ficar com isso. Mas, se você está entregando credenciais de verdade a agents,

07:17 especialmente se está simplesmente executando agents à solta, as regras por solicitação e o design em que o agent nunca vê a chave são importantes, porque os sandboxes costumavam responder a uma pergunta: o agent consegue acessar isso? Este responde à pergunta que realmente importa: o que o agent tem permissão para fazer com isso? Aqui é o Josh, da BetterStack. Se você gosta de dicas e truques de programação como este, não deixe de se inscrever. A gente se vê em outro vídeo. >> [música]

Transcrição original

[00:00] If we drop an AI agent in a Docker container, hand it a GitHub token, that container can’t tell whether your agent is reading your repo or opening issues on it. To the container, it’s all just traffic to the same address. Nvidia just shipped an open-source sandbox that can tell the difference. And no, you don’t need an Nvidia GPU cuz I’m running it on a Mac. The core problem here is so many people

[00:30] are just running agents in any mode, really. Cloud, code, Codex, open code, run it, approve nothing, and do something else while it’s running. If we want that agent to be useful, then that agent needs your files, your packages, APIs, and your credentials. And today, a lot of people just hand them everything cuz it’s easier. A container is a locked room. It stops the agent wandering into the rest of your machine. But once you hand the agent a key, well, they can go anywhere they want. That’s what Open

[01:01] Shell is for. It’s open-source Apache 2.0 written in Rust. You write a policy for what each agent is allowed to touch, and it checks every file access, every system call, and every network connection against it. There are three pieces to all this that make it actually work. A gateway, which is what you talk to, a supervisor, a trusted bouncer that makes every decision, and the sandbox where the agent lives. The sandbox’s only door to the outside world goes through the bouncer, that supervisor.

[01:33] Let me show you. If you enjoy coding tools that speed up your workflow, be sure to subscribe. We got videos coming out all the time. Okay, so I spin up the sandbox right here after it’s installed with sandbox status to check it, and run this command here. Right away, you see it runs unprivileged. So, who am I? ID, right? It can’t escalate. And file system access is locked at the kernel level. Try to write outside the paths it was given, so I can touch a file right here, and we get denied. It can only

[02:06] touch what the policy allows. So, if I go into the temp folder and it’s working directory, that could be allowed. Those file system and process rules are fixed when the sandbox starts. The agent itself can’t weaken them. Now, I try to hit the GitHub API from inside it right here with curl. What do we expect? Denied. I can run that here in terminal two just to check those logs. Now, out of the box, the sandbox can’t reach anything at all, default deny. That’s the point here. Over in another terminal, where my logs are here, that’s

[02:38] what’s telling me exactly what happened. I can fire up those open shell logs and we can see a backtrace of that. Curl tried to reach api.github.com on this port, it got blocked. Every denial is logged, so nothing is silent. Now, I can add one rule. Curl can reach the GitHub API, read only. I don’t have to restart anything. I can run this command right here, openshell policy update, and I can update that whole thing. Now, let’s fire back that same command.

[03:09] I’ll run the curl command to access GitHub, and it works. Now, same tool, same address, but this time a post to create an issue. We’ll fire up a post to create that issue, and because we didn’t allow it, we get denied. That’s the line a container can’t draw. Not can it reach GitHub, but what is the specific process allowed to do there? The rule is tied to the binary. A different process doesn’t give the same permission. And the agent never

[03:39] sees real credentials. That has important. Open shell injects them only for requests that hit an approved endpoint. That’s the control point for an agent, kernel enforced file system and process limits that can’t be weakened at runtime. Plus, network rules that say exactly which binary can do what on which endpoint, with a full audit trail of every decision. A normal container, right? We can’t draw those lines on those. Your agent never sees your real credentials. The supervisor adds them on

[04:11] the way out. So, if someone prompt injects your agent and tells it to leak your API key, there’s nothing to leak. It never had the key to begin with. The sandbox doesn’t even look up its own domain names. The supervisor resolves DNS and opens only the approved connections. Underneath, Open Shell runs on Docker, Podman, Kubernetes, and a tiny micro VM. It’s not going to replace your container. It’s just like a set of rules. Then there’s the part I’d expect from a sandbox at all, approver. Before

[04:41] policy change goes live, Open Shell feeds it to a Z3 solver, a math engine, to work out what new access that change would actually grant. Policy files with one wildcard nobody thought though. This checks the rule before you trust it with an a 10-second default time limit. Now, Open Shell itself, it went public in February. Nvidia announced it at GTC in March with Cisco, CrowdStrike, Google Cloud, and Microsoft Security as partners. Big names. And it has a little over 20,000 stars on GitHub. Nvidia’s

[05:14] own telemetry reports says that in 2 weeks this summer, it created over 550,000 sandboxes and denied 4.2 million agent actions. 4.2 million times an agent tried something the policy said no. Those are Nvidia’s numbers, not an audit, but that’s a lot of no’s. So, how is this different from what we already got? Cuz let’s face it, we got a lot out there, but they aren’t all the same. Docker, Firecracker, Apple’s container, those are walls. Open Shell runs on top

[05:45] of them and adds the per request rules, the key injection, and the audit log. And the Tropic sandbox runtime is the lightweight option. Per process file and network limits, much less setup. E2B and Daytona are hosted throwaway sandboxes for running a bit of code. Open Shell is self-hosted, policy-first, and built for agents that run for hours. We got to look at a few things here though first. First, telemetry is on by default. It’s anonymous counts and it’s one environment variable turns it off. I’d

[06:17] turn it off. Then, on a Mac, the sandboxes are still Linux. They run inside Docker Desktop’s virtual machine and that machine needs a kernel feature called landlock plus host networking switched on, which is off by default. Open Shell’s own Docker command says everything’s green either way, so test it first. Next up, Nvidia’s own telemetry shows about 12% of sandbox creations failing in that same two-week window. Their blog calls it an early

[06:47] preview. The readme says stable weekly releases, but its version is only 0.1.5. Believe the version number, so try it out. And then finally, a sandbox is not some guarantee. It’s just controls what an agent can reach. Remember these. Are you going to use it? Well, maybe yeah. If you just want a quick sandbox for cloud code on your laptop, honestly, Anthropic sandbox runtime or plain containers is a lot less work. Maybe just stick with that. But if you’re handing actual credentials to agents,

[07:17] especially if you’re just running agents like wild, the per request rules in the agent never sees the key design, those are real because sandboxes used to answer one question. Can the agent reach it? This one answers the question that actually matters. What is the agent allowed to do with that? I’m Josh from BetterStack. If you enjoy coding tips and tricks like this, be sure to subscribe. We’ll see you in another video. >> [music]