TL;DR: A semana teve um fio condutor: o console de operação passando para agentes de IA. O Azure SRE Agent foi de alerta a remediação e ganhou ponte para rede privada, Elasticsearch via MCP e monitor de SSL; o AKS recebeu CLI agentic em cluster mode com call_az e call_kubectl; e o GitLab Duo 18.9 abriu self-hosted e BYOM. Por baixo, M8azn de 5 GHz, SageMaker para Nova e o relatório norte-coreano da GitLab lembraram que automação sem RBAC é exposição.
Não houve keynote esta semana, nem um anúncio que sozinho dominasse o noticiário. Houve algo mais revelador: uma repetição. Vários fornecedores, em frentes diferentes, publicaram a mesma ideia com sotaques distintos — o console que historicamente pertencia ao engenheiro de plantão está sendo, peça por peça, entregue a agentes de IA. Não como copiloto que sugere, mas como operador que investiga, correlaciona e propõe remediação.
O retrato é nítido quando se empilha o que saiu. A Microsoft publicou quatro materiais sobre o Azure SRE Agent — resposta reativa a incidentes, investigação em rede privada, monitor de SSL e integração com Elasticsearch via MCP. O AKS ganhou um CLI agentic em cluster mode e novas ferramentas no MCP Server. O GitLab liberou o Duo Agent Platform self-hosted com Bring Your Own Model e colocou o Claude Opus 4.6 com janela de 1 milhão de tokens dentro do pipeline. Três fornecedores, uma só direção.
E, como contraponto que dá sentido a tudo, a própria GitLab publicou um relatório de inteligência de ameaças mostrando o quão profissionalizado ficou o crime que mira exatamente esse pipeline. A leitura para quem opera infra no Brasil é direta: a agentização das operações não é uma promessa de futuro, é uma decisão de arquitetura de agora — e ela só compensa se a camada de governança (RBAC, IAM, segregação de ambientes) for tratada como pré-requisito, não como item de roadmap.
Por que três fornecedores estão entregando o console de operação a agentes ao mesmo tempo?
O caso mais didático é o Azure SRE Agent. No fluxo tradicional de resposta a incidentes, o tempo de 30 a 60 minutos é comum — boa parte gasta em "descoberta de contexto": o engenheiro acorda, autentica, e tateia no escuro para entender o que quebrou. O agente inverte essa ordem: inicia a investigação assim que o alerta dispara, correlaciona telemetria e deduz causa raiz antes de o plantonista estar plenamente consciente do incidente. Num caso de Web App Health Failure por conectividade SQL, ele verificou a configuração do ARM, cruzou métricas via KQL e identificou que o publicNetworkAccess estava desabilitado sem a contrapartida de uma VNet integration. O ponto não é a mágica — é que o trabalho braçal de coleta e correlação saiu da cabeça do humano.
O que chama atenção é a maturidade do ecossistema ao redor do agente nesta mesma semana. Saiu o padrão para ele operar contra um Log Analytics Workspace enclausurado em rede privada (via Azure Functions como proxy reverso dentro da VNet, com Managed Identity e Easy Auth, já que o SRE Agent roda como serviço gerenciado externo). Saiu a integração com Elasticsearch via MCP (Agent Builder MCP endpoint, para Elastic 9.2.0+), permitindo diagnóstico conversacional sobre logs sem montar query DSL na mão. E saiu um walkthrough de monitor de certificado SSL em Python virando tool e skill do agente — um runbook injetado que classifica risco (EXPIRED, CRITICAL, WARNING) e executa verificações em paralelo. É a estampa de uma plataforma saindo da demo e entrando na operação.
Do lado do AKS, o movimento é o mesmo aplicado ao cluster. O cluster mode do CLI agentic (public preview) ataca um problema real de governança: até então, cada operador subia sua própria instância do agente de diagnóstico, frequentemente com cluster-admin — privilégio excessivo e visibilidade de compliance fragmentada. O cluster mode centraliza esse baseline. Na mesma leva, o AKS MCP Server ganhou call_az e call_kubectl (também preview) para cortar o context-switching entre CLIs. E o GitLab fecha o trio levando o agente para dentro do fluxo de entrega: o Duo 18.9 com self-hosted, BYOM e o Opus 4.6 orquestrando complex development workflows com human-in-the-loop mantido.
A conta da autonomia é paga em RBAC: governança como pré-requisito, não opcional
Há um padrão que se repete em cada um dos anúncios acima, e ele não é sobre inteligência do modelo — é sobre permissão. O Azure SRE Agent só é seguro com RBAC granular: a recomendação explícita da Microsoft é começar em modo de aprovação, garantir que o agente tenha apenas os direitos para diagnosticar e aplicar o plano estabelecido, e tratar Incident Response Plans (IRP) como o mecanismo que ensina o agente o que é um "processo runaway" antes que ele derrube um processo crítico por engano. O AKS cluster mode "transfere a responsabilidade para a definição correta de RBAC em nível de cluster" — a frase é praticamente um aviso. E o GitLab BYOM é explícito: a orquestração é dele, mas a validação de performance, segurança e risco do modelo é do seu time.
Por que esse rigor importa tanto justo agora? Porque a Threat Intelligence da GitLab publicou na mesma semana o retrato de quem está do outro lado. O esquema "Contagious Interview" — agentes se passando por recrutadores para induzir desenvolvedores a executar código malicioso disfarçado de teste técnico — resulta em lateral movement e roubo de credenciais. Em 2025, a GitLab baniu em média 11 contas por mês, com payloads em JavaScript (famílias BeaverTail e Ottercookie), carga remota via serviços como Vercel, e — o detalhe que arrepia — uso de IA (ChatGPT e Cursor) pelos próprios atacantes para refinar ofuscadores. O caso do gerenciador Kil-Nam Kang revelou uma célula com faturamento de US$ 1,64 milhão em operações fraudulentas de TI: não são script kiddies, são empresas estruturadas, com metas e gestão de pessoas.
A síntese é incômoda e útil ao mesmo tempo. Você está entregando o console a um agente que pode executar call_az, call_kubectl, abrir VNets e tocar produção — no mesmo momento em que adversários profissionalizados miram exatamente esse pipeline de CI/CD e essas identidades sintéticas. A defesa que a GitLab prescreve não é nova, mas virou inegociável: SAST e DAST automatizados (porque code review humano não vê lógica escondida em .env ou fontes alteradas), segregação real de ambientes, e políticas restritivas de IAM. Autonomia sem least privilege não é eficiência — é superfície de ataque com cara de produtividade.
Como controlar o custo dessa nova densidade de processamento e IA?
Enquanto a camada de software fica autônoma, a de hardware fica densa — e cara. A AWS abriu fevereiro empurrando a fronteira de compute. As instâncias EC2 M8azn, com AMD EPYC de 5ª geração atingindo 5 GHz (a maior frequência da nuvem, segundo a AWS), entregam o dobro de performance computacional, 4.3x mais memory bandwidth e cache L3 dez vezes maior frente à M5zn, sobre o Nitro System de sexta geração. No HPC, a Hpc8a (também EPYC 5ª geração, até 4.5 GHz) chega com 192 cores, 768 GiB e 300 Gbps de EFA, prometendo até 40% mais performance e 25% melhor price-performance que a Hpc7a — por ora em Ohio e Estocolmo. São números de simulação financeira em tempo real e dinâmica de fluidos, não de blog de marketing.
Na frente de IA, a AWS expandiu o Amazon Bedrock com seis modelos open weights (DeepSeek V3.2, MiniMax M2.1, GLM 4.7 e Flash, Kimi K2.5 e Qwen3 Coder Next), com o Project Mantle garantindo compatibilidade nativa com as APIs da OpenAI — argumento direto de portabilidade e anti-lock-in. E o SageMaker Inference atingiu GA para modelos Nova customizados (Micro, Lite e Nova 2 Lite com reasoning), com auto-scaling e a recomendação de FinOps de usar instâncias G5/G6 no lugar de P5 quando o caso de uso permite. Tudo isso reforça que a fatura de IA é, antes de tudo, uma fatura de infraestrutura — e que sem disciplina ela "se traduz em custos crescentes, não em valor de negócio", como a própria perspectiva editorial da semana resumiu.
Para o operador no Brasil, dois fatos aterrissam essa discussão. O Azure Premium SSD v2 chegou à região Brazil Southeast, desacoplando capacidade de IOPS e throughput — ganho real de TCO para banco transacional, com a ressalva importante de que Brazil Southeast ainda não opera com Availability Zones, exigindo DR de aplicação para resiliência total. E o relógio do Nginx Ingress continua correndo: o fim do suporte em março de 2026 empurra a migração para o App Routing add-on (coberto até novembro de 2026), com o destino de longo prazo na Microsoft sendo Istio sobre Gateway API. Densidade de hardware, custo de inferência e dívida de borda — os três entram na mesma planilha de FinOps.
O que levar desta semana
A semana sem keynote entregou um padrão mais valioso que qualquer lançamento isolado: a agentização das operações parou de ser tese e virou produto. Operação: o Azure SRE Agent foi de alerta a causa raiz, ganhou ponte para rede privada, MCP com Elasticsearch e monitor de SSL — e o AKS recebeu CLI agentic em cluster mode com call_az/call_kubectl. Entrega: o GitLab Duo 18.9 abriu self-hosted e BYOM, e plugou o Opus 4.6 de 1M de tokens no pipeline, sempre com human-in-the-loop. Governança: cada um desses recursos vem com a mesma letra miúda — RBAC granular, modo de aprovação, IAM restritivo — e o relatório norte-coreano da GitLab (11 contas/mês banidas, célula de US$ 1,64 milhão) explica a urgência. Custo: M8azn de 5 GHz, Hpc8a, Bedrock com seis modelos abertos e SageMaker para Nova mostram que a densidade de compute e a fatura de IA precisam de FinOps desde o dia zero, com o Premium SSD v2 no Brazil Southeast e o prazo do Nginx Ingress como decisões concretas na mesa. Quem adotar o agente com disciplina de permissão vai colher a redução de toil. Quem só ligar a automação vai descobrir, no primeiro incidente, que entregou o console sem trancar a porta.
Perguntas Frequentes
O Azure SRE Agent já remedia incidentes sozinho ou só investiga?
Ele faz as duas coisas, mas a recomendação da própria Microsoft é começar em modo de aprovação. Nos casos demonstrados, o agente iniciou a investigação assim que o alerta disparou, correlacionou telemetria via KQL, cruzou a configuração do ARM e chegou à causa raiz — por exemplo, um Web App Health Failure causado por publicNetworkAccess desabilitado sem VNet integration. A remediação automática em produção deve ser o estágio final, só depois que o agente amadureceu o conhecimento do seu ambiente via Incident Response Plans (IRP) e com RBAC granular limitando o que ele pode tocar.
O que muda no AKS com o 'cluster mode' do CLI agentic?
Antes, cada operador subia sua própria instância do agente de diagnóstico, muitas vezes com cluster-admin — visibilidade de compliance fragmentada e privilégio excessivo. O cluster mode, em public preview, centraliza esse baseline de diagnóstico para um controle de acesso mais granular. Na mesma leva, o AKS MCP Server ganhou as ferramentas call_az e call_kubectl, também em preview, para reduzir o context-switching entre CLIs. O preço dessa centralização é transferir a responsabilidade para a definição correta de RBAC em nível de cluster.
GitLab Duo self-hosted e BYOM resolvem o problema de soberania de dados?
Ajudam, mas não dispensam governança. A versão 18.9 liberou a GitLab Duo Agent Platform self-hosted para licenças online cloud, com faturamento por consumo via GitLab Credits — o que dá previsibilidade de FinOps e chargeback. O Bring Your Own Model (BYOM) amplia o AI Gateway para registrar modelos próprios ou de terceiros no mesmo control plane, com mapeamento granular de modelo por fluxo. A ressalva do próprio GitLab: a validação de performance, segurança e risco desses modelos passa a ser responsabilidade do seu time.
Preciso migrar do Nginx Ingress no AKS agora?
Sim, com calma e plano. O Comitê de Direção do Kubernetes marcou o fim do suporte ao Nginx Ingress controller para março de 2026 — depois disso, sem patches de segurança. No AKS, o App Routing add-on (que usa Nginx como motor) tem suporte oficial garantido até novembro de 2026, o que compra fôlego. Mas o destino de longo prazo da Microsoft é uma solução baseada em Istio, exclusiva para Gateway API. Use a migração via IngressClass paralela para ganhar tempo e já comece a mapear o caminho para Gateway API com ferramentas como o Ingress2Gateway.
Qual a relevância do relatório de ameaças norte-coreanas da GitLab para quem opera no Brasil?
É o lembrete de que o crime que mira o pipeline ficou corporativo. A Threat Intelligence da GitLab descreveu o esquema 'Contagious Interview' — recrutadores falsos induzindo devs a rodar código malicioso disfarçado de teste técnico — e células de trabalhadores de TI fraudulentos, uma com faturamento de US$ 1,64 milhão. Em 2025, foram banidas em média 11 contas por mês, com payloads em JavaScript (BeaverTail, Ottercookie) e uso de IA pelos próprios atacantes para refinar ofuscadores. A lição prática: code review humano não basta — exige SAST/DAST automatizados, segregação de ambientes e IAM restritivo nos pipelines de CI/CD.
Fontes:
- Resposta Reativa a Incidentes com o Azure SRE Agent: do alerta à resolução em minutos — Microsoft Tech Community
- Investigação com Azure SRE Agent em redes privadas — Microsoft Tech Community
- Integração do servidor Elasticsearch MCP com o Azure SRE Agent — Microsoft Tech Community
- Monitor de certificado SSL customizado com Azure SRE Agent — Microsoft Tech Community
- Evolução no AKS: cluster mode para o CLI agentic — Azure Updates
- Unificação de ferramentas no AKS MCP Server (call_az e call_kubectl) — Azure Updates
- IA agentica e controle corporativo: GitLab Duo self-hosted e BYOM — GitLab Blog
- Claude Opus 4.6 disponível na GitLab Duo Agent Platform — GitLab Blog
- GitLab Threat Intelligence revela o tradecraft norte-coreano — GitLab Blog
- Migração de Nginx Ingress para o AKS App Routing add-on — Microsoft Tech Community
- Radar AWS: instâncias M8azn, novos modelos no Bedrock e observabilidade — AWS News Blog
- Amazon EC2 Hpc8a com processadores AMD EPYC de 5ª geração — AWS News Blog
- Amazon SageMaker Inference para modelos Amazon Nova customizados — AWS News Blog
- Azure Premium SSD v2 chega à região Brazil Southeast — Azure Updates