Anthropic Simon Testou o smolvm, mas o Sandbox Ainda Precisa de um Plano de Controle

O pesquisador Simon Willison, do Anthropic Simon, testou o smolvm com um objetivo exigente: executar Python e JavaScript não confiáveis com segurança, sem abusos de rede, sistema de arquivos ou recursos. O experimento encontrou um conflito imediato. O Claude Code para web rodava dentro de um guest Firecracker, enquanto o smolvm precisava acessar recursos de virtualização de hardware que o guest não expunha.

Essa falha não demonstrou que o smolvm era inseguro. Ela mostrou que avaliar uma microVM dentro de outra máquina virtual restrita pode falhar antes mesmo de os testes de segurança começarem. A distinção importa para equipes que consideram scripts fornecidos por usuários, programas gerados por IA ou transformações automatizadas de dados.

As notas de pesquisa sobre sandbox também expõem uma lacuna maior de engenharia. Uma fronteira robusta de máquina virtual é apenas uma parte de um serviço seguro de execução de código. Operadores ainda precisam de prazos, contabilização de recursos, preparação de arquivos, controles de saída, monitoramento e limpeza em torno dessa fronteira.

O smolvm oferece vários componentes úteis. A rede é desativada por padrão, as cargas de trabalho recebem kernels guest separados e os valores de CPU e memória são configuráveis. Ainda assim, esses recursos não criam automaticamente um serviço de produção para código hostil.

A disputa real, portanto, não é smolvm contra Docker, ou Python contra JavaScript. É a promessa de isolamento com um único comando contra os controles operacionais necessários para uma execução multiusuário confiável.

O Teste Falhou Antes de o Código Não Confiável Ser Executado

O primeiro resultado foi uma falha de compatibilidade do ambiente, não uma fuga do sandbox ou um limite de recursos que falhou.

Willison pediu a um modelo Anthropic operando por meio do Claude Code para web que investigasse o smolmachines como um sandbox rápido. A carga de trabalho proposta era concreta: executar código fornecido por usuários para tarefas como transformar dados estruturados.

Esse código precisava de limites rígidos. Não deveria ter acesso à rede, deveria acessar apenas arquivos designados, consumir memória limitada e parar após um intervalo definido pelo operador. Um loop infinito, como while true, não deveria ocupar capacidade de computação indefinidamente.

O modelo conseguiu pesquisar o projeto e projetar testes. Não conseguiu iniciar as máquinas smolvm necessárias para executá-los. Segundo o relato de Willison, o ambiente do Claude Code já era um guest Firecracker executando Linux.

O smolvm usa virtualização assistida por hardware por meio de hypervisors específicos de cada plataforma. No Linux, isso normalmente significa KVM, a interface do kernel que expõe recursos de virtualização do processador a um monitor de máquina virtual. Um guest de nuvem restrito frequentemente não tem o dispositivo /dev/kvm necessário para iniciar outro guest acelerado por hardware.

Esse é o problema da virtualização aninhada. Uma máquina virtual só pode hospedar outra máquina virtual quando a plataforma externa expõe os recursos necessários do processador e o acesso a dispositivos. Muitos sandboxes gerenciados os ocultam intencionalmente.

A limitação cria um paradoxo incomum de testes. O Claude Code para web estava isolado, em parte, porque rodava dentro de uma microVM. Esse isolamento o impediu de iniciar a microVM diferente que havia sido encarregado de avaliar.

Nenhuma carga de ataque relevante em Python ou JavaScript chegou ao smolvm durante essa tentativa. O teste não produziu medições independentes de latência de inicialização, aplicação de limites de memória, saturação de CPU, isolamento de arquivos ou comportamento de encerramento.

Essa evidência ausente deve orientar qualquer conclusão. Seria impreciso afirmar que o exercício validou o smolvm como um serviço seguro de execução. Também seria impreciso tratar a inicialização bloqueada como evidência contra o isolamento de guests do smolvm.

Em vez disso, o resultado identifica um pré-requisito de implantação. Uma equipe precisa executar o smolvm em um host físico compatível ou em uma máquina virtual que permita virtualização aninhada.

O modelo de segurança oficial do smolvm identifica o KVM como o backend Linux. Ele também oferece suporte ao framework Hypervisor da Apple e à Windows Hypervisor Platform em seus respectivos sistemas operacionais.

Esse design multiplataforma ajuda no desenvolvimento local. Ele não torna o smolvm executável dentro de todos os sandboxes de agentes existentes, workers de integração contínua ou ambientes serverless.

Para o experimento anthropic simon, esta é a primeira inversão importante. A mesma camada de isolamento que protegia o agente de pesquisa também impediu o agente de testar uma segunda camada de isolamento.

Anthropic Simon Expôs o Plano de Controle Ausente

O smolvm pode fornecer uma fronteira de VM, mas a aplicação ao seu redor precisa decidir quando o código começa, o que ele recebe e quando é encerrado.

O projeto descreve o smolvm como uma ferramenta de linha de comando para máquinas virtuais Linux isoladas e portáteis. Cada carga de trabalho é executada com seu próprio kernel guest por meio do libkrun, um monitor de máquina virtual projetado para cargas de trabalho leves.

Essa arquitetura cria uma fronteira padrão mais forte do que um contêiner comum. Um contêiner convencional normalmente compartilha o kernel do host, mesmo quando namespaces ocultam processos, rede e mounts. Um guest smolvm recebe um kernel separado por trás de uma fronteira de hypervisor.

A distinção reduz a exposição direta ao kernel do host. Ela não elimina a necessidade de desconfiar de tudo que roda dentro do guest. A documentação do smolvm afirma explicitamente que os operadores devem tratar o root do guest como não confiável.

Sua postura de rede padrão corresponde ao objetivo de Willison. O acesso à rede é opt-in, portanto uma máquina iniciada sem a opção de rede não deve receber conectividade de saída comum. Listas de permissões de hosts estão disponíveis quando uma aplicação precisa de egressos estritamente delimitados.

A exposição do sistema de arquivos também é explícita. Diretórios do host se tornam visíveis apenas quando o operador os monta. Isso torna possível um padrão de diretório de staging para tarefas de transformação.

Um serviço de execução poderia copiar entradas designadas para um diretório temporário. Poderia montar esse diretório como somente leitura, fornecer um local de saída gravável separado e descartar ambos após validar os resultados.

No entanto, a limitação documentada do smolvm é importante. Sua interface de volumes monta diretórios, não arquivos individuais. Um serviço que promete acesso a “apenas arquivos designados” precisa, portanto, criar um diretório isolado contendo exatamente esses arquivos.

O serviço também precisa proteger essa etapa de staging. Deve rejeitar links simbólicos, arquivos de dispositivo incomuns, permissões inesperadas e caminhos que escapem do diretório pretendido. A fronteira da VM não consegue corrigir um processo descuidado de preparação de arquivos no host.

A configuração de memória está disponível por meio da opção --mem ou de um Smolfile, a configuração declarativa de máquinas do smolvm. O padrão documentado é 8 GiB, com a memória apresentada por meio de um balão virtio elástico.

A alocação elástica melhora a utilização do host porque ele não compromete imediatamente todo o valor configurado. Ela não deve ser confundida com controle de admissão entre muitas tarefas hostis.

Se um serviço iniciar numerosos guests com alocações otimistas, a demanda agregada ainda poderá sobrecarregar o host. O agendador precisa de um modelo de capacidade separado que cubra memória, CPUs virtuais, armazenamento e a quantidade de máquinas simultâneas.

A configuração de CPU apresenta uma distinção semelhante. Atribuir uma CPU virtual limita a execução paralela dentro de um guest. Isso não garante automaticamente que o programa receba apenas um número fixo de segundos de CPU.

Um loop infinito de thread única pode consumir sua CPU virtual atribuída para sempre. O hypervisor contém o loop, mas um supervisor externo precisa impor um prazo e encerrar a máquina.

Sistemas de produção normalmente precisam de políticas baseadas tanto em tempo de relógio quanto em recursos. Um timeout de tempo de relógio lida com travamentos, processos em espera e programas em deadlock. A contabilização de CPU detecta cargas de trabalho que consomem computação sem avançar.

O supervisor deve permanecer fora do guest. O código executado dentro da máquina não deve controlar o temporizador, o sinal de encerramento ou a decisão final de limpeza. Caso contrário, a carga de trabalho pode tentar desativar sua própria proteção.

É por isso que a expressão “sandbox para código não confiável” pode ocultar dois produtos distintos. Um é o mecanismo de isolamento. O outro é o plano de controle que agenda e supervisiona esse mecanismo com segurança.

O teste anthropic simon buscava o comportamento do produto completo. A interface pública do smolvm fornece principalmente o mecanismo de isolamento e a configuração de baixo nível necessária para construí-lo.

Uma MicroVM Muda a Fronteira, Não o Modelo de Ameaças

A virtualização de hardware melhora a contenção, mas cada capacidade deliberadamente encaminhada ao guest se torna parte da superfície de ataque.

O smolvm usa o libkrun VMM para iniciar máquinas virtuais leves. O guest recebe seu próprio kernel, enquanto o host mantém o controle sobre o hardware virtual e os dispositivos expostos.

Esse design aborda uma preocupação central com contêineres. Contêineres isolam cargas de trabalho usando recursos do kernel, mas processos hostis ainda interagem com o mesmo kernel do host por meio de chamadas de sistema permitidas. Uma vulnerabilidade no kernel pode, portanto, ameaçar a fronteira do contêiner.

Sistemas de microVM movem essa fronteira para fora. O código hostil primeiro encontra um kernel guest e dispositivos virtuais. Em geral, alcançar o host exige cruzar a fronteira do monitor de máquina virtual ou do hypervisor.

A AWS desenvolveu as microVMs Firecracker com um princípio semelhante para cargas de trabalho serverless. O Firecracker combina virtualização KVM com um modelo de dispositivos deliberadamente reduzido, limitando hardware emulado desnecessário.

O smolvm não é simplesmente um wrapper do Firecracker. Sua documentação atual descreve backends libkrun para macOS, Linux e Windows. Ainda assim, ambas as abordagens colocam cada carga de trabalho atrás de um kernel guest separado.

Essa separação é relevante quando um sistema de IA escreve código de forma autônoma. O código gerado pode conter comportamento destrutivo acidental, ataques a dependências, sondagens de credenciais ou payloads deliberados copiados de dados não confiáveis.

Um recurso de transformação de dados enfrenta o mesmo risco mesmo sem IA. Um usuário poderia enviar Python que varre o sistema de arquivos, cria processos repetidamente, aloca memória até falhar ou tenta conexões de saída.

JavaScript não é automaticamente mais seguro. Programas Node.js podem ler arquivos, iniciar subprocessos, abrir sockets, carregar extensões nativas e esgotar a memória quando essas capacidades continuam disponíveis.

Restrições apenas no nível da linguagem frequentemente se tornam frágeis porque bibliotecas padrão expõem funcionalidades amplas. Dependências transitivas também podem introduzir código nativo ou caminhos de acesso inesperados.

Um guest Linux completo permite que desenvolvedores executem pacotes Python e Node.js comuns sem reescrevê-los para um runtime especializado. Essa compatibilidade é uma das razões pelas quais microVMs continuam atraentes.

A contrapartida é um ambiente guest maior. O serviço precisa fornecer um kernel, uma imagem de runtime, bibliotecas e dispositivos virtuais. Cada componente mantido afeta correções, reprodutibilidade e a base de computação confiável.

A documentação do smolvm lista o sistema operacional host, o backend de hypervisor, o libkrun, o smolvm e a conta host que faz a invocação como componentes confiáveis. Um comprometimento nessas camadas pode enfraquecer a fronteira prometida.

A documentação também alerta sobre o encaminhamento explícito de capacidades. Um diretório montado expõe seu conteúdo. Habilitar a rede amplia os serviços alcançáveis. Encaminhar um agente SSH permite que processos guest solicitem assinaturas enquanto o socket permanece disponível.

Esses são recursos sensatos para máquinas de desenvolvimento. Normalmente, eles devem permanecer desativados em um serviço que executa envios anônimos ou adversariais.

O acesso à GPU exige ainda mais cautela. O smolvm oferece suporte a interfaces que envolvem recursos de GPU compartilhados do host ou processos executados no host. Sua documentação afirma que o acesso remoto ao CUDA não deve ser tratado como isolamento robusto de GPU para múltiplos inquilinos.

Essa limitação não afeta um simples trabalho de conversão de dados em Python. Ela ilustra a regra mais ampla: recursos de conveniência podem atravessar a fronteira limpa do guest que torna a arquitetura básica atraente.

Para cargas de trabalho hostis, o perfil mais seguro é intencionalmente simples. Não use rede, credenciais encaminhadas, serviços do host ou GPU; mantenha as entradas somente leitura no mínimo necessário e use uma área de saída descartável.

A VM deve ser destruída após um trabalho. Reutilizar uma máquina cria o risco de levar arquivos alterados, processos, caches ou estados ocultos para a execução do próximo usuário.

Imagens portáveis podem ajudar a estabelecer ambientes de execução consistentes. O smolvm usa imagens OCI, baseadas no formato de imagem OCI, para que operadores possam preparar ambientes Python ou Node.js usando um padrão de empacotamento familiar.

A compatibilidade de imagens não estabelece a confiabilidade delas. Um serviço de produção ainda precisa de digests fixados, registries controlados, tratamento de vulnerabilidades e um processo para reconstruir ambientes após atualizações de segurança.

Os Limites de Recursos Exigem Mais do que Sinalizadores de CPU e Memória

A defesa mais difícil contra “while true” não é o isolamento, mas a terminação confiável em todos os modos de falha.

Uma configuração de memória impõe ao guest um teto para a RAM visível. Quando um programa excede essa capacidade, o kernel do guest pode acionar seu comportamento de falta de memória. Isso contém uma forma de abuso de recursos.

O host ainda precisa observar o que acontece em seguida. O guest pode encerrar apenas um processo, deixar de responder ou gastar muito tempo recuperando memória. O serviço não pode presumir que toda falha de memória produzirá um resultado limpo.

Um executor rigoroso deve classificar os resultados. Sucesso, exceção do usuário, esgotamento de memória, tempo esgotado, excesso de saída, falha interna do sandbox e rejeição por falta de capacidade do host são eventos distintos.

Essa classificação importa para usuários e operadores. Um script de transformação com sintaxe inválida não deve parecer uma indisponibilidade de infraestrutura. Uma máquina que não consegue iniciar não deve consumir a cota de tentativas do usuário.

Os limites de CPU exigem várias camadas. O guest pode receber uma contagem restrita de CPUs virtuais. Controles do host, como cgroups, podem então regular o processo VMM em relação a outras cargas de trabalho.

Um supervisor de prazo deve encerrar toda a VM após o intervalo permitido. Encerrar apenas o processo Python ou Node.js de nível superior é insuficiente, porque o programa pode criar processos filhos ou processos em segundo plano.

A terminação também deve ter escalonamento. O supervisor pode solicitar primeiro um desligamento gracioso e, depois, interromper o processo VMM se o guest não responder. Ele deve verificar que os processos relacionados e recursos temporários desapareceram.

A saída é outro recurso. Um programa pode imprimir indefinidamente, criar arquivos de resultado enormes ou gerar dados profundamente aninhados que consomem memória do analisador depois que a execução termina.

O serviço precisa de limites em bytes para a saída padrão, a saída de erro padrão e os arquivos gerados. Ele deve transmitir ou truncar logs sem armazenar conteúdo ilimitado na memória da aplicação.

As cotas de armazenamento devem se aplicar à camada gravável do guest e a todos os diretórios de saída exportados. Caso contrário, uma entrada pequena pode produzir dados suficientes para encher o sistema de arquivos do host.

A quantidade de processos também importa. Uma fork bomb cria processos mais rápido do que um operador humano consegue reagir. O kernel do guest precisa de limites de processos, enquanto o host deve restringir o VMM e seus processos auxiliares.

Um programa hostil também pode explorar o tempo sem saturar uma CPU. Ele pode dormir indefinidamente, esperar por uma entrada ausente ou criar um deadlock. É por isso que prazos de tempo de parede continuam obrigatórios.

O tempo deve ser medido pelo plano de controle externo. Um guest pode modificar seu próprio relógio ou interferir em processos internos de watchdog. O temporizador monotônico do host oferece uma fonte mais confiável.

A exportação de arquivos só deve ocorrer após o fim da execução. O host deve inspecionar tipos, tamanhos, caminhos e quantidades de arquivos antes de mover os resultados para o armazenamento persistente.

Para transformações comuns de dados, um contrato de saída mais restrito pode reduzir riscos. O executor pode aceitar um documento JSON, um arquivo CSV ou um arquivo compactado limitado, em vez de uma árvore de diretórios arbitrária.

Um serviço também deve limitar a complexidade das entradas antes de iniciar a máquina. Arquivos compactados podem se expandir muito além de seu tamanho enviado, enquanto formatos maliciosos podem atacar analisadores fora do guest.

Portanto, a sequência segura começa antes do smolvm. Valide e prepare as entradas, crie uma máquina nova, aplique limites de execução, interrompa a máquina, inspecione as saídas e então destrua o estado temporário.

A observabilidade também pertence fora do guest. Os operadores precisam de identificadores de máquina, digests de imagem, horários de início e término, classificações de saída, picos de recursos e status de limpeza.

Esses registros devem evitar, por padrão, o armazenamento de dados sensíveis dos usuários. Os logs podem se tornar outro canal de vazamento quando scripts imprimem registros de entrada, credenciais ou conteúdo proprietário.

Nenhum desses requisitos diminui o valor do smolvm. Eles definem o trabalho ao redor necessário para transformar seus primitivos de baixo nível em um serviço confiável.

Docker, WebAssembly e Sandboxes Hospedados Ainda Competem

O smolvm ocupa uma posição intermediária útil, oferecendo compatibilidade com Linux comum e uma separação mais forte do que um contêiner com kernel compartilhado.

O Docker continua sendo o ponto de partida mais fácil para muitas equipes de engenharia. Imagens, registries, ferramentas de build e sistemas de orquestração já dão suporte a fluxos de trabalho com contêineres em escala.

Os contêineres podem aplicar namespaces, capabilities, filtros seccomp, sistemas de arquivos somente leitura e limites de cgroup. Esses controles podem ser adequados quando as cargas de trabalho são confiáveis ou apresentam apenas risco moderado.

O kernel compartilhado continua sendo a principal preocupação para código totalmente hostil. Uma vulnerabilidade de escape no kernel do host ou no runtime de contêineres pode expor outras cargas de trabalho e dados do host.

O smolvm altera essa exposição ao atribuir um kernel de guest separado a cada máquina. Ele também aceita imagens OCI, reduzindo parte da fricção de migração para equipes com ambientes Python ou Node.js existentes.

No entanto, as plataformas de contêineres têm camadas maduras de agendamento e políticas. A documentação de segurança do smolvm afirma que a ferramenta independente não é, por si só, um plano de controle robusto para múltiplos usuários.

Uma equipe que substitui contêineres por smolvm deve evitar perder salvaguardas operacionais durante a migração. Um isolamento mais forte sob um agendador mais fraco ainda pode resultar em um serviço pouco confiável.

O WebAssembly segue outro caminho. Um runtime WebAssembly começa com um modelo de capacidades restrito e então concede explicitamente funções como acesso a arquivos ou rede.

Essa abordagem pode criar uma interface menor para cargas de trabalho compactas de transformação. Ela também permite inicialização rápida e incorporação precisa em uma aplicação.

A compatibilidade é a contrapartida. Pacotes padrão de Python e Node.js podem esperar chamadas de sistema Linux, extensões nativas, subprocessos ou comportamentos de runtime indisponíveis em um ambiente WebAssembly restrito.

Uma equipe que controla a linguagem de transformação pode aceitar essas restrições. Um serviço que promete ampla compatibilidade com Python e JavaScript as encontrará rapidamente.

Sandboxes de código hospedados oferecem um terceiro caminho. Fornecedores empacotam ciclo de vida da máquina, tempos limite, política de rede, armazenamento e APIs em serviços gerenciados.

Isso pode encurtar o tempo de implementação. Também transfere código e dados sensíveis para outro operador, introduz dependências de serviço e limita o controle sobre o desenho de isolamento subjacente.

Hospedar o smolvm por conta própria mantém o runtime sob a administração do comprador. Também torna o comprador responsável pelo reforço do host, atualizações de segurança, planejamento de capacidade, monitoramento e resposta a incidentes.

A escolha deve seguir a carga de trabalho, e não a moda. Um avaliador de expressões restritas não precisa de um guest Linux completo. Um pacote Python complexo com dependências nativas provavelmente precisa.

Para transformações executadas uma única vez, a inicialização de microVMs precisa permanecer pequena em relação à duração do trabalho. O smolvm afirma que cargas de trabalho empacotadas podem iniciar em menos de 200 milissegundos, mas medições independentes devem abranger exatamente os hosts e as imagens do comprador.

Os benchmarks devem incluir recuperação de imagem a frio, criação da máquina, inicialização do runtime, preparação das entradas, execução, validação da saída e destruição. Medir apenas o tempo de inicialização do guest subestima a latência visível ao usuário.

As equipes também devem testar a densidade. Um guest rápido diz pouco sobre um host executando centenas de envios simultâneos sob pressão de memória.

Portanto, a questão competitiva é mais ampla do que a força do isolamento. Ela inclui compatibilidade, comportamento de inicialização, maturidade do agendamento, carga operacional e as consequências de um escape bem-sucedido.

O smolvm merece avaliação porque combina cargas de trabalho Linux familiares com uma fronteira de VM. A tentativa de simon da anthropic mostra que essa avaliação precisa ocorrer em infraestrutura capaz de expor os recursos de virtualização necessários.

Três Testes Decidirão se o smolvm Está Pronto

A próxima evidência útil precisa vir de testes com cargas de trabalho hostis, não de outra lista de recursos.

O primeiro sinal é um teste reproduzível em um host compatível de bare metal ou com virtualização aninhada. Ele deve executar suítes Python e JavaScript por meio do mesmo supervisor externo.

Essas suítes devem incluir loops infinitos, esgotamento de memória, fork bombs, saída excessiva, sondagens do sistema de arquivos, sondagens de rede, processos filhos com atraso e desligamentos anormais do guest. Cada caso precisa de um resultado esperado.

Um resultado bem-sucedido reforçaria o argumento de que o smolvm pode servir como motor de isolamento para trabalhos de transformação. Falhas repetidas de limpeza ou terminação inconsistente o enfraqueceriam.

O segundo sinal é a aplicação explícita e documentada do ciclo de vida. Um executor de referência deve mostrar como impor prazos de tempo de parede, controles de CPU no nível do host, limites de memória, cotas de saída e destruição completa da máquina.

Sinalizadores de configuração não bastam. O teste deve verificar o comportamento quando o guest ignora solicitações de desligamento, enche o armazenamento e deixa processos descendentes para trás.

Esse sinal fecharia a lacuna entre os primitivos de VM do smolvm e o serviço que Willison originalmente queria examinar. Sem ele, cada adotante precisará projetar o supervisor crítico de forma independente.

O terceiro sinal é uma revisão de segurança sob um modelo de ameaça declarado. A revisão deve identificar componentes confiáveis do host, comportamento de arquivos montados, aplicação da rede, procedência das imagens e premissas de múltiplos inquilinos.

A documentação existente do smolvm já faz divulgações úteis. Ela afirma que as versões atualmente não têm assinaturas nem atestações de procedência, embora a verificação de checksum esteja disponível quando seu arquivo de checksum pode ser baixado.

Essa divulgação dá aos avaliadores uma questão concreta de cadeia de suprimentos. Um operador de produção precisa de um método controlado para adquirir, verificar, fixar e atualizar o binário do smolvm e as imagens de guest.

Uma avaliação também deve distinguir a execução local por um único usuário da multitenência hostil. Um desenvolvedor executando código gerado em um laptop enfrenta consequências diferentes das de um serviço público que aceita envios anônimos.

Nenhum sandbox pode transformar código arbitrário em uma carga de trabalho livre de riscos. O objetivo prático é contenção em camadas, capacidades controladas, consumo de recursos limitado e recuperação rápida quando uma camada falha.

O padrão de implantação mais promissor usa o smolvm como uma camada dentro desse sistema. Um serviço de host valida as entradas, cria um guest descartável, retém o acesso à rede, impõe prazos, verifica as saídas e destrói o ambiente.

Para as equipes que desenvolvem fluxos de trabalho de IA, a lição vai além da execução de código. Qualquer sistema que permita a um modelo agir com base em informações locais precisa de limites explícitos sobre o que o modelo pode ler, escrever e reter.

Uma base de conhecimento pesquisável pode ajudar engenheiros a reter resultados de testes, modelos de ameaças e conclusões de incidentes. Ela não pode substituir o isolamento em tempo de execução, mas pode tornar as decisões de segurança mais fáceis de auditar.

O experimento anthropic simon deve, portanto, ser tratado como uma avaliação inacabada com uma primeira constatação útil. O smolvm não pôde ser executado no ambiente Claude Code escolhido porque o sandbox externo impedia o acesso à virtualização.

O próximo passo não é flexibilizar esse sandbox externo. É repetir a avaliação em um host dedicado e compatível, com um supervisor externo e uma suíte de testes adversariais publicada.

Seu serviço ainda interromperia todos os trabalhos, preservaria apenas as saídas aprovadas e faria uma limpeza completa quando o ambiente convidado se tornasse hostil? Se essa resposta não foi medida, o sandbox não está pronto para código de usuários.