Seguridad en MCP: 10 mejores prácticas

Riesgos de seguridad en MCP

Un servidor MCP es un programa que ejecutas en tu máquina y que tiene acceso a servicios externos via tokens. Los riesgos principales:

• Exfiltración de datos: Un MCP malicioso podría enviar tus datos a un servidor externo.
• Escalación de privilegios: Un token con demasiados permisos permite acciones no deseadas.
• Supply chain: Un paquete npm comprometido podría inyectar código malicioso en el MCP.
• Inyección: Datos de entrada malformados podrían ejecutar queries o comandos no deseados.
• Persistencia: Un MCP podría modificar archivos locales para mantener acceso.

Estos riesgos no son exclusivos de MCP. Son los mismos de cualquier paquete npm o pip que instalas. La diferencia es que los MCPs tienen acceso explícito a servicios externos.

1. Principio de mínimo privilegio

Cada MCP debe tener solo los permisos que necesita. Nada más.

• Base de datos: Si solo lees, usa un token de solo lectura (SELECT). Nunca INSERT/DELETE en producción.
• Slack: Si solo lees canales, no añadas chat:write.
• GitHub: Si solo consultas, usa un token con scope repo:read.

Regla: si dudas entre dar o no un permiso, no lo des. Siempre puedes añadirlo después.

2. Separar dev y producción

Usa configuraciones diferentes por entorno:

# Desarrollo: settings.json del proyecto
# .claude/settings.json (permisos amplios, datos de prueba)
{
  "mcpServers": {
    "supabase": {
      "env": { "SUPABASE_TOKEN": "token-desarrollo" }
    }
  }
}

# Producción: settings.json global con restricciones
# ~/.claude/settings.json (solo lectura, datos reales)
{
  "mcpServers": {
    "supabase": {
      "env": { "SUPABASE_TOKEN": "token-solo-lectura-prod" }
    }
  }
}

El .claude/settings.json del proyecto tiene prioridad sobre el global. Úsalo para sobrescribir con permisos restrictivos en proyectos de producción.

3. Auditar servidores de terceros

Antes de instalar un MCP de terceros, revisa:

• Código fuente: Está en GitHub? Puedes leer el código? Busca llamadas a URLs externas sospechosas.
• Mantenedor: Quién lo mantiene? Es una organización conocida o un usuario anónimo?
• Dependencias: Cuántas dependencias tiene? Más dependencias = más superficie de ataque.
• Descargas: Un paquete con 10 descargas tiene menos escrutinio que uno con 10.000.
• Fecha: Cuándo fue la última actualización? Está activamente mantenido?

4. Gestión de secretos

Nunca hardcodees tokens en archivos que compartas o commitees:

• Variables de entorno: Usa export en tu shell profile, no en settings.json.
• .gitignore: Asegúrate de que .claude/settings.json está en .gitignore si contiene tokens.
• Gestores de secretos: Para equipos, usa 1Password CLI, Vault, o similar.

5. Sandboxing con allowedTools

Claude Code permite limitar qué tools de un MCP están disponibles:

# Solo permitir lectura de Supabase, no escritura
claude --allowedTools "mcp__supabase__list_tables,mcp__supabase__execute_sql"

Esto previene que Claude Code use tools destructivas incluso si el MCP las expone.

6. Rotación de tokens

Rota tokens regularmente:

7. Monitorización de actividad

Revisa periódicamente qué hacen tus MCPs:

• Supabase: Logs > API requests. Filtra por el token del MCP.
• GitHub: Settings > Security log. Filtra por token.
• Slack: Analytics > Activity logs del bot.
• Red: Herramientas como nettop (macOS) o nethogs (Linux) muestran tráfico por proceso.

8. Validación de inputs

Si creas tu propio MCP, valida todos los inputs con schemas estrictos:

// Mal: acepta cualquier string como query SQL
server.tool("query", { sql: z.string() }, ...)

// Bien: valida formato y limita longitud
server.tool("query", {
  sql: z.string()
    .max(1000)
    .refine(s => !s.toLowerCase().includes("drop"), "DROP no permitido")
}, ...)

9. Aislamiento de red

Para entornos sensibles, aísla el tráfico de red de los MCPs:

• Firewall: Limita las IPs/dominios a los que el proceso MCP puede conectar.
• VPN: Ejecuta MCPs de bases de datos dentro de la red privada (Tailscale, WireGuard).
• Containers: Ejecuta MCPs en contenedores Docker con red limitada.

10. Plan de respuesta a incidentes

Si sospechas que un MCP está comprometido:

1. Desconectar: Elimina el MCP de settings.json inmediatamente.
2. Revocar: Revoca todos los tokens que usaba el MCP.
3. Auditar: Revisa logs de actividad de los servicios conectados.
4. Rotar: Cambia credenciales de servicios relacionados.
5. Reportar: Si es open source, abre un issue. Si es malicioso, reporta a npm.

Checklist antes de instalar un MCP

Preguntas frecuentes

Son seguros los servidores MCP?

Los oficiales (Anthropic, GitHub, Slack) sí. Los comunitarios varían. Revisa código fuente antes de instalar.

Puede un MCP robar mis datos?

Técnicamente sí, si tiene acceso y código malicioso. Mitiga con: permisos mínimos, revisión de código, monitorización.

Cómo limito lo que puede hacer un MCP?

Con --allowedTools, tokens con permisos limitados, y configuraciones separadas dev/prod.

Debo rotar tokens?

Sí. Cada 15-30 días para servicios críticos. Para MCPs locales (filesystem, SQLite) no aplica.

Qué hago si un MCP se comporta mal?

Desconéctalo, revoca tokens, audita logs, rota credenciales, reporta al mantenedor.