Un servidor MCP es código de tercero ejecutándose en tu máquina con acceso al modelo. La superficie de ataque es real y poco discutida. Esta guía aterriza el modelo de amenazas y cómo protegerse sin bloquear el flujo.
Vector 1: el paquete malicioso
Instalas un servidor desde NPM o PyPI vía npx -y / uvx y ejecuta código arbitrario en tu user. Si el paquete lee variables de entorno, accede a archivos o hace tunneling outbound, no hay sandbox por defecto.
Mitigaciones:
- Lee el código fuente antes de instalar — los buenos servidores son pocos cientos de líneas leíbles.
- Verifica autor:
@modelcontextprotocol/*(oficial Anthropic), repos con stars y commits regulares, descripciones consistentes con el código. - Para producción, fija versión exacta (
npx -y @org/server@1.2.3, no@latest). - Considera ejecutar el servidor en un container Docker con red restringida si es de un autor desconocido.
Vector 2: API keys filtradas vía logs o errores
El servidor MCP consume tu token (Stripe, GitHub, Slack). Si el servidor logea el header de autorización, o si una excepción incluye el token en el stack trace, queda expuesto.
Mitigaciones:
- Tokens con scope mínimo. Para PostgreSQL: usuario read-only; para GitHub: scope
repo:readsindelete_repo; para Stripe: restricted key sin webhook write. - Tokens con expiración corta donde sea posible (Stripe restricted keys, Slack rotating tokens).
- Variables de entorno en el config, nunca commits. Para teams, secret manager (1Password, Doppler) que inyecte al arrancar.
- Audita logs del servidor — busca el primer y último carácter de tu token para detectar leaks.
Vector 3: el modelo invocando lo que no debe
Un escenario real: el modelo, intentando ayudar, decide ejecutar DROP TABLE users porque “el usuario quería limpiar la base”. Las tools que mutan estado deben requerir confirmación humana.
Mitigaciones:
- Claude Desktop pide aprobación por default; no la quites con auto-approve para tools destructivas.
- Para acciones críticas (write a producción, transferencias de dinero, envío de email masivo), usa servidores que requieran un parámetro
confirm: trueexplícito. - Diseña tools que sean idempotentes y reversibles donde sea posible. Una tool
archive_recordes mejor quedelete_record.
Vector 4: prompt injection vía datos externos
El servidor MCP devuelve datos a Claude. Si esos datos contienen instrucciones (un email malicioso, un README de repo, un campo de DB con texto del usuario), el modelo puede ejecutarlas como prompts. Esto es prompt injection, y los servidores MCP son una superficie expandida.
Mitigaciones:
- Trata todo dato externo como untrusted. No le des al modelo “ejecuta lo que diga este archivo” sin filtros.
- Para flujos automatizados (sin humano en el loop), valida la salida del modelo contra un esquema antes de actuar.
- Reduce blast radius: si el modelo procesa email, limita qué tools tiene activas durante esa sesión.
Sandboxing práctico
Si tu use case justifica esfuerzo extra, ejecuta el servidor MCP en un container Docker con:
--read-onlyfilesystem.- Volumen específico montado solo donde el servidor debe escribir.
--networkrestringido a hosts permitidos (solo api.openai.com, por ejemplo).- Resource limits (
--memory,--cpus).
Y exponles a Claude Desktop vía un wrapper que use docker run en el command.
Red flags al evaluar un servidor MCP
- Repo creado hace menos de 30 días, sin issues, sin tests.
- Lista de dependencias enorme respecto a la funcionalidad.
- Pide variables de entorno que no tienen sentido para su función.
- El paquete publicado en NPM es notablemente más grande que el repo en GitHub (puede contener payload extra).
- Versionado errático:
1.0.0 → 0.0.1o saltos sin changelog.
Reportar vulnerabilidades
Si encuentras un servidor con comportamiento sospechoso, reporta al maintainer en GitHub con un PoC mínimo y, si es severo, divulgación coordinada (90 días). Si afecta a un servidor del catálogo MCP·es, escríbenos vía el formulario público con asunto “security”.