OpenShell no Kubernetes: guia para engenheiros de plataforma isolarem agentes de IA com sandbox e políticas em YAML

O ponto central do guia é a separação de papéis. O OpenShell não traz scheduler próprio. No Kubernetes, o backend usa o Agent Sandbox (recurso Sandbox agents.x-k8s.io, do SIG Apps), e cada agente vira Pod, Service, PVC, Secret e NetworkPolicy. O que o OpenShell acrescenta é a visão que o Kubernetes não tem: qual agente chama, qual binário fez a requisição e se um POST pode sair do cluster. Uma NetworkPolicy libera api.github.com na 443, mas não diferencia um curl que lê issues de um que cria issues. O OpenShell diferencia e altera a regra num sandbox em execução, sem reiniciar.

O fluxo de criação é rígido. O CLI fala com o gateway por mTLS, sem tocar na API do Kubernetes. O gateway grava o registro na fase Provisioning (a fonte de verdade, não o Pod) e o driver cria duas NetworkPolicies: uma para os Pods de workload, sem saída e com entrada só dos supervisors na TCP 5500, outra para os Pods de supervisor. Depois o driver relê o Pod admitido e falha a criação se um webhook mexeu em UID, capabilities, seccomp ou token de ServiceAccount. A demo nirmata/demo-openshell roda tudo em kind com Kubernetes 1.35, Cilium 1.20, Agent Sandbox v1.0.5, OpenShell 0.1.3 e Kyverno 1.18.2. Exige CNI que aplique ingress e egress (a demo troca o kindnet pelo Cilium).

Limitações declaradas: sandboxes só nascem pela Gateway API, e há uma issue aberta (openshell/#1719) para um CRD OpenShellSandbox e um operator. Um Pod de supervisor por agente isola bem, mas pode não escalar em ambientes grandes. O roadmap prevê opções mais flexíveis (RFC 0018). O guia também compara com o Agent Substrate, que tem scheduler e runtime próprios e suspende agentes ociosos, e propõe Kyverno em modo Enforce (seis ValidatingPolicies e uma MutatingPolicy em CEL) para o que o RBAC não vê, como imagens, tamanho e credenciais.

A cobertura anterior acompanha esse tema desde antes. Em 23 de março de 2026, o CEVIU noticiou "Executando Agentes no Kubernetes com Agent Sandbox", quando o projeto estava chegando ao Kubernetes. Em 4 de abril de 2026, "Segurança do Meu Agente com Openshell" tratou das restrições de filesystem e rede via Landlock, e em 17 de julho de 2026 o CEVIU noticiou a introdução do OpenShell pela NVIDIA, com a ressalva de que a governança da frota ainda era um desafio. Agora o guia mostra as duas peças juntas: o OpenShell sobre o Agent Sandbox, com fluxo de ciclo de vida, Cilium e Kyverno. Em 26 de outubro de 2026, o CEVIU publicou "Kagent e Agent Substrate: sandboxing de agents com isolamento, segurança e escala no Kubernetes", e o guia de 4 de novembro de 2026 coloca o Substrate lado a lado com o OpenShell, com os dois já no CNCF Sandbox.

Para quem opera plataforma, a leitura prática é que o agente deixa de ser um caso à parte e vira objeto Kubernetes, com RBAC, Kyverno, audit log e kubectl funcionando. A divisão do guia é clara: RBAC decide quem cria sandboxes, Kyverno decide o que eles podem conter, e o OpenShell controla cada requisição. Se você tem muitos agentes ociosos e o custo por agente pesa, o Substrate merece avaliação. Se os agentes seguram credenciais reais e tocam produção, o controle por requisição do OpenShell pesa mais. O ponto de atenção é o Pod de supervisor por agente, que pode custar caro em escala.