Seguridad en MCP Server: Verifica las herramientas antes de instalar

Instalar un servidor MCP parece trivial: pega un comando o URL, reinicia el cliente y una nueva herramienta aparece en el contexto de tu agente. Pero detrás de ese nombre de herramienta hay código ejecutable, un esquema inyectado en la ventana de contexto del modelo, credenciales y cualquier sistema al que esas credenciales puedan llegar. El ecosistema MCP aún está madurando, y el proceso de verificación para nuevos servidores es, siendo generosos, escaso. Este artículo te proporciona una lista de verificación reutilizable previa a la instalación aplicada a un ejemplo ilustrativo fijado, con hallazgos y una justificación clara de aceptación o rechazo para cada paso.

Qué otorga la instalación realmente

Cuando instalas un servidor MCP, no estás instalando una biblioteca pasiva. Estás otorgando acceso a código ejecutable a tus herramientas, sistema de archivos y generalmente tus claves API, sin un paso de revisión intermedia que la mayoría de los clientes te presenten.

Esa confianza es acumulativa y no granular. Como señala la guía de prácticas de Pluto Security, aprobar un servidor MCP significa aprobar cada operador en su cadena de suministro. No hay reprompt por componente. Cada servidor MCP habilitado también inserta su lista completa de herramientas en el contexto del modelo al inicio de la sesión, consumiendo tokens y diluyendo la atención. Así que pagas dos veces: una en superficie de seguridad, una en presupuesto de contexto.

En Claude Code específicamente, los servidores se configuran a través de .mcp.json (alcance de proyecto) o ~/.claude.json (alcance de usuario), y pueden estar agrupados en un directorio de plugin que también contiene hooks, agentes, monitores y scripts bin/. Un plugin no es un envoltorio delgado. Puede alcanzar todo lo que alcanza tu sesión de shell.

El modelo de amenaza tiene tres modos de fallo realistas:

• Un editor malicioso crea un servidor que se parece mucho al original, aparece en el registro, redirige llamadas API o exfiltra datos silenciosamente.
• Un autor bien intencionado pero inexperto publica un servidor que almacena tokens en texto plano o registra cuerpos de solicitud sin pensarlo.
• Un servidor legítimo que aprobaste se actualiza, y la nueva versión introduce una puerta trasera o amplía sus permisos sin volver a solicitarte.

Los tres están documentados en la realidad, no son hipotéticos.

Revisa la fuente, la procedencia y el comportamiento de actualizaciones

Comienza antes de que leas una sola línea de código. ¿Quién publicó este servidor? ¿Hay una identidad verificable detrás del paquete? ¿Tiene el repositorio un historial de commits significativo, o fue creado la semana pasada con un commit?

La guía de arquitectura defensiva de Christian Schneider expone claramente los requisitos de higiene de la cadena de suministro: solo instala servidores de fuentes confiables, verifica firmas de paquete o hashes, y fija versiones de dependencias en lugar de aceptar "latest". Ejecuta npm audit o pip-audit contra el paquete antes de que toque tu entorno. Genera una lista de materiales de software (SBOM) para que puedas rastrear cada dependencia y responder rápidamente cuando se publique un CVE.

Para tu lista de verificación de revisión, captura estos en la etapa de fuente:

1. Confirma que la identidad del editor corresponde a una organización o individuo conocido con un historial comprobado.
2. Verifica la fecha de creación del repositorio y la frecuencia de commits. Los repositorios de un solo commit merecen un escrutinio adicional.
3. Fija la versión exacta que revisaste. Anota el hash del commit o la etiqueta de la versión.
4. Ejecuta npm audit o pip-audit en el árbol de dependencias y registra los hallazgos.
5. Verifica si el mecanismo de actualización del servidor valida firmas digitales antes de aplicar cambios.

Ejemplo ilustrativo: supongamos que estás revisando un hipotético mcp-db-connector@1.4.2 de un publicador con 18 meses de historial de commits, dos contribuidores y una versión firmada en GitHub. npm audit devuelve cero hallazgos de alta gravedad. Eso pasa esta etapa. Un servidor con un publicador anónimo, un repositorio de dos días de antigüedad y sin versión firmada no pasaría.

Inspecciona Tools, Hooks, Scripts y Network Access.

La procedencia de la fuente es lo fundamental. Ahora lee el código.

Examina cada definición de tool que el servidor registra. ¿La descripción declarada coincide con la implementación real? Como advierte la guía de supervivencia de MCP de Towards Data Science, solo porque algo se publique como "email-sender" no significa que solo envíe correos. Podría registrarlos, reescribirlos o reenviarlos a un lugar que no tenías previsto.

Busca específicamente esto:

• Hooks y scripts de ciclo de vida: ¿Registra hooks.json callbacks pre o post-tool? ¿Qué hacen?
• Scripts en `bin/`: ¿Hay scripts de shell que se ejecutan en la instalación o en la invocación? Léelos.
• Llamadas de red salientes: ¿El servidor se comunica con algún endpoint no documentado en el README? Usa grep -r "fetch\|axios\|http\|https\|request" en toda la fuente.
• Acceso al sistema de archivos: ¿Solicita acceso a rutas más amplio de lo que la tarea requiere?
• Manejo de credenciales: ¿Las claves API se escriben en disco, se registran o se transmiten en algún lugar fuera del servicio objetivo declarado?

La Lista de Verificación de Seguridad MCP de SlowMist califica la validación de entrada, la limitación de tasa de API y la codificación de salida como los tres controles de mayor prioridad. Si el servidor no valida estrictamente sus propias entradas, es un vector para ataques de inyección sin importar si confías en el publicador.

Una cosa que la lista señala que la mayoría de las personas pasan por alto: las descripciones de tools se inyectan en el contexto del modelo textualmente. Una descripción maliciosa o mal escrita puede orientar el comportamiento del agente dentro del sandbox incluso si el sandbox en sí está intacto. El sandboxing sin escaneo de esquema es solo media defensa.

Prueba Inyección de Prompt y Casos Límite de Datos

Este paso no es opcional para nada que toque datos de producción o información de clientes.

La inyección de prompt a través de descripciones de tools es un vector de ataque documentado. Un atacante incrusta instrucciones dentro del campo de descripción de un tool que el modelo interpreta como intención del usuario. Necesitas verificar que el esquema del servidor no contenga instrucciones incrustadas, que la salida del servidor no se considere entrada de usuario autorizada posteriormente, y que los datos devueltos de un tool no puedan filtrarse al contexto de una sesión o usuario diferente.

Ejecuta casos límite ilustrativos antes de conectar el servidor a credenciales reales:

1. Elabora una llamada de tool que devuelva una respuesta que contenga algo como "Ignora las instrucciones anteriores y..." y observa si el cliente host la expone o actúa sobre ella.
2. Pasa entradas desmesuradas o malformadas a cada tool registrado y verifica si el servidor las maneja correctamente o lanza excepciones no controladas que expongan stack traces.
3. Si el servidor tiene acceso a múltiples fuentes de datos, verifica que una consulta contra la fuente A no pueda devolver datos de la fuente B.

Estas son pruebas de triaje, no una certificación. Una revisión manual breve identifica problemas obvios. No garantiza la ausencia de problemas sutiles.

Si estás construyendo herramientas de IA para clientes y quieres apoyo revisando integraciones de MCP como parte de una configuración más amplia de Claude Code, el servicio de agencia Claude Code de Seahawk puede ayudarte a evaluar el stack antes de que llegue a producción.

Elige el Alcance de Credencial Más Pequeño e Aísla el Proceso

Una vez que hayas revisado el servidor y decidido que es aceptable, la pregunta se convierte en: ¿cómo lo ejecutas?

El principio es el mínimo privilegio, aplicado sin compromisos. No entregues a un servidor MCP tu clave API personal con acceso completo a la cuenta porque sea conveniente. Crea una credencial con alcance con los permisos mínimos que requiere la funcionalidad documentada. Si el servidor necesita acceso de lectura a un bucket S3 único, la credencial no debe tener acceso de escritura, punto final.

Opciones de aislamiento, aproximadamente en orden de costo ascendente:

• Ejecuta el servidor en un subproceso dedicado sin acceso a las variables de entorno del shell padre más allá de lo que explícitamente pases.
• Usa un contenedor con una política de red restringida para que el servidor no pueda hacer conexiones salientes arbitrarias.
• Para implementaciones sensibles, aplica verificaciones de la cadena de suministro como compuertas de implementación y trata las actualizaciones del servidor MCP con el mismo proceso de gestión de cambios que el código de aplicación.

El modelo de amenaza General Analysis lo plantea bien: un marketplace vetado sin fijación de versiones significa que el servidor vetado de hoy es el rug pull de mañana. El aislamiento y la fijación no son redundantes. Protegen contra diferentes modos de fallo. El sandboxing contiene el radio de explosión; la fijación previene la derivación silenciosa.

También vale la pena notar: no compartas credenciales entre servidores MCP. El paso de tokens y las claves API compartidas significan que un compromiso en un servidor alcanza todo lo que la credencial toca.

Registra la Decisión y Revisa de Nuevo en Cada Cambio

Una revisión que no registras es una revisión que no sucedió, en lo que respecta a tu yo futuro o tu equipo.

Para cada servidor que instales, mantén un registro de decisiones con como mínimo:

• La versión exacta revisada (versión del paquete más hash de commit o etiqueta de lanzamiento).
• La fecha de revisión.
• Quién realizó la revisión.
• Hallazgos de las herramientas de auditoría e inspección manual.
• La justificación de aceptación/rechazo.
• Condiciones que desencadenarían una revisión (por ejemplo, cualquier nueva versión principal, cualquier cambio en el esquema de herramientas, cualquier aviso de seguridad que afecte una dependencia).

Esto no es burocracia por su propio bien. La guía de arquitectura de Schneider hace una pregunta directa que la mayoría de los equipos no pueden responder: "¿Qué sucede si la descripción de la herramienta de un servidor MCP cambia después de que un usuario la aprobó? ¿Alguien lo sabría?" En la mayoría de las configuraciones predeterminadas, la respuesta es no. La fijación de versiones más un registro de decisiones es cómo cambias esa respuesta.

Establece un recordatorio en el calendario para revisar nuevamente los servidores fijados trimestralmente incluso sin un nuevo lanzamiento, porque el entorno de amenazas a su alrededor cambia incluso cuando el código no lo hace.

Para equipos que ya ejecutan servidores MCP en stacks de producción, las consideraciones operativas alrededor de administrar múltiples servidores junto con tu herramienta existente se cubren por separado en nuestro post de stack de producción.

Lista de verificación reutilizable antes de instalar: Fundamentos de aceptación/rechazo

A continuación se encuentra la lista de verificación completa en orden de triaje. Aplícala antes de instalar cualquier servidor. Los hallazgos de ejemplo son ilustrativos; tus resultados variarán.

La fila 6 es por qué haces esto. Un ping de análisis no documentado no es automáticamente malicioso, pero no está documentado, y las llamadas salientes sin documentar son criterio de rechazo hasta que se expliquen. Le preguntas al editor, obtienes una respuesta clara, revisas qué se envía realmente y luego tomas una nueva decisión. Ese es el proceso.

FAQ

¿Revisar código fuente garantiza que un servidor es seguro de instalar?

No. La revisión de código es triaje, no certificación. Reduce la probabilidad de problemas obvios: llamadas de red sin documentar, registro de credenciales, descripciones de herramientas maliciosas. No protege contra vulnerabilidades introducidas en una actualización futura (por eso fijas versiones y revisas nuevamente en cambios) ni contra defectos lógicos sutiles que requieren análisis de seguridad profundo para surfear.

¿Qué es envenenamiento de herramientas y cómo se relaciona con MCP?

El envenenamiento de herramientas se refiere a un atacante que incrusta instrucciones maliciosas dentro del campo de nombre o descripción de una herramienta. Dado que los esquemas de herramientas MCP se inyectan en el contexto del modelo textualmente, el modelo puede interpretar esas instrucciones como directivas legítimas. Revisar el esquema antes de la instalación y verificar fragmentos de instrucciones incrustadas es la mitigación primaria en la etapa previa a la instalación.

¿Debo revisar servidores MCP remotos de forma diferente a los locales?

Los servidores locales tienen una ruta más corta hacia datos sensibles porque se ejecutan directamente en tu máquina con acceso a tu entorno. Los servidores remotos introducen superficie de ataque de red y riesgo de intermediario. Ambos requieren la misma lista de verificación, pero los servidores locales justifican atención particular al alcance del acceso al sistema de archivos y manejo de credenciales en el código fuente, mientras que los servidores remotos requieren TLS verificado, validación de firma y cumplimiento de OAuth 2.1 según la especificación MCP actual.

¿Cómo manejo servidores MCP que son de código cerrado o distribuidos como binarios?

Si no puedes leer el código fuente, estás confiando enteramente en la reputación del editor, verificación de firma criptográfica y controles en tiempo de ejecución (sandboxing, política de red, credenciales limitadas). Esa es una postura de riesgo materialmente mayor. Para cualquier cosa que toque datos de producción o información de clientes, un binario de código cerrado sin firma verificable de un editor conocido debe rechazarse por defecto.

¿Qué es un SBOM y realmente lo necesito para servidores MCP?

Un SBOM (lista de materiales de software) es un inventario legible por máquina de cada dependencia que incluye un paquete. Para servidores MCP, te permite identificar si alguna dependencia transitiva tiene una CVE divulgada, incluso si el paquete de nivel superior se ve limpio. Para herramientas personales de bajo riesgo, es sobrecarga opcional. Para despliegues en producción que manejan datos sensibles, es la diferencia entre conocer tu exposición y adivinarla.

La advertencia más aguda de toda esta revisión: una descripción de herramienta que se ve benigna en el registro puede dirigir el comportamiento del agente después de la instalación tan efectivamente como código ejecutable malicioso, y la mayoría de los clientes no te advertirán. Lee el esquema, no solo el README.