kagent em producao: 7 camadas de controle que ninguem esta falando

"Um deployment faz o que o manifesto diz. Um agent faz o que o contexto sugere."

Essa frase parece simples, mas ela carrega o ponto central de tudo que vou falar aqui. Quando voce escreve um Deployment no Kubernetes, o comportamento e determinIstico. O manifesto declara 3 replicas, imagem X, porta Y — e e exatamente isso que acontece. Sem surpresas.

Agora imagina um agente de IA rodando dentro do cluster. Ele recebe um contexto — logs de erro, metricas anomalas, um alerta do PagerDuty — e decide o que fazer. Escalar um HPA? Fazer rollback de um deployment? Isolar um pod? A decisao nao esta no manifesto. Esta no modelo. E isso muda absolutamente tudo sobre como voce precisa pensar em seguranca.

O kagent acabou de chegar no ecossistema Cloud Native e esta fazendo exatamente isso: trazendo agentes de IA para dentro do Kubernetes de forma nativa. E se voce acha que os controles tradicionais dao conta do recado, esse artigo e pra voce.

O que e o kagent e por que voce deveria prestar atencao

O kagent e um projeto open-source, mantido pela Solo.io, que entrou recentemente no CNCF Sandbox. Isso ja diz muita coisa: a Cloud Native Computing Foundation nao aceita qualquer projeto. Existe um processo de avaliacao, e estar no Sandbox significa que a comunidade reconhece o potencial.

Na pratica, o kagent faz o seguinte: ele permite que voce defina agentes de IA como recursos nativos do Kubernetes via CRDs (Custom Resource Definitions). Cada agente tem um conjunto de ferramentas MCP (Model Context Protocol) que determinam o que ele pode fazer — listar pods, inspecionar logs, executar comandos via kubectl, interagir com Helm, Istio, e outros componentes do ecossistema.

A arquitetura e elegante: voce declara o agente, define as tools disponiveis, configura o modelo LLM backend e faz deploy. O agente roda como um workload no cluster, com acesso ao que voce definir.

Mas aqui mora o problema. A facilidade de deploy nao significa facilidade de operar com seguranca. E e exatamente ai que a maioria dos times esta errando.

As 7 camadas de controle para kagent em producao

Vou ser direto: se voce esta colocando kagent (ou qualquer agent framework) em producao sem essas camadas, voce esta construindo um incidente esperando pra acontecer. Vamos la.

1 RBAC — Least Privilege para Service Accounts dos agentes

Essa e a camada mais obvia e, mesmo assim, a mais negligenciada. O agente precisa de um ServiceAccount dedicado, e esse ServiceAccount precisa ter o minimo de permissoes possivel.

Nao use cluster-admin. Nao use roles genAcircos. Crie Roles e RoleBindings especificos para cada agente, limitados ao namespace onde ele opera. Se o agente so precisa ler pods e logs, ele so deve ter get, list e watch em pods e pods/log. Ponto.

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: kagent-reader
  namespace: monitoring
rules:
- apiGroups: [""]
  resources: ["pods", "pods/log", "events"]
  verbs: ["get", "list", "watch"]

Se o agente precisa executar acoes destrutivas (delete pods, scale deployments), isso precisa de uma Role separada com aprovacao explicita. O que me leva a camada 4.

2 Network Policies — Isolamento do blast radius

Um agente comprometido ou com alucinacao nao pode ter acesso irrestrito a rede do cluster. Implemente NetworkPolicy para garantir que o agente so se comunica com os servicos que ele realmente precisa.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: kagent-network-restrict
  namespace: ai-agents
spec:
  podSelector:
    matchLabels:
      app: kagent
  policyTypes:
  - Egress
  egress:
  - to:
    - namespaceSelector:
        matchLabels:
          name: monitoring
    ports:
    - protocol: TCP
      port: 443

Isso parece basico? E. Mas quantos clusters voce ja viu que nao tem nenhuma NetworkPolicy? A resposta e: a maioria. E agora voce vai colocar um agente autonomo la dentro sem isolamento de rede? Boa sorte.

3 Tool Allowlisting — Controle o que o agente pode executar

O kagent usa MCP tools para interagir com o cluster. Cada tool e uma capacidade: listar pods, fazer rollback, editar ConfigMaps, executar comandos via exec. O ponto chave aqui e: nao habilite todas as tools por padrao.

Trabalhe com allowlists explicitas. Se o agente de observability precisa de kubectl-get e kubectl-logs, defina exatamente essas tools no CRD. Nada de kubectl-exec, kubectl-delete ou helm-install no escopo de um agente que deveria apenas monitorar.

Pense no Tool Allowlisting como o equivalente a politica de IAM na AWS: nao e sobre o que o agente quer fazer, e sobre o que ele pode fazer. E voce define isso antes dele existir.

4 Human-in-the-Loop — Aprovacao para acoes destrutivas

Isso nao e opcional. Eu repito: isso nao e opcional.

Qualquer acao que modifica estado — scale, delete, patch, rollback — precisa de uma camada de aprovacao humana. O kagent suporta hooks de confirmacao, e voce pode integrar com Slack, PagerDuty ou qualquer sistema de aprovacao que seu time ja use.

O fluxo ideal: o agente identifica o problema, propoe a acao, envia para aprovacao, e so executa apos confirmacao. Sim, isso adiciona latencia. Nao, isso nao e um bug — e um feature. A velocidade do agente nao vale nada se ele derruba producao as 3 da manha porque alucionou que precisava deletar um StatefulSet.

5 Rate Limiting e Cost Guardrails

Agentes conversam com LLMs. LLMs custam dinheiro. Cada chamada de API, cada reasoning step, cada tool call consome tokens. Sem controle, um agente pode entrar em loop e queimar sua conta da OpenAI/Anthropic em horas.

Implemente:

• Rate limiting por agente: maximo de N chamadas por minuto
• Budget maximo por hora/dia: se o agente ultrapassar $X, ele para e alerta o time
• Circuit breaker: se o agente falhar 3x seguidas na mesma acao, ele para de tentar
• Token cap por request: limitar o tamanho do contexto enviado ao LLM

Isso nao e paranoia. E gestao de custo basica. Ja vi cenarios onde um agent loop queimou $4.000 em uma tarde porque ninguem colocou um guardrail de budget.

6 Observability — OpenTelemetry + Prometheus + Grafana

Voce nao pode operar o que voce nao observa. Cada acao do agente precisa gerar traces, metricas e logs estruturados. Use OpenTelemetry para instrumentar:

• Traces: cada decisao do agente como um span — da entrada do contexto ate a execucao da tool
• Metricas: latencia de decisao, taxa de sucesso/falha, tokens consumidos, custo por acao
• Logs: o reasoning do agente, as tools chamadas, os parametros usados, o resultado

Monte dashboards no Grafana com alertas claros: agente fez mais de X acoes em Y minutos? Alerta. Custo ultrapassou threshold? Alerta. Tool call falhou? Alerta. Nao tem desculpa pra nao fazer isso em 2026 — as ferramentas estao maduras e sao open-source.

Se voce ja tem um stack de observability para seus microservicos, o agente e so mais um servico. Trate ele como tal.

7 Security Scanning — Kubescape 4.0 nos CRDs do kagent

Essa e a camada que quase ninguem esta implementando, e talvez a mais critica. Os CRDs do kagent sao configuracoes de seguranca. Eles definem o que o agente pode fazer, quais tools tem acesso, qual modelo usa. Se esses CRDs estao mal configurados, seu agente e um vetor de ataque.

Integre Kubescape no seu CI/CD. Cada PR que altera um CRD do kagent deve passar por scan automatico. Defina policies especificas para agent workloads: ServiceAccount tem RBAC restrito? NetworkPolicy existe? Tools destrutivas exigem human-in-the-loop? Secret do LLM esta em um Secret Manager?

# Pipeline: scan CRDs do kagent com Kubescape
kubescape scan framework nsa \
  --include-namespaces ai-agents \
  --format json \
  --output kagent-scan-results.json

Automatize isso. Nao dependa de revisao manual para pegar misconfiguracoes. Em escala, humanos erram. Ferramentas de scan nao.

O cenario real: onde a maioria dos times esta hoje

Vamos ser honestos. A maioria dos times que estao experimentando com kagent hoje estao fazendo POCs sem nenhuma dessas camadas. E tudo bem — e um projeto Sandbox, a exploracao faz parte do processo.

O problema e quando a POC vira producao sem que ninguem pare pra pensar nos controles. E isso acontece mais rapido do que voce imagina. O PM viu o demo, ficou impressionado, e na semana seguinte voce tem um agente com cluster-admin rodando no cluster de producao. Eu ja vi esse filme. Nao termina bem.

Os numeros nao mentem: 82% das empresas usam Kubernetes em producao e 57% ja tem agentes de IA interagindo com infra. O gap entre "temos agentes" e "temos agentes com controles adequados" e onde os incidentes moram.

Conclusao: explorar sim, mas com guardrails

O kagent e um projeto promissor. A ideia de ter agentes de IA como cidadaos de primeira classe no Kubernetes e poderosa. A integracao com MCP tools, a extensibilidade, o fato de ser CNCF Sandbox — tudo aponta pra um futuro onde agentes autonomos vao ser parte do dia a dia de operacoes.

Mas futuro promissor nao e desculpa pra negligencia presente.

Explorar e contribuir? Sim, por favor. O projeto precisa de contribuidores, feedback e adocao. Roda num cluster de dev, testa os limites, abre issues, contribui com tools.

Colocar em prod sem guardrails? Boa sorte. Voce vai precisar.

As 7 camadas que eu descrevi aqui nao sao teoria. Sao pratica. Sao o minimo que eu considero aceitavel antes de qualquer agent workload tocar producao. Se voce implementar metade delas, ja esta na frente de 90% do mercado. Se implementar todas, voce esta blindado.

E blindar, como voce sabe, e o que a gente faz aqui.