Durante anos, o grande projeto de integração das empresas foi conectar dados: sincronizar o ERP com o e-commerce, unificar cadastros, montar o data warehouse, fazer o CRM conversar com o marketing. Em 2026, o eixo se deslocou. O trabalho de integração deixou de ser só sobre dados e passou a ser sobre agentes — softwares autônomos que chamam ferramentas, disparam ações e conversam entre si. E, na mesma semana, dois marcos deixaram essa virada impossível de ignorar: o gateway de MCP virou uma camada de infraestrutura, e os próprios protocolos que conectam agentes ganharam um dono neutro.
Este artigo explica o que aconteceu, por que o "portão" dos agentes de IA virou o novo tecido conectivo do stack corporativo, o que exatamente um gateway de MCP controla, e como montar essa camada com identidade, política e auditoria — antes que cada novo agente vire uma porta aberta que ninguém rastreia.
1. O que aconteceu: o gateway de MCP virou camada de infraestrutura
No Black Hat 2026, a Snowflake anunciou o Cortex AI Gateway, integrando a tecnologia da Natoma — empresa que ela havia adquirido em maio de 2026. Na prática, é um gateway de MCP centralizado: um ponto único por onde passam as chamadas de ferramenta (tool-calls) dos agentes, impondo identidade, política e auditoria no nível de cada chamada. E o detalhe que muda tudo: ele governa tanto agentes próprios quanto de terceiros — Amazon Bedrock, Azure AI Foundry, ChatGPT, Claude Code, Cursor, aplicações construídas com LangChain ou LlamaIndex.
O Model Context Protocol (MCP) nasceu como a forma padronizada de um modelo de IA descobrir e usar ferramentas externas — bancos, APIs, sistemas internos. Até aqui, cada time plugava seus MCP servers de forma isolada, sem um controle central. O anúncio da Snowflake formaliza uma tendência que já estava no ar: o gateway de MCP deixou de ser um utilitário de nicho e virou uma camada horizontal de infraestrutura — o equivalente, para o mundo dos agentes, ao que o API gateway foi para o mundo dos microserviços. A leitura de mercado ficou clara na frase de Mayank Upadhyay, da Snowflake: "a IA empresarial está indo de interoperabilidade de dados para interoperabilidade de agentes — e a segurança tem que estar no centro dessa mudança."
2. De interoperar dados a interoperar agentes: o que muda de verdade
A distinção parece sutil, mas reorganiza a arquitetura inteira. Na interoperabilidade de dados, o que trafega entre sistemas são registros: um pedido, um cliente, um SKU. O controle é relativamente estático — você mapeia campos, define contratos de schema, valida payloads. O risco é conhecido: dado errado, dado duplicado, dado desatualizado.
Na interoperabilidade de agentes, o que trafega é intenção e ação. Um agente não pede "me devolva o registro X"; ele decide, em tempo de execução, quais ferramentas chamar, em que ordem, com quais parâmetros — e pode acionar outro agente para completar a tarefa. O fluxo é dinâmico, não determinístico e, muitas vezes, cruza fronteiras de confiança: o seu agente chama uma ferramenta que toca um sistema crítico; o agente de um fornecedor chama o seu agente; um agente de IA de um parceiro aciona um processo dentro da sua casa.
É por isso que a pergunta de segurança muda de natureza. Antes: "esse dado está correto e protegido em trânsito?" Agora: "quem é esse agente, o que ele tem permissão de acionar, e como eu provo depois o que ele fez?" Sem uma resposta clara para essas três perguntas, escalar agentes é escalar superfície de ataque.
3. O que um gateway de MCP faz: identidade, política e auditoria no tool-call
Um gateway de MCP bem desenhado atua exatamente no ponto mais granular — a chamada de ferramenta — e resolve três controles que, soltos, são impossíveis de manter:
Identidade. Todo agente que chega ao gateway precisa se autenticar e carregar uma identidade verificável — não um token genérico de aplicação, mas um princípio de identidade que diz "sou o agente de compras do time X, agindo em nome do usuário Y". Sem isso, todo tool-call é anônimo, e auditoria vira adivinhação.
Política. O gateway aplica autorização no momento da chamada: este agente pode ler este recurso, mas não escrever; pode consultar o estoque, mas não emitir a nota; pode chamar a ferramenta de refund até um limite de valor. A política vive em um lugar só, versionada, em vez de espalhada em prompts e no código de cada agente — onde ninguém consegue auditar.
Auditoria e observabilidade. Cada chamada é registrada: qual agente, qual ferramenta, quais parâmetros, qual resultado, com que latência e a que custo. Isso não é só compliance — é a única forma de responder, depois de um incidente, "o que exatamente esse agente acessou?" e de otimizar custo e performance quando você tem dezenas de agentes rodando em produção.
É a mesma lógica de defesa que já existia para tráfego de API — autenticação, rate limiting, WAF, logs — reencarnada para o tráfego de tool-calls de agentes. A novidade não é o princípio; é o ponto de aplicação.
4. MCP + A2A com dono: a Linux Foundation e o que isso significa
O segundo marco é institucional, e talvez mais duradouro que qualquer produto. Os dois protocolos que sustentam a interoperabilidade de agentes — MCP (agente ↔ ferramenta) e A2A (agente ↔ agente) — passaram a ser governados pela Linux Foundation, sob a recém-criada Agentic AI Foundation (AAIF). Seis co-fundadores que competem ferozmente no mercado — OpenAI, Anthropic, Google, Microsoft, AWS e Block — sentaram na mesma mesa para governar os protocolos em conjunto.
Os números dão o tamanho do movimento: mais de 18.000 MCP servers já indexados, e um roadmap que inclui o MCP v2, uma trust chain para o A2A (como um agente prova, em cadeia, que tem permissão para agir) e um programa de conformidade de segurança para gateways. Quando protocolos de infraestrutura saem das mãos de um único fornecedor e vão para uma fundação neutra com múltiplos concorrentes, a mensagem para quem compra é direta: essa camada veio para ficar, vale a pena investir arquitetura nela, e ela não vai ser refém da estratégia comercial de um único vendor.
5. O número que dói: 57% das organizações sem segurança pronta para agentes
A urgência não é teórica. 57% das organizações relatam um déficit sério de segurança e gestão de risco em relação a agentes de IA. Traduzindo: mais da metade das empresas já tem — ou está prestes a ter — agentes chamando ferramentas e tocando dados sem identidade, sem política central e sem auditoria.
O padrão é conhecido de todo ciclo de adoção de tecnologia nova: os times de produto e os fornecedores correm para colocar agentes em produção, porque o ganho é real e imediato. A camada de governança fica para depois — e "depois" costuma chegar na forma de um incidente. A diferença, com agentes, é a velocidade de propagação: cada novo agente que entra sem passar por um ponto de controle é uma nova porta, e agentes se multiplicam muito mais rápido que integrações tradicionais. Sem um gateway, você não consegue nem responder à pergunta básica — quantos agentes estão ativos e o que cada um pode acionar?
6. Como a CCX monta e opera essa camada
Montar e operar a malha de conectividade dos agentes é, na sua essência, um projeto de integração enterprise — exatamente o que a CCX faz há anos, agora aplicado ao stack agêntico. Na prática, o trabalho tem quatro frentes que se sustentam:
Integrações & APIs Enterprise. Desenhar e expor os MCP servers que dão ferramentas aos agentes, orquestrar o A2A entre agentes, e posicionar o gateway de MCP como ponto único de identidade, política e auditoria no tool-call. É conectividade entre sistemas via REST, GraphQL, gRPC e arquitetura event-driven com Kafka e RabbitMQ — o mesmo repertório que já liga SAP a e-commerce ou ERPs de médio porte a plataformas de venda, agora estendido para agentes.
Security Engineering. Identidade de agente, guardrails, prevenção de exfiltração e controle de acesso no gateway — o "centro" que 57% das organizações admitem não ter. Security by design em cada camada, com OAuth2, gestão de identidade, criptografia e pentest.
Observabilidade 360°. Rastrear cada chamada — qual agente, qual ferramenta, latência, custo — com tracing distribuído (OpenTelemetry) e dashboards em Datadog, Grafana e Prometheus. É o que transforma "confio que está tudo certo" em "sei exatamente o que aconteceu".
Arquitetura Cloud + DevOps. Rodar gateway, registry de MCP servers e brokers com escala elástica e governança, para a camada aguentar produção real e não virar gargalo.
Agente de IA sem gateway é porta aberta — e 57% das empresas admitem esse déficit. A CCX desenha e opera a camada de integração dos seus agentes: MCP servers para ferramenta, A2A entre agentes e um gateway que impõe identidade, política e auditoria em cada chamada, com observabilidade ponta a ponta. Implemente a arquitetura de integração e governança dos seus agentes de IA →
7. Perguntas frequentes
O que é um gateway de MCP? É um ponto central por onde passam as chamadas de ferramenta (tool-calls) dos agentes de IA. Ele autentica o agente, aplica políticas de autorização e registra cada chamada — funcionando como um API gateway, mas para o tráfego de agentes em vez de tráfego de APIs tradicionais.
Qual a diferença entre MCP e A2A? MCP (Model Context Protocol) padroniza como um agente descobre e usa ferramentas externas. A2A (Agent-to-Agent) padroniza como um agente conversa e delega tarefas a outro agente. Um cobre a relação agente↔ferramenta; o outro, agente↔agente.
Por que governar agentes é um problema de integração, e não só de política? Porque a política só é efetiva no ponto onde a ação acontece — o tool-call. Definir regras em um documento não impede um agente de agir; é preciso uma camada técnica (o gateway, a identidade, a auditoria) que aplique a regra em tempo de execução. Isso é engenharia de integração e segurança, não governança em PowerPoint.
Preciso de um gateway se uso apenas agentes de um fornecedor? Mesmo em um cenário de fornecedor único, o gateway concentra identidade e auditoria e evita que cada equipe reinvente o controle. E o cenário realista é multi-fornecedor: o valor do gateway cresce justamente quando você mistura agentes próprios e de terceiros cruzando fronteiras de confiança.
Por onde começar? Pelo inventário: quantos agentes estão ativos, o que cada um pode acionar e por onde passam as chamadas hoje. A partir daí, se define o ponto único de controle (o gateway), a identidade de cada agente e o que auditar. É o diagnóstico que a CCX conduz antes de desenhar a arquitetura.