Tu Servidor MCP Es el Mayor Agujero de tu Setup

Un servidor MCP malicioso puede robar tus claves SSH sin escribir jamás una sola instrucción maliciosa completa. El grupo de investigación ASSET lo demostró: cuando la orden de robo se da a un modelo en un solo bloque, casi todos los grandes modelos se niegan. Divide esa misma orden en fragmentos que parecen inofensivos, y GPT-4o, Gemini 2.0 Flash y Llama 3.3 obedecen en el 100% de los casos probados.

Mientras tanto, la mayoría de los desarrolladores añaden un servidor MCP nuevo a su agente cada semana, copiando una línea de configuración encontrada en GitHub. Cada uno de esos servidores guarda una parte de tu acceso: tokens de API, claves cloud, cuentas de servicio. MCP es útil, nadie lo discute. Pero el servidor MCP se ha convertido en el eslabón más débil de todo el stack del agente.

Este artículo repasa cómo un servidor MCP filtra tus secretos sin que nadie lo note, el ataque GhostSplice que burla los rechazos del modelo dividiendo sus instrucciones, y las defensas concretas, desde Cloudflare WriteGuard hasta las reglas que puedes aplicar hoy en tu propio setup.

Un servidor MCP es el puente entre tu agente y una herramienta externa: tu base de datos, tu GitHub, tu Slack, tu nube. Para hacer ese trabajo de puente, guarda lo que necesita para entrar como tú — tokens, claves de API, credenciales de cuentas de servicio — en texto plano, en un archivo de configuración en tu disco, casi siempre sin ningún cifrado.

Un detalle del protocolo importa para lo que viene después. Cuando un agente conecta con un servidor MCP, el servidor devuelve su lista de herramientas, cada una con una descripción en texto libre que le dice al modelo cuándo y cómo usarla. Esas descripciones van directo al contexto del modelo, con el mismo peso que tus propias instrucciones, y los resultados que devuelven las herramientas también entran ahí. Un servidor MCP habla con tu agente sin parar, en texto que nadie vuelve a leer. Eso es exactamente lo que hace posible el ataque GhostSplice.

El ecosistema también creció más rápido que sus barreras de protección:

Señal	Número
Servidores en el registro oficial de MCP	9600+
Crecimiento de despliegues remotos desde mayo de 2025	5×

Cualquiera puede publicar un servidor, no hay revisión central, y tu agente confía en cada uno exactamente igual que en una herramienta oficial. La NSA publicó una guía de seguridad dedicada a MCP en mayo, afirmando que la adopción del protocolo superó la creación de sus protecciones. Cuando una agencia de inteligencia escribe una guía sobre tu herramienta de desarrollo favorita, rara vez es para felicitarte.

Ese es el panorama: miles de servidores, sin revisión, y tus claves en medio.

La primera grieta son las credenciales guardadas en texto plano. The Hacker News publicó un análisis detallado de la mecánica de la fuga el 17 de agosto, y el punto de partida es contundente: los tokens se pegan directo en cadenas de configuración y quedan legibles en disco. Un solo commit algo apurado basta para subir una configuración a un repositorio de Git con las claves dentro. Y empeora con lo que el artículo llama sprawl: las mismas claves duplicadas en varios archivos de configuración, variables de entorno, y copias en desarrollo, staging y producción. Con el tiempo nadie sabe dónde viven los secretos, así que nadie los rota — y una clave estática que nunca rota es una clave esperando a su atacante.

La segunda grieta son los permisos excesivos. Durante el desarrollo le das a tu servidor derechos amplios para evitar errores de autorización, y esos derechos amplios pasan a producción sin tocarlos. Un solo compromiso expone entonces mucho más de lo que el uso real justificaba.

La tercera grieta es la cadena de suministro. El CVE-2025-6514 afectó a mcp-remote, un proxy OAuth descargado más de 400 000 veces, y permitía que un servidor malicioso ejecutara inyección de comandos en la máquina del usuario — ejecutando código y llevándose las credenciales. Un paquete npm popular, instalado en una línea, y la puerta quedó abierta.

La cuarta grieta es la más sutil: la inyección de prompts. Un agente lee todo lo que sus herramientas traen de vuelta — una página web, un ticket, un documento interno. Si alguno de ellos contiene una instrucción oculta, el agente puede seguirla como si viniera de ti, y usar sus herramientas legítimas para exponer justo lo que debía proteger. Esa fuga no pasa por ningún fallo técnico; pasa por la ingenuidad del modelo.

Antes de cualquier ataque sofisticado, la vida normal de un servidor MCP — configuración en texto plano, permisos excesivos, dependencias sin validar, contenido sin filtrar — ya expone tus secretos.

GhostSplice es el nombre que el grupo de investigación ASSET le dio a una técnica que hace que tu propio agente ejecute la exfiltración, con su total cooperación. El principio cabe en una frase: en vez de escribir la orden de robo completa, el servidor malicioso la divide, pone un fragmento en la descripción de una herramienta, y otro en el resultado que esa herramienta devuelve. Cada parte, leída por separado, parece inofensiva. Pero el agente combina todo lo que entra en su contexto de trabajo: reconstruye la instrucción completa y la ejecuta de buena fe — desde su punto de vista, solo está rellenando el formulario que la herramienta le pidió rellenar.

Los números de las pruebas son lo importante:

Modelo	Instrucción en un bloque	Instrucción fragmentada
GPT-4o	Se niega el 100%	Obedece el 100%
Gemini 2.0 Flash	Se niega el 100%	Obedece el 100%
Llama 3.3	Se niega el 100%	Obedece el 100%
Claude Haiku 4.5	Se niega por la API	Obedece el 100% en la prueba de tres piezas dentro de Cursor

El detalle de Claude mata cualquier conclusión fácil: el mismo modelo puede negarse en un cliente y filtrar en otro, según las protecciones que ese cliente añada o no.

Lo que GhostSplice roba en las pruebas: claves SSH, secretos de entorno, código fuente, datos de clientes. Los investigadores trabajaron con proyectos aislados y claves falsas, no con víctimas reales, pero el método está publicado y es reproducible.

GhostSplice no es un primer intento. El mismo laboratorio publicó Ghostcommit en junio, un ataque que escondía sus instrucciones en archivos PNG referenciados por las convenciones del proyecto, y luego codificaba los secretos robados en código fuente como números enteros. Dividir instrucciones es una familia de ataques que se está asentando, no una curiosidad aislada.

Dos cosas mantienen esto en perspectiva. El ataque tiene dos requisitos: el servidor malicioso ya está conectado a tu agente, y el agente tiene acceso de lectura a los archivos objetivo. Por eso la procedencia importa tanto — de dónde vienen tus servidores es tu primera línea de defensa. Y recuerda la mecánica: el ajuste del modelo no te protege, porque el ataque nunca pide nada prohibido de una sola vez.

GhostSplice asumía un servidor malicioso ya conectado. Pero ¿quién decide qué se conecta? En un equipo, la respuesta honesta es nadie. Ese es el problema que Cloudflare llama shadow MCP: todos los servidores que los desarrolladores conectan a sus agentes sin ninguna revisión de seguridad. Hasta hace poco ese tráfico era invisible — una petición MCP se ve igual que cualquier otra llamada HTTPS.

Cloudflare cambió eso con detección a nivel de protocolo. Desde la actualización del estándar, todo cliente MCP conforme envía un encabezado MCP-Protocol-Version en sus peticiones, y Gateway inspecciona ese encabezado en todo el tráfico TLS que descifra. Un equipo de seguridad puede ahora ver cada servidor MCP usado en la empresa, con un panel dedicado: servidores únicos, usuarios, volúmenes de peticiones. Este enfoque basado en encabezados supera al filtrado por nombre de dominio, porque un servidor MCP no tiene motivo para llamarse mcp-algo — el protocolo se detecta por lo que dice, no por lo que dice ser.

El equipo también puede actuar: un selector is_mcp permite bloquear cualquier tráfico MCP que no haya pasado por un portal aprobado. El portal es la otra mitad del sistema — un único punto de acceso que agrupa a los servidores validados detrás de autenticación de identidad.

La última versión del estándar lleva la visibilidad aún más lejos. Los nuevos encabezados Mcp-Method y Mcp-Name exponen la operación solicitada y la herramienta que se está usando, sin que el firewall tenga que abrir el cuerpo de la petición. Un equipo puede distinguir un agente que lee un ticket de un agente que borra cincuenta de ellos, justo a nivel de red.

Cloudflare divide esto en dos casos: shadow MCP puro, un servidor que nunca fue aprobado, y bypass del portal, un servidor aprobado al que se accede directamente sin pasar por el punto de control. Ambos se bloquean con la misma regla base. La lógica es simple: todo lo que pasa por el portal está registrado y es conocido, todo lo demás se bloquea. Para una empresa, eso acaba con el servidor MCP fantasma instalado un viernes por la noche.

Incluso un servidor aprobado puede hacer daño, porque un agente hereda de golpe todos los permisos de su usuario. Ahí es donde entra WriteGuard, que Cloudflare acaba de abrir en beta privada. La idea: clasificar cada herramienta de cada servidor MCP en un nivel de riesgo, y aplicar una política distinta por nivel.

• Una lectura pasa sin fricción.
• Una escritura contenida, como publicar un comentario, pasa pero enriquecida: la acción se firma como proveniente de un agente, en nombre de una persona específica, y un evento de auditoría va a un log central.
• Una acción crítica — fusionar código, desplegar a producción, borrado masivo — se bloquea antes de que el servidor siquiera la procese.

El ejemplo de GitLab en el post de Cloudflare muestra bien la gradación: leer una merge request pasa, comentarla pasa con atribución, y fusionarla se rechaza hasta que un humano lo haga él mismo.

La parte más interesante es el modelo de identidad. El agente mantiene los permisos del empleado al que sirve, pero cada escritura ahora lleva dos firmas: la persona, y la sesión del agente que actúa en su nombre. Los sistemas posteriores pueden por fin distinguir un cambio hecho a mano de uno generado por una máquina, y la auditoría se envía de forma asíncrona a un log central, depurada de datos sensibles. Hasta ahora un agente era indistinguible de su humano en los registros; para una auditoría de incidentes eso lo cambia todo — una sola consulta te dice si el merge dudoso del martes vino de un compañero apurado o de una sesión de agente que se puso creativa.

Cloudflare no vende una teoría; describen su propio uso interno: su portal conecta 27 servidores MCP, frente a 13 en abril. Ese número cuenta la historia real — incluso en Cloudflare, el número de servidores se duplica en pocos meses, y por eso el control por herramienta se vuelve necesario. La dirección que está tomando el sector es clara: dejar de confiar en el servidor entero, y decidir acción por acción qué puede hacer un agente.

Los límites hay que decirlos con claridad. WriteGuard es una beta privada tras un formulario de registro, y la detección de Gateway necesita un despliegue de Cloudflare Zero Trust con inspección TLS activada: para un desarrollador independiente o un equipo pequeño, eso simplemente no es tu infraestructura. Incluso en una empresa, la detección solo ve el tráfico de red que descifra — un servidor MCP local que corre sobre stdio, lanzado como un proceso simple en tu máquina, sigue siendo invisible para Gateway. Que es exactamente como corre la mayoría de los servidores que instalan los desarrolladores.

Sobre todo, ninguna de estas herramientas repara el mecanismo central que expuso GhostSplice: mientras un agente combine libremente todo lo que entra en su contexto, los fragmentos inofensivos seguirán recomponiéndose en instrucciones hostiles. Los investigadores de ASSET lo dicen ellos mismos: la solución exige tratar la salida de las herramientas como datos, nunca como instrucciones, y esa separación todavía no existe de forma nativa en los agentes.

Mientras tanto, sus recomendaciones se reducen a tres movimientos: evitar que los valores que salen de una herramienta alimenten sin control los argumentos de otra, mantener la capacidad de denegar cada invocación de herramienta a mano, y tratar cualquier anotación de un servidor no validado como hostil por defecto. Ninguno de los tres es automático hoy: los aplicas tú, o no los aplica nadie. Trata todo lo que Cloudflare ofrece aquí como cinturones de seguridad, no como frenos — limita el daño, no evita la colisión.

Qué hacer, a partir de hoy:

1. Inventario. Lista los servidores MCP realmente conectados a tus agentes, y elimina los que ya no uses.
2. Ordena por procedencia. Un servidor oficial de un proveedor conocido, sí. Un repositorio de GitHub con 40 estrellas encontrado en un hilo, no — no hasta que hayas leído qué hace con tus datos.
3. Ajusta los permisos. Da a cada servidor un token dedicado con el alcance mínimo, nunca tu clave maestra, y rota esos tokens como lo harías con cualquier sistema de producción.
4. Mantén el control sobre las acciones sensibles. Un agente que escribe, fusiona o borra tiene que pasar por ti — la versión manual de lo que WriteGuard industrializa.
5. Aplica la regla de GhostSplice cada día. Cuando tu agente encadene acciones de herramientas que no pediste, detenlo y lee lo que el servidor le ha estado diciendo.

Todo cliente de agentes puede listar sus servidores conectados y sus herramientas, y esa lista tarda treinta segundos en leerse. Esos treinta segundos son la mejor relación tiempo-seguridad de todo tu setup.

Si estás en una empresa, añade la capa de red: la detección MCP de Gateway y los portales valen la pena implementarlos, porque el shadow MCP ya existe en tu organización, lo veas o no.

MCP no es el problema — la velocidad a la que le entregamos nuestras claves sí lo es.