O MCP Corporativo Acabou de Atravessar a Linha da Engenharia

Em 14 de abril de 2026, a Cloudflare publicou a primeira arquitetura de referência pública que descreve o MCP fora da engenharia. A frase do post é curta e deliberada: equipes de produto, vendas, marketing e finanças já usam fluxos agênticos nas tarefas diárias. Cinco linhas de texto resolvem um debate que arrastávamos há meses.

Vínhamos defendendo, com algum incômodo, que as funções de negócio não tinham ferramentas de governança à altura do que a engenharia já tem. Como argumentamos em A Lacuna de Ferramentas de Governança Entre Domínios, marketing, design e finanças operavam no escuro enquanto a engenharia ganhava reverse proxies, auditoria e detecção de prompt injection. A Cloudflare publica agora o primeiro contraexemplo sério. A tese não morre. Ela se estreita.

O que a Cloudflare nomeou

A arquitetura de referência distribui controles em cinco planos. Vale a pena memorizar o mapa, porque qualquer conversa corporativa sobre MCP nos próximos meses vai girar em torno dele.

Identidade: Cloudflare Access faz OAuth, SSO, MFA e atributos contextuais (IP, localização, certificado de dispositivo). Decide quem chega a qual servidor MCP.

Descoberta e política: os portais MCP são um endpoint único que agrega vários servidores. Um usuário de finanças só vê o portal de finanças. Visibilidade é resultado de política, não de convenção de nomes.

Mediação de modelo: o AI Gateway registra chamadas, aplica limites de tokens por funcionário e roteia entre provedores. A política entra antes dos tokens saírem do perímetro.

Conteúdo: perfis de DLP e políticas HTTP do Gateway examinam os primeiros 1.024 bytes do corpo das requisições POST com expressões regulares em Rust. Redação de PII, bloqueio por padrão.

Tráfego sombra: o Gateway faz varredura de domínios com mcp, URIs como /mcp e /sse, e dez padrões regex em JSON-RPC para detectar servidores MCP não sancionados.

Essa taxonomia não resolve tudo, como veremos. Mas fecha a primeira versão de algo que a comunidade vinha pedindo desde que o protocolo apareceu. Como relatamos em A Trilogia de Governança da Cloudflare, a empresa passou os últimos meses transformando governança em produto. Este post é o terceiro ato.

A economia de tokens que torna a governança viável

Governar MCP custa caro se cada servidor conectado empurrar mais tokens para dentro do contexto do agente. É por isso que o Code Mode importa. No portal, 52 ferramentas distribuídas em servidores MCP pesavam cerca de 9.400 tokens de definições; com o Code Mode, viram duas primitivas, search e execute, que cabem em 600 tokens. Redução de 94%. Na implementação do lado do servidor para a API da Cloudflare, com mais de 2.500 endpoints, o corte vai de 1,17 milhão de tokens para mil. Redução de 99,9%.

O que essa compressão compra? Desacopla o custo do agente da quantidade de integrações. Sem ela, cada servidor MCP adicional deixa o agente mais burro e mais caro. Com ela, governar fica economicamente viável. É o efeito que descrevemos em Agent Ops em Escala de Produção: a engenharia só escala quando o custo marginal da disciplina cai para perto de zero.

O Code Mode roda em isolados V8, sem sistema de arquivos, sem variáveis de ambiente e com fetch externo desligado por padrão. Não é um modelo de segurança completo, mas reduz a superfície de prompt injection.

Project Think preenche a execução durável

Uma arquitetura de portal sem runtime durável cai no primeiro reboot. Em 15 de abril de 2026, a Cloudflare publicou o Project Think, que oferece os três blocos que faltavam.

Fibers dão execução durável por checkpointing. Um agente sobrevive ao reinício, ao crash, à janela de manutenção. Facets são Durable Objects filhos com SQLite isolado e RPC tipado: a Cloudflare chama de sub-agentes, mas o que importa é que o isolamento é estrutural, não por política. A hibernação dos Durable Objects derruba o custo ocioso: dez mil agentes ativos 1% do tempo consomem o equivalente a cem agentes concorrentes. Matemática arquitetônica, não benchmark auditado.

Isso importa porque uma função de negócio não aceita fluxo que precisa ser reiniciado na mão quando a máquina cai. Finanças fecha o mês uma vez por mês; não há segunda chance. A camada de runtime precisa ser tão séria quanto a camada de acesso. Como exploramos em Governança como Produto: A Lição da Datadog, governança sem continuidade operacional é slide, não sistema.

Humwork preenche o hand-off agente→humano

Ainda em 15 de abril, a Humwork (Y Combinator P26) anunciou um marketplace A2P, agent-to-person, integrado via MCP. Mil especialistas verificados em engenharia, design, jurídico, marketing, estratégia e finanças: as mesmas superfícies que a Cloudflare nomeou. Handoff em menos de trinta segundos, com redação automática de PII, resposta na mesma thread, contexto devolvido ao agente.

A promessa fecha um ciclo que estava aberto: o que acontece quando o agente falha? Até agora, a resposta honesta era “escala para alguém do time, torce por contexto”. Humwork propõe um loop operacional explícito. Os números, porém, são de beta: 87% de resolução sobre 2.858 perguntas, primeira resposta abaixo de dois minutos. Autorrelatado, não auditado. Empresa nenhuma compra SLO assim; empresa nenhuma ignora o padrão que isso estabelece.

A trilogia que vale guardar: Access governa quem conecta, Think roda o trabalho de forma durável, Humwork escala quando o agente erra. Esse é o loop operacional que um CIO assina, não um protocolo.

Onde a retórica ultrapassa a evidência

Um bom leitor de posts corporativos sabe que a arquitetura de referência é sempre mais ambiciosa do que a documentação pública. Três observações honestas.

Primeiro, a lacuna de detecção versus prevenção no MCP sombra. A Cloudflare entrega dez padrões regex e o corte de 1.024 bytes no corpo da requisição POST. Qualquer servidor que não traga mcp no domínio, que use SSE via GET, ou que empurre o payload para além do limite, passa invisível. Detecção é um sinal inicial útil. Perímetro, não é. A diferença é decisiva para quem precisa responder a auditoria regulatória.

Segundo, o controle de default-deny para escrita aparece no post, mas não está documentado nas páginas canônicas da Cloudflare One. Vive no template do servidor de referência, não na camada de plataforma. Se o cliente não adota o template exato, herda a semântica de escrita que o servidor MCP subjacente expõe. É uma boa prática recomendada, vestida como garantia arquitetônica.

Terceiro, o log de auditoria do portal captura tempo, status, servidor, capacidade e duração. Não captura argumentos, saídas ou contexto do prompt. Dá para responder “quem invocou qual ferramenta, quando”. Não dá para responder “com quais dados, e com que consequência”. Para investigação forense ou resposta a incidente regulado, o schema é fino. A DX Heroes sinalizou esse mesmo vão em pesquisa independente deste mês, e a Cloudflare só o endereça em parte.

A frase sobre produto, vendas, marketing e finanças também merece cautela. A Cloudflare disse que os times usam fluxos agênticos: não quantos, não quais, não se rodam processos críticos ou apenas experimentos pessoais. A arquitetura está pronta. A profundidade da adoção continua opaca.

O que muda na tese

A forma antiga da tese sustentava que as funções fora da engenharia não tinham ferramentas. A forma nova precisa dizer outra coisa.

As primitivas existem. O que ainda falta é a profundidade de implantação documentada, as bibliotecas de políticas específicas por domínio (DLP de finanças, PII de marketing, escopos de vendas) e, sobretudo, o dono organizacional. Quem, em finanças, assina a política do servidor MCP que toca o ERP? Quem, em marketing, audita o portal de ferramentas de campanha? Quando falamos em Lacuna de Disciplina de Governança na Automação, esse é o buraco real: não a ausência de ferramenta, mas a ausência de responsabilidade nomeada.

A Cloudflare respondeu metade da pergunta. A outra metade é sua. Três perguntas rendem mais do que mil slides:

O seu portal MCP tem política de identidade que sobrevive a auditoria em finanças regulamentadas?
Quem assina a política de DLP específica do domínio, e não o template genérico?
Quando um agente falha numa operação crítica, o hand-off está escrito, testado, com SLO que você aceitaria para um incidente humano?

A infraestrutura cruzou a linha da engenharia. A governança precisa cruzar junto. E é aí que a maioria das empresas ainda vai tropeçar nos próximos doze meses.

Fontes

Goldberg, Sharon; Carey, Matt; Anguiano, Ivan. “Scaling MCP adoption: Our reference architecture for simpler, safer and cheaper enterprise deployments of MCP.” Cloudflare, abril 2026.
Pai, Sunil; Reznykova, Kate. “Project Think: Cloudflare’s next-generation agent SDK.” Cloudflare, abril 2026.
Carey, Matt. “Code Mode: give agents an entire API in 1,000 tokens.” Cloudflare, fevereiro 2026.
TestingCatalog. “Humwork A2P marketplace connects AI agents with experts.” Abril 2026.
DX Heroes. “MCP governance in the enterprise: what the landscape looks like in early 2026.” Abril 2026.

Ajudamos empresas a avaliar e implementar infraestrutura de agentes com controles de governança embutidos: contato@victorino.com.br | www.victorino.com.br