Rodando Agentes de IA no Kubernetes com o Agent Sandbox

O cenário da inteligência artificial está passando por uma enorme mudança de paradigma. Num passado não tão distante da IA Generativa, a interação com um agente de IA era comumente tratada como algo transitório, com chamadas de funções sem estado: uma requisição iniciava um processo, executava por um curto período de tempo e então era encerrada.

Atualmente o ecossistema está migrando de tarefas efêmeras e isoladas para implementações múltiplas e coordenadas de agentes de IA com execução constante e contínua. Estes novos agentes autônomos mantêm contexto, usam ferramentas externas, escrevem e executam código e se comunicam entre si. Agentes modernos (como os que usam LLMs) podem executar comandos em sistemas, manipular arquivos, fazer chamadas de rede e inteargir com serviços internos. Isso é ótimo da perspectiva da automação mas também representa um grande risco se não houver isolamento adequado.

Rodar esses agentes diretamente em containers tradicionais pode não ser suficiente, uma vez que os Containers compartilham o kernel do host. Eventuais falhas de isolamento podem comprometer todo o ambiente, além de ser bastante complexo garantir políticas finas de segurança para código dinâmico. Quando se pensa em uma infraestrutura para hospedar estes novos modelos de agentes e suas cargas de trabalho, o Kubernetes se destaca como uma escolha natural. Mapear, porém, estas novas cargas de trabalho para as primitivas tradicionais do nosso querido K8s exige novas camadas de abstração.

IA, Kubernetes e camadas de abstração

Atualmente quando um projeto necessita uma ferramenta que possibilite extensibilidade, redes robustas e maturidade de ecossistema para orquestração de aplicações nativas para a nuvem, por padrão pensamos em Kubernetes. Entretanto, à medida que a IA evolui de solicitações de execuções curtas para agentes autônomos de longa duração, fica evidente o surgimento de um novo padrão operacional.

Agentes de IA são, tipicamente, cargas de trabalho isoladas, com estado e de execução única. Um agente precisa de uma identidade persistente e um espaço de trabalho seguro para escrever e executar código (frequentemente não confiável). Como esses agentes de longa duração permanecem ociosos na maior parte do tempo, exceto por breves períodos de atividade, exigem um ciclo de vida que suporte mecanismos como suspensões e retomadas rápidas.

Devido a essas propriedades únicas, os recursos primitivos tradicionais do Kubernetes não se encaixam perfeitamente. É aí que está a nossa deixa para falar do novo Projeto Agent Sandbox (atualmente em desenvolvimento sob a tutela do SIG Apps da comunidade do Kubernetes).

Introduzindo o Projeto Agent Sandbox

O Agent Sandbox é um projeto voltado a simplificar a execução de ambientes isolados e persistentes sobre Kubernetes. Seu foco está em casos de uso como runtimes de agentes de IA, ambientes de desenvolvimento e sessões interativas que precisam preservar contexto ao longo do tempo.

Dentre as novidades está a Definição de Recurso Personalizado (CRD) do tipo Sandbox e um controller para Kubernetes. O objetivo é fornecer uma API declarativa para gerenciar cargas de trabalho que necessitam especificamente de apenas 1 instância (contêiner singleton), com estado, longa duração e identidade estável, oferecendo uma experiência semelhante à de uma máquina virtual leve e de contêiner único, mas construída sobre primitivas nativas do Kubernetes.

Em sua essência, o projeto busca oferecer:

– Forte isolamento para código não confiável: Quando um agente de IA gera e executa código de forma autônoma, a segurança é fundamental. O recurso personalizado Sandbox oferece suporte nativo a diferentes ambientes de execução, como gVisor ou Kata Containers. Isso fornece o isolamento de kernel e de rede necessário para a execução multi-tenant e não confiável.

– Gerenciamento de ciclo de vida: Ao contrário dos servidores web tradicionais otimizados para tráfego constante e sem estado, um agente de IA opera como um espaço de trabalho com estado que pode ficar ocioso por horas entre as tarefas. O Agent Sandbox permite o escalonamento desses ambientes ociosos para zero, economizando recursos, ao mesmo tempo que garante que eles possam ser retomados exatamente de onde pararam.

– Identidade estável: Sistemas multiagentes coordenados exigem redes estáveis. Cada Sandbox recebe um nome de host e uma identidade de rede estáveis, permitindo que diferentes agentes se descubram e se comuniquem entre si sem problemas.

A ideia central é simples: Criar um sandbox por agente, com isolamento forte, políticas restritas e execução controlada.

O fluxo básico do Agent Sandbox é se inicia quando um agente precisa executar uma tarefa. O controller do Kubernetes cria um ambiente sandbox isolado, o código do agente roda dentro desse sandbox e o ambiente é destruído após a execução.

Motivação

Atualmente quando se pensa em gerenciamento de aplicações replicadas e sem estado (Deployments) e conjuntos estáveis ​​e numerados de conteiners com estado (StatefulSets), automaticamente se pensa em Kubernetes. No entanto, há uma crescente necessidade de uma abstração para lidar com casos de uso como:

• Ambientes de Desenvolvimento: Ambientes de nuvem isolados, persistentes e acessíveis pela rede para desenvolvedores.

• Runtimes de Agentes de IA: Ambientes isolados para executar código não confiável gerado por LLM.

• Notebooks e Ferramentas de Pesquisa: Sessões persistentes de contêiner único para ferramentas como o Jupyter Notebook.

• Serviços de Pod Único com Estado: Hospedagem de aplicações de instância única (por exemplo, agentes de build, pequenos bancos de dados) que precisam de uma identidade estável sem a sobrecarga do StatefulSet.

Embora esses casos possam ser aproximados combinando um StatefulSets ( de tamanho 1), um Service e um PersistentVolumeClaims para cada aplicação (ou agente), essa abordagem é demasiadamente complexa e carece de gerenciamento especializado de ciclo de vida, como hibernação.

Arquitetura

Trabalhar com o Agent Sandbox segue a mesma lógica declarativa já familiar em outras abstrações do Kubernetes. Em vez de criar manualmente todos os componentes necessários para executar um ambiente isolado, o usuário declara um recurso do tipo Sandbox descrevendo o estado desejado, e o controller do projeto assume a responsabilidade de reconciliar esse estado com o cluster.

A partir dessa definição, ele pode criar e gerenciar recursos adjacentes, como Pods, volumes, políticas, identidades e configurações de runtime, de forma semelhante ao modo como um Deployment gerencia ReplicaSets e Pods ou um StatefulSet coordena instâncias com identidade e armazenamento persistentes.

O Sandbox

O CRD Sandbox é o núcleo do Agent Sandbox. Ele fornece uma API declarativa para gerenciar um único pod com estado, com identidade estável e armazenamento persistente. Isso é útil para cargas de trabalho que não se encaixam bem no modelo sem estado e replicado de Deployments ou no modelo numerado e estável de StatefulSets.

Os principais recursos do CRD Sandbox incluem:

• Identidade Estável: Cada Sandbox possui um nome de host e identidade de rede estáveis.

• Armazenamento Persistente: Os Sandboxes podem ser configurados com armazenamento persistente que sobrevive a reinicializações.

• Gerenciamento do Ciclo de Vida: O controlador Sandbox gerencia o ciclo de vida do pod, incluindo criação, exclusão agendada, pausa e retomada.

O CRD Sandbox define um novo tipo de recurso:

apiVersion: sandbox.k8s.io/v1alpha1
kind: Sandbox
spec:
  runtime: wasm
  resources:
    cpu: "1"
    memory: "512Mi"
  policy:
    network: restricted

Para o recurso Sandbox é importante salientar que você não está criando um Pod de Sandbox diretamente, está declarando uma intenção de execução isolada.

O CRD, por si só, não executa nenhuma carga de trabalho. Ele funciona como uma interface declarativa que é traduzida pelo controller em recursos concretos dentro do cluster. Dependendo do valor definido em spec.runtime, o Agent Sandbox pode materializar diferentes formas de execução isolada, como Pods configurados com runtimes especiais, incluindo gVisor ou Kata Containers, workloads baseados em WebAssembly por meio de WASI, ou até microVMs, como Firecracker, quando houver integração externa disponível.

Além do ambiente principal de execução, o controller também pode criar Pods auxiliares que atuam como parte do plano de controle do sandbox. Esses componentes intermediários podem ser responsáveis por inicializar o ambiente isolado, preparar ou injetar o código do agente e gerenciar aspectos do ciclo de vida da execução. Dessa forma, a criação de um Sandbox envolve mais do que simplesmente iniciar um Pod: trata-se de coordenar os recursos necessários para entregar um ambiente controlado, persistente e alinhado à especificação declarada.

Para reforçar o isolamento, o Agent Sandbox também pode recorrer a namespaces efêmeros ou a mecanismos de isolamento lógico. Isso permite criar namespaces dedicados para cada sandbox ou aplicar labels e annotations que facilitem a segmentação, a aplicação de políticas e a identificação dos recursos associados a uma execução específica.

O spec.policy do Sandbox não atua apenas como metadado declarativo; ele é convertido pelo controller em recursos concretos de segurança e governança dentro do cluster. Por meio de objetos como NetworkPolicy, é possível restringir o tráfego externo do sandbox e permitir comunicação apenas com endpoints previamente autorizados, reduzindo a superfície de exposição da carga de trabalho.

Da mesma forma, mecanismos como PodSecurityContext, Seccomp e AppArmor podem ser utilizados para restringir chamadas de sistema, remover privilégios desnecessários e limitar capacidades do processo em execução. Já recursos como ResourceQuota e LimitRange permitem controlar o consumo de CPU e memória, evitando que um agente ou workload isolado comprometa a estabilidade dos demais componentes do cluster.

Escalando com novos CRDs e extensões

Como o universo de IA está evoluindo rapidamente, o projeto Agent Sandbox não se limita ao CRD Sandbox principal. A documentação oficial descreve uma camada de extensões formada por CRDs e controllers adicionais que se apoiam na API base para facilitar o uso em escala. O SandboxTemplate permite que equipes de plataforma codifiquem configurações reutilizáveis de runtime, imagem, armazenamento e políticas; o SandboxClaim oferece uma abstração mais simples para que usuários, desenvolvedores ou agentes solicitem um ambiente a partir de um template; e o SandboxWarmPool mantém sandboxes previamente preparados para que novas sessões possam ser alocadas com menor latência.

Essa abordagem é especialmente relevante para workloads interativos de IA. Em uma aplicação tradicional, aguardar a criação de um novo Pod pode ser aceitável, mas em fluxos com agentes autônomos, interpretadores de código ou sessões de desenvolvimento, a inicialização a frio prejudica a continuidade da interação. Com pools pré-aquecidos, o controlador pode entregar um ambiente isolado já disponível, reduzindo o tempo entre a solicitação do agente e o início efetivo da execução.

Tecnicamente, esses CRDs formam um fluxo de provisionamento em camadas. O SandboxTemplate concentra a configuração reutilizável que define como um sandbox deve ser criado, incluindo a imagem do container, parâmetros do runtime, volumes e políticas associadas. O SandboxClaim atua como a interface de consumo dessa configuração: em vez de descrever todo o Sandbox manualmente, o usuário ou agente cria uma claim apontando para um template, e o controller de claims reconcilia esse pedido criando ou associando um Sandbox compatível. Já o SandboxWarmPool mantém um conjunto de sandboxes preparados antecipadamente para um determinado perfil de uso; quando uma claim precisa de um ambiente novo, o controller pode alocar um sandbox do pool em vez de aguardar todo o ciclo de criação a frio. Nas versões recentes do projeto, esse mecanismo também passou a operar sobre CRs Sandbox, reforçando a integração com a API declarativa principal em vez de depender apenas de Pods pré-criados.

Na prática, essas extensões transformam o Agent Sandbox em uma interface programável, tornando-o perfeito para automações programáticas ou engenharia de plataformas. Em vez de montar manualmente combinações de Pods, Services, PersistentVolumeClaims, políticas de rede e configurações de runtime, a plataforma pode expor templates e claims como contratos de alto nível. Esse modelo também se conecta aos SDKs oficiais, como os clientes Python e Go, permitindo que aplicações e agentes criem, consultem, reutilizem e removam sandboxes diretamente a partir do próprio fluxo de execução.

Características desejadas e o futuro do Agent Sandbox

O objetivo da comunidade é que o projeto seja independente de fornecedores e capaz de oferecer suporte a diferentes runtimes, como gVisor ou Kata Containers. Essa flexibilidade é importante para permitir níveis mais robustos de isolamento entre o sandbox e o host, incluindo isolamento de kernel e de rede, especialmente em cenários de execução de código não confiável ou ambientes multi-tenant.

Outro ponto desejado é a capacidade de hibernação profunda, com o salvamento do estado em armazenamento persistente e a possibilidade de arquivamento do objeto Sandbox. Com isso, um sandbox poderia ser retomado automaticamente ao se reconectar à rede, aproveitando mecanismos de persistência eficientes, elásticos e provisionados rapidamente.

Também há espaço para explorar o compartilhamento de memória entre sandboxes executados no mesmo host, mesmo quando eles não forem homogêneos. Como esse tipo de capacidade depende do runtime escolhido, os usuários precisarão selecionar uma opção compatível com seus requisitos de segurança e desempenho.

Por fim, o futuro do Agent Sandbox também passa por recursos avançados de identidade e conectividade, como identidades duplas de usuário e sandbox, além de roteamento de tráfego eficiente sem a necessidade de criar serviços individuais para cada sandbox. A proposta é que aplicações e agentes consumam a API Sandbox de forma programática, tornando esse recurso uma base mais flexível para automação e execução segura de workloads.

Conclusão

O Agent Sandbox surgiu como uma resposta natural da comunidade Kubernetes aos novos desafios trazidos pela execução de agentes de IA em ambientes Kubernetes. Ao combinar isolamento, identidade estável, persistência e controle declarativo, ele amplia o modelo tradicional de orquestração de containers para atender cargas de trabalho mais dinâmicas, interativas e sensíveis ao estado.

Embora ainda existam pontos em evolução, como hibernação profunda, suporte a múltiplos runtimes e conectividade mais eficiente, a proposta indica um caminho promissor para tornar a infraestrutura de agentes mais segura, programável e independente de fornecedores. Com isso, o Kubernetes pode se consolidar não apenas como plataforma para aplicações tradicionais, mas também como base para a próxima geração de sistemas autônomos orientados por IA.