MCP-SandboxScan: WASM-based Secure Execution and Runtime Analysis for MCP Tools

Este artículo presenta SandScope, un marco de auditoría consciente de MCP que combina la ejecución segura basada en WebAssembly, la detección de testigos en tiempo de ejecución y el perfilado semántico de herramientas para identificar y reportar riesgos de delegado confundido donde las entradas controladas por un atacante causan que las herramientas MCP benignas filtren datos sensibles o ejecuten operaciones no autorizadas dentro de contextos de agentes LLM.

Lo esencial

El panorama general: El problema del "Diputado Confundido"

Imagina que contratas a un asistente robótico muy inteligente y servicial (un agente de IA) para que te ayude a escribir código o gestionar tus archivos. Para que el robot sea más útil, le permites instalar "herramientas" (como un lector de archivos, un navegador web o un conector de bases de datos) que actúan como aplicaciones en un teléfono.

El problema es la confianza. Podrías instalar una herramienta que parece inofensiva, pero si un hacker engaña al robot para que le dé a esa herramienta un comando específico, la herramienta podría entregar accidentalmente tus contraseñas privadas o archivos secretos al robot.

Esto se llama el problema del "Diputado Confundido" (Confused Deputy). La herramienta no es malvada; simplemente está haciendo exactamente lo que el robot le ordenó hacer. Pero debido a que el robot está hablando con la herramienta, la herramienta podría accidentalmente susurrar tus secretos de vuelta al robot, y el robot podría entonces mostrar esos secretos a ti (o peor aún, usarlos para tomar malas decisiones).

La solución: SandScope (El inspector de "Caja de Cristal")

Los investigadores construyeron una herramienta llamada SandScope para atrapar estas filtraciones accidentales antes de que ocurran. Piensa en SandScope como una caja de cristal de alta tecnología donde puedes probar estas herramientas de forma segura.

Así es como funciona, paso a paso:

1. El "Canario en la Mina de Carbón" (Preparar la trampa)

Antes de probar una herramienta, SandScope planta "trampas" invisibles dentro del entorno.

• La analogía: Imagina que quieres ver si un nuevo repartidor está robando en tu casa. Dejas unos cuantos sobres de color rojo brillante y distintivo sobre tu escritorio con un código único escrito en su interior.
• En el artículo: SandScope coloca valores "canario" falsos (como contraseñas falsas o códigos únicos) en el entorno de la herramienta, en los archivos o en los argumentos que el robot envía a la herramienta.

2. La "Caja de Cristal" (Ejecución segura)

SandScope ejecuta la herramienta en una sala especial y aislada.

• La analogía: No dejas que el repartidor entre en tu casa real. En su lugar, lo dejas en una cabina insonorizada con paredes de cristal. Él puede ver lo que hay sobre la mesa, pero no puede tocar tu caja fuerte real ni llamar a tu banco.
• En el artículo: Utilizan una tecnología llamada WASM (WebAssembly) para ejecutar la herramienta en un entorno aislado (sandbox). Esto limita lo que la herramienta puede hacer realmente en tu computadora real. Si la herramienta intenta acceder a un archivo real, el sandbox lo bloquea.

3. El "Eavesdropper" o "Escucha" (Observar la salida)

Mientras la herramienta se ejecuta en la caja de cristal, SandScope observa todo lo que la herramienta le dice de vuelta al robot.

• La analogía: Estás escuchando a través de un micrófono para ver si el repartidor dice accidentalmente: "¡Oh, encontré ese sobre rojo sobre el escritorio!".
• En el artículo: SandScope escanea la salida de la herramienta (el texto que envía de vuelta a la IA) para ver si alguno de esos códigos canario falsos aparece allí.

4. El "Boletín de Notas" (La evidencia)

Si la herramienta repite accidentalmente un código falso, SandScope levanta una bandera roja.

• La analogía: Si el repartidor dice el código, sabes: "¡Ajá! Esta herramienta filtra información". No necesitas saber cómo la robó, solo que la filtró.
• En el artículo: Esto se llama un "Testigo de Fuente a Sumidero" (Source-to-Sink Witness). Demuestra que un secreto (Fuente) terminó en un lugar (Sumidero) que la IA puede ver.

Dos formas de observar las herramientas

SandScope es inteligente porque utiliza dos métodos diferentes para comprobar las herramientas:

1. La "Prueba en Vivo" (Análisis Dinámico): Realmente ejecuta la herramienta en la caja de cristal para ver qué sucede. Es como dejar que el repartidor intente entregar un paquete para ver si lo deja caer.

   • Resultado: Probaron 35 herramientas del mundo real de esta manera y descubrieron que 12 de ellas filtraban información en escenarios específicos.

2. El "Chequeo de Currículum" (Perfilado Semántico): A veces, una herramienta es demasiado complicada para ejecutarla (tal vez necesita una contraseña o una configuración especial). En este caso, SandScope simplemente lee el "currículum" de la herramienta (su descripción de código y metadatos) para ver lo que afirma que puede hacer.

   • Resultado: Incluso cuando no pudieron ejecutar las herramientas, analizaron los "currículums" de 1,127 herramientas. Descubrieron que 886 de ellas afirmaban tener acceso a cosas sensibles como redes, archivos o contraseñas. Esto ayuda a saber qué herramientas vigilar.

¿Qué encontraron?

• Funciona: SandScope logró atrapar herramientas que filtraban secretos falsos de vuelta a la IA en pruebas controladas.
• No es perfecto: Si una herramienta oculta el secreto mediante el cifrado (codificando las letras) o la compresión, SandScope podría pasarlo por alto. Es bueno detectando filtraciones de "texto plano".
• Es práctico: Probaron 100 herramientas del mundo real. Pudieron ejecutar unas 35 de ellas por completo. Para el resto, aún pudieron leer sus "currículums" para entender los riesgos.

La Conclusión

El artículo presenta SandScope, un inspector de seguridad para herramientas de IA. No intenta detener a los hackers directamente; en su lugar, crea un entorno de prueba seguro y aislado para ver si una herramienta derrama accidentalmente secretos de vuelta a la IA. Combina la prueba en vivo (observar la ejecución de la herramienta) con la lectura de currículums (comprobar lo que la herramienta afirma hacer) para dar a los desarrolladores un informe claro y auditable sobre si una herramienta es segura de usar.

Nota importante: El artículo no afirma que esto solucione todos los problemas de seguridad ni que pueda predecir cada hackeo futuro. Simplemente proporciona una forma de reunir evidencia de las filtraciones para que los desarrolladores puedan corregirlas antes de que se conviertan en desastres reales.

Resumen técnico

Resumen Técnico: MCP-SandboxScan (SandScope)

Declaración del Problema

El Protocolo de Contexto de Modelo (MCP) permite que los agentes de Modelos de Lenguaje Grande (LLM) invoquen herramientas externas y accedan a fuentes de datos, creando una nueva superficie en la cadena de suministro de software. Aunque las herramientas se instalan como paquetes de terceros, sus salidas suelen entrar en el contexto de razonamiento del agente. Esta arquitectura introduce un riesgo de delegado confundido (confused-deputy risk): entradas controladas por un atacante (por ejemplo, mediante argumentos generados por el LLM, páginas web recuperadas o metadatos de repositorios) pueden inducir a herramientas que de otro modo serían benignas o confiables a ejercer autoridad legítima sobre archivos locales, variables de entorno u operaciones de red. El peligro crítico es que estas herramientas pueden devolver contenido sensible o de tipo instructivo en campos visibles para el LLM, filtrando eficazmente secretos o inyectando instrucciones en el siguiente paso de razonamiento del agente.

Los enfoques de seguridad existentes son insuficientes porque:

1. La inspección estática de las descripciones de las herramientas o del código fuente no puede detectar comportamientos que se manifiestan solo en tiempo de ejecución (por ejemplo, acceso a archivos ofuscado o secretos derivados de lecturas de archivos en tiempo de ejecución).
2. El monitoreo basado en proxies del tráfico a menudo no logra capturar los comportos internos de los procesos de la herramienta o el flujo específico de datos desde las entradas externas hacia las salidas visibles para el LLM.
3. La ejecución directa de herramientas de terceros en el host es insegura debido a los amplios privilegios que estas herramientas suelen heredar.

Existe una brecha en la observabilidad y contención en tiempo de ejecución: los auditores necesitan observar los flujos desde las entradas externas hacia las salidas visibles para el LLM sin otorgar a las herramientas no confiables una autoridad descontrolada sobre el host.

Metodología: Marco de Trabajo SandScope

Los autores proponen SandScope, un marco de auditoría consciente de MCP que combina la ejecución controlada con la detección de testigos en tiempo de ejecución y el perfilado semántico de herramientas. Opera sin asumir que el código de la herramienta sea malicioso, centrándose en el comportamiento de delegado confundido inducido por entradas externas.

1. Backends de Ejecución

SandScope admite dos rutas de ejecución para equilibrar la contención y la fidelidad del protocolo:

• Ruta de Sandbox WASI: Para herramientas portátiles (artefactos WebAssembly o aquellos envueltos en adaptadores ligeros), SandScope las ejecuta bajo la Interfaz de Sistema WebAssembly (WASI). Esto otorga capacidades explícitas y limitadas (por ejemplo, variables de entorno específicas, directorios de datos pre-abiertos) y deniega el acceso a la red por defecto.
• Ruta Nativa stdio: Para servidores MCP no modificados (Node.js, Python, Go, etc.), SandScope los dirige mediante entrada/salida estándar. Si bien esto preserva la fidelidad del protocolo, depende de un sandboxing externo a nivel de SO (por ejemplo, Docker, Bubblewrap) para la contención.

2. Pipeline de Evidencia

El marco sigue un pipeline de seis etapas:

1. Configuración de la Fuente de Auditoría: SandScope siembra valores "canario" distinguibles en variables de entorno, directorios de archivos y argumentos de llamada a herramientas. También rastrea señales de intención de red (por ejemplo, cadenas que sugieren solicitudes salientes).
2. Descubrimiento y Adaptación del Objetivo: Identifica el objetivo (artefacto portátil vs. servidor nativo) y selecciona la ruta de ejecución apropiada. Para servidores nativos, realiza un escaneo superficial para recuperar los metadatos de tools/list.
3. Ejecución Controlada: Se ejecuta el objetivo. Para servidores nativos, un controlador inicializa el protocolo, solicita listas de herramientas e invoca herramientas.
4. Monitoreo en Tiempo de Ejecución: El sistema registra stdout/stderr acotados, códigos de salida, transcripciones MCP (JSON-RPC) y eventos de sandbox (por ejemplo, conexiones denegadas).
5. Extracción de Sumideros (Sinks): SandScope identifica sumideros visibles para el LLM—regiones textuales que probablemente serán re-insertadas en el prompt del agente. Estos incluyen:
   • Líneas que contienen marcadores de prompt (por ejemplo, PROMPT:).
   • Campos prompt o messages en respuestas JSON.
   • Nodos hoja con valores de cadena en retornos de herramientas estructurados.
6. Detección de Testigos: El sistema hace coincidir los canarios de origen con los sumideros extraídos. Emplea un detector de evidencia positiva que verifica:
   • Subcadenas exactas.
   • Ventanas de prefijo/sufijo (para capturar fugas parciales como claves API).
   • Formas normalizadas y decodificadas (manejando ROT13, Hex, Base64 y fragmentación por separadores).

3. Perfilado Semántico

Para abordar casos donde la ejecución dinámica falla (debido a errores de compilación, falta de credenciales o estados complejos), SandScope incluye una capa semántica. Extrae capacidades declaradas de:

• Respuestas de tools/list en tiempo de ejecución.
• Registros estáticos a nivel de fuente (por ejemplo, decoradores, definiciones de funciones).
• Metadatos del repositorio (READMEs).
  Esta capa caracteriza la superficie de ataque (por ejemplo, "acceso a la red", "acceso al sistema de archivos") y prioriza las herramientas para su prueba, incluso si no pueden ejecutarse dinámicamente.

Contribuciones Clave

1. Definición de Sumideros de Seguridad de MCP: Los autores definen formalmente los campos de respuesta de MCP visibles para el LLM (resultados de herramientas, campos de prompt/mensajes, cargas útiles estructuradas) como sumideros de seguridad a nivel de protocolo y enmarcan la exposición de externo-a-sumidero como un riesgo en tiempo de ejecución.
2. Pipeline de Auditoría en Tiempo de Ejecución Basado en Escenarios: Un sistema que ejecuta herramientas bajo WASI o dirige servidores stdio nativos, vinculando fuentes de entorno, archivos y entradas de herramientas con sumideros visibles para el LLM mediante testigos auditables de caja negra, registrando además evidencia de intención de red.
3. Perfilado Semántico Complementario: Un método para recuperar capacidades declaradas de las herramientas a partir de metadatos y registros estáticos, permitiendo la caracterización de la superficie de ataque cuando la ejecución dinámica es incompleta y permitiendo la validación cruzada de riesgos de egreso declarados contra la evidencia en tiempo de ejecución.
4. Evaluación Empírica: Una evaluación exhaustiva a través de sujetos controlados multilingües, un benchmark de evasión y un corpus de 100 repositorios MCP.

Resultados de la Evaluación

Los autores evaluaron SandScope en tres frentes:

1. Benchmarks de Tiempo de Ejecución Controlados

• Sujetos: 30 sujetos multilingües (Go, Python, Rust, TypeScript) que cubren herramientas benignas, fugas de entorno, exfiltración de archivos y fijaciones de C2-beacon.
• Rendimiento: SandScope logró una precisión del 100% (0 falsos positivos) y un recall del 88.9% (F1 = 0.941).
• Hallazgos: Detectó con éxito 16 verdaderos positivos donde las fuentes con autoridad alcanzaron los sumideros visibles para el LLM. Los dos falsos negativos ocurrieron en casos de C2-beacon no protocolares donde la salida no produjo un testigo de origen-a-sumidero recuperable bajo las reglas de extracción actuales.

2. Benchmark de Evasión

• El detector mejorado (con soporte para ROT13, Hex, Base64 y fragmentación) identificó con éxito transformaciones de bajo esfuerzo que el emparejamiento de subcadenas simple no detectó.
• Limitación: El sistema sigue siendo un detector de evidencia positiva; no pretende ser completo contra el cifrado, la compresión, el hashing o la reescritura semántica.

3. Corpus del Mundo Real (100 Repositorios)

• Cobertura Dinámica: SandScope resolvió 91 repositorios y completó escaneos dinámicos superficiales para 35 (tasa de éxito del 38.5%). Los fallos se debieron principalmente a problemas de construcción, arranque o inicialización del protocolo, no al detector en sí.
• Exploración Dirigida: De los 35 repositorios escaneados con éxito, una pasada de exploración guiada por esquemas re-ejecutó 33 y observó testigos de origen-a-sumidero en 12 repositorios (60 testigos en total).
• Perfilado Semántico: La capa semántica recuperó metadatos a nivel de herramienta para 71 repositorios (cubriendo 1,127 herramientas), incluyendo 886 herramientas con al menos una capacidad sensible de seguridad declarada (por ejemplo, acceso a red, acceso al sistema de archivos).
• Validación Cruzada: La comparación de las capacidades de egreso declaradas con la evidencia en tiempo de ejecución reveló casos donde las capacidades fueron declaradas pero no ejercidas, y casos donde se observó comportamiento en tiempo de ejecución (por ejemplo, conexiones salientes denegadas) a pesar de la falta de metadatos declarados.

Significado y Reivindicaciones

El artículo posiciona a SandScope como el primer marco de auditoría conductual específico para MCP que trata los campos de protocolo visibles para el LLM como sumideros de seguridad e informa testigos de origen-a-sumidero en tiempo de ejecución a través de servidores MCP no modificados y sujetos portátiles de WASI.

• Reivindicaciones Modestas: Los autores declaran explícitamente que SandScope no es un motor completo de seguimiento de flujo (taint-tracking) ni un detector de vulnerabilidades independiente. No infiere flujos arbitrarios transformados o cifrados.
• Valor Central: Su contribución es proporcionar evidencia práctica y auditable para el riesgo de las herramientas MCP. Al separar los metadatos semánticos (capacidades declaradas) de los testigos en tiempo de ejecución (flujos observados), ofrece una visión estratificada del riesgo que ayuda a priorizar las pruebas y comprender la brecha entre lo que una herramienta afirma hacer y lo que realmente expone en un escenario de ejecución específico.
• Reproducibilidad: El código fuente se publica para facilitar la reproducibilidad, y el marco está diseñado para trabajar con implementaciones de MCP existentes sin requerir modificaciones en el código de las propias herramientas.