Esta semana em cloud (09–15/fev): o MCP virou o barramento dos agentes de operação

TL;DR: O fio da semana foi o Model Context Protocol virando o barramento pelo qual agentes de IA passam a operar a nuvem: a Microsoft mostrou o Azure SRE Agent governando Databricks e o Well-Architected via MCP, e a Oracle expôs a tenancy OCI como servidor MCP. Em cima vieram as contas de identidade (Entra ID OBO para preservar o Unity Catalog), de rede (enclaves de agente da Equinix) e de fundação: Claude Opus 4.6 no Bedrock e nftables no AKS.

Foi uma semana de blocos: a AWS soltou o resumo de segunda-feira, a Oracle publicou meia dúzia de posts de OCI, a Microsoft despejou atualizações de Azure, Fabric e Sentinel. Lido item a item, parece a enxurrada de sempre — uma família nova de EC2 aqui, um preview de conector ali. Mas quando você empilha os anúncios e procura o que se repete, aparece um fio condutor nítido: o Model Context Protocol (MCP) deixou de ser uma curiosidade de quem brinca com agentes e virou a interface padrão pela qual a IA passa a operar a infraestrutura, não apenas conversar sobre ela.

Três fontes independentes desta semana descrevem o mesmo movimento por ângulos diferentes. A Microsoft mostrou o Azure SRE Agent usando MCP para auditar e remediar tanto o Databricks quanto a conformidade com o Well-Architected Framework. A Oracle apresentou a OCI Policy Analysis expondo a tenancy inteira como um servidor MCP que Claude ou o VS Code consultam em linguagem natural. E a AWS colocou o Claude Opus 4.6 no Amazon Bedrock, descrito como o motor de raciocínio para exatamente esse tipo de agente complexo. Não é coincidência: é a mesma aposta sendo feita ao mesmo tempo pelas três grandes nuvens.

A leitura para quem opera infra no Brasil é a de sempre, em roupa nova. Assim que o agente ganha o poder de agir — descobrir recursos, rodar SQL, gerar comando de remediação —, ele herda três problemas antigos e nada triviais: identidade (com qual permissão ele age?), rede (por onde os agentes conversam sem vazar dado nem latência?) e fundação (a plataforma embaixo aguenta?). Esta edição segue exatamente essa trilha.

Por que o MCP virou o barramento dos agentes de operação?

A promessa do MCP é modesta no enunciado e ampla na consequência: dar a um agente de IA uma forma padronizada de descobrir e chamar ferramentas externas, eliminando a necessidade de integrações ad-hoc para cada serviço. Esta semana, a Microsoft transformou essa promessa em dois casos de operação concretos. No primeiro, o Azure SRE Agent atua sobre o Databricks: o servidor MCP roda containerizado em Azure Container Apps e expõe a API REST do Databricks como ferramentas (list_clusters, list_catalogs, list_jobs, execute_sql). Com isso, o agente valida um workspace inteiro contra as melhores práticas e, quando um job falha com código não-zero, investiga a causa raiz cruzando logs e metadados — derrubando o tempo de review de conformidade de horas para minutos e o MTTR de investigação em 80–95%, segundo os números do próprio time.

No segundo caso, o mesmo padrão é apontado para a governança: o servidor Azure MCP expõe o Azure Resource Graph e as APIs ARM como ferramentas, e o agente inventaria recursos em múltiplas subscriptions, avalia cada um contra os cinco pilares do Well-Architected Framework (Reliability, Security, Cost Optimization, Operational Excellence, Performance) e gera remediação pronta — comando de Azure CLI, snippet de Terraform ou passo no portal — com impacto quantificado. O detalhe que importa para quem opera: ele cruza os achados com um arquivo org-practices.md, ou seja, a base de conhecimento da empresa entra no loop. É a diferença entre um checklist genérico e uma auditoria que entende o seu contexto.

A Oracle inverteu o vetor e chegou ao mesmo lugar. A ferramenta OCI Policy Analysis — feita em Python sobre o OCI SDK — consolida políticas, compartimentos, grupos e dynamic groups para responder às perguntas que todo administrador de tenancy adia: quem tem privilégio excessivo no lugar errado? e como as permissões mudaram ao longo do tempo?. Entre os recursos avançados está, justamente, a integração com servidor MCP: a tenancy OCI passa a ser consultável por ferramentas como Claude ou o VS Code, que respondem sobre políticas com base em dados reais. Aqui o MCP não orquestra ação, ele abre a porta da governança para o agente ler o estado com fidelidade — pré-requisito para qualquer ação confiável depois.

Quer estruturar agentes de SRE e conformidade via MCP sem abrir mão da governança? Fale com os especialistas em automação e SecOps da Nuvem Online.

A conta da identidade: agente não pode ter privilégio maior que o humano

Dar a um agente o poder de rodar SQL contra o seu data lake é exatamente onde a empolgação encontra o risco. O artigo da Microsoft sobre IA multi-agente com Entra ID OBO cravou o problema sem rodeios: quando um agente consulta o backend usando service accounts ou PAT tokens compartilhados, ele contorna row-level security, column masking e as regras de governança do Unity Catalog — a organização perde visibilidade, controle de acesso e auditabilidade de uma vez. O princípio que precisa governar tudo é simples de enunciar e fácil de violar na prática: a IA, agindo em nome de, nunca pode ter privilégios superiores aos do humano que disparou a solicitação.

A solução proposta usa o fluxo On-Behalf-Of (OBO) do Microsoft Entra ID para preservar a identidade ponta a ponta. A arquitetura encadeia Chainlit (interface conversacional sobre OAuth 2.0), Azure App Service, LangGraph (orquestração dos agentes), Azure Databricks Genie (linguagem natural para SQL) e Cosmos DB (memória de longo prazo). O truque está na troca de token: o access token precisa carregar a audiência correta (api://{client_id}/access_as_user), e a biblioteca MSAL faz a troca pelo token de escopo do Databricks. O resultado contém o UPN do usuário — então, ao passar para o WorkspaceClient do Databricks SDK, cada query obedece às permissões do Unity Catalog configuradas para aquele indivíduo, não para um robô genérico.

Há três alertas de engenharia que valem repetir, porque são onde implementações reais escorregam. Isolamento de agentes: jamais use agentes globais em cache — cada sessão de usuário precisa de instâncias independentes, sob pena de vazamento de contexto e de privilégio entre usuários. Claims do ID Token: quando a audiência impede o acesso direto ao Graph API, extraia o contexto de identidade das claims. E Human-in-the-Loop: mesmo com RBAC alinhado, operações destrutivas (DROP, DELETE, UPDATE) devem exigir aprovação explícita, via interrupt do LangGraph. Para quem opera sob LGPD, essa abordagem identity-first não é refinamento — é a condição para colocar um agente perto de dado sensível sem reabrir um buraco de auditoria que levou anos para fechar.

Sua rede não foi feita para agentes conversando entre nuvens

Resolvida a identidade, sobra a topologia. O blog da Equinix colocou o dedo numa ferida que a euforia com agentic AI costuma ignorar: a rede que você tem não foi projetada para o tráfego entre agentes. A tese da arquitetura distribuída é que o comportamento inteligente emerge da colaboração de múltiplos agentes autônomos rodando em ambientes diferentes — uns na AWS, outros no Azure, outros on-premises. O problema é que, quando um agente na AWS precisa consultar um agente de dados no Azure para fechar uma tarefa em tempo real, cada milissegundo de latência e cada salto pela internet pública degrada a performance e amplia a superfície de ataque. Pior: à medida que novos agentes surgem espalhados, as políticas de rede e os controles de segurança ficam fragmentados, sem um plano de governança comum.

A resposta proposta são os Secure Agent Enclaves: zonas isoladas e de alta performance onde os agentes interagem com segurança, independentemente de onde esteja o provedor de infraestrutura. Em vez da internet pública, a aposta é em interconexões privadas — eliminando o throughput instável e garantindo que o fluxo de dados sensíveis não escape do controle corporativo. O recado para times brasileiros é estratégico: a estratégia multi-cloud precisa evoluir de conectividade para orquestração de rede inteligente. Implementar enclaves permite mover o deployment de agentes com agilidade, mantendo conformidade local e a resiliência que se exige de sistemas que tomam decisões autônomas em nome do negócio. É o mesmo argumento das seções anteriores num terceiro plano: o agente é a parte fácil; a infraestrutura ao redor é o que decide se ele escala ou vira passivo.

Sob os agentes, a fundação cloud-native que ninguém aplaude

Por mais que os holofotes fiquem na IA, a semana também entregou os avanços de base que sustentam qualquer coisa rodando em cluster — e é aqui que a operação de verdade acontece. O mais concreto veio da rede do Kubernetes: o AKS passou a oferecer o kube-proxy em modo nftables (em preview), encerrando a longa era do iptables. A justificativa é puramente de escala: o iptables avalia regras de forma linear, então o tempo de lookup cresce com o número de serviços, virando um imposto oculto de CPU e latência em clusters grandes com endpoint churn constante. O nftables usa estruturas otimizadas e faz busca direta. O upstream marcou esse modo como estável na v1.33, o Project Calico passou a suportá-lo na v3.29+, e no AKS a configuração delega a rede ao Calico via --network-plugin none. A nota de rodapé operacional importa: o troubleshooting muda — entram ferramentas como o Calico Whisker para visualizar fluxos em tempo real e o Microsoft Retina, que usa eBPF para enxergar descartes de pacotes e métricas de DNS.

Na camada de contrato, o Kubernetes publicou um perfil do subprojeto de API Governance do SIG Architecture, com Jordan Liggitt, que também é tech lead do SIG Auth. O ponto que atravessa a entrevista é o que torna o Kubernetes confiável como base de tudo o que vem em cima: o escopo da governança não é só a API REST, mas todas as interfaces — flags de linha de comando, arquivos de configuração, como os binários persistem dados no etcd. A revisão entra cedo, ainda na fase de KEP, antes da primeira linha de código, justamente para preservar a semântica de spec/status e a retrocompatibilidade. A pergunta que eles fazem em toda revisão — "como você evolui isso daqui a dois anos sem quebrar quem usa hoje?" — é a razão pela qual dá para construir agentes, gateways e plataformas sobre o Kubernetes sem medo de que a fundação se mova debaixo dos pés.

E há a observabilidade, que é o que permite confiar em qualquer automação. Numa conversa com Ted Young, cofundador do OpenTelemetry (hoje na Grafana Labs), ficou a metáfora do "caracol de corrida": o projeto tem alta latência de decisão, mas altíssimo throughput de impacto, porque não pode se dar ao luxo de quebrar compatibilidade reversa. O insight que mais interessa a quem vai automatizar operação é a unificação dos sinais — tracing, nessa leitura, é "logging com o contexto que sempre quisemos". Se a telemetria é padronizada na origem, a correlação acontece naturalmente e você reduz vendor lock-in: dá para trocar o backend de análise sem re-instrumentar a aplicação. E o recado para a era da IA é sóbrio: qualquer IA de observabilidade só será tão boa quanto a precisão dos dados que o OpenTelemetry fornece. Vale para o agente de SRE também — sem telemetria de qualidade, automação confiante é só palpite rápido.

O que levar desta semana

A semana não anunciou um paradigma; mostrou três das grandes nuvens convergindo, ao mesmo tempo, na mesma direção: o MCP como o barramento que dá ao agente de IA o poder de operar a infraestrutura, não só comentá-la. O Azure SRE Agent fez isso no Databricks e no Well-Architected; a Oracle expôs a tenancy OCI como servidor MCP; a AWS pôs o Claude Opus 4.6 no Bedrock como motor desse raciocínio, com Structured Outputs para domar a saída. Mas o valor da edição está no que vem junto com o agente. Identidade: sem Entra ID OBO preservando o UPN, o agente fura o Unity Catalog e a LGPD junto — privilégio de robô nunca pode passar do privilégio do humano. Rede: a Equinix lembrou que tráfego entre agentes multi-cloud pela internet pública é latência e superfície de ataque; enclaves privados são a correção. Fundação: nftables no AKS, a governança de API do Kubernetes e a disciplina do OpenTelemetry são o chão que decide se a automação escala ou desaba no primeiro incidente. Quem tratar a IA agêntica como um recurso de produto vai colher demos; quem tratá-la como mais uma carga que exige identidade, rede e observabilidade bem operadas vai colher plataforma.

Perguntas Frequentes

O que é o Model Context Protocol (MCP) e por que ele apareceu em tantos anúncios desta semana?
O MCP é um padrão que permite a um agente de IA descobrir e chamar ferramentas externas de forma previsível, sem integrações ad-hoc para cada serviço. Nesta semana ele apareceu como a interface comum de três frentes: o Azure SRE Agent consumindo as APIs do Databricks e do Azure Resource Graph/ARM como ferramentas MCP, e a Oracle expondo a tenancy OCI como um servidor MCP que Claude ou o VS Code podem consultar. O ponto não é o protocolo em si, mas o que ele habilita: o agente deixa de só responder e passa a inventariar, avaliar e propor remediação contra o ambiente real.

Usar um agente de IA para consultar dados no Databricks não fura a governança do Unity Catalog?
Fura se o agente usar service accounts ou PAT tokens compartilhados — porque aí ele consulta com privilégios próprios, contornando row-level security, column masking e as regras do Unity Catalog. A arquitetura apresentada pela Microsoft resolve isso com o fluxo On-Behalf-Of (OBO) do Entra ID: o token carrega o UPN do usuário final, então cada query do Databricks Genie respeita exatamente as permissões daquela pessoa. A regra de ouro é que a IA, agindo em nome de alguém, nunca tenha privilégio maior que o humano que disparou a solicitação.

O Claude Opus 4.6 no Bedrock muda algo para quem opera infraestrutura?
Muda o teto de complexidade dos agentes que dá para colocar em produção. A AWS posicionou o Opus 4.6 como o modelo mais capaz da Anthropic para tarefas de agentes complexos, codificação pesada e workflows que exigem raciocínio profundo — exatamente o perfil dos agentes de SRE e conformidade que dominaram a semana. Some a isso os Structured Outputs no Bedrock, que permitem fixar um schema JSON na resposta do modelo, e você remove a camada frágil de validação manual que costuma quebrar pipelines de automação.

Por que o AKS está migrando do iptables para o nftables no kube-proxy?
Porque o iptables avalia regras de forma linear: o tempo de lookup cresce com o número de serviços, virando um imposto oculto de CPU e latência em clusters grandes com endpoint churn constante. O nftables usa estruturas otimizadas e faz busca direta, escalando sem essa degradação. O upstream marcou o kube-proxy em modo nftables como estável na 1.33, o Project Calico passou a suportá-lo na v3.29+, e o AKS agora oferece a opção em preview — delegando a rede ao Calico via --network-plugin none.

A rede multi-cloud tradicional aguenta o tráfego entre agentes de IA?
Segundo a Equinix, não sem custo. Quando um agente na AWS precisa consultar um agente de dados no Azure em tempo real, cada salto pela internet pública adiciona latência e amplia a superfície de ataque, enquanto as políticas de rede ficam fragmentadas entre ambientes. A proposta são os Secure Agent Enclaves: zonas isoladas e de alta performance, conectadas por interconexões privadas em vez da internet pública, onde os agentes interagem sem que o dado sensível saia do controle de governança. Para o Brasil, isso significa tratar multi-cloud como orquestração de rede, não só conectividade.

Fontes: