A palavra que as pessoas usam para descrever um servidor MCP determina quais controles elas aplicam. E quase todo mundo usa a palavra errada.
O que muda com o nome
Chamar de plugin aciona um conjunto de expectativas: instalação por um comando, escopo limitado, risco contido no aplicativo que o hospeda. Nada disso é verdade aqui. Um servidor MCP executa código, carrega credenciais, alcança a rede e produz efeitos irreversíveis em sistemas de terceiros.
Chamar de carga de trabalho aciona outro conjunto: precisa de identidade própria, de segmentação, de log, de dono nomeado, de ciclo de vida e de avaliação de fornecedor quando vem de fora. Todas essas expectativas são as corretas.
Não é semântica. A classificação é o que decide se o componente entra no inventário de ativos ou fica invisível para o programa de segurança.
O teste de reclassificação
Para cada servidor MCP no seu ambiente, responda cinco perguntas. São as mesmas que você faria para qualquer serviço em produção:
- Qual identidade ele usa, e essa identidade é dele ou emprestada de um humano?
- Quem consegue alcançá-lo, e para onde ele consegue sair?
- Onde vão os logs dele, e alguém olha?
- Quem é o dono humano quando ele quebra às duas da manhã?
- Se o fornecedor abandonar o projeto, qual é o plano?
Se essas perguntas parecem exageradas para o componente, é porque ele foi classificado como plugin. Se parecem óbvias, a reclassificação já aconteceu.
Por que a indústria erra isso de novo
Aconteceu igual com container. Durante anos, container foi tratado como detalhe de empacotamento — até o mercado perceber que era unidade de execução com identidade, rede e superfície próprias. Aí vieram admission control, scanning de imagem, política de runtime.
MCP está no mesmo ponto da curva, com uma diferença: a adoção está mais rápida e o ferramental de postura ainda não existe. Quem fizer a reclassificação agora aplica controles maduros a um componente novo. Quem esperar vai aplicar controles novos a um problema já espalhado.
