OpenShell no Kubernetes: como isolar agentes de IA com sandbox, política de rede e credenciais protegidas

O ponto central para quem opera plataforma é que o OpenShell não traz scheduler próprio. No backend Kubernetes ele usa o Agent Sandbox (recurso Sandbox agents.x-k8s.io, do SIG Apps), e cada agente vira Pod, Service, PVC, Secret e NetworkPolicy. O gateway é dono do sandbox e grava o registro na fase Provisioning, que é a fonte da verdade, não o Pod. Clientes falam com o gateway via mTLS e nunca com a API do Kubernetes.

O fluxo de criação tem várias travas. O driver cria primeiro as duas NetworkPolicies (workload sem saída, entrada só dos supervisors na TCP 5500) e só depois o Sandbox, suspenso. Após a admissão, ele relê o Pod e falha se algo mudou: UID e GID não root, sem capabilities, seccomp RuntimeDefault, sem host namespaces, sem token de ServiceAccount. O demo (nirmata/demo-openshell) roda em kind com Kubernetes 1.35, Cilium 1.20, Agent Sandbox v1.0.5, OpenShell 0.1.3 e Kyverno 1.18.2. Ali, o Kyverno aplica sete políticas em Enforce (seis ValidatingPolicy e uma MutatingPolicy, em CEL) que olham a requisição, não quem envia, e valem até para o gateway.

Há limites declarados. Sandboxes só nascem pela API do Gateway (a issue openshell/#1719 propõe um CRD OpenShellSandbox e um operator), e um Pod de supervisor por agente pode não escalar em ambientes grandes (RFC 0018). O comparativo com o Agent Substrate mostra a troca: o OpenShell dá política por requisição e objetos visíveis a RBAC, Kyverno e kubectl. O Substrate dá densidade, suspendendo agentes ociosos, mas guarda atores e políticas de egress em API própria com PostgreSQL. A RFC 0012, mesclada em 10 de setembro de 2026, torna o isolamento um backend plugável, e há proposta de um backend Substrate (NVIDIA/OpenShell#3362), ainda sem resposta de mantenedor na última checagem de 11 de outubro.

O CEVIU já tratou o tema. Em 4 de abril de 2026, em "Segurança do Meu Agente com Openshell", o foco era a ideia de governança externa com restrições de filesystem e rede via Landlock. Em 17 de julho de 2026, "NVIDIA OpenShell Protege Agentes de IA, Mas a Governança da Frota Ainda é um Desafio" apresentou o runtime e apontou a gestão em escala como lacuna. Agora o material mostra o encaixe concreto no Kubernetes, com Agent Sandbox, gateway, NetworkPolicies e Kyverno, e o OpenShell já como projeto CNCF Sandbox.

Em 26 de outubro de 2026, o CEVIU noticiou "Kagent e Agent Substrate: sandboxing de agents com isolamento, segurança e escala no Kubernetes". A notícia de hoje coloca Substrate e OpenShell lado a lado e discute a possível integração futura entre os dois. Em 4 de novembro de 2026, o CEVIU publicou "OpenShell no Kubernetes: guia para engenheiros de plataforma isolarem agentes de IA com sandbox e políticas em YAML", sobre o mesmo guia da CNCF.

Leitura editorial: para quem opera plataforma, o ganho é tratar agente como workload comum, com RBAC e admission control que a equipe já domina. A escolha entre OpenShell e Substrate parece passar por perfil de carga: agentes com credenciais reais e acesso a produção pedem controle por requisição, e muitos agentes ociosos pedem densidade e custo por agente. Quem adotar o OpenShell hoje deve planejar o Kyverno desde o início, porque o próprio runtime deixa imagens, limites e credenciais por conta do time.