Português

A Snowflake Comprou a Natoma. A Microsoft Entregou o Agent 365. A Anthropic Fez Tunnel com MCP. Aqui Está o Padrão de CTO para o Roadmap de Governança de Agents

Três control planes MCP da Snowflake, Microsoft e Anthropic disputando o roadmap de governança de agents do CTO

Três grandes fornecedores empresariais se movimentaram sobre governança de Model Context Protocol (MCP) em 30 dias. A pergunta para o CTO não é qual deles vai vencer. É se você enxerga o padrão antes do próximo ciclo de renovação.

O Que a Snowflake de Fato Comprou

Em 27 de maio de 2026, a Snowflake anunciou um acordo definitivo para adquirir a Natoma, uma plataforma de governança MCP empresarial construída especificamente para AI agents. De acordo com o comunicado à imprensa da Snowflake, o negócio acrescenta três capacidades ao stack da Snowflake: um registro verificado de servidores MCP, uma camada de identidade e um plano de políticas de acesso.

O que isso significa na prática: os Cortex Agents, o Snowflake Intelligence e o Cortex Code da Snowflake agora podem alcançar aplicativos SaaS empresariais, bancos de dados, APIs, nuvens privadas virtuais (VPCs) e sistemas on-premises por meio de uma única superfície de governança. Plataformas de AI de terceiros têm o mesmo acesso. Cada ação de agent é auditável, cada conexão é controlada por políticas e cada servidor MCP deve passar pelo registro antes que um agent possa usá-lo.

O blog técnico da Snowflake enquadra a motivação diretamente: a adoção de MCP introduziu governança fragmentada, atividade de shadow AI e risco de exfiltração de dados conforme os agents se multiplicam nos sistemas empresariais. A Natoma transforma o data warehouse na malha de governança, não apenas no armazenamento de dados. A cobertura da CIO do negócio chamou isso de uma aposta de que a gravidade dos dados puxa as decisões de governança para onde quer que seu data warehouse já esteja.

Fatos Relevantes

  • A Snowflake anunciou sua intenção de adquirir a Natoma em 27 de maio de 2026, adicionando um registro verificado de servidores MCP, uma camada de identidade e um plano de políticas de acesso ao seu stack (comunicado à imprensa da Snowflake, 2026).
  • O negócio da Natoma é a terceira grande movimentação de governança MCP em uma janela de 30 dias: a Anthropic entregou sandboxes self-hosted e tunnels MCP em 19 de maio, a Microsoft posicionou o Agent 365 como o control plane de AI em 28 e 29 de maio, e a Snowflake fechou a janela em 27 de maio.
  • Três camadas de plataformas distintas agora competem para ser donas do control plane de agents: a camada de dados (Snowflake), a camada de produtividade (Microsoft) e a camada de modelos (Anthropic).

O Padrão de Aquisição MCP que a Maioria dos CTOs Ainda Não Nomeou

Diagrama de três camadas de control plane MCP com destaque para Snowflake mais Natoma na camada de dados

A armadilha não é escolher o fornecedor errado. A armadilha é tratar cada uma dessas movimentações como um anúncio de produto isolado, em vez de um único padrão que se desdobra em sequência.

Aqui está o padrão: todo grande fornecedor de plataforma empresarial está correndo para ser dono do control plane de MCP, não porque o MCP seja tecnicamente maduro, mas porque quem estabelece a propriedade de governança agora define as regras de compras para os próximos cinco anos de compras de agents empresariais.

Os três players representam três apostas estruturalmente diferentes sobre qual camada conquista o direito de ser a âncora de governança.

Camada de dados (Snowflake mais Natoma). A aposta aqui é que a gravidade dos dados vence. As empresas já concentram dados sensíveis em seu warehouse. Se a governança segue os dados, o operador do warehouse se torna o executor natural de políticas para todo agent que toca esses dados. O registro, a camada de identidade e o plano de políticas da Natoma caem diretamente nesse campo gravitacional.

Camada de produtividade (Microsoft via Agent 365). A aposta da Microsoft, anunciada no final de maio pelo Agent 365, é que a camada de fluxo de trabalho empresarial possui a governança porque os agents derivam valor dos fluxos de trabalho. Se os agents vivem no Microsoft 365, no Teams e no Copilot Studio, então o tecido de identidade e políticas já tecido pelo Entra ID e pelo Azure é o lar natural para o controle de agents. O pacote de produtividade já sabe quem é o usuário, o que ele está autorizado a fazer e quais sistemas ele pode acessar.

Camada de modelos (Anthropic via sandboxes self-hosted e tunnels MCP). A movimentação da Anthropic, entregue em 19 de maio, é um argumento diferente: execute o ambiente de execução de agents dentro do perímetro de segurança do cliente. Os sandboxes self-hosted e tunnels MCP da Anthropic permitem que agents empresariais alcancem sistemas privados por meio de um único gateway de saída, sem exposição de firewall de entrada. O fornecedor do modelo se torna a âncora de confiança porque controla onde o raciocínio acontece e como os sistemas privados são acessados.

Nenhuma dessas apostas está errada. As três são coerentes. Mas não são compatíveis como a única camada de governança, e os três fornecedores estão apresentando a sua exatamente como isso.

O CTO que se comprometer com o control plane de uma camada antes que o padrão se estabilize corre o risco de construir uma arquitetura de governança que funciona até que um ciclo de renovação crie um momento de lock-in que ele não previu.

Por Que o Argumento da Camada de Dados É Diferente

O argumento da Snowflake merece sua própria análise porque é estruturalmente distinto dos outros dois.

O argumento da camada de produtividade (Microsoft) e o argumento da camada de modelos (Anthropic) dependem de efeitos de rede por meio de relacionamentos de software existentes. A alavancagem da Microsoft é que seus funcionários já vivem no Teams e no Outlook. A alavancagem da Anthropic é que seus desenvolvedores já estão construindo com Claude. Ambos os argumentos dizem: você já confia em nós para X, agora estenda essa confiança para a governança de agents.

O argumento da Snowflake é diferente. Ele diz: sua governança deve seguir seus dados porque seus dados não se movem. Registros empresariais sensíveis ficam no warehouse. Requisitos de conformidade já se ligam ao warehouse. Controles de segurança já envolvem o warehouse. O registro e o plano de políticas da Natoma não pedem que você estenda a confiança para uma nova superfície. Eles anexam a governança a uma superfície que já é confiável.

Esse argumento é estruturalmente mais forte do que pode parecer em um briefing de produto. Ele não exige que você acredite que a Snowflake é a melhor empresa de AI. Exige apenas que você acredite que a gravidade dos dados é real e que sua equipe de conformidade sempre vai perguntar "onde os dados vivem?" antes de aprovar qualquer ação de agent.

Mas não confunda "estruturalmente coerente" com "estrategicamente seguro". Aceitar o argumento de governança da camada de dados da Snowflake ainda significa aceitar a Snowflake como o ponto de aplicação de políticas para todos os agents em seu stack, incluindo agents construídos em infraestrutura que não é da Snowflake. Isso é uma centralização arquitetônica significativa, independentemente de quão limpo seja o argumento.

Para um framework sobre avaliação de risco de lock-in de fornecedor na camada de governança, o artigo sobre soberania de AI e lock-in de fornecedor cobre o padrão de dependência com mais detalhes.

O Teste de 4 Perguntas para CTOs sobre Qualquer Control Plane MCP

Antes de se comprometer com a abordagem de governança MCP de qualquer fornecedor, seja a aquisição da Natoma pela Snowflake, o Agent 365 da Microsoft ou a arquitetura de sandbox da Anthropic, faça estas quatro perguntas.

1. Registro verificado de servidores MCP: quem garante que um servidor MCP é seguro para instalar? Um control plane MCP precisa de uma lista gerenciada centralmente e assinada de servidores aprovados. Pergunte a cada fornecedor: qual é o processo para incluir um servidor no registro? Quem o audita? O que acontece quando um servidor registrado é comprometido? A resposta diz se o registro é um mecanismo real de segurança ou apenas um item de checklist de produto.

2. Modelo de identidade: o agent herda a identidade do usuário, a própria identidade de serviço do agent, ou ambas? Essa pergunta tem consequências significativas mais adiante. Se o agent herda a identidade do usuário, ele tem acesso de nível de usuário a cada sistema que aquele usuário pode acessar. Se usa sua própria identidade de serviço, você precisa de um modelo de permissões separado. Se usa ambas (identidade delegada para algumas ações, identidade de serviço para outras), você precisa de clareza sobre quais ações usam qual modelo. Respostas imprecisas aqui são um risco de governança, não uma lacuna de produto.

3. Motor de políticas: onde "o agent X pode executar a ação Y no sistema Z" é de fato avaliado? O motor de políticas é a lógica em tempo de execução que determina o que um agent tem permissão de fazer em um determinado contexto. Ele precisa ser centralizado (para que não haja fragmentação de políticas entre sistemas), auditável (para que você possa reconstruir decisões) e rápido o suficiente para não introduzir latência que torne os agents inutilizáveis. Pergunte aos fornecedores onde o motor de políticas roda, como é atualizado e se a avaliação de políticas é síncrona ou em cache.

4. Trilha de auditoria: você consegue reconstruir exatamente qual agent fez o quê, em qual registro, em nome de quem? "Trilha de auditoria" não é o mesmo que "logs". Uma trilha de auditoria responde a perguntas de causalidade: por que o agent fez essa chamada de API, quais dados ele recuperou, cuja autorização ele usou e o que mudou como resultado. Se a história de auditoria de um fornecedor é "você recebe logs de servidor", essa é uma resposta diferente de "você recebe um fluxo estruturado de eventos com ligação causal à ação do usuário originador". Saiba qual dos dois você está comprando. O recurso de trilhas de auditoria para ações executadas por AI cobre como é uma arquitetura de auditoria pronta para produção.

Para o framework de avaliação mais amplo, a orientação sobre AI approval gates e revisão de fornecedores é um complemento útil.

Perguntas Frequentes

O que é a aquisição da Natoma pela Snowflake?

A Natoma é uma plataforma de governança MCP empresarial que adiciona um registro verificado de servidores, uma camada de identidade e um plano de políticas de acesso às implantações de AI agents. A Snowflake anunciou sua intenção de adquirir a Natoma em 27 de maio de 2026. O negócio dá à Snowflake uma malha de governança que permite que os Cortex Agents e plataformas de AI de terceiros se conectem a sistemas empresariais por meio de uma única superfície de controle auditável, sem exigir que os agents ignorem os controles de segurança existentes do data warehouse.

Por que os control planes MCP se tornaram repentinamente o campo de batalha das compras em 2026?

O MCP, o Model Context Protocol, é o padrão emergente para como AI agents se conectam a ferramentas e fontes de dados externas. Conforme a adoção de agents empresariais acelera, quem controla a camada de políticas que governa quais agents podem se conectar a quais sistemas ganha alavancagem significativa nas compras. Três grandes fornecedores (Snowflake, Microsoft, Anthropic) fizeram movimentações distintas sobre governança MCP em 30 dias. A corrida não é sobre o MCP ser maduro. É sobre estabelecer a propriedade de governança agora, enquanto o padrão ainda está se formando e as empresas ainda não se comprometeram com uma arquitetura.

Como os CTOs podem evitar ficar presos na camada MCP de um fornecedor?

O primeiro passo é escrever seu próprio rubrica de avaliação de control plane MCP usando as quatro perguntas acima antes de avaliar qualquer fornecedor. Isso dá a você critérios neutros em relação ao fornecedor. O segundo passo é fazer um inventário de quais agents em sua organização atualmente usam MCP e qual superfície de controle eles já tocam. Se a maioria dos seus agents conectados via MCP roda pelo Microsoft 365, você já está parcialmente no campo da camada de produtividade, quer tenha pretendido ou não. Tornar isso visível permite que você faça uma escolha arquitetônica intencional em vez de herdar uma por meio da adoção de produto.

O Que CTOs Devem Fazer Este Mês

Quatro ações concretas que custam menos do que um ciclo completo de avaliação de fornecedores, mas estabelecem a postura de governança necessária:

  • Escreva uma rubrica de avaliação de control plane MCP em uma página. Use o teste de quatro perguntas acima. Uma página força a priorização. Compartilhe com suas equipes de segurança e compras antes que qualquer fornecedor apresente. Assim você vai avaliar os argumentos dos fornecedores com base nos seus critérios, não nos deles.

  • Faça um inventário de quais agents atualmente usam MCP e qual superfície de controle eles tocam. Isso não requer uma auditoria completa. Pergunte aos seus líderes de engenharia: quais agents estão rodando, quais usam conexões MCP e qual camada de identidade ou políticas do fornecedor está lidando com essas conexões hoje. A resposta provavelmente vai surpreender você.

  • Agende uma conversa de 30 minutos com cada um dos três fornecedores antes do seu próximo ciclo de renovação. Não um demo de produto. Uma conversa de arquitetura de governança. Traga as quatro perguntas. Faça-as especificamente. A capacidade do fornecedor de responder com clareza, não apenas com fluência, diz muito sobre o quão madura é a história de control plane deles de fato.

  • Mapeie seus agents para o framework de classificação de dados. Antes que qualquer conexão MCP seja autorizada em produção, o agent deve saber qual nível de classificação de dados está acessando. O recurso de classificação de dados para acesso de AI cobre como construir esse mapeamento. Sem ele, as avaliações de control plane acima são decisões de políticas sem superfície de aplicação.

O padrão está se movendo rapidamente. Mas a resposta certa não é escolher o primeiro fornecedor que parecer credível. É estabelecer seu próprio framework de avaliação enquanto todas as três opções ainda estão genuinamente disponíveis.

Saiba Mais