Kagent e Agent Substrate: sandboxing de agents com isolamento, segurança e escala no Kubernetes

26 de outubro de 2026

Resumo

Sem isolamento, segurança e escala, agents não podem ser implementados de forma adequada em um ambiente controlado: ficam sem policy enforcement que garanta que façam apenas o que devem e sem nenhuma garantia de disponibilidade quando forem necessários.

O kagent atua como runtime para agents declarativos e BYO (incluindo frameworks como langgraph e ADK), e o Agent Substrate fornece o ambiente de sandbox subjacente. Juntos, cobrem essas três necessidades de produção ao executar workloads agentic. O post apresenta os conceitos-chave de agent sandboxing, o uso do Substrate e sua implementação com o kagent. Para acompanhar na prática, é preciso um cluster Kubernetes, e um cluster local com Kind ou Minikube serve.

O texto argumenta que um container rodando em Docker é tecnicamente um sandbox, mas com ingress e egress abertos e sem policy enforcement, o isolamento é "flat". Um sandboxing eficaz exige que código não confiável de agents não escape para o host, que o blast radius do harness seja minimizado, que credenciais, saídas do modelo e tool calls fiquem em uma fronteira isolada, que haja snapshots do estado dos agents e que o multiplexing em ambientes multi-tenant seja isolado. Para isso, é preciso isolamento em nível de hardware e software, além de policy enforcement no AI Gateway.

No Agent Substrate, os agents rodam em Workers, que são Pods, e são operados por Actors gerenciados pelo ateapi, o control plane do Substrate. O isolamento em software usa o gVisor, com um kernel de aplicação em user space chamado Sentry, que intercepta e trata as chamadas de sistema. O isolamento em hardware usa microVM, cujo sistema operacional convidado roda diretamente nos núcleos físicos de CPU por meio de extensões de virtualização.

Aprofundamento CEVIU

Aprofundamento

O ponto central do texto é que sandbox sem política é pouco sandbox. Um container em Docker com ingress e egress abertos tecnicamente isola, mas o isolamento é "flat": o workload manda pacote para onde quiser, sem policy enforcement. Network policies e segmentação ajudam, mas não mudam a natureza do arranjo.

No Agent Substrate, os agents rodam em Workers (Pods), operados por Actors que o ateapi, o control plane, gerencia. Há duas camadas de isolamento: gVisor em software, com o kernel de aplicação Sentry interceptando syscalls em user space, e microVM em hardware, com o SO convidado rodando direto nos núcleos de CPU via extensões de virtualização. O kagent entra como runtime, com UI e CRDs declarativos. Sem ele, a entrada seria só chamada programática (um curl no Actor).

Na prática, o Helm do kagent cria por padrão um WorkerPool com dois Workers (Pods), via substrateWorkerPool.create=true. O AgentTemplate funciona como uma "golden image" reutilizável, e o Harness é o Actor em si (Codex, Claude Code ou um BYO com langgraph). Um Actor só roda com sessão ativa: nova sessão sobe um Actor, sessão existente reaproveita, e ele desce ao fim. O contador na aba Substrate passou de 0/8 para 0/9 e 0/10 a cada sessão nova.

O que mudou

O Agent Substrate já tinha aparecido na cobertura. Em 12 de junho de 2026, o CEVIU noticiou "Agent Substrate habilita agentes de IA no Kubernetes com kagent": a Solo.io anunciou colaboração com o Google no projeto, open source, para rodar agents em sandboxes no Kubernetes. Agora o foco sai do anúncio e vai para o passo a passo: arquitetura (Workers, Actors, ateapi), as duas camadas de isolamento e a instalação com o kagent v1.0.

Em 25 de junho de 2026, o CEVIU publicou "Execução segura de agentes de IA dentro do Kubernetes", com checklist de NetworkPolicies, gVisor/Kata e RBAC de privilégio mínimo. O texto atual mostra gVisor e microVM embutidos numa plataforma, em vez de montados à mão.

Por que isso importa

Para quem opera plataforma, a leitura é que o isolamento deixa de ser montagem artesanal de NetworkPolicy e RuntimeClass e passa a ser um componente com control plane próprio. O modelo de Actor por sessão também sugere custo de hardware proporcional ao uso, algo a medir no seu cluster antes de apostar. Vale testar em Kind ou Minikube, como o texto propõe, antes de levar para produção.

Linha do tempo

12/06/2026
CEVIU noticia a colaboração da Solo.io com o Google no Agent Substrate para agents em sandboxes no Kubernetes.
25/06/2026
CEVIU publica checklist de segurança para agents no Kubernetes com NetworkPolicies, gVisor/Kata e RBAC.
26/10/2026
Post da CNCF mostra o sandboxing de agents com kagent e Agent Substrate, com isolamento em gVisor e microVM.

Perguntas frequentes

Qual a diferença entre o kagent e o Agent Substrate?

O kagent é o runtime para agents declarativos e BYO, com UI e CRDs. O Agent Substrate é a plataforma de sandbox por baixo, que fornece o isolamento. Sem o kagent, a interação com o Substrate seria só programática, por exemplo com curl no Actor.

Como funciona o isolamento no Agent Substrate?

Há duas camadas. O gVisor faz isolamento em software, com o kernel Sentry em user space interceptando syscalls. A microVM faz isolamento em hardware, com o SO convidado rodando direto nos núcleos de CPU por extensões de virtualização.

Preciso de um cluster de produção para testar?

Não. Um cluster local com Kind ou Minikube serve. Sem cluster, dá para acompanhar só a parte conceitual até ter um disponível.

Por que o número de Actors aumenta a cada teste?

Cada nova sessão sobe um novo Actor, que desce quando a sessão termina. Reusar uma sessão existente não altera a contagem. O comportamento se liga à eficiência de recursos de hardware do Substrate.

Fontes

cncf.iofonte original

Avalie este artigo:

Categoria: CEVIU DevOps
Publicado: 26 de outubro de 2026
Editoria: CEVIU DevOps