Quando um agente de IA vira o seu SRE, permissão passa a ser engenharia de confiabilidade

Um assistente de chat que erra a resposta faz alguém perder alguns minutos. Um agente de operação que toma a ação errada durante um incidente pode transformar uma queda parcial numa queda total. Por isso, as decisões mais importantes no desenho de agentes de operação não são sobre o modelo. São sobre o que o agente pode ler, o que pode propor e o que pode fazer.

A AWS tem dois agentes que deixam isso concreto. O AWS DevOps Agent, em disponibilidade geral (GA) desde março de 2026 e com a referência de API atualizada em 2 de outubro, funciona como um colega de operação sempre disponível. O AWS Well-Architected Agent, anunciado em preview em 1º de outubro, leva a revisão de arquitetura para o mesmo modelo.

O que cada agente faz

A AWS descreve o DevOps Agent como um agente que resolve e previne incidentes, otimiza confiabilidade e desempenho e executa tarefas de SRE sob demanda na AWS, em outras nuvens e em ambientes on-premises. Ele trabalha com ferramentas de observabilidade, runbooks, repositórios de código e pipelines de CI/CD, e cruza telemetria, código e dados de deploy. As integrações incluem GitHub, GitLab, Dynatrace, Datadog, New Relic, Splunk, ServiceNow e servidores MCP.

O Well-Architected Agent é a evolução, com IA, do Trusted Advisor e da Well-Architected Tool. Ele lê configurações, métricas de uso e topologia de aplicação por meio de roles do IAM gerenciadas pelo cliente, compara tudo com as práticas do Well-Architected em mais de 65 serviços e prioriza os achados conforme os objetivos de negócio que o cliente declara. Também revisa projetos de Terraform, CloudFormation e CDK antes do deploy. Cada achado vem com um pacote de implementação: runbook do SSM, script de CLI ou passo a passo no console. O preview roda em US East (N. Virginia), US East (Ohio) e US West (Oregon), aceita workloads de qualquer região comercial e exige um plano de AWS Support.

Os limites que a AWS escolheu

Lendo o changelog do DevOps Agent dos últimos meses, aparece um modelo de permissão bem claro:

• Ler é o padrão. Ações de leitura vêm habilitadas. Ações dirigidas que criam ou alteram recursos vêm desabilitadas e precisam ser ligadas explicitamente, com uma política gerenciada e nas preferências do Agent Space.
• Proposta antes da ação. Quando um alarme dispara uma investigação, o agente apresenta propostas de mitigação que o operador revisa e ajusta antes de aplicar.
• Toda aprovação tem nome. Segundo a AWS, cada aprovação e cada ação ficam atribuídas ao operador que aprovou, no AWS CloudTrail.
• Código roda isolado. O código de investigação roda numa microVM isolada por investigação, com chamadas à AWS limitadas a leitura.
• Quem decide o acesso de escrita ao código é o cliente. O GitHub App próprio pode ser criado com acesso só de leitura ou de leitura e escrita.

O Well-Architected Agent vai ainda mais longe no lado conservador: não muda nada sozinho. O cliente escolhe o caminho de correção e executa.

1. Ler telemetria, código e deploys
2. Investigar e correlacionar
3. Propor mitigação ou correção
4. Operador aprova
5. Ação dirigida, se habilitada
6. Registro no CloudTrail

• Ligado por padrão: Ler telemetria, código e deploys · Investigar e correlacionar · Propor mitigação ou correção
• Opcional e rastreável: Operador aprova · Ação dirigida, se habilitada · Registro no CloudTrail

Autonomia do agenteAutoridade humana e evidência

Por que permissão virou decisão de confiabilidade

Na prática clássica de SRE, a confiabilidade vem de limitar o raio de impacto: mudanças pequenas, rollout gradual, rollback rápido. Um agente de operação é uma nova fonte de mudança, então a mesma disciplina vale para ele:

Dê ao agente o escopo de uma conta de serviço, não o de um engenheiro sênior. O Agent Space define quais contas e recursos o agente enxerga. Comece estreito. É o mesmo desenho da autonomia com limites que vimos no SOC agêntico: autonomia para ler, autoridade para escrever.

Dê ao agente uma identidade própria. Se as ações rodam numa role de administrador compartilhada, ninguém consegue separar depois o que o agente fez do que uma pessoa fez. É o argumento para tratar a identidade de agentes como disciplina própria de IAM.

Trate mitigação aplicada pelo agente como mudança. Ela precisa passar pela gestão de mudanças e deixar ticket e revisão pós-incidente, não só uma linha no CloudTrail.

Saiba para onde vão os dados. Aqui está o ponto que mais pesa para empresas brasileiras. O DevOps Agent está disponível em São Paulo, e os dados do Agent Space (investigações, topologia, recomendações) ficam na região onde ele é criado. Mas a documentação de segurança da AWS diz que, para Agent Spaces em São Paulo, a inferência é roteada globalmente, para a região que a AWS considerar ideal, e que políticas de controle de serviço que restringem regiões não se aplicam a essa inferência. Ou seja: prompts e respostas, que contêm trechos de logs, podem ser processados fora do país. Para a LGPD, isso é transferência internacional de dados pessoais, regulada pela Resolução CD/ANPD nº 19/2024, e precisa de mecanismo e base legal. A mesma documentação avisa que o agente não filtra dados pessoais ao resumir logs. A conclusão prática: mascarar CPF, e-mail e dados de cliente antes que cheguem aos logs deixou de ser boa prática e virou pré-requisito.

O que muda na revisão de arquitetura

Revisões Well-Architected costumam ser questionários periódicos. Um agente que lê configuração viva e IaC transforma isso em algo próximo de revisão contínua: o desvio aparece quando acontece, não na próxima sessão trimestral. A responsabilidade, porém, não muda de lugar. O agente recomenda e empacota a correção; o arquiteto decide, e a mudança passa pelo pipeline como qualquer outra, de preferência com a revisão de IaC pegando o problema antes do deploy, como fazem os agentes do Google dentro da revisão de código. Vale notar que, durante o preview, a análise roda em regiões dos Estados Unidos, mesmo para workloads em São Paulo; a configuração da sua conta passa a ser lida de lá.

O que fazer agora

1. Escreva a escada de permissões antes de ligar qualquer coisa: ler, propor, agir com aprovação, agir sozinho. Coloque cada tipo de ação num degrau.
2. Mantenha as ações dirigidas desligadas até existir um playbook dizendo quais mitigações o agente pode executar e quem aprova.
3. Crie uma role dedicada por Agent Space com escopo nas contas necessárias.
4. Leve a questão da inferência global ao encarregado de dados antes de conectar logs com dados pessoais, e mascare esses dados na origem.
5. Encaminhe as propostas do agente para o processo de mudanças, para que uma mitigação aprovada carregue um ticket.
6. Meça a ajuda: tempo até a primeira hipótese útil, proporção de propostas aceitas, propostas que teriam piorado a situação.

Para fechar

Os agentes de operação da AWS mostram um padrão sensato: ler à vontade, propor com generosidade, agir só com permissão explícita e aprovador com nome. Vale adotar esse padrão como política da empresa, e não só como configuração de produto, porque o próximo agente de operação que chegar talvez não venha com a mesma prudência. No Brasil, a política precisa de mais uma linha: onde a inferência acontece.