Principais conclusões
Em 28 de julho de 2026, o MCP (Protocolo de contexto de modelo) passará oficialmente a adotar uma arquitetura corporativa sem estado.
Ao adotar um modelo sem estado e apresentar aplicativos com interfaces do usuário ricas e tarefas assíncronas, o protocolo transfere para os desenvolvedores toda a responsabilidade de estabelecer limites de segurança críticos.
A atualização elimina com sucesso os principais riscos de segurança históricos, incluindo sequestro de sessão em nível de protocolo, prompts não solicitados do servidor e métodos de autenticação fracos.
No entanto, a inclusão de um estado gerenciado por aplicativos, interfaces de IA interativas e sofisticadas e tarefas assíncronas de longa duração, abre novas possibilidades para abusos.
Se não forem adequadamente protegidas, essas novas funcionalidades podem permitir o acesso não autorizado aos dados de clientes, ataques de phishing direcionados a usuários (que se passam por experiências de IA confiáveis), a violação de controles de segurança corporativos e a interrupção de serviços devido ao uso indevido de processos em segundo plano.
A próxima especificação do MCP de 28 de julho de 2026 representa a maior evolução arquitetônica do MCP (Protocolo de contexto de modelos) desde sua criação. O que começou como uma ferramenta de integração de IA local de usuário único está se transformando em uma plataforma com compatibilidade para implementações em larga escala e nativas da nuvem para empresas.
Após o lançamento do release candidate em 21 de maio de 2026, a especificação final está programada para ser lançada em 28 de julho de 2026, acompanhada de um período formal de descontinuação de 12 meses de algumas funcionalidades legadas.
Evolução da superfície de ataque
A atualização reformula completamente a forma como o protocolo gerencia dados e processos para criar essa base adequada para uso empresarial. Ela apresenta uma arquitetura sem estado, baseada em solicitações com múltiplas rotas, novos cabeçalhos HTTP padronizados e um objeto _meta universal para mensagens contextuais. Além disso, a especificação formaliza as aplicações MCP e as tarefas assíncronas, ao mesmo tempo que eleva a integração OAuth a um patamar de destaque.
Embora grande parte das discussões sobre essas funcionalidades gire em torno de escalabilidade e interoperabilidade, seu impacto estrutural na superfície de ataque do protocolo também é extremamente significativo. Conforme o modelo de segurança evolui, alguns riscos de longa data relacionados ao protocolo são mitigados ou eliminados por completo, enquanto novas responsabilidades passam a ser atribuídas diretamente aos desenvolvedores de aplicações MCP (Figura 1). Em última análise, embora essas mudanças melhorem a base, são as decisões de implementação que agora determinam a postura geral de segurança.
Fig. 1: evolução da superfície de ataque no MCP na nova especificação
Superfícies de ataque que foram reduzidas ou eliminadas
Versões anteriores do MCP apresentavam diversos riscos de segurança devido a sessões gerenciadas por protocolo, comunicação iniciada pelo servidor e requisitos de autenticação menos robustos. A nova especificação redesenha ou elimina vários desses mecanismos, reduzindo a superfície de ataque em nível de protocolo. Esses mecanismos incluem:
Sequestro de sessão no nível de protocolo
Prompts não solicitados do servidor
Métodos de autenticação fracos
Sequestro de sessão no nível de protocolo
As versões anteriores do MCP dependiam de um processo de inicialização com estado que mantinha uma sessão de longa duração utilizando o cabeçalho Mcp-Session-Id. Esses identificadores de sessão são geralmente alvos de alto valor, pois eles permitem que invasores se passem por usuários autenticados.
A nova especificação elimina completamente essas sessões gerenciadas por protocolo, removendo esse vetor de ataque específico. No entanto, os desenvolvedores agora precisam criar seus próprios mecanismos seguros de gerenciamento de estado (abordaremos esse assunto mais adiante neste artigo).
Prompts não solicitados do servidor
Versões anteriores do MCP permitiam que servidores enviassem prompts ou solicitações inesperadas aos clientes em momentos aleatórios por eventos Server-Sent.
As novas regras impõem limites rigorosos a esse comportamento, impedindo que servidores comprometidos interrompam os usuários de forma silenciosa com interações maliciosas e não solicitadas.
Métodos de autenticação fracos
A atualização exige a adoção dos rigorosos requisitos do Oauth 2.1, reduzindo drasticamente os riscos de autenticação. Ao eliminar senhas antigas, permissões implícitas e exigir medidas de proteção modernas, como a PKCE (Chave de prova para troca de código), o protocolo restringe de forma significativa a maneira como as credenciais e os tokens podem ser vazados ou explorados.
Coletivamente, essas mudanças reduzem drasticamente a superfície de ataque relacionada à autenticação e o raio de impacto em sessões que existiam em implantações anteriores de MCP.
Novas superfícies de ataque introduzidas pela especificação
Embora o protocolo elimine vários tipos de vulnerabilidades, ele também introduz novas áreas em que a segurança depende intensamente da qualidade da implementação, incluindo:
Sequestro de fluxo de trabalho entre agentes
Manipulação de metadados controlados pelo cliente
Confusão de cabeçalho e exposição de dados pelos cabeçalhos
Aplicações MCP e cross-site scripting armazenado
Exploração de riscos em tarefas de longa duração executadas em segundo plano
Sequestro de fluxo de trabalho entre agentes
A busca pelo “sem estado” acompanha desafios sutis relacionados à segurança. Em ambientes corporativos, as interações com IA nem sempre são conversas simples e diretas, baseadas em uma única solicitação. Muitas vezes, elas exigem uma sequência de eventos interligados. Por exemplo:
Solicitação de esclarecimentos: uma ferramenta pode interromper uma tarefa no meio para solicitar ao usuário informações adicionais que estejam faltando
Verificação de progresso: um trabalho demorado pode exigir que o sistema solicite atualizações regularmente
Interrupção de fluxos de trabalho: um processo complexo pode ser interrompido por uma hora enquanto aguarda aprovação humana e retomar a execução exatamente de onde parou
Como o novo MCP não tem estado, ele não utiliza sessões permanentes para identificar quem é quem. Em vez disso, ele introduz identificadores de rastreamento e objetos de estado que o servidor fornece ao cliente. O cliente então devolve esses dados quando está com tudo pronto para retomar o fluxo de execução; isso fornece ao cliente controle praticamente total sobre o estado da tarefa.
A preocupação com a segurança é simples: como esses IDs de rastreamento e objetos de estado são enviados diretamente pelo cliente, o servidor não pode confiar neles sem uma verificação prévia. Na Figura 2, pode-se notar que, se um servidor MCP utilizar IDs de rastreamento previsíveis ou não validar rigorosamente a integridade do objeto de estado recebido, um invasor pode adivinhar ou alterar esses valores para:
Sequestrar o fluxo de trabalho ativo de outro usuário
Acessar informações pertencentes a outro agente
Executar ações não autorizadas entre diferentes locatários
Fig. 2: ilustração de tentativa de adivinhação de ID de rastreamento e manipulação de estado
Embora a especificação oficial do MCP alerte explicitamente os desenvolvedores sobre a necessidade de verificar a integridade desses objetos, ela não define um padrão ou método de implementação específico, deixando a responsabilidade de criar essa camada de segurança totalmente a cargo dos desenvolvedores de cada servidor.
Manipulação de metadados controlados pelo cliente
A nova especificação introduz um objeto _meta que permite aos clientes anexar metadados personalizados a praticamente qualquer mensagem MCP. Mesmo em uma única solicitação simples, um invasor pode fornecer pares de chave-valor maliciosos, como {"tenant": "admin", "authenticated": true}.
Como esses campos não possuem assinatura criptográfica, se um servidor confiar cegamente nesses metadados para tomar decisões de roteamento ou autorização, um único pedido malicioso pode resultar imediatamente em escalada de privilégios ou acesso a dados entre diferentes locatários.
Confusão de cabeçalho e exposição de dados pelos cabeçalhos
A especificação introduz cabeçalhos HTTP específicos do MCP, como Mcp-Method e Mcp-Name, que ajudam intermediários, proxies, gateways e servidores a entender e rotear corretamente as solicitações do MCP de forma consistente.
No entanto, esses cabeçalhos também introduzem dois novos riscos de segurança:
Ataques de confusão de protocolo (dessincronização): os invasores podem enviar valores conflitantes entre os cabeçalhos HTTP e o corpo da solicitação JSON-RPC, explorando uma incompatibilidade entre dois protocolos de comunicação diferentes (HTTP e JSON-RPC) para desestabilizar a infraestrutura de back-end do servidor. Essa inconsistência pode fazer com que proxies e servidores de back-end interpretem a mesma solicitação de formas diferentes, permitindo que invasores burlem medidas de segurança, evitem monitoramento ou ocultem ações maliciosas.
Vazamento de dados pelo x-mcp-header: esta nova diretriz permite que os desenvolvedores mapeiem argumentos específicos de ferramentas diretamente para cabeçalhos HTTP. Isso ajuda os proxies a rotearem o tráfego mais rapidamente, sem a necessidade de analisar todo o conteúdo da solicitação. No entanto, se os desenvolvedores acidentalmente mapearem dados confidenciais, como chaves de API (interface de programação de aplicações), tokens ou PII (informações de identificação pessoal), esses dados serão enviados diretamente para os cabeçalhos. Nos cabeçalhos, eles são visíveis para todos os balanceadores de carga, proxies e sistemas de registro ao longo do caminho.
Aplicações MCP e cross-site scripting armazenado
Uma das atualizações mais empolgantes do MCP é a transformação das aplicações MCP em uma extensão de protocolo de alto nível. As aplicações MCP são os painéis visuais interativos que você encontra em aplicações de inteligência artificial, como o Claude Desktop (por exemplo, formulários e painéis interativos, visualizadores de documentos, telas de acompanhamento de fluxos de trabalho e tarefas).
Embora essas interfaces melhorem significativamente a experiência do usuário, elas também trazem para o ecossistema de IA os riscos tradicionais dos navegadores web, como o XSS (cross-site scripting). Por exemplo, um invasor pode armazenar códigos maliciosos em HTML ou JavaScript em uma ferramenta MCP. Quando outro usuário (ou um agente de IA) acessa esse conteúdo, o script malicioso é executado automaticamente dentro da interface da aplicação.
Embora a especificação do MCP exija que os agentes executem esses scripts dentro de um <iframe> de testes para impedir que agentes maliciosos assumam o controle total do agente de IA, os usuários ainda correm riscos. Um invasor ainda pode usar o painel comprometido para exibir conteúdo enganoso, realizar campanhas de phishing para obter informações confidenciais com prompts falsos, roubar quaisquer dados de usuários que estejam visíveis no painel específico e enviar essas informações roubadas de volta para seus próprios servidores (Figura 3).
Fig. 3: ilustração de exploração de aplicações MCP por meio de XSS armazenado
Exploração de riscos em tarefas de longa duração executadas em segundo plano
A introdução de tarefas de longa duração cria um grande vetor de ataques de DoS (negação de serviço) que depende de interações unidirecionais. Como a criação de tarefas é barata para o cliente, mas exige muitos recursos do servidor, um invasor pode enviar uma única solicitação para iniciar uma operação complexa (que consome CPU, memória ou espaço de armazenamento no banco de dados) e se desconectar imediatamente.
Este método de exploração assíncrona unidirecional faz com que o servidor continue processando workloads pesadas mesmo após a desconexão do cliente, esgotando rapidamente seus recursos.
Conclusão
A especificação MCP 2026-07-28 marca a transição do protocolo, de um uso local a uma implementação empresarial em larga escala. Do ponto de vista da segurança, as mudanças não são apenas melhorias incrementais. Eles redefinem fundamentalmente onde as responsabilidades de segurança devem residir: as decisões de segurança que antes eram impostas pelo protocolo agora são cada vez mais delegadas aos desenvolvedores de servidores MCP e aos operadores da plataforma.
Conforme a adoção do MCP se expande rapidamente em ambientes de nuvem, a principal preocupação em relação à segurança já não é se o protocolo em si é seguro. Agora, as equipes de segurança devem determinar se as aplicações desenvolvidas com base nessa tecnologia implementam corretamente os novos limites de confiança, os mecanismos de gerenciamento de estado e os modelos de execução introduzidos pela especificação.
Como as equipes de segurança podem proteger adequadamente essas novas superfícies de ataque? Elas devem tratar todos os dados e metadados fornecidos pelos clientes como entradas não confiáveis, implementando verificações criptográficas rigorosas, codificação de saída para painéis visuais gerados por IA e cotas de recursos robustas para tarefas assíncronas.
Para lidar com essa mudança, é essencial adotar uma arquitetura de defesa proativa que bloqueie ataques antes que eles atinjam a infraestrutura de back-end.
Tome uma atitude agora
A Akamai permite que as organizações ajam imediatamente. Ao aprimorar nossa plataforma existente de segurança de edge, APIs e aplicações, e integrá-la com inteligência capaz de detectar o MCP, ajudamos as equipes a identificar onde o MCP está surgindo, a implementar medidas de segurança práticas durante os testes e a gerenciar os riscos à medida que a exposição aumenta.
Essa abordagem permite que as organizações adotem o MCP hoje, contando com a Akamai para aprimorar a proteção, a visibilidade e o controle à medida que o uso do MCP evolui.
Tags
