Aislar servidores MCP en sandboxes: la guía de 13 pasos de Tech Insider

La especificación de MCP con fecha 2026-07-28 marca como obsoletos el transporte HTTP+SSE y mecanismos como roots, sampling y logging. El servidor MCP oficial de GitHub ha publicado seis versiones solo en octubre, hasta la v2.0.3 del día 21. Con ese ritmo de cambio, Tech Insider ha publicado hoy una guía de 13 pasos para aislar servidores MCP en sandboxes en lugar de ejecutarlos en la máquina del desarrollador.

La firma Elias Virtanen, analista de ciberseguridad del medio, y parte de una premisa que reconocerá cualquiera que haya conectado servidores de terceros a Claude Desktop o a Claude Code: sin aislamiento, un solo prompt inyectado puede comprometer los datos del usuario o la infraestructura que hay debajo. La versión completa en la web de Tech Insider incluye ejemplos de configuración para cada paso.

Qué propone la guía

Los 13 pasos se agrupan bien en cuatro bloques.

Amenazas y arquitectura. El punto de partida es documentar los modos de fallo: prompt injection, servidores MCP maliciosos, tool poisoning, robo de credenciales, exfiltración de datos y escape del sandbox. La guía cita además MCP-2026-015, un problema en el campo de instrucciones de `server/discover` que permite inyectar contenido y que se agrava si las respuestas se cachean con `cacheScope: public`. La arquitectura de referencia encadena el runtime del agente, un gateway de políticas, el servidor MCP, un ejecutor aislado, el control de salida de red y el saneado de la respuesta.

Tecnología de aislamiento. Compara gVisor, que intercepta syscalls en espacio de usuario, Firecracker, con una microVM por carga de trabajo, y Kubernetes Agent Sandbox para orquestar a escala de clúster. Después baja a proveedores concretos. E2B ofrece un plan Hobby con 100 dólares de crédito gratuito, sesiones de una hora y 20 sandboxes simultáneos, y un plan Pro de 150 dólares al mes con sesiones de 24 horas. Cloudflare lanzó su Sandbox SDK 1.0 el 30 de septiembre, y la guía recomienda migrar aunque la rama 0.x siga recibiendo parches.

Configuración y credenciales. Desactivar las herramientas que no se usan, limitar el servidor a rutas explícitas, declarar la versión de la especificación y activar `denySymlinkEscape`. Autenticar con bearer token en todos los transportes, incluido localhost, con tokens limitados a herramientas concretas. Restringir la salida de red con una allowlist de hosts (el ejemplo usa `api.github.com` y `pypi.org`) y probarla contra SSRF, DNS rebinding y cadenas de redirecciones. Emitir credenciales por sesión y revocarlas al cerrar el sandbox, no cuando caducan; para esto menciona la función Secrets de E2B, disponible desde el 7 de octubre.

Operación. Tratar toda salida de una herramienta como potencialmente hostil y no dejar que el agente la interprete como una instrucción nueva. Pedir aprobación humana para las acciones con consecuencias (escribir, desplegar, borrar) y dejar en automático las de solo lectura. Registrar el nombre de la herramienta, los argumentos, el ID de sesión, la duración, el código de salida y los destinos de red. Y destruir cada sandbox dentro de un bloque `try/finally` con un timeout duro para no dejar sesiones huérfanas.

Por qué importa

Muchos servidores MCP se instalan con un comando y unas líneas en `claude_desktop_config.json`, y se ejecutan con los mismos permisos que el usuario. Es cómodo para probar y arriesgado cuando hay datos reales de por medio. La guía no inventa técnicas nuevas: reúne prácticas conocidas de seguridad en contenedores y las aplica a un escenario en el que el atacante puede entrar a través del texto que lee el modelo.

Para nosotros, lo más aprovechable son los pasos 8 y 9. El control de salida de red y las credenciales por sesión cortan la mayoría de escenarios de exfiltración aunque falle todo lo demás. Los pasos 11 y 12 encajan bien con Claude Code: los permisos por herramienta y los hooks `PreToolUse` y `PostToolUse` permiten montar puertas de aprobación y registros sin infraestructura adicional.

Para quién es

Equipos que exponen servidores MCP propios a agentes en producción.
Desarrolladores que instalan servidores de la comunidad sin revisar su código.
* Responsables de seguridad que tienen que decidir qué servidores se permiten dentro de la empresa.

Para un uso individual con dos o tres servidores de confianza, los 13 pasos son excesivos. Empezar por la allowlist de red y por tokens con alcance limitado ya cubre buena parte del riesgo.

Es una guía de referencia más que una novedad, y ahí está su valor. El ecosistema MCP avanza más rápido que sus prácticas de seguridad, y tener una lista ordenada con la que auditar una instalación propia es un buen punto de partida.