MCP cacheScope: Impedindo Vazamentos de Resultados Privados Entre Usuários

MCP cacheScope aborda um problema sutil: uma resposta pode ser nova e ainda assim ser insegura para outro usuário.

A especificação MCP de 2026-07-28 define dicas de cache para resultados reutilizáveis. Um servidor pode marcar um resultado como public ou private, enquanto ttlMs diz quanto tempo pode permanecer novo. Mas um cache de cliente compartilhado ainda precisa de informações de identidade suficientes para manter as entradas privadas separadas.

Se Alice aquece um cache e Bob usa o mesmo armazenamento mais tarde, uma chave de cache incompleta pode retornar o resultado de Alice para Bob. Eu considero isso como uma fronteira de segurança que vale a pena testar.

Por que o MCP cacheScope precisa de uma partição de cache

A especificação de cache MCP cobre descoberta, listas de ferramentas e prompts, listas de recursos, modelos de recursos e leituras de recursos.

Seus escopos têm significados diferentes:

• public resultados podem ser reutilizados em diferentes contextos de autorização, mesmo quando o endpoint requer autenticação.
• private resultados podem ser reutilizados apenas dentro do mesmo contexto de autorização.

Para um catálogo de ferramentas específico do usuário, o servidor pode descrever o resultado assim:

const server = new McpServer(
  { name: "private-catalog", version: "1.0.0" },
  {
    cacheHints: {
      "tools/list": {
        ttlMs: 60_000,
        cacheScope: "private",
      },
    },
  },
);

Essa dica comunica a intenção de cache do servidor. Não informa a um cache compartilhado qual chamador fez a solicitação.

Uma chave de cache já precisa do método e de todos os parâmetros que podem mudar o resultado. A identidade de autorização normalmente viaja fora dos parâmetros de tools/list, então o cliente precisa de uma partição separada para isso.

Reproduza o vazamento com um armazenamento compartilhado

A forma perigosa é pequena: dois contextos de autorização, um cache de resposta e nenhuma partição.

const sharedCache = new InMemoryResponseCacheStore();

function unpartitionedClient() {
  return new Client(
    { name: "shared-gateway", version: "1.0.0" },
    { responseCacheStore: sharedCache },
  );
}

Minha demonstração usa dois endpoints em processo com a mesma identidade de servidor MCP. Um expõe uma ferramenta exclusiva de Alice; o outro expõe uma ferramenta exclusiva de Bob. Esses endpoints representam os diferentes resultados que um servidor autenticado real produziria.

Alice chama tools/list primeiro, colocando seu resultado privado no armazenamento compartilhado. Bob então chama o mesmo método com os mesmos parâmetros e identidade de servidor.

Sem cachePartition, a busca não distingue os contextos de autorização. Bob recebe a lista de ferramentas em cache de Alice, e seu endpoint não manipula nenhuma solicitação de tools/list. O guia de cache do SDK TypeScript v2 alerta que essa configuração pode servir o corpo de resposta privada de um usuário para outro.

O teste passa intencionalmente quando reproduz o resultado inseguro. Isso torna o modo de falha visível sem credenciais, um serviço de rede, um modelo ou uma chamada de API paga.

Corrija o MCP cacheScope com uma partição estável

A correção é dar a cada contexto de autorização uma partição de cache estável:

const sharedCache = new InMemoryResponseCacheStore();

function clientFor(cachePartition: string) {
  return new Client(
    { name: "shared-gateway", version: "1.0.0" },
    {
      responseCacheStore: sharedCache,
      cachePartition,
    },
  );
}

const alice = clientFor("subject:alice");
const bob = clientFor("subject:bob");

Agora as entradas privadas de Alice vivem separadamente das de Bob. O mesmo método, parâmetros e identidade de servidor não resolvem mais para o mesmo local de cache privado. O segundo teste prova que ambos os endpoints recebem uma solicitação e cada cliente vê apenas sua própria ferramenta.

Eu derivaria a partição de uma identidade de autorização estável e opaca. Ela deve incluir todas as dimensões que podem mudar a visibilidade, como inquilino, sujeito, função ou escopo efetivo. Um token bearer bruto é uma partição ruim: é material secreto e pode rotacionar enquanto o principal subjacente permanece o mesmo.

O