O dia em que meu adaptador MCP deixou de ser apenas encanamento

TL;DR: Remote MCP Adapter começou como uma camada de usabilidade para fluxos de trabalho remotos de MCP, mas a recente pesquisa sobre contaminação de ferramentas de MCP deixou uma coisa dolorosamente clara: o middleware no caminho também faz parte da fronteira de segurança. Na versão v0.3.0, adicionei fixação de definição de ferramenta, detecção de desvio, saneamento de metadados, minimização de descrições e vinculação de sessão mais rigorosa para reduzir o que metadados inseguros e o uso indevido de sessão podem fazer.

Depois de finalizar o trabalho principal para Remote MCP Adapter, fiz o que a maioria de nós faz depois de lançar algo que finalmente funciona: dei um passo atrás e comecei a olhar ao redor.

Eu queria ver como outras pessoas estavam lidando com a mesma classe de problemas. O Remote MCP é útil, mas uma vez que o cliente e o servidor param de compartilhar um sistema de arquivos, as coisas ficam feias rapidamente. Os uploads se tornam complicados. Os arquivos gerados se tornam complicados. Qualquer coisa envolvendo capturas de tela, PDFs, artefatos ou estado com escopo de sessão se torna complicada. Essa foi a razão original pela qual construí o adaptador em primeiro lugar.

Escrevi mais sobre esse lado da história em o blog anterior que inspirou este trabalho.

Então, encontrei um post no DEV: As descrições de ferramentas do seu servidor MCP são uma superfície de ataque.

Esse post, junto com a pesquisa subjacente a que aponta, forçou uma realização desconfortável.

O adaptador que eu havia construído para tornar o MCP remoto utilizável já havia se colocado no meio de uma fronteira de confiança.

E se algo está no meio de uma fronteira de confiança, não pode mais fingir que é apenas encanamento.

A realização

Meu adaptador já estava fazendo um trabalho sério. Ele estava sentado entre o cliente e os servidores MCP upstream. Estava encaminhando metadados de ferramentas visíveis ao modelo. Estava gerenciando uploads, artefatos e estado por sessão. Estava traduzindo comportamentos através de fronteiras que não existem em configurações apenas locais.

Esse é o tipo de componente que as pessoas costumam classificar mentalmente como um relé fino.

Não é.

Uma vez que um gateway ou adaptador vê catálogos de ferramentas, texto de esquema, descrições, identificadores de sessão, uploads, contexto de autenticação e artefatos retornados, ele já se tornou parte da postura de segurança do sistema, quer o mantenedor tenha planejado isso ou não.

Esse foi o momento em que o projeto mudou na minha cabeça.

O Remote MCP Adapter não era mais apenas uma camada de conveniência para manuseio remoto de arquivos e artefatos. Ele também havia se tornado um ponto de aplicação natural.

Não uma bala de prata. Não um firewall de IA. Não uma solução mágica para a segurança do MCP.

Mas definitivamente um ponto de aplicação.

O que mudou na v0.3.0

A v0.3.0 é o primeiro lançamento em que tratei o adaptador dessa forma explicitamente.

O objetivo não era resolver todos os problemas de segurança do MCP. Isso seria desonesto.

O objetivo era mais restrito e muito mais prático:

• parar de retransmitir cegamente metadados de ferramentas visíveis ao modelo
• detectar quando as definições de ferramentas desviam durante a sessão
• reduzir quanto texto de descrição inseguro ou desnecessário chega ao modelo
• apertar a semântica da própria sessão do adaptador uma vez que recursos com estado e autenticação estejam envolvidos
• documentar o que está implementado e o que ainda está fora do escopo

Isso levou a cinco mudanças concretas.

1) Padrões mais seguros para metadados de ferramentas visíveis ao modelo

O adaptador agora adota uma postura padrão mais rigorosa para metadados de ferramentas.

• core.tool_metadata_sanitization.mode agora tem como padrão sanitize
• core.tool_definition_pinning.mode agora tem como padrão warn

Esse padrão é importante.

Antes disso, os usuários tinham que pensar como engenheiros de segurança desde o início e optar pelo comportamento correto. Agora, o adaptador começa de uma posição mais segura e se torna mais rigoroso a partir daí, se o ambiente exigir.

Eu prefiro essa troca. Muitos recursos de segurança falham em campo simplesmente porque existem apenas como opções que ninguém ativa.

2) Fixação de definição de ferramenta e detecção de desvio

Este aborda o que algumas pessoas estão chamando de problema de "rug pull".

Se um servidor apresenta um catálogo de ferramentas no início de uma sessão e depois muda os títulos, descrições ou esquemas das ferramentas, isso não é mais uma atualização cosmética inofensiva. Isso é um comportamento visível ao modelo mudando sob uma relação de confiança já estabelecida.

Assim, o adaptador agora pode estabelecer uma linha de base para o primeiro catálogo de ferramentas visível de uma sessão e comparar catálogos posteriores com ele.

Quando um desvio é detectado, a política decide o que acontece a seguir:

• avisar
• bloquear
• invalidar a sessão completamente

Isso não é para ser inteligente. É para ser chato e confiável.

Se o que o modelo vê mudou, essa mudança não deve passar silenciosamente.

3) Saneamento de metadados antes de encaminhar esquemas de ferramentas

A contaminação de ferramentas não se trata apenas da descrição da ferramenta de nível superior.

Essa é uma das conclusões mais importantes da pesquisa recente. Uma vez que os metadados da ferramenta entram no contexto do modelo, qualquer texto visível ao modelo pode se tornar uma superfície de instrução: títulos, descrições, texto de esquema, títulos de anotações, descrições aninhadas e outros campos que parecem inofensivos quando tratados como metadados normais de software.

Assim, a v0.3.0 adiciona saneamento de metadados visíveis ao modelo para:

• títulos de ferramentas
• descrições de ferramentas
• títulos de anotações
• texto de esquema

No modo mais rigoroso, o adaptador pode bloquear ferramentas com metadados sujos em vez de encaminhá-las.

Este é o lugar certo para ser conservador. Se o middleware já está no caminho, ele deve pelo menos parar de agir como se todo esquema upstream fosse inocente por padrão.

4) Minimização e remoção de descrições de ferramentas

Agora há uma tool_description_policy unificada que se aplica tanto às descrições de ferramentas de nível superior quanto às descrições de esquema aninhadas.

Ela suporta três modos:

• preserve
• truncate
• strip

Este é especialmente útil para ambientes paranoicos ou rigidamente controlados.

Às vezes, a resposta certa não é "tentar detectar cada truque de contaminação inteligente em texto de descrição livre".

Às vezes, a resposta certa é: por que tanta prosa está chegando ao modelo?

É para isso que essa política serve.

Se um ambiente não precisa de texto de descrição rico, deve ser permitido minimizar ou removê-lo completamente.

5) Vinculação de sessão mais rigorosa quando a autenticação do adaptador está habilitada

Este é menos chamativo, mas importa.

Uma vez que o adaptador armazena uploads, artefatos, estado de cancelamento ou outros dados por sessão, a integridade da sessão deixa de ser apenas uma preocupação de transporte do MCP. Torna-se parte do próprio modelo de segurança do produto.

Assim, quando a autenticação do adaptador está habilitada, as sessões agora estão vinculadas ao contexto autenticado que as estabeleceu.

Isso significa que um Mcp-Session-Id reutilizado não pode simplesmente ser pego sob um contexto autenticado diferente.

Se o adaptador vai gerenciar estado, então também precisa assumir as consequências desse estado sendo mal utilizado.

Por que eu não queria exagerar isso

Seria muito fácil comercializar tudo isso como:

"Remote MCP Adapter agora protege você contra contaminação de MCP."

Isso seria preguiçoso e falso.

O que a v0.3.0 faz é muito mais específico.