Una pregunta para la próxima reunión del comité técnico: ¿cuántos servidores MCP hay configurados hoy en los portátiles de vuestro equipo, en qué versión y con qué credenciales? Lo más probable es que nadie sepa contestarla. No porque nadie se haya preocupado, sino porque no hay ningún sitio donde mirar.
Un desarrollador quiere que su asistente lea los tickets del gestor de proyectos. Busca el servidor MCP correspondiente, copia cuatro líneas en el fichero de configuración de Claude Code, Cursor o VS Code, pega su token personal en una variable de entorno y reinicia. Diez minutos. A partir de ese momento hay un programa de un tercero ejecutándose en su máquina, con su identidad, conectado a un sistema de la empresa y a un modelo que decide cuándo usarlo. Nadie más lo sabe, y no por descuido: ninguno de los procesos de la empresa estaba diseñado para enterarse.
La tesis de esta pieza es que el error no está en instalar servidores MCP, que son útiles, sino en tratarlos como una extensión del editor. Un servidor MCP es una integración con credenciales, y la pregunta no es si es seguro, sino si se gobierna como el resto de integraciones. Hoy casi nunca es así.
Lo que se instala con esas cuatro líneas
MCP (Model Context Protocol) es el protocolo con el que un asistente de IA se conecta a herramientas y datos externos. Un servidor MCP expone esas herramientas: leer el correo, consultar una base de datos, abrir un pull request. Muchos se ejecutan en local, lanzados por el propio cliente con un comando del tipo npx paquete-mcp, que descarga el paquete del registro público y lo arranca.
La documentación de buenas prácticas de seguridad de la propia especificación lo dice sin rodeos: los clientes deben avisar de que los servidores MCP se ejecutan con los mismos privilegios que el cliente y, cuando se instalan en un clic, mostrar el comando exacto que se va a ejecutar, sin recortarlo. Es decir, tienen acceso a lo mismo que el usuario: sus ficheros, sus claves SSH y las variables de entorno con los tokens del resto de servidores.
Y esos tokens suelen ser de los que más alcance tienen. En octubre de 2025, Astrix analizó 5.205 repositorios de servidores MCP: alrededor del 88% necesita credenciales, el 53% se apoya en claves de API estáticas o tokens personales de acceso, el 79% de las claves se pasan como simples variables de entorno y sólo el 8,5% usa OAuth. Traducido: lo normal es que un servidor MCP funcione con un token personal, de larga duración, guardado en texto plano en el portátil de alguien.
Por qué no lo ve ningún control
Una empresa mediana tiene, aunque no lo llame así, varios filtros por los que pasa cualquier integración nueva. El servidor MCP los esquiva todos, y no por mala fe de nadie: simplemente entra por una puerta que esos filtros no miran.
| Control habitual | Qué revisa | Por qué no ve el servidor MCP |
|---|---|---|
| Review de código | Lo que entra en el repositorio | La configuración vive en la carpeta personal del usuario, no en el repositorio |
| Inventario de dependencias | Los ficheros de bloqueo y el SBOM del producto | El paquete no es una dependencia del producto; a menudo se descarga sin versión fijada cada vez que arranca |
| Compras y proveedores | Contratos y evaluaciones de terceros | Es gratuito y de código abierto: no hay factura que dispare la revisión |
| Gestión de identidades | Aplicaciones conectadas a las cuentas corporativas | Con un token personal no se registra ninguna aplicación nueva: el servidor actúa como el usuario |
| Política de uso de IA | Qué asistentes y qué datos se pueden usar | Suele aprobar el asistente, no lo que se conecta a él |
Elaboración propia de onext
La última fila es la más frecuente. Muchas empresas tienen ya una política sobre qué asistentes de IA están permitidos, como la que proponíamos en shadow AI. Pero aprobar Claude Code o Copilot dice poco sobre lo que la gente conecta después. Es como aprobar un navegador y no preguntar nunca qué extensiones tiene. OWASP le ha puesto nombre en su lista de riesgos específica de MCP: Shadow MCP Servers, el noveno de diez.
Cuatro fallos reales, y ninguno es del modelo
En la pieza sobre inyección de prompts analizamos cómo un texto hostil convierte a un agente con demasiados permisos en una fuga. Ese riesgo existe, pero no es el único. Los cuatro casos siguientes no necesitan que el modelo se equivoque en nada. Fallan antes: en qué se instaló, de dónde salió y quién lo cambió.
El paquete que era legítimo hasta que dejó de serlo. En septiembre de 2025, Koi Security encontró lo que se considera el primer servidor MCP malicioso en circulación: postmark-mcp, un paquete de npm que imitaba la integración del servicio de correo Postmark. Durante quince versiones funcionó correctamente. La 1.0.16, publicada el 17 de septiembre, añadió una línea que enviaba en copia oculta a una dirección del atacante todos los correos que salían por él. Según CSO Online, el paquete tenía unas 1.500 descargas semanales. Quien lo hubiera revisado en la versión 1.0.15 lo habría aprobado, y con razón.
La descripción que el usuario no ve. En abril de 2025, Invariant Labs describió el tool poisoning: instrucciones escondidas en la descripción de una herramienta, invisibles para el usuario pero visibles para el modelo. En el mismo trabajo describieron dos variantes: el rug pull, en el que el servidor cambia la descripción después de que el usuario lo haya aprobado, y el shadowing, en el que un servidor malicioso manipula cómo se usan las herramientas de otro servidor de confianza. La especificación de MCP recoge la lección: las descripciones de comportamiento de las herramientas deben considerarse no fiables salvo que vengan de un servidor de confianza.
La pieza de infraestructura que nadie mira. En julio de 2025, JFrog publicó la CVE-2025-6514 en mcp-remote, un paquete que sirve de puente para conectar clientes locales con servidores MCP remotos: conectarse a un servidor no confiable permitía ejecutar comandos del sistema operativo en la máquina del usuario. Puntuación CVSS de 9,6, y más de 437.000 descargas según The Hacker News. Nadie elige mcp-remote como herramienta; viene de serie en las instrucciones de instalación de muchos servidores.
El servidor oficial del proveedor. Asana lanzó su servidor MCP el 1 de mayo de 2025. El 4 de junio detectó un error que podía exponer información de un cliente a usuarios de otras organizaciones; lo desconectó del 5 al 17 de junio y avisó a los clientes afectados, alrededor de mil según dijo un portavoz a BleepingComputer. No era un paquete pirata ni un ataque: era el servidor oficial, de un proveedor serio, con un fallo de aislamiento.
La ficha de cada servidor
La consecuencia práctica es tratar cada servidor MCP como cualquier otra integración: con una ficha. No es la misma que la ficha de permisos de cada herramienta que proponíamos para diseñar un agente; aquella decide qué puede hacer un sistema que alguien ha diseñado. Esta responde a una pregunta anterior: qué hay instalado en la empresa, y de quién es.
| Campo | Qué se anota | Qué fallo corta |
|---|---|---|
| Origen | Quién publica el paquete y si es el proveedor del sistema al que se conecta | El paquete que imita a una marca, como postmark-mcp |
| Versión fijada | Una versión concreta, nunca «la última»; las actualizaciones se aprueban | La versión 16 maliciosa de un paquete con quince versiones limpias |
| Descripciones revisadas | Las descripciones de herramientas se leen al aprobar y se comparan al actualizar | El tool poisoning y el rug pull |
| Credencial propia | Un token emitido para ese servidor, con alcance mínimo y caducidad; nunca el token personal de alguien | El tamaño del incidente cuando falla el servidor oficial, como en Asana |
| Dónde se ejecuta | En local, con los privilegios del usuario, o en remoto, y a través de qué componentes | Las piezas intermedias que nadie eligió, como mcp-remote |
| Propietario | Una persona que responde del servidor y decide sus actualizaciones | El aviso de seguridad que llega y nadie sabe a quién afecta |
Seis campos por servidor. Caben en una hoja de cálculo y se mantienen como cualquier otro inventario
El cuarto campo merece una línea aparte, porque la especificación ya lo exige para los servidores remotos. Desde la revisión de junio de 2025, y también en la vigente de julio de 2026, la autorización de MCP prohíbe el llamado token passthrough: un servidor MCP debe validar que el token se emitió para él y no debe aceptar ni reenviar ningún otro. La lógica de fondo es la que aplicamos a cualquier integración: cada pieza con su credencial, para que el alcance del token sea el alcance del incidente y no más. Copiar el token personal de un administrador en una variable de entorno es exactamente lo contrario.
Los dos primeros campos son la misma disciplina que pedíamos para las dependencias que propone un asistente: saber quién publica lo que se ejecuta y no dejar que la versión cambie sola. La diferencia es que aquí no hay ni siquiera un fichero de bloqueo que revisar. Hay que crearlo.
El control está en la configuración administrada, no en un PDF
Una ficha que sólo vive en una hoja de cálculo es documentación. Se convierte en control cuando el cliente se niega a arrancar lo que no está en ella. Los clientes principales ya lo permiten:
- Claude Code admite un fichero
managed-mcp.json, desplegado por el administrador en una ruta del sistema, con listas de servidores permitidos y denegados y la opción de permitir sólo los gestionados. - GitHub Copilot aplica listas de servidores permitidos y denegados desde la configuración gestionada de la empresa en VS Code, la CLI y su aplicación. Lo anunció como disponible de forma general el 6 de agosto de 2026; la primera versión, para VS Code Insiders, era de septiembre de 2025.
- Cursor permite, en su plan Enterprise, que el equipo controle desde el panel de administración qué servidores MCP pueden usar sus miembros.
Casi un año entre la primera versión y la disponibilidad general en el caso de GitHub dice algo útil: los controles corporativos llegan después de la adopción, no antes. Si el equipo lleva desde 2025 conectando servidores, la lista de permitidos de hoy llega sobre un parque instalado que nadie ha inventariado. Por eso el orden importa: primero el inventario, después la lista.
¿Y el registro oficial? El MCP Registry, lanzado en preview el 8 de septiembre de 2025, es un catálogo abierto de servidores públicos, útil para saber qué existe. Pero su moderación funciona por denuncia: la comunidad marca los servidores maliciosos y los mantenedores los retiran después. No es una revisión de seguridad previa, y sus autores lo dicen: prevén subregistros privados en las empresas con requisitos estrictos. Ese subregistro privado es, en la práctica, la lista de fichas de la tabla anterior.
La lección incómoda: la lista de permitidos no basta
Sería cómodo cerrar aquí, con la lista de permitidos como solución. Los propios casos lo desmienten. Una lista de permitidos habría aprobado postmark-mcp antes de la versión 1.0.16, y no habría hecho nada contra el fallo del servidor oficial de Asana, que estaría el primero en cualquier lista. La lista decide qué se instala. No decide qué versión se ejecuta mañana ni cuánto puede tocar cuando falla.
Por eso la ficha tiene seis campos y no uno. La versión fijada corta el primer caso; la credencial propia, con el alcance mínimo, limita el segundo. Ninguna de las dos depende de adivinar qué servidor es malicioso, que es justo lo que nadie puede hacer el día de la instalación. Es la misma idea que recorre el mínimo exigible de gobernanza de IA: controles que funcionan aunque falle la previsión.
Y una advertencia en el otro sentido: prohibir MCP no es una alternativa. Los servidores son útiles, y por eso se instalan. Si el proceso de alta tarda tres meses, la gente seguirá conectando servidores en otro cliente o con su cuenta personal, y el inventario volverá a estar vacío. El objetivo no es frenar la adopción, sino que el camino aprobado sea más cómodo que el atajo: una lista inicial corta con los servidores que ya se usan, versiones fijadas, credenciales emitidas para cada uno y un alta que tarde días. Es la misma conclusión a la que llegábamos al comparar Claude, Cursor y Copilot para empresas: la herramienta importa menos que el sistema que la rodea.
Preguntas frecuentes
¿Qué es un servidor MCP y por qué afecta a la seguridad de la empresa?
Un servidor MCP (Model Context Protocol) es un programa que da a un asistente de IA acceso a una herramienta o a unos datos: el correo, el repositorio, la base de datos, el CRM. En la mayoría de los casos se instala añadiendo unas líneas a un fichero de configuración del portátil y se ejecuta con los mismos permisos que el usuario. Es una integración con credenciales, y no pasa por ninguno de los controles por los que pasan las demás integraciones de la empresa.
¿En qué se diferencia un servidor MCP de una dependencia de código?
Una dependencia entra por el fichero de bloqueo del proyecto, se ve en un pull request y aparece en el inventario de software. Un servidor MCP vive en la configuración local de cada persona, fuera del repositorio, y muchas veces se lanza con un comando que descarga la última versión del paquete cada vez que arranca. Tiene los mismos riesgos de cadena de suministro que una dependencia, pero ninguno de los controles.
¿Qué es el tool poisoning en MCP?
Es un ataque descrito por Invariant Labs en abril de 2025: el servidor esconde instrucciones en la descripción de una herramienta, que el usuario no ve y el modelo sí lee. Una variante, el rug pull, consiste en cambiar esa descripción después de que el usuario haya aprobado el servidor. Por eso la propia especificación de MCP pide tratar las descripciones de herramientas como no fiables salvo que vengan de un servidor de confianza.
¿Sirve el registro oficial de MCP para saber qué servidores son seguros?
No por sí solo. El MCP Registry, lanzado en preview en septiembre de 2025, es un catálogo abierto de servidores públicos. Su moderación se basa en que la comunidad reporte servidores maliciosos para retirarlos después, no en una revisión de seguridad previa. Sus propios autores prevén que las empresas con requisitos estrictos tengan subregistros privados con su propia lista.
¿Cómo se limita qué servidores MCP puede usar el equipo?
Con la configuración administrada de cada cliente, no con una política en un documento. Claude Code admite un fichero managed-mcp.json con listas de servidores permitidos y denegados; GitHub Copilot ofrece listas de permitidos en su configuración de empresa, disponibles de forma general desde agosto de 2026 para VS Code, la CLI y su aplicación; y Cursor lo permite en su plan Enterprise. La lista se acompaña de versiones fijadas y de un camino corto para pedir servidores nuevos.
¿Conviene prohibir los servidores MCP?
No. Prohibir algo útil sólo lo saca de la vista: la gente lo seguirá usando con su cuenta personal o en otro cliente. Lo que funciona es un inventario, una lista corta de servidores aprobados con la versión fijada y credenciales propias, y un proceso de alta que tarde días, no meses. El objetivo es que el camino aprobado sea más cómodo que el atajo.
Fuentes
- Model Context Protocol, especificación revisión 2026-07-28: «Authorization» y «Security Best Practices».
- Luca Beurer-Kellner y Marc Fischer (Invariant Labs), «MCP Security Notification: Tool Poisoning Attacks», 1 de abril de 2025.
- Tal Skverer (Astrix Security), «State of MCP Server Security 2025», 15 de octubre de 2025.
- Postmark, «Information regarding malicious postmark-mcp package», 25 de septiembre de 2025; Shweta Sharma, CSO Online, 26 de septiembre de 2025; Ravie Lakshmanan, The Hacker News, 29 de septiembre de 2025.
- JFrog Security Research, CVE-2025-6514 en mcp-remote, 9 de julio de 2025; The Hacker News, 10 de julio de 2025.
- Bill Toulas, «Asana warns MCP AI feature exposed customer data to other orgs», BleepingComputer, 18 de junio de 2025.
- OWASP, MCP Top 10 (beta, 2025) y Top 10 for Agentic Applications for 2026, 9 de diciembre de 2025.
- David Soria Parra y otros, «Introducing the MCP Registry», 8 de septiembre de 2025.
- Documentación de administración: Claude Code, GitHub Copilot (6 de agosto de 2026) y Cursor.
Jordi García es Tech Lead en onext. Trabaja en llevar la IA a producción gobernada en equipos de desarrollo y de producto —con Spec-Driven Development, ingeniería de contexto y verificación humana en cada paso— y firma los insights técnicos de onext sobre método, calidad y coste de la IA aplicada.
LinkedIn →