A Cloud Native Computing Foundation publicou uma orientação esta semana com um argumento específico e importante para quem implanta cargas de LLM em Kubernetes: as primitivas de infraestrutura que o K8s oferece (roteamento, isolamento de rede, RBAC em nível de pod, gerenciamento de secrets) são necessárias mas não suficientes para segurança de LLM. A observação de fundo é que um LLM não é uma carga de cômputo sem estado. É um sistema que aceita input não confiável e decide o que fazer com ele, incluindo se invoca ferramentas, emite dados sensíveis ou segue instruções que aparecem dentro do seu prompt. Esse modelo de ameaça é diferente de "conteinerize este microsserviço e isole-o", e precisa de controles que vivam na camada de aplicação e de prompt, não na camada de cluster.

A lista específica da CNCF do que o Kubernetes não consegue fazer é útil. O Kubernetes não consegue determinar se um prompt deveria passar para o modelo, se uma resposta contém dados sensíveis que deveriam ser redatados antes de chegar ao usuário, ou se o modelo deveria ter acesso a uma ferramenta específica para uma request específica. A camada de infraestrutura cuida de roteamento e isolamento de pods. A camada de aplicação tem que cuidar de autenticação, autorização, validação de input, filtragem de output, decisões de acesso a ferramentas, e logging de auditoria do que o modelo de fato fez. O OWASP Top 10 para aplicações LLM é o melhor checklist atual dos modos de falha que os controles em nível de aplicação precisam endereçar: injeção de prompt, divulgação de informação sensível, ataques de cadeia de suprimentos, envenenamento de dados e modelos, manuseio impróprio de output, agência excessiva, vazamento de prompt de sistema, fraquezas de vetores e embeddings, desinformação, e consumo ilimitado. Se seu deploy de LLM não tem controles explícitos para cada um desses itens, o fato de ele rodar em um cluster Kubernetes seguro não o torna seguro.

Isso encaixa no padrão maior de 2026 que atravessou as matérias cobertas aqui a semana toda: a camada de governança para cargas de agente e LLM está virando uma categoria de primeira classe, separada da camada de modelo e separada da camada de infraestrutura. O Agent Registry da AWS envia a versão catálogo-e-auditoria empresarial disso; a CNCF publica a versão de padrões abertos para quem roda infraestrutura LLM baseada em Kubernetes. O programa Kubernetes AI Conformance se expande mais tarde em 2026 para incluir padrões Sovereign AI, o que se amarra diretamente ao Sovereign AI Fund do Reino Unido e ao padrão de soberania mais amplo na indústria. Para quem quer implantar LLMs em ambientes regulados ou self-hosted, o caminho open-source K8s-mais-AI-conformance é uma opção real que deixa você escapar do lock-in de hyperscaler enquanto ganha estrutura real de segurança. Para empresas comprometidas com hyperscaler, o Agent Registry da AWS com Bedrock AgentCore é a versão gerenciada. Os dois stacks vão competir pelos mesmos dólares de procurement empresarial.

Para times rodando cargas de LLM em Kubernetes, seguem-se três movimentos. Primeiro, audite seu deploy atual contra o OWASP Top 10 para aplicações LLM; se você não tem controles nomeados para cada um dos dez itens, comece pelos que cobrem validação de input, filtragem de output e autorização de acesso a ferramentas, porque esses fecham a maior superfície de ataque. Segundo, separe a postura de segurança de infraestrutura da postura de segurança em nível de aplicação na sua documentação interna; uma auditoria de compliance que diz "nosso cluster K8s está CIS-benchmarked" não é a mesma coisa que "nosso deploy de LLM é production-safe", e os dois pertencem a times diferentes com habilidades diferentes. Terceiro, acompanhe o programa CNCF AI Conformance durante o resto de 2026; os padrões Sovereign AI que vêm mais tarde neste ano provavelmente vão se tornar a arquitetura de referência de facto para deploys de LLM em indústria regulada, e estar cedo nessa spec vale mais do que correr atrás depois que sai. Para times em stacks gerenciados por hyperscalers, os mesmos princípios se aplicam com nomes de produto diferentes: Bedrock, Vertex AI e Azure AI Foundry todos têm superfícies equivalentes de controle em nível de aplicação que precisam ser configuradas, não presumidas.