MCP fica stateless e ganha autorização corporativa em 28/07

Em 28 de julho de 2026 a especificação do Model Context Protocol muda de forma mais profunda do que qualquer atualização desde o lançamento. O núcleo do protocolo deixa de guardar sessão, e a extensão de autorização corporativa que estava em teste desde junho vira padrão estável, já adotada por Anthropic, Microsoft e Okta. Se sua empresa já expõe dados ou ferramentas via MCP para agentes de IA, ou está prestes a expor, essas duas mudanças mexem direto em como esse servidor vai escalar e em quem vai conseguir acessá-lo.

O timing importa. A janela entre o release candidate e a especificação final é curta, e o release concentra atenção de pesquisadores de segurança e de atacantes ao mesmo tempo. Vale entender o que muda de fato, o que isso resolve e, principalmente, o que continua sendo trabalho da sua empresa depois que o protocolo estiver atualizado.

O momento também coincide com uma virada de adoção no Brasil. Guias em português sobre o que é MCP e como montar um servidor básico já circulam há meses, mas essa cobertura ainda trata o protocolo como novidade técnica isolada, sem entrar na especificação que muda em 28 de julho nem na extensão de autorização corporativa que várias empresas grandes já adotaram. Quem decide arquitetura de agentes de IA na sua empresa vai ouvir falar dessa atualização de um jeito ou de outro; melhor entender o que ela muda antes de alguém perguntar na reunião errada.

O que muda tecnicamente no protocolo em 28 de julho

A mudança central tem nome técnico: o MCP passa a ser stateless na camada de protocolo. Duas propostas de mudança de especificação (SEP, na sigla do projeto) sustentam isso.

A SEP-2575 remove o handshake initialize/initialized que abria toda conexão MCP. Antes, cliente e servidor trocavam versão do protocolo, informações do cliente e capacidades uma vez, no início da conversa, e essa troca definia o resto da sessão. Agora esses dados viajam em _meta a cada requisição, então não existe mais um momento de “abertura” que precise ser lembrado depois.

A SEP-2567 remove o cabeçalho Mcp-Session-Id e a sessão em nível de protocolo que vinha junto. Servidores que hoje precisam de sticky routing, ou seja, garantir que toda requisição de um cliente caia sempre na mesma instância, e de um armazenamento de sessão compartilhado entre instâncias, deixam de precisar disso na camada do protocolo. Um servidor MCP remoto passa a rodar atrás de um load balancer comum, do tipo round-robin, sem inspeção profunda de pacote no gateway para manter afinidade de sessão.

Junto dessa mudança de núcleo entram três peças novas: um framework de extensões formal (é assim que a própria EMA existe como extensão, não como parte obrigatória do core), a extensão Tasks para trabalho assíncrono de longa duração, e o MCP Apps, que permite interfaces renderizadas pelo servidor dentro do cliente. O projeto também formalizou uma política de depreciação, o que muda o ritmo com que versões antigas do protocolo deixam de ser suportadas.

Na prática, o efeito é visível em como um servidor MCP lida com escala hoje versus depois de 28 de julho. Hoje, um servidor que atende três equipes diferentes precisa saber, a cada requisição, a qual sessão aberta ela pertence, e o gateway precisa garantir que essa requisição chegue na instância que guarda o estado daquela sessão. Depois da mudança, cada requisição carrega o que o servidor precisa saber sobre si mesma, e qualquer instância consegue respondê-la. Isso reduz o número de componentes que podem falhar sob pico de uso, justamente quando mais agentes de IA estão chamando o mesmo servidor ao mesmo tempo. O ganho não fica só na infraestrutura.

Por que isso importa para quem já roda MCP em produção

Se você opera um servidor MCP hoje, provavelmente já sentiu o custo operacional da sessão em protocolo: infraestrutura dedicada para manter afinidade, complexidade extra no gateway, e um ponto a mais que pode falhar sob carga. Tirar isso do protocolo simplifica a arquitetura de quem escala servidor MCP para múltiplos agentes e múltiplas equipes.

Há também um ganho direto de cache. Sem handshake obrigatório repetindo capacidades a cada nova sessão, um cliente pode manter em cache a resposta de tools/list pelo tempo que o parâmetro ttlMs do servidor permitir, em vez de reconsultar a cada conexão. Para quem opera dezenas de servidores MCP atendendo agentes diferentes, isso reduz round-trips e latência sem trocar nada na lógica de negócio.

O outro lado da moeda é migração. A janela de dez semanas contadas a partir do release candidate existe justamente porque mantenedores de SDK e implementadores de cliente precisam validar as mudanças contra carga real antes de considerar suporte pronto. SDKs classificados como nível 1 (Tier 1) devem oferecer suporte dentro desse prazo; os demais seguem depois. Na prática, isso quer dizer que 28 de julho é o dia em que a especificação final é publicada, não o dia em que todo servidor em produção precisa estar migrado. Mas quem espera até o fim da janela corre o risco comum de toda mudança de protocolo: descobrir a incompatibilidade no dia em que o cliente do usuário já atualizou e o servidor ainda não.

O que é a Enterprise-Managed Authorization

A segunda mudança relevante não é sobre o transporte, é sobre quem entra. A Enterprise-Managed Authorization, ou EMA, é uma extensão do MCP que ficou estável em 18 de junho de 2026 e resolve um problema conhecido de quem já testou MCP em escala: o consentimento OAuth repetido, aplicativo por aplicativo, servidor por servidor.

O mecanismo depende do provedor de identidade que a empresa já usa. Durante o login único (SSO), o cliente obtém do IdP um token chamado ID-JAG, sigla para Identity Assertion JWT Authorization Grant. Esse token é trocado pelo access token específico do servidor de autorização do servidor MCP em questão. O usuário faz login uma vez, e os servidores MCP que a empresa autorizou aparecem conectados sem prompt adicional.

O efeito prático é administrativo tanto quanto técnico. Hoje, cada novo servidor MCP costuma exigir que o usuário passe por uma tela de consentimento OAuth própria, o que trava adoção em escala e cria uma superfície de decisões de segurança espalhadas nas mãos de usuários individuais. Com EMA, quem decide o que fica autorizado é a equipe de identidade da empresa, no IdP central, e isso se propaga automaticamente para os servidores conectados. A extensão já tem adoção confirmada por Anthropic, Microsoft e Okta, além de um número crescente de servidores MCP que passaram a suportá-la.

O que isso resolve em segurança, e o que não resolve

A pesquisa mais citada sobre os riscos de MCP, do time de threat research da Akamai, é clara ao apontar os dois lados da mudança. Do lado positivo, tirar sessão do protocolo elimina uma classe inteira de risco que existia antes: sequestro de sessão em nível de protocolo. O guia de segurança publicado pela NSA em maio de 2026 descreve exatamente esse risco na versão anterior do protocolo: um ator malicioso conseguindo se passar por um cliente legítimo, injetar prompt não solicitado ou interagir com o servidor MCP sem ser detectado, tudo a partir de uma sessão reutilizada indevidamente. Sem Mcp-Session-Id para roubar, essa via de ataque específica deixa de existir.

Só que a mesma análise da Akamai avisa que a superfície de ataque não desaparece, se desloca. O modelo stateless, combinado com Tasks (trabalho assíncrono) e MCP Apps (interface renderizada pelo servidor), abre caminhos novos que dependem de quem constrói e opera o servidor prestar atenção a ciclo de vida de token e validação de parâmetro, exatamente os dois pontos que o guia da NSA recomenda reforçar. Trocando em miúdos: o protocolo ficou mais seguro por padrão em um eixo específico, mas isso não substitui revisão de segurança do lado de quem opera o servidor.

O que fazer antes de 28 de julho

Para quem já expõe ou está prestes a expor um servidor MCP, o checklist prático até a data do release é curto, mas vale a pena revisar com antecedência:

1. Confirme a versão do SDK que seu servidor e seu cliente usam, e se ela está na lista de Tier 1 com suporte previsto dentro da janela de dez semanas. Se não estiver, planeje o intervalo até a atualização chegar.
2. Mapeie quais servidores MCP sua empresa já expõe, internos ou expostos a parceiros, e quais dependem hoje de sticky routing ou sessão compartilhada. Esses são os que mais sentem o benefício operacional da mudança, e também os que precisam de teste de carga depois de migrar.
3. Avalie se faz sentido adotar EMA se sua empresa já centraliza identidade num IdP corporativo e tem mais de um servidor MCP em uso. O ganho cresce com o número de servidores, porque cada um deixa de exigir consentimento próprio.
4. Não trate a atualização como suficiente em segurança. Revise ciclo de vida de token, validação de parâmetro e escopo de acesso de cada servidor, seguindo a recomendação da NSA, independente de já estar ou não na nova especificação.
5. Documente quem aprovou o quê. Se sua empresa vai migrar para EMA, registre qual time definiu quais servidores MCP ficam autorizados no IdP e por quê. Essa decisão hoje concentrada em uma tela de administração é exatamente o tipo de dado que jurídico e auditoria vão pedir mais cedo do que se imagina.

Onde a governança de contexto entra

Nada do que descrevemos até aqui decide quais fontes um agente pode consultar através de um servidor MCP, nem separa conteúdo aprovado de conteúdo em rascunho, nem deixa registro do que sustentou uma resposta específica. EMA resolve quem consegue logar sem prompt repetido. O núcleo stateless resolve como o servidor escala e fecha uma classe de sequestro de sessão. Nenhum dos dois toca no problema seguinte, que é justamente onde mora o risco que preocupa segurança, jurídico e auditoria: o que o agente vê depois de autenticado.

Essa é a distinção que já vale para MCP vs function calling vs RAG: MCP resolve conexão, não decide qual fonte é confiável, qual escopo cada agente tem, nem registra o que foi usado numa resposta. Um servidor MCP com EMA bem configurada garante que só usuários autorizados entrem. Não garante que o agente de vendas, uma vez conectado, esteja vendo só as bases aprovadas para a finalidade dele, nem que exista trilha para reconstruir por que ele respondeu o que respondeu. Isso é trabalho de MCP corporativo com camada de contexto governado por cima do protocolo, não do protocolo em si.

Na prática, as duas coisas se somam. A especificação de 28 de julho resolve autenticação e escala. A camada de governança resolve fonte aprovada, escopo por agente e evidência auditável. Empresas que tratam a atualização do protocolo como o fim da lição de segurança tendem a descobrir tarde que autenticação correta e acesso indevido a fonte errada são dois problemas diferentes, e só o primeiro está coberto pela nova especificação.

Faça o diagnóstico gratuito e descubra se seus servidores MCP já têm fonte aprovada, escopo definido e trilha de evidência, ou se dependem só da autenticação para parecer seguros.

Marcas citadas (Anthropic, Microsoft, Okta, Akamai, NSA) pertencem a seus respectivos proprietários. Contextfy é uma camada independente de contexto governado e não declara parceria oficial, certificação ou integração nativa, salvo quando explicitamente informado.