Proteger um servidor MCP de empresa resume-se a três perguntas, respondidas por ordem. Quem é que se pode sequer ligar? Isso é o OAuth. A que é que um cliente ligado pode alguma vez aceder? Isso é o isolamento por workspace. E, do que é acessível, quem vê que parte? Isso é o âmbito — privado versus público, e os lugares. Acerta nas três e «expusemos o conhecimento da nossa empresa a clientes de IA» deixa de ser uma frase assustadora. Falha numa, e as outras duas não te salvam.

Eis o que cada camada significa na prática, e o que verificar em qualquer plataforma que aloje um servidor MCP por ti.

Camada 1: OAuth 2.1, segundo a especificação atual

O MCP fixou-se no OAuth 2.1 para autorização, e a palavra «atual» está a fazer trabalho a sério nessa frase. A especificação evoluiu, e as revisões recentes fecharam falhas reais. Há dois itens que vale a pena conhecer pelo nome, mesmo que nunca os implementes tu próprio.

A validação do emissor (iss) significa que o cliente verifica que uma resposta de autorização veio mesmo do servidor de autorização com que começou. Sem ela, um servidor malicioso pode fazer jogos de intermediário — os chamados ataques mix-up — e sair dali com um código destinado a outra pessoa. Aborrecido, essencial, e fácil de saltar se fizeres tudo à mão.

Os Client ID Metadata Documents (CIMD) são a forma como os clientes se identificam perante o teu servidor. Em vez de cada cliente MCP se pré-registar em cada servidor MCP — o que não escala para lá de uma demo — o cliente apresenta um URL que o descreve, e o servidor vai buscar e verifica esses metadados. É a peça que permite ao teu servidor funcionar com o Claude e com clientes MCP de que ainda nem ouviste falar, sem transformar o registo num vale-tudo.

O SuperCognit implementa ambos, segundo a especificação atual, em todos os servidores publicados. Se estiveres a avaliar qualquer produto MCP alojado, pergunta especificamente por estes dois. «Suportamos OAuth» é uma resposta de 2023 a uma pergunta de 2026.

Camada 2: isolamento por workspace

A autorização decide quem entra pela porta. O isolamento decide o que está atrás da porta. Cada servidor MCP do SuperCognit está limitado ao seu workspace: as suas bases de conhecimento, as suas ferramentas, os seus subscritores. Um token do servidor de um workspace não vale nada no de outro, e não há query, por mais criativa que seja, que recupere os documentos de um vizinho — a fronteira é estrutural, não um filtro aplicado no momento da resposta.

Isto importa mais do que parece. Os sistemas de recuperação respondem a partir do corpus que conseguem pesquisar. Se a fronteira do corpus for mole — um ID de tenant num filtro de query, por exemplo — então a segurança de cada resposta assenta em nunca ninguém escrever uma query mal feita. Uma fronteira rígida por workspace significa que a falha interessante não é possível, em vez de ser apenas improvável.

Camada 3: quem vê o quê

Com o perímetro e as paredes no sítio, as decisões que restam são tuas — e são política, não engenharia:

  • Privado — o servidor é um cérebro interno da empresa: procedimentos, políticas, factos de produto, acessível apenas pela tua própria equipa. A predefinição certa para tudo o que não porias no teu website.
  • Público — qualquer pessoa se pode ligar. Certo para documentação, factos de produto e tudo aquilo que queres ativamente que os clientes de IA respondam corretamente em teu nome.
  • Pago — público, mas atrás de uma subscrição por lugar. Subscrições Stripe, faturas e pagamentos vêm incluídos, com o SuperCognit como merchant of record. Um lugar é uma primitiva de controlo de acesso com um preço em cima: revoga o lugar e o acesso vai com ele.

A disciplina útil é decidir primeiro o nível e só depois o conteúdo. Um servidor que mistura factos de produto públicos com contactos internos para escalar problemas numa única base de conhecimento já cometeu o seu pior erro, seja qual for o aspeto do seu OAuth.

O que isto te dá no dia a dia

Um colaborador liga o servidor da empresa no Claude, autoriza uma vez e pergunta como funciona o processo de exceção de reembolsos. Um cliente no servidor público pergunta o que inclui cada plano — e não consegue chegar aos procedimentos internos, porque estes vivem noutro servidor, noutro âmbito, e não atrás de um prompt que diz «por favor não fales deles». Controlo de acesso por arquitetura ganha a controlo de acesso por instrução. Os modelos seguem instruções bem, mas «bem» não é uma fronteira de segurança.

Nada disto exigiu que a tua equipa operasse um servidor de autorização, rodasse chaves ou lesse o changelog da especificação. É esse o argumento honesto: as camadas de segurança de um MCP de empresa são exatamente a parte que queres aborrecida, padrão e a tempo inteiro nas mãos de outra pessoa.