Esta semana em cloud (27/abr–03/mai): o agente precisa de identidade, e o dado precisa de endereço

TL;DR: A semana do Google Cloud Next '26 vendeu a "agentic enterprise", mas o que virou produto foi a camada chata: identidade e governança de agentes (MCP gerenciado, SRE Agent) e soberania de dados (Azure Local sem Active Directory, OCI isolated region, framework C3A). No contramão, Equinix, CNCF e o Kubernetes 1.36 lembraram que kernel, egress e data center ainda mandam. Para quem opera infra no Brasil: agente é identidade, e dado é endereço.

Toda semana a indústria de cloud anuncia mais do que qualquer pessoa consegue acompanhar. O trabalho aqui não é listar — é achar o fio que costura os anúncios e dizer o que muda para quem opera infra no Brasil. Esta foi a semana do Google Cloud Next '26 e da enxurrada de "agentic enterprise", o jargão de que sua empresa inteira passará a rodar sobre agentes de IA. Fácil descartar como hype. Mas, lendo o que de fato virou produto — e não keynote —, aparece um padrão menos glamouroso e muito mais útil: a indústria parou de discutir o que o agente faz e começou a resolver quem o agente é e onde o dado dele mora. Identidade e endereço. O resto é demo.

E houve um contraponto saudável: enquanto os hyperscalers vendiam autonomia, a comunidade e o chão de fábrica (CNCF, Kubernetes, Equinix) lembraram que tudo ainda roda sobre kernel, cgroup, egress e concreto de data center. É essa tensão — futuro agêntico em cima, fundamentos teimosos embaixo — que define a semana.

Por que "identidade de agente" foi o anúncio que importou?

O Google abriu o Next '26 com um número que resume a aposta: mais de 50 servidores MCP gerenciados (Model Context Protocol) disponíveis para conectar agentes ao ecossistema da nuvem. O marketing fala em "agentes para todos". A leitura de quem opera infra é outra: o anúncio é sobre eliminar integração point-to-point frágil e padronizar como o agente acessa dado real — com IAM herdado da plataforma, deny policies granulares, OTel Tracing, Cloud Audit Logs e Model Armor para conter prompt injection e exfiltração. Em outras palavras, não é a inteligência do agente que ganhou produto; é a trilha de auditoria dele.

A mesma tese apareceu na visão de segurança que o Google publicou nesta semana sob a ótica do CISO: a "agentic enterprise" precisa de três pilares que nada têm de mágico — Agent Gateway para governança de IAM, Model Armor para higienizar prompts e Agent Identity para que a autonomia aconteça dentro de protocolos de autenticação auditáveis. O recado é claro: o agente está sendo tratado como identidade a ser governada, não como recurso novo a celebrar. As métricas de "redução de X% no tempo de mitigação" que acompanham esses anúncios são do próprio fornecedor — leia como direção, não como benchmark independente.

A Microsoft fez o mesmo movimento pelo flanco da operação, com o Azure SRE Agent. Dois anúncios da semana se encaixam: um marketplace de plugins ("construa uma vez, instale em qualquer lugar"), em que um plugin empacota skills (regras de triagem) e MCP connectors (acesso a CMDB, custos, deployment); e a integração com o New Relic via MCP, que deixa o agente traduzir linguagem natural para consultas NRQL e reduzir MTTR sem proxy local. O detalhe que merece atenção não é a conveniência — é a recomendação de segurança que vem junto: chave de API read-only atrelada a um service user dedicado, nunca conta de administrador pessoal. De novo: identidade e least privilege, não autonomia irrestrita.

Para o gestor brasileiro, a tradução é direta. Antes de habilitar qualquer agente que toque a sua infra, responda a uma pergunta de SecOps: qual a identidade dele, qual o escopo de permissão e onde ficam logadas as ações? Se a resposta for "ele usa a credencial do time de plataforma", você não tem um agente — tem um ponto cego com privilégio de admin.

Soberania de dados parou de ser slide. O que mudou na prática?

O segundo fio da semana é onde o dado mora — e aqui os anúncios foram concretos o suficiente para mudar arquitetura, não apenas conversa de compliance.

A Microsoft levou o Azure Local versão 2604 para um patamar de "nuvem privada soberana" com duas mudanças que importam para edge e ambientes regulados. A primeira: deploys desagregados, separando compute e storage, com suporte a anexar SAN externo via Fibre Channel agora em disponibilidade geral — ou seja, dá para reaproveitar storage de brownfield sem refresh total de hardware, convivendo com volumes de Storage Spaces Direct. A segunda, e a mais relevante para soberania: provisionar o Azure Local sem depender do Microsoft Active Directory, com identidade local via Azure Key Vault. Quem já tentou rodar infra em ambiente air-gapped sabe o peso de manter controladores de domínio e regras de firewall só para o cluster existir; remover essa dependência é destravar cenário soberano de verdade.

A OCI reforçou o tema por outro ângulo. Numa análise de mercado sobre clouds privadas isoladas (creditada ao Gartner no material), o ponto central é o tradeoff clássico — soberania versus funcionalidade — e a tese de que os modelos de Dedicated Region e Isolated Region entregam um control plane local completo, que continua operando mesmo em desconexão total da nuvem pública. É o que um banco ou órgão público pede: autonomia que não depende de tethering constante com a rede global do provedor.

E o Google publicou a leitura europeia do tema, em torno do framework C3A do BSI alemão. A mensagem que atravessa para o Brasil é a parte boa: a soberania madura não é "isolamento absoluto", é escolha técnica calibrada pela criticidade do dado — Data Boundary, operação via parceiro local, isolamento físico — apoiada em tecnologia aberta (Kubernetes) justamente para evitar vendor lock-in. É o ponto que defendemos há tempo: soberania que te prende a um único fornecedor não é soberania, é dependência com outro nome.

Precisa desenhar uma arquitetura soberana sem cair em lock-in de fornecedor? A Nuvem Online ajuda a equilibrar compliance, portabilidade e custo.

Para fechar o tema com FinOps: a Microsoft revisou a política de egress para clientes no Reino Unido, reduzindo o atrito financeiro de tirar dado da Azure. Não é global, não chegou ao Brasil e não é automático — mas é um sinal competitivo de que a taxa de saída, historicamente a maior âncora do lock-in, está sob pressão. Não desenhe arquitetura apostando em egress barato; desenhe para ter portabilidade real e, com ela, poder de barganha.

Segurança na era do agente autônomo: detectar ou conter por design?

Se o agente ganhou autonomia, a pergunta de segurança muda de "como eu detecto a brecha?" para "como eu contenho o estrago quando — não se — algo der errado?". A CNCF publicou nesta semana um ensaio provocativo argumentando que AI sandboxing está vivendo seu "momento Kubernetes": rodar código não confiável (gerado ou executado por agentes) sobre um kernel compartilhado transforma o nó inteiro num single point of failure. A solução proposta não é mais uma camada de RBAC, network policy ou perfil de seccomp — é isolamento estrutural, distribuindo o domínio de falha em instâncias de kernel independentes, do mesmo jeito que o Kubernetes nos ensinou a tratar falha como evento esperado. (O texto cita um exemplo dramático de exploit autônomo que não conseguimos verificar de forma independente; ficamos com a tese de arquitetura, que se sustenta sozinha.)

No nível do pipeline, a contenção mais barata da semana veio de um guia muito concreto da Microsoft: matar credencial de longa duração com Workload Identity Federation (OIDC) em pipelines de Terraform. Em vez do velho ARM_CLIENT_SECRET — que vaza em log, em print, em fork e expira na sexta à noite —, o pipeline troca um JWT de curta duração por um access token via Microsoft Entra ID, vinculado a um subject (repo:org/projeto:environment:prod) que nenhum outro branch reutiliza. Não é tecnologia nova (GitHub Actions suporta WIF desde 2021; Azure DevOps, desde fevereiro de 2024; o provider azurerm desde a v3.7) — o que faltava era prioridade. A arquitetura recomendada é didática: uma user-assigned managed identity por ambiente, escopo RBAC no resource group (não na subscription), state file com use_oidc e shared key access desabilitado. Se você ainda autentica CI/CD com segredo estático, esse é o item de SecOps de maior retorno para este mês.

E o pano de fundo, também da CNCF, é o que dá realismo a tudo: a pesquisa State of AI in CNCF Projects (133 respondentes, quase 100 projetos) mostrou que cerca de metade dos engenheiros já usa assistentes de IA integrados à IDE ou ao CLI — mas dois terços dos projetos não têm política formal de uso de IA, e menos de 4% proíbem. Tradução para o gestor: o problema não é a ferramenta, é a governança ausente. A recomendação madura não é bloquear IA, é exigir transparência (sinalizar contribuição assistida) e manter revisão humana rigorosa nos componentes críticos. A pesquisa segue aberta até 18 de maio, para quem quiser contribuir.

E quem cuida do concreto enquanto todos falam de agente?

O contraponto mais útil da semana foi o lembrete de que nada disso flutua. A Equinix inaugurou o SP6 em Santana de Parnaíba (São Paulo), um IBX com investimento de US$ 114 milhões projetado para alta densidade e resfriamento líquido — a condição física para sustentar os clusters de IA que os keynotes pressupõem. E a mesma Equinix publicou o texto que mais combina com a nossa cabeça: "cloud não é resposta para tudo". O argumento é o que repetimos para clientes — nuvem pública é imbatível para experimentação e elasticidade, mas migrar workload de produção estável sem critério esbarra em dois muros: perda de controle sobre data residency e a escalada invisível de custo (egress + pay-per-use sem previsibilidade). O mindset correto é distribuição inteligente, não fé cega no público.

E, na base de tudo, o Kubernetes 1.36 entregou dois recursos do SIG Node que são FinOps disfarçado de engenharia. O Memory QoS ganhou reserva em camadas (TieredReservation): pods Guaranteed usam memory.min (proteção absoluta), Burstable usam memory.low (proteção suave que o kernel só libera para evitar pânico sistêmico) e BestEffort ficam sem reserva — o que permite densificar o nó sem deixar a aplicação core desprotegida. O segundo: a mutabilidade de recursos em Jobs suspensos (em beta), que deixa um orquestrador como o Kueue ajustar CPU/GPU de um batch antes de iniciá-lo, sem o delete-and-recreate que apagava histórico. Ambos atacam desperdício computacional — que é, no fim, do que FinOps trata. Aviso operacional: o Memory QoS depende de cgroup v2 e kernel 5.9+; em ambiente legado, não ative, sob risco de livelock.

O que a Nuvem Online tira da semana

O discurso da "agentic enterprise" é real, mas o que importa para quem opera não é a autonomia — é a plumbing que a torna segura: identidade auditável para cada agente, permissão mínima e log de tudo que ele faz. Se for adotar um SRE Agent ou um MCP gerenciado, comece pela governança, não pela demo.

No dado, soberania saiu do PowerPoint: dá para rodar infra sem Active Directory, com SAN reaproveitado e control plane local — mas exija que ela venha sobre tecnologia aberta, ou você só trocou um lock-in por outro. E não esqueça do chão: kernel, egress e data center seguem definindo custo e risco mais do que qualquer agente. A semana, no fundo, foi um convite à sobriedade. Agente é identidade; dado é endereço; e infra boa é a que você consegue auditar, mover e pagar de forma previsível.

Perguntas Frequentes

Por que "identidade de agente" virou tema de infra e não de IA?
Porque um agente que age na sua nuvem é, na prática, um ator com permissões: ele provisiona recurso, consulta banco, executa rollback. Se ele não tem uma identidade própria, auditável e com least privilege, você não consegue responder "quem fez isso?" depois de um incidente. Os anúncios da semana (servidores MCP gerenciados do Google com integração IAM e deny policies, Agent Gateway e Agent Identity) atacam exatamente esse buraco. Para quem opera no Brasil, a lição é tratar agente como service account de primeira classe, não como um script com a credencial do dono.

Soberania de dados é só discurso de marketing ou já mudou algo prático?
Mudou. O Azure Local versão 2604 passou a permitir provisionar clusters sem depender do Microsoft Active Directory (identidade local via Azure Key Vault) e levou o suporte a SAN externo via Fibre Channel para disponibilidade geral — ou seja, dá para reaproveitar storage que você já tem em ambientes air-gapped. A OCI reforçou o modelo de isolated/dedicated region com control plane local completo. São capacidades concretas, não slides. Para setores regulados no Brasil (financeiro, saúde, governo), isso amplia o leque de arquiteturas soberanas viáveis.

O Kubernetes 1.36 traz algo que impacta meu custo de cluster?
Sim, dois recursos do SIG Node são FinOps disfarçado de feature técnica. O Memory QoS com TieredReservation separa proteção de memória por classe de QoS (Guaranteed usa memory.min, Burstable usa memory.low), permitindo densificar o nó sem deixar workload crítico sem garantia. E a mutabilidade de recursos em Jobs suspensos deixa você ajustar CPU/GPU de um batch antes de rodá-lo, sem o delete-and-recreate que perdia histórico. Ambos reduzem desperdício, que é o coração de FinOps. Atenção: o Memory QoS exige kernel 5.9+.

Se egress ficou mais barato, vale a pena repensar minha estratégia multicloud?
Vale acompanhar, mas com pé no chão. A Microsoft revisou a política de egress para clientes no Reino Unido, sinalizando pressão competitiva para reduzir a taxa de saída de dados — uma das maiores barreiras financeiras do multicloud. Isso não é automático nem global, e não chegou ao Brasil. Mas é um indicador de tendência: o custo de tirar dado de um provedor está sob escrutínio. A recomendação é não desenhar arquitetura apostando em egress barato hoje, e sim manter portabilidade real (Kubernetes, IaC, observabilidade padronizada) para ter poder de barganha amanhã.

Com agente autônomo e IA gerando código, o que muda na minha postura de segurança?
Muda o eixo: sai de "detectar a brecha" para "conter o estrago por design". A discussão de AI sandboxing na CNCF argumenta que kernel compartilhado é um single point of failure quando você roda código não confiável — a resposta é isolamento estrutural, não só política de RBAC e seccomp. No pipeline, o caminho mais barato e imediato é matar credencial de longa duração: o Workload Identity Federation (OIDC) substitui o ARM_CLIENT_SECRET por token de curta duração emitido em runtime. E a pesquisa da CNCF mostra que dois terços dos projetos open source ainda não têm política formal de uso de IA — governança é o gargalo, não a ferramenta.

Fontes: