Seguridad en MCP: cómo auditar y proteger tus servidores

El protocolo MCP da a la IA acceso directo a tu sistema de archivos, secretos y servicios externos. Aprende a auditar cada servidor antes de instalarlo y a mantener un entorno seguro.

Modelo de amenazas

Cada servidor MCP que añades a tu configuración recibe los mismos permisos que la herramienta que lo ejecuta. Un MCP malicioso —o un MCP legítimo con una vulnerabilidad— puede causar daños en varias áreas:

Acceso al sistema de archivos

Servidores como @modelcontextprotocol/server-filesystem pueden leer, escribir y eliminar cualquier archivo dentro del directorio que se les conceda. Si el directorio de inicio se expone sin restricciones, un MCP podría leer claves SSH, tokens de acceso o credenciales de base de datos almacenadas en archivos de configuración.

Exfiltración por HTTP / SSE

Un servidor MCP puede realizar peticiones HTTP a Internet. Esto significa que puede enviar datos sensibles —como tokens o fragmentos de código propietario— a un servidor controlado por un atacante. La exfiltración es difícil de detectar porque el tráfico parece una comunicación API legítima.

Acceso a tokens de entorno

Los MCPs de terceros suelen requerir tokens de API (GitHub, Stripe, Slack, etc.). Si el servidor es malicioso, puede capturar esas variables de entorno y reutilizarlas. Incluso si el servidor es legítimo, una vulnerabilidad en sus dependencias puede exponer esos tokens.

Ejecución de comandos arbitrarios

Algunos servidores ejecutan comandos del sistema a través de child_process o declaran scripts de postinstall en package.json. Un paquete comprometido puede ejecutar cualquier cosa con los permisos del usuario que ejecuta el MCP.

Auditar un servidor antes de instalarlo

Nunca confíes ciegamente en un servidor MCP. Aplica esta auditoría mínima antes de añadirlo a tu configuración:

Revisar package.json

Examina el package.json del paquete. Busca dos cosas principalmente:

• Dependencias. Cuantas más dependencias tenga, mayor es la superficie de ataque. Un paquete con 200 dependencias indirectas debería ser examinado con cuidado.
• Scripts de postinstall. Cualquier script en scripts.postinstall se ejecuta automáticamente al instalar. Si ves comandos como curl, eval o descargas desde URLs no verificadas, desconfía.

Buscar process.env en el código fuente

El servidor necesita acceder a variables de entorno para funcionar, pero debes verificar qué hace con ellas. Busca en el código referencias a process.env y asegúrate de que los tokens solo se usan para autenticar peticiones API, no para enviarlos a terceros ni almacenarlos en logs.

Verificar los argumentos del comando

Algunos MCPs aceptan rutas como argumento ("args": ["/ruta/al/proyecto"]). Nunca pases rutas sin control: si el servidor espera un directorio, asegúrate de que sea el mínimo necesario. Por ejemplo, en lugar de pasar ~, pasa ./mi-proyecto.

Preferir servidores open-source verificables

Los servidores con código fuente abierto permiten inspeccionar cada línea. Los paquetes cerrados o sin repositorio público son una caja negra. Siempre que sea posible, elige servidores cuyo código puedas revisar directamente en GitHub.

Buenas prácticas de configuración

Una vez que has auditado el servidor, la configuración segura es igual de importante. Estas prácticas reducen el riesgo incluso si un servidor se ve comprometido:

• .env separado. No hardcodees tokens en el archivo de configuración del MCP. Usa un archivo .env que no se suba al repositorio y referencia las variables con ${VAR_NAME}.
• GitHub tokens con scopes mínimos. Crea tokens de acceso personal con permisos de solo lectura (repo:read, contents:read). Nunca uses tokens con permisos de escritura a menos que sea estrictamente necesario.
• Rotación periódica de tokens. Programa la rotación de tokens cada 30-90 días. Un token filtrado tiene una ventana de exposición limitada si se rota con regularidad.
• No subir tokens a repos públicos. El archivo opencode.json contiene la configuración de los MCPs. Asegúrate de que los tokens no aparecen literalmente en ese archivo. Usa variables de entorno y añade .env a .gitignore.

// Mal — token hardcodeado en el config
"servers": {
  "github": {
    "command": "npx",
    "args": ["-y", "@modelcontextprotocol/server-github"],
    "env": {
      "GITHUB_TOKEN": "ghp_miTokenAqui"
    }
  }
}

// Bien — token desde variable de entorno
"servers": {
  "github": {
    "command": "npx",
    "args": ["-y", "@modelcontextprotocol/server-github"],
    "env": {
      "GITHUB_TOKEN": "${GITHUB_TOKEN}"
    }
  }
}

Sandboxing

El sandboxing es la capa más efectiva de defensa. Aísla los MCPs de terceros para que, incluso si son maliciosos, el daño esté contenido.

Docker para aislar MCPs de terceros

Ejecuta servidores MCP no verificados dentro de contenedores Docker. Esto limita el acceso al sistema de archivos, la red y los procesos del host. Puedes definir un contenedor con montajes de solo lectura y sin acceso a la red externa.

services:
  mcp-filesystem:
    image: node:20-alpine
    working_dir: /proyecto
    volumes:
      - ./proyecto:/proyecto:ro
    command: npx -y @modelcontextprotocol/server-filesystem /proyecto
    network_mode: none
    read_only: true

Deno con permisos selectivos

Si el servidor MCP está escrito en Deno, puedes usar su sistema de permisos granular. Por ejemplo, deno run --allow-read=/proyecto --allow-net=api.github.com restringe el acceso a solo un directorio y un host específico. Evita usar --allow-all.

Sistema de archivos read-only

Cuando configures un MCP que solo necesita leer archivos, monta el volumen como read-only. Así, incluso si el servidor es comprometido, no podrá modificar ni eliminar archivos del proyecto.

MCPs de confianza vs comunidad

No todos los MCPs tienen el mismo nivel de fiabilidad. Aquí tienes una clasificación orientativa:

Los servidores oficiales del @modelcontextprotocol pasan por revisiones de seguridad y tienen un mantenimiento activo. Para servidores de terceros, aplica siempre la auditoría descrita en la sección anterior.

Mantener actualizados los servidores

Las vulnerabilidades se descubren constantemente. Ejecuta npm audit regularmente en los proyectos que instalan MCPs. Si un servidor no se actualiza en meses, considera migrar a una alternativa más activa. Un servidor abandonado es un riesgo acumulativo.

Lista de verificación de seguridad

Usa esta checklist cada vez que añadas un nuevo servidor MCP a tu proyecto:

• ✅ Revisé el package.json — dependencias razonables, sin scripts de postinstall sospechosos
• ✅ Leí el código fuente del servidor (al menos los archivos principales)
• ✅ Verifiqué que los tokens solo se envían a la API esperada
• ✅ Configuré los tokens como variables de entorno, no hardcodeados
• ✅ Restringí el directorio de trabajo al mínimo necesario
• ✅ Usé un token con scopes de solo lectura siempre que fue posible
• ✅ Ejecuté el servidor en un contenedor Docker si es de un tercero no verificado
• ✅ Añadí .env a .gitignore
• ✅ Verifiqué que el servidor tiene mantenimiento activo (commits recientes, releases)
• ✅ Ejecuté npm audit y no hay vulnerabilidades críticas