Esta semana em cloud (04–10/mai): o agente ganhou as chaves da infraestrutura

TL;DR: A semana de 04 a 10/mai foi a do MCP server virando produto: AWS, Azure ARM e o Cosmos DB Shell deram a agentes de IA acesso autenticado à infra, enquanto Google e Azure publicaram camadas de identidade e governança para conter o agent sprawl. Por baixo do hype, os fundamentos cobraram a conta: fragmentação de observabilidade, fim de Reserved Instances no Azure, Kyverno 1.18 e a física do resfriamento líquido. Agente novo, disciplina velha.

Por que esta semana importou

Houve semanas em que o agente de IA era uma demo: ele escrevia YAML bonito que não rodava em produção. A semana de 04 a 10 de maio foi diferente. Quase em paralelo, três hyperscalers entregaram a peça que faltava — o MCP server — que tira o agente do papel de gerador de texto e o coloca com as mãos, autenticadas, dentro da sua infraestrutura. E, não por acaso, os mesmos provedores publicaram na mesma janela as camadas de identidade e governança para que esse agente não vire um passivo de segurança e de custo.

É um movimento coordenado e revelador: a indústria decidiu que 2026 é o ano em que o agente deixa de sugerir e passa a executar. Mas a leitura honesta para quem opera infra no Brasil é que nada disso suspende os fundamentos. Na mesma semana, a CNCF mostrou que metade das empresas ainda não unificou observabilidade, a Microsoft marcou o fim de Reserved Instances legadas, o Kyverno avançou política como código e a Equinix lembrou que existe um limite físico — térmico e elétrico — por baixo de toda essa inteligência. O agente é novo; a disciplina que ele exige é velha conhecida.

O MCP server virou produto: o que muda quando o agente tem acesso autenticado?

O padrão da semana foi claro. A AWS anunciou a disponibilidade geral do AWS MCP Server, um servidor gerenciado de Model Context Protocol que dá a agentes acesso autenticado aos serviços da AWS via IAM, com uma ferramenta (call_aws) capaz de executar mais de 15.000 operações de API usando as credenciais existentes. O ponto não é só conveniência: o servidor resolve o problema crônico do agente que "não sabe" dos serviços lançados depois do seu treino, consultando documentação oficial em tempo de execução.

A Microsoft seguiu o mesmo trilho por dois caminhos. O Azure Resource Manager MCP Server entrou em public preview permitindo que o agente consulte o Azure Resource Graph em linguagem natural (traduzindo para KQL nos bastidores) e gerencie o ciclo de vida de deployments de ARM templates. E o Azure Cosmos DB Shell, também em preview, transformou a gestão do banco numa CLI estilo Unix que é, ao mesmo tempo, um MCP server — o agente navega com cd/ls, roda queries e manipula dados.

O que isso muda na prática para quem opera no Brasil? Três coisas. Primeiro, o agente para de alucinar sobre infra recente — o gap de conhecimento que tornava as sugestões inúteis foi endereçado na fonte. Segundo, o acesso passa a ser rastreável: credenciais temporárias de IAM/Entra ID e log de cada ação, em vez de chave estática colada num prompt. Terceiro — e aqui mora o alerta — a Microsoft é explícita ao dizer que não há garantia de qualidade para ARM templates gerados puramente por IA, recomendando que a engenharia use seus próprios templates validados. Traduzindo: o MCP server é uma porta de entrada governada, não um piloto automático. Comece read-only, libere escrita por exceção.

Quem é esse agente? A semana em que a identidade virou requisito

Dar mãos ao agente sem dar a ele uma identidade própria é a receita do caos. Os provedores entenderam isso e publicaram, na mesma janela, o arcabouço de governança.

No Google Cloud, a aposta é tratar o agente como principal de primeira classe. O Agent Identity — baseado no padrão SPIFFE, provisionado e protegido criptograficamente — separa a identidade do agente das service accounts humanas ou genéricas; o componente para o Agent Runtime já está em GA. Em volta dele orbitam o Agent Gateway, que centraliza o tráfego agent-to-tool e impede acesso a endpoints não autorizados, o Principal Access Boundary, que cria limites rígidos independentemente de outras permissões, e o Model Armor, um filtro inline contra prompt injection e vazamento de dados que se integra ao gateway sem exigir refactoring do código.

A Microsoft ataca o mesmo problema pela arquitetura. A referência de landing zone multi-region publicada nesta semana nomeia o vilão — agent sprawl — e prescreve a separação entre plano de controle e plano de execução em três camadas: Azure AI Gateway (com a policy llm-token-limit para conter o consumo de tokens), Azure AI Foundry (inventário, avaliação contínua e guardrails em massa) e Microsoft Agent 365 (identidade Entra ID, conformidade e quarentena de agentes não autorizados).

A convergência é o sinal mais importante da semana. Dois provedores, arquiteturas diferentes, mesma conclusão: agente é workload governável, com identidade própria e least privilege — não é um chatbot com permissão de admin. Para o time brasileiro, isso conversa direto com LGPD e com a velha pergunta de auditoria — quem fez o quê, com qual permissão. A boa notícia é que o caminho recomendado pelos próprios fornecedores é o mesmo que já praticamos para humanos e CI: identidade granular, fronteira de acesso e log de tudo.

Quer dar acesso a agentes de IA na sua infra sem abrir mão de governança e least privilege? Fale com os especialistas em SecOps e DevOps da Nuvem Online.

E os fundamentos? A semana também cobrou a conta do básico

Enquanto o agente roubava as manchetes, três sinais lembraram que infraestrutura continua sendo um exercício de disciplina.

Observabilidade ainda é uma promessa não cumprida. Um estudo CNCF publicado nesta semana, com 407 especialistas (campo em fevereiro de 2026), trouxe o número incômodo: 46,7% das organizações operam de duas a três stacks de observabilidade em paralelo e apenas 7,4% alcançaram uma experiência verdadeiramente unificada. O gargalo não é tecnologia — OpenTelemetry, Prometheus e Jaeger já são padrão. É atrito operacional: 54% apontam configuração de dashboards e alertas como a maior dor, acima de qualquer lacuna de feature. E há um dado contraintuitivo: 81% dizem estar satisfeitos com a stack, mas 63% trocariam de ferramenta — por qualidade de integração. A lição para o Brasil é a mesma que defendemos: pare de procurar a ferramenta perfeita e invista em compor o ecossistema sobre OpenTelemetry. É também a melhor defesa contra vendor lock-in.

Política como código amadureceu. O Kyverno 1.18, primeira release após a graduação na CNCF, trouxe segurança por padrão — bloqueio de loopback e endpoints de metadados para mitigar SSRF, e scoped token authorization endereçando o CVE-2026-41323 — além de avançar a migração para CEL. Mas o recado operacional está na mudança do modelo de suporte para N-1: patches só para a versão atual e a anterior, com cadência de upgrade mais curta. E a depreciação das ClusterPolicy em favor de ValidatingPolicy/MutatingPolicy já está no horizonte. Quem opera clusters precisa colocar a migração no backlog deste ano, não no do ano que vem.

Supply chain de CI continua sendo o elo fraco. Um guia da CNCF Technical Advisory Group, também desta semana, repetiu o básico que ainda não é praticado: rodar uma GitHub Action de terceiro é executar código alheio com as permissões da sua esteira. As recomendações são as de sempre, e por isso mesmo valiosas — pinning por SHA (não por tag mutável @v1), least privilege no GITHUB_TOKEN, e linters de segurança como zizmor ou scorecard no pipeline. No mês em que abrimos a esteira para agentes de IA, fechar a porta da supply chain deixou de ser opcional.

FinOps e a física: o que sustenta (e limita) a era agêntica

Dois fatos da semana ancoraram o hype na realidade material.

Do lado do custo, a Microsoft confirmou o fim das Reserved Instances para uma lista de séries legadas — incluindo Dv2, Dsv2, Dv3, Ev3, F, G e Ls — a partir de 1º de julho de 2026. Não há impacto técnico: as reservas vigentes valem até o fim do term e nada para de rodar. O risco é silencioso e puramente de billing — quem não planejar cai no pay-as-you-go, bem mais caro. A recomendação é direta: auditar o inventário de reservas agora e avaliar Savings Plan for Compute ou modernização de SKU. Do outro lado, o Google reduziu em até 4x o tempo de inicialização de nodes no GKE (em Autopilot, para famílias com GPU como L4, A100, H100 e compute de propósito geral), o que ataca diretamente o over-provisioning — aquele buffer de instâncias ociosas que muitos times mantêm só para mascarar cold start. Menos capacidade ociosa, menos desperdício; o ganho é nativo e não exige mexer no Terraform.

Do lado da física, a Equinix trouxe o lembrete mais sóbrio da semana: a densidade de rack saltou dos 5–10 kW que sustentaram a década passada para mais de 200 kW, rumo a 1 megawatt por rack, empurrada por GPU de IA. O ar atingiu seu limite prático e o resfriamento líquido Direct-to-Chip virou imperativo. A mesma Equinix mostrou o outro lado da moeda — IA como ferramenta de eficiência, não só de consumo: controles adaptativos no data center FR6 em Frankfurt cortaram 900 MWh por ano e melhoraram o PUE. Para quem consome cloud pública no Brasil, isso não é abstração: define quais regiões terão GPU, a que preço e sob quais SLAs.

O posicionamento da Nuvem Online

A leitura da semana é que a indústria entregou, de uma vez, o acelerador e o freio: o MCP server que dá poder ao agente e a camada de identidade que o disciplina. Quem adotar só o primeiro vai colecionar agent sprawl, custo de token fora de controle e um buraco de auditoria. Quem adotar os dois juntos — agente com identidade própria, acesso read-only por padrão, escrita por exceção, tudo logado — ganha produtividade real sem trocar governança por velocidade.

E há uma ironia saudável: a observabilidade, base para confiar em qualquer automação, ainda está fragmentada em mais de 9 de cada 10 empresas. Antes de entregar as chaves da infra ao agente, garanta que você ainda enxerga o que ele faz. Agente novo, sim — mas com a disciplina de sempre: identidade, least privilege, observabilidade e FinOps. O básico continua separando quem escala de quem quebra.

Perguntas Frequentes

Vale a pena adotar MCP server em produção agora ou ainda é cedo?
O AWS MCP Server saiu como GA e o Azure ARM MCP Server e o Cosmos DB Shell estão em public preview. Para produção, comece pelo caminho read-only: limite o agente a ações de leitura via SCP/Azure Policy, use credenciais temporárias de IAM/Entra ID e mantenha auditoria (CloudTrail, logs do shell). O ganho real é o agente parar de alucinar sobre serviços recentes; o risco é dar permissão de escrita cedo demais.

Como evitar que agentes de IA estourem o orçamento e o controle de acesso?
Trate o agente como workload governável, não como experimento. A arquitetura de referência do Azure separa plano de controle e execução em três camadas — gateway com quota de tokens, Foundry para inventário e Agent 365 para identidade. O Google segue a mesma lógica com Agent Identity (baseado em SPIFFE), Agent Gateway e Principal Access Boundary. O denominador comum: identidade própria por agente e least privilege, não service account compartilhada.

O fim das Reserved Instances no Azure vai parar meus workloads?
Não. A partir de 1º de julho de 2026 a Microsoft encerra novas compras e renovações de RIs para uma lista de séries legadas (Dv2, Dv3, Ev3, F, G, Ls e outras), mas as reservas já contratadas valem até o fim do term e nada para de rodar. O risco é puramente de billing: sem plano, o workload cai no pay-as-you-go. Avalie Savings Plan for Compute ou modernização de SKU antes do prazo.

Se as ferramentas de observabilidade já são maduras, por que ainda mantenho três stacks?
Segundo estudo CNCF de fevereiro de 2026 (407 especialistas), 46,7% das organizações ainda operam de duas a três stacks em paralelo e só 7,4% têm experiência unificada. O gargalo não é técnica — é atrito de configuração e integração (54% apontam dashboards e alertas como a maior dor). A saída é tratar OpenTelemetry como base de composição, não adotar mais uma ferramenta.

Por que falar de resfriamento líquido se eu só consumo cloud pública?
Porque a densidade de rack para IA passou de 5–10 kW para mais de 200 kW, rumo a 1 MW, e isso redefine quais regiões e parceiros de colocation conseguem hospedar GPU em escala. Mesmo quem só consome IaaS sente nos SLAs, na disponibilidade de GPU por região e no custo. A camada física virou variável de arquitetura, não detalhe de fornecedor.

Fontes: