eu vi esse filme antes.
por volta de 2012, eu tava começando a carreira e o npm era um ecossistema jovem, crescendo rápido, cheio de promessa. lançado em janeiro de 2010 pelo Isaac Schlueter pra resolver o caos de dependência do Node.js, em pouco tempo tinha virado o padrão de facto pro JavaScript no servidor — e nos anos seguintes viraria a espinha dorsal do JavaScript no cliente também, com React, Webpack, Babel. qualquer dev publicava pacote. você dava npm install e resolvia o problema em 30 segundos. produtividade insana. e todo mundo comemorava.
aí vieram os bugs. depois as vulnerabilidades. depois os pacotes abandonados que metade da internet dependia. depois o left-pad quebrando o deploy de todo mundo porque um cara ficou puto e deletou 11 linhas de código, em 2016. depois o event-stream sendo sequestrado em 2018 — um mantenedor cansado transferiu o projeto pra um voluntário que, poucas semanas depois, adicionou uma dependência maliciosa (flatmap-stream) com payload criptografado pra roubar carteira de bitcoin da Copay. o código rodou em silêncio por 2 meses e meio antes de ser descoberto.
a gente aprendeu — caro — que “ecossistema crescendo rápido + barreira de entrada baixa + confiança implícita” é uma combinação que sempre, sempre dá ruim.
adivinha o que tá acontecendo com MCP agora mesmo?
os números que ninguém tá olhando direito
em março de 2026, o ecossistema MCP tá com mais de 10 mil servers públicos e 97 milhões de downloads de SDK por mês (Effloow). toda empresa grande lançando server — Stripe, Google Analytics, Klaviyo, PagerDuty, Amazon, Microsoft. adoção explosiva em 18 meses.
isso é lindo. e é exatamente o problema.
o pulo do gato do MCP foi eliminar o problema N×M de integração. antes, pra conectar 5 modelos com 10 ferramentas, você precisava de 50 integrações customizadas. com MCP, cada ferramenta publica um server, cada cliente implementa o protocolo uma vez, e pronto — a matriz colapsa de M×N pra M+N. é genial.
só que a barreira de entrada é tão baixa que qualquer um publica server. um dev sozinho, numa tarde, sobe um MCP server no Vercel e lista no registry. sem review. sem auditoria. sem nada.
soa familiar?
o que já deu ruim (e você não leu no feed)
setembro de 2025, três meses antes da AAIF ser criada dentro da Linux Foundation pra dar governança ao MCP: o pacote postmark-mcp no npm. se passando por uma integração legítima do Postmark — que nunca tinha publicado MCP server oficial em npm, só no GitHub — o mantenedor (user phanpak) publicou 15 versões limpas (1.0.0 até 1.0.15) pra construir confiança. o código era cópia do repositório oficial, funcionando perfeitamente. download semanal batendo 1.500. uns 300 times integraram no workflow real.
aí veio a versão 1.0.16.
uma linha. uma única linha adicionada no código.
BCC em todo email que saía pra phan@giftshop.club.
300 organizações. e-mails corporativos. potencialmente credenciais em reset de senha. vazando silenciosamente por semanas até o pessoal da Koi Security descobrir (The Vulnerable MCP Project).
janeiro de 2026, a BlueRock Security analisou 7.000 MCP servers: 36.7% estavam vulneráveis a SSRF — aquele tipo de vulnerabilidade onde um atacante faz o server fazer requisição pra recursos internos que não deveriam estar expostos. a prova de conceito deles num MCP server da Microsoft conseguiu extrair chaves IAM da AWS direto do metadata endpoint de uma instância EC2. um server mal configurado virando porta de entrada pra cloud inteira.
fevereiro de 2026, a Check Point Research divulgou a CVE-2025-59536: vulnerabilidade crítica no próprio Claude Code (sim, o cliente, não um server aleatório). qualquer .claude/settings.json malicioso num repositório clonado conseguia execução remota de código antes do dialog de confirmação aparecer na tela. você abria o projeto. o código rodava. fim.
a Trend Micro encontrou 492 MCP servers na internet pública com zero autenticação e zero criptografia. nem HTTPS, camarada.
e a Qualys batizou o fenômeno: “MCP Shadow IT”. time de marketing ou de dados sobe um MCP server pra conectar uma ferramenta nova no agente, sem aprovação, sem visibilidade, sem auditoria. igualzinho o SaaS Shadow IT que dominou os anos 2010, só que agora com acesso direto a dados sensíveis via LLM.
o espelho do npm (e o que ele prevê)
pega o timeline do npm e sobrepõe:
npm 2010-2013: ecossistema novo, crescimento viral no mundo Node.js, barreira de entrada baixa, cultura de “instala e confia”. o registry saiu de centenas pra dezenas de milhares de pacotes nesse intervalo. MCP 2024-2026: igualzinho. 18 meses do zero a 10 mil servers públicos.
npm 2016-2018: primeiros incidentes sérios em escala. left-pad (março 2016) mostra o risco de dependência em cascata. event-stream (novembro 2018) mostra o risco de ownership transfer. comunidade descobre que “trust by default” não escala. MCP 2025-2026: já tá acontecendo. postmark-mcp, CVE no Claude Code, 36.7% vulneráveis a SSRF — e a gente nem chegou no equivalente ao event-stream ainda.
npm 2017-2020: gateways, auditoria, npm audit (2018), lockfiles (2017), signed packages, Snyk virando categoria de mercado.
MCP 2026-?: começando. MCP gateways aparecendo (MCP Manager, MCP-Hive), OAuth 2.1 na spec em abril de 2026, scanners estáticos (Cisco mcp-scanner, Snyk agent-scan), SBOMs pra MCP servers. mas nada disso é default ainda.
npm hoje: ecossistema maduro, ferramentas automatizadas, cultura de paranoia justificada — e ainda assim os ataques continuam, só que detectados em horas em vez de meses. MCP em 2028-2030: provavelmente chega lá. mas os próximos dois anos vão ser dolorosos.
a história não se repete, mas rima com persistência impressionante.
o que dá pra fazer hoje
se você usa MCP em projeto sério — não exploração, sério — vale adotar alguns hábitos que a gente aprendeu do npm mas que ainda não são reflexo no mundo MCP:
pin de versão. não use latest em MCP server. fixa a versão no seu settings.json do Claude Code, do Cursor, de qualquer cliente. e revisa antes de atualizar — o caso postmark-mcp foi literalmente “versão nova, código novo, backdoor novo”. 15 versões limpas não te protegem da 16ª.
trate MCP server como dependência, não como plugin. isso significa entrar na lista de dependências que seu time audita. significa code review antes de adicionar no projeto. significa SBOM, se seu time já faz. se você não faria npm install de um pacote aleatório de um mantenedor desconhecido, não adiciona MCP server de um repositório aleatório.
princípio do menor privilégio. MCP server de leitura de arquivo não precisa de acesso de escrita. server de query em banco não precisa de DDL. a maioria dos servers hoje pede permissão ampla porque é mais fácil — e a maioria dos devs aceita porque também é mais fácil. não faça isso.
use gateway se tiver mais de 3 servers. gateway te dá observabilidade, rate limit, auditoria, scope de permissão. com 1 ou 2 servers, é overhead. com 5+, é sanidade. o pessoal do enterprise já começou a adotar — MCP Manager, MCP-Hive, alguns times grandes construíram gateway interno. se você é dev solo, tudo bem por enquanto. se você é de time, já deveria ter.
separa MCP oficial de MCP comunidade. os servers oficiais (GitHub MCP, Stripe MCP, Google Drive MCP) passam por review interno da empresa dona do produto. os da comunidade passam por ninguém. não é que os oficiais são invulneráveis — a própria CVE no Claude Code mostra que o código oficial também quebra — é que a superfície de risco é diferente. trata como categorias diferentes no teu registry mental.
a parte que eu acho mais interessante
o MCP é a coisa mais promissora que aconteceu em integração de IA nos últimos anos. eu uso. eu recomendo. eu ensino. e vou continuar.
o problema não é o protocolo. o problema é a cultura.
o npm também é genial. o problema do npm nunca foi o npm — foi a gente tratar install como “apertar um botão” em vez de “clonar código de alguém que eu não conheço pra rodar na minha máquina com acesso ao meu filesystem.”
com MCP o risco é maior, não menor. porque agora o código não tá só na tua máquina — tá conectado a um agente com autonomia pra executar ações, mandar email, queries no banco, acessar API, mexer em repo. o dano potencial por integração comprometida é ordem de grandeza acima do pior caso do npm.
a gente tá numa janela curta onde dá pra aprender a lição antes de levar porrada em escala. o npm levou uns 8 anos (2010 até npm audit em 2018) pra ter segurança nativa — e ainda hoje os ataques acontecem. o MCP precisa fazer em 1 ou 2.
e não é o Anthropic, o Google ou a OpenAI que vão resolver. eles tão fazendo a parte deles (spec aberta, governança no Linux Foundation, OAuth na spec). o que resolve é a cultura do dev que usa — a tua cultura, a do teu time.
ou a gente trata MCP server com o mesmo respeito que trata dependência de produção, ou a gente vai ler as mesmas manchetes de 2016, só que com “MCP” no lugar de “npm”.
e dessa vez, com o agente fazendo o estrago.