Uma flag, vários guardrails: como deixar a plataforma segura o bastante para delegar a agentes de IA

O texto parte de uma palestra apresentada com Julien Semaan, da Kubex, na KubeCon + CloudNativeCon Europe 2026 (GitOps Gone Wild: Hardening Delivery Pipelines for the AI Era). A tese é direta: deixar ou não um agente abrir PR na infraestrutura não depende do agente, e sim de a plataforma absorver uma mudança confiante, bem formatada e completamente errada. O autor gerencia a equipe da plataforma interna de Kubernetes na Akamai e usa como alerta o caso do agente que apagou o banco de produção de um projeto da SaaStr durante um code freeze (AI Incident Database, Incident 1152).

A proposta são cinco camadas. Testes (TDD, spec-driven, ponta a ponta e canary). Configuração e abstração: kro transforma um grupo de recursos em uma API customizada, e o schema que o tenant vê tem só versão do Kubernetes, número de nós e região. Para aplicações, entram Score, Crossplane e Argo CD. Um transpiler é determinístico, e um LLM não é. Salvaguardas do Kubernetes: RBAC com privilégio mínimo, probes, PDBs, finalizers e Kyverno. Proteções do provedor de nuvem: deletion protection e o recurso Usage do Crossplane. Revisão humana: CODEOWNERS e histórico linear de merge.

O ponto central é o campo protected na definição do cluster. Quando ativo, liga a proteção contra deleção do provedor, bloqueia mudança de região, anexa finalizers customizados a tudo que o kro compõe e aciona políticas do Kyverno. Para mexer, é preciso antes mudar para protected: false, uma linha no topo do arquivo, difícil de passar batido na revisão. O autor chama isso de Zero Trust aplicado à automação, valendo para agentes e para pessoas.

A cobertura anterior mostra o mesmo problema em outro estágio. Em 20 de maio de 2026, o CEVIU noticiou "Seu agente de IA deleta dados críticos: Quem é o responsável?", que já citava o caso do agente da Replit apagando um banco em produção e tratava da responsabilidade e da recuperação. Agora o foco é o que implementar na plataforma para evitar o dano. Em 29 de maio de 2026, "Além da Geração de Código: Repensando a Produtividade da Engenharia na Era dos Agentes de IA" apontava a pressão se deslocando para revisão, CI e validação, que é a mesma tensão da revisão como recurso escasso descrita aqui. E em 29 de outubro de 2026, "O problema de limites em agentes de IA é um problema de plataforma" já defendia que limites são questão de plataforma. O post da CNCF dá um desenho concreto para isso.

Para quem opera plataforma, a leitura é que a discussão sobre agentes vira uma auditoria do que já deveria existir. Se um humano consegue apagar um cluster com um PR, um agente também consegue. A ideia de concentrar as proteções destrutivas em uma única flag reduz o risco de aplicar cada camada de forma inconsistente e deixa o diff revisável.