Los agentes de codificación con inteligencia artificial suelen trabajar con herramientas externas para leer archivos, ejecutar verificaciones o recuperar contexto del proyecto. Pero esa misma capacidad puede convertirse en una puerta silenciosa cuando se introduce un servidor malicioso conectado mediante Model Context Protocol (MCP). Según pruebas divulgadas por ASSET Research Group, la técnica GhostSplice servidores MCP permite que un asistente “ensamble” partes de una orden dañina sin que ninguna parezca, por sí sola, una instrucción claramente peligrosa.
El resultado no depende únicamente del modelo. En los experimentos reportados, un mismo modelo pudo rechazar en un cliente y exfiltrar en otro, lo que subraya que los controles alrededor de la integración son determinantes.
Qué es GhostSplice servidores MCP
GhostSplice se basa en fragmentar la solicitud maliciosa en partes que, consideradas individualmente, parecen rutinarias. En lugar de enviar un único requerimiento completo para robar información sensible, el atacante “reparte” la intención en fragmentos que el agente recibe por canales que ya utiliza para operar.
De acuerdo con la divulgación, el abuso funciona contra herramientas que se conectan a servidores externos a través de MCP, un estándar abierto que permite que asistentes de IA llamen herramientas externas de manera estructurada.
La idea clave es que el asistente puede unir los fragmentos dentro del mismo contexto de trabajo y, al final, terminar ejecutando una acción que el atacante quiere: recopilar secretos locales y devolverlos al servidor.
Cómo se logra la exfiltración sin una orden “obviamente dañina”
Los detalles publicados describen un escenario en el que un servidor MCP malicioso configura herramientas que devuelven información y, además, usa descripciones y resultados de herramientas para completar la “historia” de la tarea.
Fragmentos en descripción y resultados
En algunos montajes, se usa un enfoque donde una parte del contenido aparece en la descripción de una herramienta y otra parte aparece en el resultado de esa herramienta. Aunque MCP conserva límites estructurados entre herramientas y resultados, las pruebas de ASSET indican que el agente puede seguir combinando instrucciones a través de esos límites en el contexto de trabajo.
La consecuencia práctica es que no hace falta que un solo fragmento contenga toda la orden maliciosa. Si el agente puede interpretarlo como una secuencia coherente, el robo termina ocurriendo.
Variante con tres canales
Además del enfoque de dos piezas, la divulgación incluye una variante que separa elementos en tres interacciones: inventario del proyecto, mapeo entre campos y contenido, y finalmente la recopilación. Esta separación refuerza la apariencia de tareas normales en cada paso.
Qué datos se buscaban en las pruebas
El material de referencia asociado al ataque describe una herramienta “aparentemente inocua” (por ejemplo, una verificación de integridad) con campos genéricos. Luego, en una exploración posterior del proyecto, se proporciona el mapeo que completa la intención.
En la descripción del ejemplo, los campos acaban apuntando a archivos y recursos con contenido sensible, como:
- Claves SSH, incluyendo rutas típicas como .ssh/id_rsa
- Fuentes propietarias del proyecto
- Un archivo de clientes con nombre tipo customers.csv
- Variables de entorno en .env
Leídos por separado, los fragmentos no revelan el plan completo. Sin embargo, al combinarse según el flujo esperado por el agente, el servidor termina recibiendo contenidos que no deberían salir del entorno.
Por qué los resultados cambian según el cliente
Una de las conclusiones más importantes de la divulgación no es solo “el modelo es vulnerable”, sino que el modelo y la integración funcionan como un sistema. ASSET reporta que con los mismos modelos, el resultado puede variar drásticamente según el cliente o la forma en que se gestionan las llamadas a herramientas y la seguridad de la interfaz.
La publicación describe que el rendimiento del ataque mejora cuando se divide la solicitud (por ejemplo, comparando escenarios de una sola pieza frente a dos piezas). Sin embargo, las tablas de resultados deben interpretarse con cautela: reflejan montajes específicos y controles concretos, no una tasa universal aplicable a todos los usuarios.
También se menciona un matiz relevante: algunos números publicados podrían dar la impresión de que ciertos modelos son “inmunes”, pero en pruebas reportadas también se observó la salida de fuentes con claves codificadas, mientras que otras “secrets” más obvias fueron redaccionadas. En otras palabras, la seguridad puede fallar de manera parcial y no siempre con el mismo patrón.
Límite del ataque: no es una intrusión remota “directa”
La técnica no está planteada como una manera de comprometer un agente arbitrario desde la red. El escenario presupone que el desarrollador ya conectó el servidor MCP controlado por un atacante, y que el agente tiene acceso a los archivos que luego se exfiltran.
En términos prácticos: el riesgo crece cuando una organización habilita integraciones de terceros o personalizadas sin revisión, o cuando se confía en salidas provenientes de servidores que no se consideran confiables.
La defensa: controles en el cliente y tratamiento estricto de la salida
La especificación y recomendaciones asociadas a MCP apuntan a un principio: la seguridad no debe delegarse a herramientas externas. En particular, se sugiere que el cliente mantenga supervisión humana para denegar invocaciones y que trate anotaciones provenientes de servidores no confiables como no confiables.
Asimismo, se remarca que servidores MCP inseguros aumentan el riesgo de prompt injection y que las organizaciones deberían evaluar integraciones hechas a medida y de terceros.
Recomendaciones específicas de ASSET
La guía de ASSET profundiza en un punto operativo: tratar la salida del servidor como datos y no como instrucciones. Además, recomiendan evitar que valores retornados por una herramienta se usen sin verificación directa como argumentos para otra herramienta.
Ese último detalle encaja con el mecanismo de GhostSplice: si el sistema permite que “lo que llega” se convierta sin fricción en “lo que se ejecuta”, el atacante encuentra una ruta para completar la tarea maliciosa.
Relación con investigaciones anteriores
La divulgación también conecta el hallazgo con una publicación previa del mismo laboratorio, donde se escondía una instrucción dentro de un archivo de referencia con la ayuda de convenciones del proyecto. Aunque el método difiere, ambas investigaciones apuntan a la misma debilidad de fondo: la frontera de seguridad alrededor del modelo importa tanto como el modelo en sí.
En la práctica, esto refuerza que no basta con “esperar que el modelo rechace”. Hay que revisar cómo el cliente interpreta, encadena y aplica la información que proviene de fuentes externas.
Qué pueden hacer equipos y desarrolladores hoy
Si en tu flujo usas agentes de codificación con MCP, estas acciones pueden reducir el riesgo de técnicas como GhostSplice servidores MCP:
- Audita integraciones MCP: revisa y limita servidores y herramientas que puedan influir en el contexto del agente.
- Trata la salida como datos: evita que el texto devuelto por un servidor termine convertido en comandos o argumentos sin validación.
- Controla el encadenamiento entre herramientas: implementa verificaciones para impedir que valores de un resultado fluyan hacia otro argumento sensible.
- Aplica supervisión humana cuando proceda: especialmente en acciones de alto impacto como lectura de secretos o envío de contenido.
- Revisa diferencias entre clientes: los resultados pueden cambiar; evalúa tu configuración concreta y no asumas que una prueba en otro entorno aplica igual.
Adicionalmente, dado que los informes disponibles describen ensayos controlados (con credenciales falsas en entornos aislados), conviene considerar el aprendizaje de la técnica como una evaluación del modelo de amenazas, no como prueba definitiva de explotación en tu caso particular.
Conclusión
GhostSplice servidores MCP muestra cómo un atacante puede aprovechar el trabajo “normal” de un agente de IA para lograr un objetivo anómalo: exfiltrar secretos del entorno sin que la solicitud maliciosa se presente de forma completa en una sola instrucción. La clave está en la fragmentación, en el uso de canales que el asistente ya maneja y en la forma en que el cliente interpreta y encadena lo que recibe.
La defensa, por tanto, no se reduce a elegir un modelo más o menos estricto. Se trata de reforzar el cliente: tratar salidas como datos, validar flujos entre herramientas y revisar integraciones MCP para evitar que servidores no confiables definan acciones sensibles. Con estas medidas, disminuyes la probabilidad de que un agente “ensamble” algo peligroso a partir de piezas aparentemente inocentes.
Fuente: https://thehackernews.com/2026/08/malicious-mcp-servers-can-split.html
