Esta semana em cloud (30/mar–05/abr): o agente desceu para a infraestrutura

Q: O que levar desta semana

O fio que costura tudo é um só: o agente de IA desceu para a infraestrutura, e com ele desceu a responsabilidade . Três frentes apareceram com força e merecem virar trabalho concreto. Primeiro, governança de agente na camada certa : política de MCP/A2A num gateway (Envoy, kgateway, Kong AI Gateway), token de delegação injetado pela infra e nunca pelo agente, RBAC do banco herdado pelos agentes NL2SQL — nada disso mora no runtime do modelo.

Banner - Esta semana em cloud (30/mar–05/abr): o agente desceu para a infraestrutura

TL;DR: A semana deixou claro que o agente de IA desceu da aplicação para a infraestrutura. O Envoy virou ponto de controle de MCP e A2A, Spanner e Oracle reescreveram o banco como motor de contexto, e a CNCF publicou o modelo de ameaças de LLMs no Kubernetes. O BRICKSTORM provou que a virtualização é o novo alvo. Para quem opera no Brasil, a conta vem em governança de agente, custo de inferência e hardening abaixo do sistema operacional.

Teve uma semana sem keynote de grande palco, e talvez por isso ela tenha sido mais reveladora do que as anteriores. Sem um anúncio único para roubar a cena, os times de produto da Google, AWS, Oracle e da CNCF publicaram, quase em coro, peças sobre o mesmo movimento de fundo: a IA agentic parou de ser um problema de aplicação. Ela desceu — para a rede, para o banco de dados, para o admission controller do cluster e para a camada de virtualização. O agente que antes vivia num container agora puxa contexto de um banco multi-model, fala MCP por um proxy Envoy e precisa de um guardrail que vale para todas as contas da organização.

Esse deslocamento muda quem é o dono do problema. Enquanto o discurso de 2025 colocava o agente nas mãos do time de aplicação, o material desta semana o devolve para Platform e Security: é na infraestrutura que se aplica least-privilege, se faz parsing de payload e se segmenta a rede. E o lembrete mais duro veio do lado defensivo — o malware BRICKSTORM, mirando o vSphere abaixo do sistema operacional, provou que enquanto todos olham para cima (o agente), o atacante mira para baixo (o hypervisor).

A leitura para quem opera infra no Brasil é direta: a "Agentic Era" não cria um stack novo, ela redistribui responsabilidade para camadas que já existiam e estavam mal cuidadas. Quem tratar agente como app vai descobrir, no primeiro incidente, que delegou Zero Trust para o lugar errado.

Por que o agente virou problema de rede, banco e gateway?

O sintoma mais forte da semana foi a quantidade de fornecedores reposicionando componentes de infraestrutura como "fundação para IA agentic". A Tetrate, escrevendo no blog do Google Cloud, fez a defesa mais técnica: na stack tradicional, a rede só transportava pacotes; com agentes, ela passa a mediar chamadas de modelo, invocações de ferramenta e interações agente-a-agente. Protocolos como Model Context Protocol (MCP) e Agent2Agent (A2A) rodam JSON-RPC ou gRPC sobre HTTP, mas com um problema novo: os atributos que importam para autorização — nome do modelo, nome da ferramenta — vivem no corpo da mensagem, não no header. Um proxy HTTP comum trata o body como byte stream opaco e fica cego.

A proposta é fazer o Envoy deframing dos protocolos de agente, expondo atributos de negócio como metadados estruturados para que filtros como ext_authz e RBAC decidam com base neles — por exemplo, permitir que um agente chame list_issues e get_issue do GitHub, mas nada além disso. O ponto arquitetural mais importante é o de credenciais: em vez de delegar o token diretamente ao agente (um erro grave), o Envoy injeta tokens de delegação pela infraestrutura, de modo que o agente nunca segura a credencial sensível. É exatamente o mesmo princípio que a CNCF defende para LLMs no Kubernetes — política na camada de gateway, não no runtime —, e os dois textos saíram na mesma semana sem combinar.

No plano de dados, o movimento espelha o de rede. O Spanner foi reposicionado como motor de contexto multi-model: relacional, key-value (endpoint Cassandra), grafos (padrão ISO GQL), vetorial (ScaNN, índices acima de 10 bilhões de vetores) e full-text numa única base, eliminando a sincronização entre silos. O caso citado é concreto: a MakeMyTrip consolidou MongoDB, Neo4j, Elasticsearch e Qdrant numa só instância de Spanner, com redução de 75% na complexidade operacional e ciclos de inovação até 50% mais rápidos. A Oracle empurrou na mesma direção com uma arquitetura de agente NL2SQL sobre MCP — frontend Next.js, backend FastAPI, orquestração via LangGraph e servidores MCP no OKE, com o Oracle 26ai fazendo busca vetorial de schema e o RBAC do banco herdado integralmente pelos agentes. O recado convergente: o banco deixou de ser repositório passivo e virou superfície de governança do agente.

Vai colocar agentes de IA em produção e precisa do gateway, da política e da governança de dados no lugar certo da infraestrutura? Fale com os especialistas da Nuvem Online.

A camada que ninguém olhava: vSphere, supply chain e o threat model do LLM

Enquanto o discurso subia para o agente, o ataque desceu para o hypervisor. A Mandiant detalhou a campanha BRICKSTORM, que mira o ecossistema VMware vSphere — especificamente o vCenter Server Appliance (VCSA) e os hosts ESXi. O insight desconfortável: ao se estabelecer na camada de virtualização, o atacante opera abaixo do sistema operacional guest, onde EDR tradicional não tem alcance, e explora algo que não é um CVE — é hardening fraco e lacuna de logging. Quem compromete o VCSA pode desligar, deletar ou reconfigurar qualquer VM, resetar credenciais root de ESXi e exfiltrar VMDKs direto, contornando o storage. E o vSphere 7 atingiu fim de vida em outubro de 2025, ou seja, sem mais patches críticos.

A defesa proposta é instrutiva porque não depende de produto novo: aplicar STIG (o Photon Linux DISA STIG como básico não negociável), reforçar identidade com Privileged Access Workstations e PAM, desabilitar o shell da conta vpxuser no vSphere 8.0+ (esxcli system account set -i vpxuser -s false), segmentar a rede em zonas Zero Trust (Management, VCSA, vMotion, Storage, Workloads) e — o ponto mais negligenciado — fechar o logging gap com auditd encaminhando syscalls via TLS (TCP 6514) para um SIEM externo, mais AIDE para integridade de arquivo. A lógica é tirar do atacante a invisibilidade. A Mandiant publicou um script de hardening do vCenter para automatizar boa parte disso.

A mesma semana trouxe o ângulo estratégico no CISO Perspectives da RSAC '26: a superfície de ataque virou um tripé de modelos, agentes e integridade de dados. O texto cita a ascensão de supply chain como vetor — o caso OpenClaw distribuindo backdoors e infostealers — e nomeia o problema que mais nos preocupa em campo: shadow AI e agentic identities deixaram de ser opcionais de governança. Do lado ofensivo, ferramentas como o Hexstrike AI comprimiram o tempo de resposta de horas para segundos; do lado defensivo, agentes de triagem e o "Big Sleep agent" para correção proativa devolvem escala ao defensor. O fio que liga RSAC e BRICKSTORM é o mesmo da seção anterior: identidade é o novo perímetro, e isso vale tanto para o humano quanto para o agente.

E é aqui que o modelo de ameaças de LLMs no Kubernetes, publicado pela CNCF, fecha o raciocínio. O argumento central é elegante: o Kubernetes é excelente em orquestrar e isolar processos, mas é agnóstico ao conteúdo — ele não valida se um prompt é malicioso nem se o modelo tem privilégio demais. Tratar um LLM como serviço de compute comum é o erro. O texto ancora no OWASP LLM Top 10 e destaca quatro riscos para operadores: Prompt Injection (LLM01), Sensitive Information Disclosure (LLM02), Supply Chain de modelos (LLM03) e Excessive Agency (LLM06) — esse último diretamente conectado ao least-privilege que o Envoy e o RBAC do K8s precisam impor. A recomendação operacional: a política mora num AI Gateway (LiteLLM, Kong AI Gateway, kgateway), nunca dentro do Ollama.

A conta da inferência: como rodar IA sem estourar o cluster nem a fatura

Se o agente desceu para a infra, o custo dele também desceu — e virou problema de FinOps de cluster. Dois lançamentos do GKE atacaram exatamente isso. O GKE Inference Gateway resolve o silo clássico entre inferência real-time (latência como KPI mestre) e assíncrona (tolerante a atraso): em vez de pools separados de GPU/TPU, ele trata a aceleração como um único pool fluido. Um Async Processor Agent integrado ao Pub/Sub injeta tasks batch como "filler traffic" nos ciclos ociosos, garantindo prioridade às requisições síncronas. O número apresentado é didático: sem o orquestrador, a multiplexação ingênua perdia 99% das mensagens; com ele, 100% das tasks batch processam nos ciclos vagos sem impacto na latência síncrona.

O complemento é o GKE Active Buffer, que ataca a latência de scale-out — o tempo morto de boot de VM e pull de imagem quando o Cluster Autoscaler sobe nó novo. Em vez das gambiarras conhecidas (over-provisioning 24/7 ou balloon pods com gestão manual de priority-class), o Active Buffer usa a API CapacityBuffer do Kubernetes OSS para declarar capacidade de reserva que o autoscaler interpreta como demanda pendente. Vale sublinhar a postura OSS-first que o próprio Google destaca: é um padrão de mercado, sem lock-in algorítmico, configurável por replicas fixas, percentual do deployment ou teto de vCPU. Para quem opera no Brasil, onde cada segundo de latência em pico de conversão tem preço, é a diferença entre absorver o pico e violar o SLO.

A peça que falta nessa equação é o custo do token em si — e aqui a AWS contribuiu com o Bedrock Guardrails cross-account em GA: política de IA responsável definida na management account do AWS Organizations e propagada para todas as member accounts, com enforcement em nível de organização ou de conta sobre InvokeModel e Converse. O alerta de FinOps está no próprio texto da AWS: guardrails têm custo por volume de token processado, então a governança centralizada precisa entrar no monitoramento de custo, não só no de segurança. Some isso ao Gemma 4 chegando ao Google Cloud sob licença Apache 2.0 — com deploy em Vertex AI, Cloud Run (escala-para-zero com GPU Blackwell) ou GKE, e redução de TTFT em até 70% via Inference Gateway —, e o quadro fica nítido: open-weight e roteamento inteligente são as duas alavancas de quem quer IA em produção sem dependência exclusiva de modelo proprietário nem fatura imprevisível.

Observabilidade e deprecations: a higiene que sustenta o resto

Nada disso se sustenta sem a camada que enxerga o que está acontecendo — e a observabilidade teve dois movimentos que merecem nota. O primeiro é estrutural: a CNCF anunciou que o modelo de stewardship que a Bloomberg validou em projetos como o pandas chega ao OpenTelemetry no segundo trimestre de 2026, com cohorts de mentoria reforçando SDKs, Collector, instrumentação e convenções semânticas. O ponto não é altruísmo: o OpenTelemetry é a espinha dorsal da observabilidade cloud-native, e a saúde dos mantenedores (burnout, financiamento) é um risco de SLA tão real quanto um CVE — só que invisível para o scanner de SCA. Sair de consumidor para contribuidor é estratégia de resiliência, não caridade.

O segundo é uma deprecation que precisa entrar no roadmap agora, mesmo com prazo longo: a Microsoft confirmou o fim do suporte ao sidecar de remote-write do Prometheus para o Azure Monitor Workspace em 31 de março de 2027. A recomendação é migrar para o Azure Monitor Agent ou integrar a configuração nativamente no Prometheus self-hosted. O ganho colateral é concreto — o modelo de sidecar impõe overhead de CPU e memória em cada pod, e removê-lo reduz o footprint dos nós (e a fatura). Deprecation com dois anos de antecedência parece distante, mas, como o vSphere 7 EoL mostrou nesta mesma semana, o problema de quem ignora o aviso não é a data — é estar rodando algo sem patch no dia em que a falha aparece.

O que levar desta semana

O fio que costura tudo é um só: o agente de IA desceu para a infraestrutura, e com ele desceu a responsabilidade. Três frentes apareceram com força e merecem virar trabalho concreto. Primeiro, governança de agente na camada certa: política de MCP/A2A num gateway (Envoy, kgateway, Kong AI Gateway), token de delegação injetado pela infra e nunca pelo agente, RBAC do banco herdado pelos agentes NL2SQL — nada disso mora no runtime do modelo. Segundo, segurança abaixo do óbvio: o BRICKSTORM provou que o vSphere é alvo, então hardening de VCSA/ESXi, fechamento do logging gap e o threat model de LLM no K8s (OWASP LLM Top 10) são tão prioritários quanto firewall de borda. Terceiro, a conta da inferência como FinOps: Inference Gateway e Active Buffer no GKE, custo de Guardrails no monitoramento, open-weight como Gemma 4 para fugir do lock-in. Quem operar essas três frentes com disciplina colhe a inteligência sem terceirizar a estabilidade. Quem só comprar o substantivo "agentic" vai descobrir, no incidente ou na fatura, que agente em produção é — antes de tudo — infraestrutura bem operada.

Perguntas Frequentes

Por que colocar política de IA no Envoy em vez de no runtime do modelo?
Porque o runtime de inferência (como Ollama) só deveria fazer uma coisa: inferência. Embutir regras de segurança nele é acoplamento errado. A recomendação da CNCF e o caso do Envoy convergem: a política de autorização, parsing de payload MCP e injeção de token de delegação devem ficar numa camada de gateway entre o cliente e o serviço de inferência, onde Platform e Security teams aplicam Zero Trust sem tocar na lógica do agente.

O que é o modelo de ameaças de LLM no Kubernetes e por que ele importa?
O Kubernetes orquestra e isola processos, mas é agnóstico ao conteúdo que processa — ele não valida se um prompt é malicioso nem se o modelo tem privilégio demais. A CNCF mapeia os riscos pelo OWASP LLM Top 10, com quatro críticos para operadores: Prompt Injection (LLM01), vazamento de dados sensíveis (LLM02), supply chain de modelos (LLM03) e Excessive Agency (LLM06). A defesa é tratar LLM como API: autenticação, autorização e higienização de input na camada de aplicação, não na infra.

Como o malware BRICKSTORM ataca o vSphere e como me defendo?
O BRICKSTORM mira o vCenter Server Appliance e os hosts ESXi, operando abaixo do sistema operacional guest, onde EDR tradicional não alcança. Não é um CVE específico, é exploração de hardening fraco e lacuna de logging. A defesa tem quatro fases: aplicar STIG/benchmark, gestão de identidade (PAW, PAM, desabilitar shell do vpxuser no 8.0+), rede Zero Trust segmentada e visibilidade forense com auditd encaminhando via TLS para o SIEM. A Mandiant publicou um script de hardening do vCenter.

Como controlo o custo de rodar inferência de IA em produção?
Trate compute de inferência como problema de FinOps, não de capacidade bruta. O GKE Inference Gateway unifica tráfego real-time e assíncrono num pool único — tasks batch via Pub/Sub preenchem ciclos ociosos sem degradar a latência das requisições síncronas. O GKE Active Buffer reserva capacidade declarativa para eliminar latência de scale-out sem over-provisioning 24/7. E o Bedrock Guardrails tem custo por token: integre essa métrica ao seu monitoramento.

O fim do sidecar de remote-write do Prometheus no Azure me afeta quando?
O suporte ao sidecar de remote-write para o Azure Monitor Workspace encerra em 31 de março de 2027. Apesar do prazo longo, mapeie a transição no roadmap já: a Microsoft recomenda migrar para o Azure Monitor Agent ou integrar a configuração nativamente no seu Prometheus self-hosted. O ganho colateral é reduzir o footprint de CPU e memória que o sidecar impõe em cada pod.

Fontes: