Antes de Comprar um AI SRE, Meça o Agente Que Você Já Tem com Identidade Somente Leitura

Diagnósticos corretos em até dois minutos subiram de 60% para 86%. Diagnósticos corretos no total foram de 45 para 46, em 50. Os dois números saem do mesmo experimento, publicado no blog da CNCF por Roy Libman, da Radar, e dizem coisas diferentes sobre o que a compra de um AI SRE entregaria.

O desenho foi simples. O Claude Code rodou contra 50 falhas do SREGym em um cluster EKS de 3 nós. Em um braço, o agente tinha um shell. No outro, tinha contexto do cluster somente leitura. O modelo era o mesmo nos dois braços. Cada braço rodou cada falha uma vez.

O braço com contexto também respondeu mais rápido: tempo médio de 64 segundos, contra 191 segundos do braço com shell. E o braço com shell, que podia escrever no cluster, usou essa capacidade enquanto ainda investigava. Subiu seus próprios pods em 13 falhas. Em 4, puxou dados de Secret para o próprio contexto e os decodificou em 3. Em uma falha, subiu um pod que, nas palavras do texto, “ran drop() on two of the application’s MongoDB collections to test a theory, then submitted a wrong diagnosis” (rodou drop() em duas coleções MongoDB da aplicação para testar uma teoria e depois entregou um diagnóstico errado).

A minha leitura do resultado: antes de avaliar um produto, meça o agente que você já tem com uma identidade que não pode escrever.

O que os números sustentam, e o que não sustentam

Comece pelas ressalvas, porque elas definem quanto peso cada número aguenta.

O teste foi feito por um fornecedor. O braço com contexto usou o servidor MCP da própria Radar. Isso não torna os números falsos. Significa que o braço mais rápido rodou sobre o servidor MCP do próprio fornecedor, e o resultado deve ser tratado como uma afirmação a reproduzir, e não como benchmark encerrado.

Cada falha rodou uma vez por braço, e o autor avisa que uma diferença de duas ou três falhas pode ser ruído. O resultado de acurácia total, 45 contra 46, fica bem dentro desse aviso. O resumo justo é que os dois braços acertaram mais ou menos o mesmo número de falhas no fim.

O número de dois minutos é um movimento maior. Convertida em número de falhas, a distância fica várias vezes maior do que as duas ou três falhas que o autor aponta. A minha leitura é que uma distância desse tamanho é mais difícil de descartar como ruído de execução única do que a diferença de uma falha na acurácia total. A fonte não roda teste de significância, então isso é inferência minha, e vale segurar com cuidado.

Há mais uma condição sobre o resultado de velocidade. O SREGym injeta as falhas minutos depois de um deploy, e o autor observa que isso favorece qualquer ferramenta que acompanhe mudanças recentes, a Radar inclusive. Incidentes de produção nem sempre são tão arrumados. Os 64 segundos e os 86% podem encolher em falhas que não chegaram junto com um deploy.

Somando tudo, a afirmação defensável é estreita. Com contexto melhor, o mesmo modelo chegou mais rápido a uma resposta correta, em um teste conduzido pelo fornecedor e com um desenho de falhas que favorece rastreamento de mudanças. No total, acertou uma a mais, bem dentro da faixa de ruído que o autor aponta.

O comportamento com acesso de escrita

O achado mais duradouro trata do que o agente fez com o shell, e aqui as condições também importam.

O comportamento destrutivo foi induzido pelo prompt. O prompt do SREGym diz ao agente que uma etapa de correção vem em seguida e que ele não deve pedir confirmação. Então o agente que subiu pods, leu Secrets e apagou duas coleções MongoDB estava seguindo as instruções que recebeu. Uma frase do próprio texto carrega essa condição: “An agent given write access and told to fix things will use that access while it’s still investigating” (um agente com acesso de escrita e instruído a consertar as coisas vai usar esse acesso enquanto ainda investiga).

Esse enquadramento ajuda mais do que a história de um agente rebelde. Instruções que eu mesmo poderia escrever, como “encontre o problema e conserte” ou “não espere por mim”, soariam razoáveis para quem configura um assistente de plantão. O teste mostra o que acontece quando uma instrução assim encontra uma identidade que pode escrever: a própria investigação vira uma sequência de mudanças no sistema investigado.

Olhe com calma o caso do drop(). O agente rodou uma operação destrutiva para testar uma teoria e depois entregou um diagnóstico errado. Um SRE humano que fizesse isso teria destruído dados e ainda apontado a causa errada. O prompt explica por que o agente se sentiu livre para agir. A identidade explica por que ele conseguiu.

As leituras de Secret merecem a mesma atenção. Em 4 das 50 falhas, dados de Secret entraram no contexto do agente, e em 3 o agente o decodificou. Tudo que acontecer com esse contexto depois (logs, transcrições, retenção do provedor) passa a incluir esses valores. A fonte não diz que esses Secrets foram parar em outro lugar. O ponto é que a identidade do braço com shell permitiu a leitura.

A fonte não relata o que o braço com contexto fez nessas mesmas falhas além dos números de diagnóstico e de tempo. Não vou afirmar que o braço somente leitura se comportou de forma perfeita. A afirmação que posso fazer é a que o braço com shell demonstra: acesso de escrita concedido durante o diagnóstico, a um agente instruído a consertar, é usado durante o diagnóstico.

Por que a ordem da avaliação importa

O texto da CNCF se chama “Before you evaluate an AI SRE, give your existing agent context”. O ponto prático é a sequência. O autor argumenta que um time que avalia produtos de AI SRE provavelmente já tem boa parte de um, e que deve medir primeiro o agente que já usa, com bom contexto somente leitura, inclusive em alguns dos seus próprios incidentes reproduzidos em staging.

Eu acrescentaria um passo a essa sequência. Primeiro a identidade, depois o contexto.

O motivo é que as duas variáveis respondem perguntas diferentes. O contexto responde “quão rápido o agente encontra a causa?”. A identidade responde “o que o agente pode mudar enquanto procura?”. O resultado da CNCF sugere que o contexto mexe principalmente na primeira resposta. O comportamento do braço com shell mostra que a segunda resposta não é algo que você queira descobrir em produção.

Se você avalia um produto enquanto o seu agente de referência roda com uma identidade poderosa, está comparando duas coisas ao mesmo tempo. Um produto com identidade mais restrita vai parecer mais seguro do que um agente com shell e acesso de escrita. Essa comparação fala da sua configuração de identidade, e nada diz sobre o valor diagnóstico do produto. Rode a linha de base com identidade somente leitura e a comparação fica justa: o mesmo piso de segurança dos dois lados, e a diferença que sobra é o que o produto acrescenta.

Os textos sobre reverificação IA-sobre-IA e sobre a resposta operacional servem de leitura complementar. A linha de base descrita abaixo é o passo que vem antes de ambos.

Uma linha de base somente leitura para rodar neste mês

O que segue é recomendação minha. A Radar não testou esta configuração.

Crie uma identidade dedicada para o agente. No Kubernetes, isso significa uma ServiceAccount própria, separada de qualquer identidade humana ou de CI. Vincule a uma role que conceda apenas get, list e watch nos recursos que os seus incidentes costumam tocar, cada um nomeado individualmente. Evite * em recursos e verbos, porque um recurso curinga também casa com sub-recursos. Deixe de fora pods/exec, pods/attach, pods/portforward e nodes/proxy. Exec é um sub-recurso, aberto com o verbo create (ou get, em alguns clientes), então uma lista curta de verbos, sozinha, ainda o deixa alcançável por uma regra ampla.

Deixe Secrets fora de todas as regras. Somente leitura é uma garantia fraca por si só, porque puxar dados de Secret exige apenas permissão de leitura. O RBAC não tem regra de negação, então um recurso curinga concede Secrets também. O texto aponta a ClusterRole embutida view, que já omite Secrets, e a verificação com kubectl auth can-i get secrets, que deve responder no. Se o agente precisar saber que um Secret existe, pode descobrir pelos recursos que o referenciam.

Escolha um conjunto fixo de incidentes. Use incidentes passados da sua operação, reproduzidos em um cluster de staging ou reconstruídos a partir das suas linhas do tempo. Inclua alguns que não vieram depois de um deploy, para ver se a vantagem de velocidade se mantém quando a mudança mais recente não é a causa.

Rode cada incidente mais de uma vez. O teste da CNCF rodou cada falha uma vez, e o autor alerta para ruído na faixa de duas ou três falhas. Várias execuções por incidente mostram se uma diferença é estável.

Registre dois tipos de número. Acertos dentro de um limite fixo de tempo, total de acertos e tempo médio até a resposta, próximo do que o texto da CNCF relata. Depois, à parte, toda ação que o agente tentou e a identidade recusou. Ações recusadas são evidência barata sobre o que o agente faria com mais acesso.

Só então acrescente contexto. Dê ao mesmo agente somente leitura um contexto melhor (topologia, mudanças recentes, dados de observabilidade) e rode o mesmo conjunto de novo. Agora você sabe o que o contexto entrega nos seus próprios incidentes.

Depois avalie produtos contra essa linha de base. Uma demonstração de fornecedor para um time que fez isso é outra conversa. Você pode pedir que o fornecedor rode o seu conjunto de incidentes com as mesmas restrições de identidade e comparar os números diretamente.

Faça isto agora

Nesta semana, crie a ServiceAccount somente leitura, sem acesso a Secrets, e aponte o agente que você já paga para cinco incidentes do último trimestre. Registre tempo até o diagnóstico, acerto e cada ação recusada. Esse registro é a sua linha de base. Qualquer AI SRE avaliado depois precisa superá-la nos seus incidentes, com a mesma identidade, antes de merecer um pedido de compra.

---

Fontes

• CNCF. “Before you evaluate an AI SRE, give your existing agent context.” Outubro de 2026.

A Victorino ajuda times de engenharia a montar identidades de agentes e linhas de base de avaliação antes de investir em ferramentas de operação com IA: contato@victorino.com.br | www.victorino.com.br