Contendo o operador autônomo: arquitetura de defesa em profundidade para agentes de IA no Kubernetes
O artigo propõe um framework de defesa em camadas para conter agentes de LLM que operam diretamente sobre clusters Kubernetes em produção, partindo da premissa de que o modelo deve ser tratado como potencialmente comprometido por prompt injection. A proposta inclui uma taxonomia de ameaças, nove princípios de design e sete camadas de controles mapeadas a mecanismos nativos do Kubernetes. Trata-se de uma proposta arquitetural qualitativa, sem números de taxa de sucesso de ataque ou overhead medidos experimentalmente.
O trabalho parte de uma constatação incômoda para quem opera infraestrutura: agentes de LLM estão deixando de ser apenas interfaces de chat e passando a ler telemetria, chamar ferramentas, gerar código e alterar o estado de clusters Kubernetes de produção. Isso rompe uma fronteira que a segurança cloud-native tradicional sempre assumiu como estável: a separação entre dados e controle. Um log, um ticket ou a descrição de uma ferramenta — conteúdo que o agente apenas lê — pode, via prompt injection, redirecionar o que o agente efetivamente faz no cluster.
A resposta proposta é tratar o próprio modelo como não confiável por definição, assumindo que ele pode estar totalmente comprometido, e mover toda a garantia de segurança para a camada de infraestrutura. Concretamente, o framework define dez classes de ameaça alinhadas a diretrizes emergentes da OWASP para aplicações agenticas, nove princípios de design centrados em mediação completa na fronteira de chamada de ferramentas, e sete camadas de defesa que mapeiam cada princípio a mecanismos já existentes no ecossistema Kubernetes: identidade de workload, RBAC e ValidatingAdmissionPolicy, sandboxing via gVisor/Kata, políticas de egress sensíveis a FQDN, um gateway de agente/MCP com policy-as-code sobre argumentos de ferramentas, e enforcement em tempo de execução via eBPF.
Para quem constrói ou opera essas plataformas, o valor prático está em reconhecer que colocar um LLM no loop de operações de infraestrutura não é apenas uma questão de prompt engineering seguro — é um problema de arquitetura de rede, identidade e isolamento, como qualquer outro workload não confiável que recebe entrada externa. A ênfase em quebrar a combinação de entrada não confiável, acesso sensível e egress externo é o núcleo de qualquer estratégia de contenção realista contra prompt injection.
Vale notar que o próprio artigo é honesto sobre suas limitações: não há números medidos de taxa de sucesso de ataque nem de overhead de performance — a contribuição é a arquitetura de referência, com artefatos de política concretos para EKS, AKS e GKE, e quatro walkthroughs qualitativos de ataque, deixando a validação empírica como trabalho futuro proposto.