Sandbox de servidores MCP: Servidores MCP aislados con controles de sistema de archivos, secretos y red

Los servidores MCP deben ejecutarse con montajes de sistema de archivos delimitados, secretos con mínimos privilegios, políticas de red explícitas, límites de espacio de trabajo por agente y registros, para que el acceso a herramientas no expanda silenciosamente el límite de confianza del agente. Un sandbox es útil cuando un servidor MCP puede leer archivos, generar subprocesos, instalar paquetes, llamar a API internas o mantener estado para una sesión de agente de larga duración. La parte difícil no es decidir que MCP necesita aislamiento; es decidir qué límite corresponde a cada herramienta, qué datos cruzan ese límite y qué acciones aún requieren revisión humana.

Por qué MCP cambia el límite de confianza del agente

El Model Context Protocol proporciona a las aplicaciones de IA una forma común de conectar modelos con herramientas, indicaciones y recursos. Esto hace que la integración sea más limpia, pero también convierte a cada servidor MCP en un límite de políticas. Si un servidor expone read_file, run_command, query_database o deploy_preview, el agente ahora puede solicitar acciones que van más allá de la ventana de contexto del modelo.

La especificación MCP describe varias expectativas de seguridad que son importantes para el diseño del sandbox: los usuarios deben comprender y consentir las herramientas expuestas, los anfitriones deben requerir consentimiento antes de invocar herramientas, las descripciones de herramientas no son confiables a menos que se verifiquen, y los datos sensibles deben protegerse con controles de acceso apropiados. Esas reglas son controles a nivel de aplicación. Un sandbox añade controles de tiempo de ejecución por debajo de ellos, limitando a qué puede acceder el proceso del servidor MCP incluso si el agente, la descripción de la herramienta o la cadena de indicaciones realiza una solicitud incorrecta.

Piensa en el límite de confianza en tres capas:

Capa	Qué controla	Modo de fallo común
Anfitrión o cliente MCP	Qué servidores están conectados y qué llamadas a herramientas están aprobadas	Una herramienta amplia se aprueba una vez y se reutiliza en un contexto más sensible
Servidor MCP	Implementación de herramientas, autenticación, validación de entrada, acceso a recursos	Una herramienta lee más archivos, envía más datos o ejecuta más comandos de lo esperado
Entorno de ejecución del sandbox	Sistema de archivos, procesos, red, secretos, ciclo de vida y registros	El proceso del servidor hereda el acceso del anfitrión porque se ejecuta demasiado cerca de los recursos de producción

El objetivo no es hacer que cada servidor MCP no sea confiable de la misma manera. Una herramienta de búsqueda en calendario, una herramienta de ejecución de código local y una herramienta de despliegue tienen diferentes perfiles de riesgo. El objetivo es mantener el acceso de tiempo de ejecución de cada servidor no más amplio que el trabajo que realiza.

Qué aislar primero

Comienza con los servidores MCP que pueden cambiar el estado externo, tocar datos sensibles o ejecutar código. Estos son los servidores con mayor probabilidad de convertir un error normal de indicación en un incidente más amplio.

Los candidatos de alta prioridad para el sandboxing incluyen:

• Herramientas de ejecución de código que ejecutan comandos de shell, Python, Node.js, compiladores, pruebas o cuadernos.
• Herramientas de sistema de archivos que leen o escriben en un repositorio, cargas de usuario, conjuntos de datos montados, archivos de credenciales o artefactos generados.
• Herramientas de navegador y uso de computadora que mantienen cookies, estado de sesión, archivos descargados o capturas de pantalla.
• Conectores de datos que pueden consultar registros de clientes, exportaciones de análisis, tickets o documentos privados.
• Herramientas de despliegue e IC que pueden crear ramas, publicar vistas previas, rotar configuraciones o modificar infraestructura.
• Herramientas de paquetes y dependencias que pueden obtener código de registros, repositorios Git remotos o URL arbitrarias.

Los servidores MCP de menor riesgo aún pueden merecer controles. Un servidor de búsqueda de documentación pública de solo lectura puede no necesitar una microVM por solicitud, pero aún debe tener una ruta de red permitida, registros y límites de velocidad. El aislamiento debe seguir el radio de explosión práctico de la herramienta, no la etiqueta “servidor MCP”.

Dónde debe ejecutarse el servidor MCP

Hay tres patrones de ubicación comunes. Ninguno es universalmente correcto.

Ubicación	Usar cuando	Cuidado con
Mismo sandbox que el espacio de trabajo del agente	El servidor está estrechamente acoplado a los archivos actuales del agente, comandos de shell, sesión del navegador o artefactos generados	El servidor y el agente comparten estado, por lo que una herramienta comprometida puede ver el mismo espacio de trabajo a menos que los montajes y secretos estén delimitados
Sandbox separado por servidor MCP o grupo de herramientas	La herramienta necesita un aislamiento más fuerte del espacio de trabajo del agente, maneja credenciales diferentes o realiza ejecuciones de alto riesgo	La transferencia de archivos entre sandboxes y la latencia se convierten en parte del diseño del producto
Fuera del sandbox detrás de una API delimitada	La herramienta es un servicio de producción estable con su propia autenticación, autorización, registro y límites de velocidad	La API debe ser estrecha; no expongas una superficie de administración interna amplia solo porque está fuera del sandbox

Ejecutar un servidor en el mismo sandbox es conveniente para agentes de codificación. El servidor MCP puede ver el repositorio, ejecutar pruebas, inspeccionar artefactos y devolver resultados sin mover archivos entre entornos. Esto funciona mejor cuando el espacio de trabajo en sí ya es desechable y contiene solo los archivos que el agente debe usar.

Un sandbox separado es mejor cuando la herramienta merece una política diferente. Por ejemplo, un servidor MCP de análisis de paquetes podría necesitar acceso a Internet para registros públicos, mientras que el agente de codificación principal no debería tenerlo. Un servidor MCP de navegador puede necesitar cookies para una cuenta de prueba, mientras que un servidor de ejecución de código nunca debería ver esas cookies.

Un servicio externo es adecuado para herramientas que no son realmente “herramientas de tiempo de ejecución”. Una consulta de facturación, lectura de banderas de características o búsqueda en un sistema de tickets puede ser más segura como una API backend normal con autorización del lado del servidor que como un servidor de forma libre dentro del entorno de cómputo del agente.

Montajes del sistema de archivos y espacios de trabajo por agente

El acceso al sistema de archivos es donde la conveniencia de MCP a menudo se convierte en privilegio accidental. Un servidor que necesita leer ./src no debería heredar el directorio personal de un desarrollador. Una herramienta que escribe gráficos generados no debería poder sobrescribir la configuración de despliegue.

Usa límites de espacio de trabajo explícitos:

• Asigna a cada ejecución del agente su propio directorio de espacio de trabajo.
• Monta solo el repositorio, la carpeta de carga, el conjunto de datos o el directorio de artefactos necesarios para la tarea.
• Prefiere montajes de solo lectura para el material fuente y montajes de lectura y escritura solo para las salidas.
• Separa las salidas generadas de los archivos fuente de confianza.
• Evita montar carpetas de credenciales como .ssh, directorios de configuración en la nube, perfiles de navegador o archivos de autenticación del gestor de paquetes local.
• Restablece o crea una instantánea del espacio de trabajo entre usuarios, inquilinos o trabajos no relacionados.

Las raíces MCP pueden ayudar a los clientes a comunicar las ubicaciones del sistema de archivos en las que debe operar un servidor, pero las raíces no son un límite de seguridad completo por sí mismas. Trátalas como un mecanismo de coordinación entre cliente y servidor. El tiempo de ejecución aún necesita límites a nivel del sistema de archivos, y el servidor debe validar las rutas para que las solicitudes no puedan escapar del espacio de trabajo previsto con enlaces simbólicos, rutas relativas o trucos de extracción de archivos.

Un patrón práctico es dividir el acceso al espacio de trabajo por rol:

Directorio	Acceso	Propósito
/workspace/input	Solo lectura	Cargas de usuario, repositorio semilla, fixture de referencia o datos de prueba
/workspace/output	Lectura y escritura	Archivos generados, informes, parches, gráficos o capturas de pantalla
/workspace/tmp	Lectura y escritura, desechable	Caché de compilación, caché de instalación de paquetes, archivos temporales
/workspace/secrets	Evitar montajes de archivos siempre que sea posible	Si es inevitable, montar un archivo de secreto delimitado con tiempo de vida estricto y redacción

Las rutas exactas no importan. El principio sí.

Secretos y variables de entorno

Los secretos suelen ser más fáciles de filtrar que los archivos porque viajan a través de variables de entorno, registros, trazas de pila, scripts de paquetes, historial de shell, sesiones de navegador y respuestas de herramientas. Cuando un servidor MCP necesita una credencial, dale la credencial más restringida que pueda completar la acción de la herramienta.

Usa credenciales separadas para servidores MCP separados. Un servidor de búsqueda de issues de GitHub puede necesitar acceso de solo lectura a issues. Un servidor de creación de PR puede necesitar acceso de escritura a ramas. Un servidor de despliegue no debería compartir ninguno de los dos tokens a menos que el modelo de permisos realmente lo requiera.

El manejo adecuado de secretos para servidores MCP se ve así:

• Inyecta secretos al inicio del sandbox o proceso, no a través de indicaciones.
• Usa tokens de corta duración o revocables cuando el proveedor los admita.
• Delimita las credenciales por herramienta, inquilino, entorno y acción.
• Redacta los secretos de stdout, stderr, respuestas estructuradas de herramientas y registros de trazas.
• No devuelvas variables de entorno sin procesar al modelo.
• No permitas que el agente decida qué secreto cargar.
• Rota las credenciales utilizadas por servidores de alto riesgo y después de una sospecha de exposición por inyección de indicaciones.

Evita un antipatrón común: un archivo de entorno para todo propósito montado en cada sesión de agente. Facilita el desarrollo local pero dificulta la revisión en producción. Si una herramienta no necesita un secreto, no debería poder leerlo.

Salida de red y opciones de transporte

MCP admite patrones de transporte local y remoto. La especificación describe stdio para la comunicación de procesos local y Streamable HTTP para la comunicación servidor-cliente a través de HTTP. Los diseños más antiguos basados en SSE todavía aparecen en el ecosistema, pero las nuevas integraciones deben consultar la documentación actual de MCP y el SDK elegido antes de depender de un transporte específico.

La elección del transporte y la política de red del sandbox resuelven problemas diferentes:

Pregunta	Respuesta del transporte	Respuesta de la política de red
¿Cómo se comunica el cliente MCP con el servidor?	stdio, transporte basado en HTTP u otro patrón compatible	No aplica
¿Qué hosts externos puede llamar el servidor?	No es suficiente por sí mismo	Lista de permitidos, lista de denegados, proxy, política DNS o sin salida
¿Puede el servidor obtener paquetes o páginas web?	No es suficiente por sí mismo	Listas de permitidos de registros, listas de permitidos de URL, almacenamiento en caché y registro
¿Puede otro proceso alcanzar el servidor?	Detalles de enlace y autenticación	Cortafuegos de entrada y límite de red del sandbox

Para servidores stdio locales, el riesgo suele ser el acceso heredado del anfitrión. El servidor puede ejecutarse como un proceso hijo de la aplicación anfitriona y ver archivos locales, variables de entorno y rutas de red. Si ese servidor ejecuta código o lee archivos sensibles, muévelo a un proceso en sandbox o ejecuta todo el par anfitrión-trabajador dentro de un espacio de trabajo desechable.

Para servidores MCP basados en HTTP, el riesgo se desplaza hacia la autenticación, la exposición en la red y la separación entre inquilinos. Usa autorización del lado del servidor, TLS, verificaciones de origen cuando sea relevante y credenciales por cliente. No expongas un servidor MCP remoto en una red interna amplia sin una política clara sobre quién puede invocar qué herramientas.

Para la salida de red, el denegado por defecto es más fácil de razonar que el abierto por defecto. Si una herramienta necesita instalaciones de paquetes, permite el registro de paquetes o un caché de extracción. Si necesita investigación web, enruta a través de un proxy que registre los dominios solicitados y bloquee los puntos finales de metadatos internos. Si necesita API internas, expone una API estrecha en lugar de toda la red privada.

Instalaciones de paquetes, subprocesos y estado de larga duración

Muchas herramientas MCP útiles necesitan subprocesos. Los agentes de codificación ejecutan pruebas. Los agentes de datos instalan bibliotecas. Los agentes de navegador lanzan navegadores. Los agentes de compilación llaman a compiladores. El soporte de subprocesos no es el problema; el soporte invisible de subprocesos sí lo es.

Antes de permitir instalaciones de paquetes o ejecución de shell, define:

• Qué comandos están permitidos, denegados o sujetos a aprobación.
• Si los gestores de paquetes pueden alcanzar la Internet pública.
• Si las versiones de dependencias deben estar fijadas o basadas en archivos de bloqueo.
• Dónde viven los cachés de compilación y los paquetes instalados.
• Cuánto tiempo pueden ejecutarse los procesos en segundo plano.
• Qué archivos de salida se conservan después de la limpieza.
• Si el agente puede iniciar oyentes de red.

Los servidores MCP de larga duración introducen un segundo problema: la deriva del estado. Un servidor que vive durante horas puede acumular archivos, credenciales, cookies del navegador, historial de shell, cambios de dependencias y trabajos en segundo plano. Ese estado puede ser útil para flujos de trabajo de varios pasos, pero debe pertenecer al agente, usuario y tarea correctos.

Usa controles de ciclo de vida:

Control	Por qué es importante
IDs de sandbox por agente	Evita que el estado de la herramienta de un agente se convierta en el contexto de otro agente
Tiempo de espera por inactividad	Limpia las sesiones de herramientas abandonadas
Política de pausa y reanudación	Soporta trabajos largos sin mantener cómputo innecesario activo
Política de instantáneas o plantillas	Inicia entornos repetibles desde una línea base conocida
Desmontaje explícito	Elimina archivos, mata procesos y libera credenciales después del trabajo

Si una herramienta produce artefactos duraderos, copia solo esos artefactos fuera del sandbox. No conserves todo el espacio de trabajo a menos que el producto necesite explícitamente la reproducción completa de la sesión.

Registros, limpieza y revisión humana

Los registros de herramientas MCP deben responder preguntas de seguridad y depuración sin convertirse en un nuevo almacén de secretos. Los registros útiles incluyen nombre de la herramienta, identidad de la persona que llama, ID del sandbox, ID del espacio de trabajo, categoría de comando, archivos leídos o escritos, dominios externos contactados, nombres de paquetes instalados, estado de salida y rutas de artefactos.

No registres indicaciones sin procesar, datos de clientes sin procesar, tokens, contenidos completos de archivos ni salidas completas de comandos por defecto. Mantén las trazas sensibles detrás de controles de acceso y políticas de retención más estrictas.

Algunas acciones de MCP deben permanecer bajo revisión humana incluso dentro de un sandbox:

• Publicar o desplegar en producción.
• Enviar correos electrónicos, chats, tickets, facturas o mensajes dirigidos al cliente.
• Modificar control de acceso, facturación, datos de usuario o configuración de infraestructura.
• Exfiltrar archivos grandes, repositorios privados, exportaciones de bases de datos o cadenas similares a credenciales.
• Ejecutar comandos fuera de la política del espacio de trabajo.
• Llamar a API internas con permisos de escritura.

El sandbox debe reducir el radio de explosión. No debe convertirse en una razón para eliminar la revisión de acciones comerciales sensibles.

Cómo encaja Novita Agent Sandbox

Novita Agent Sandbox está diseñado para cargas de trabajo de agentes que necesitan un entorno de ejecución aislado para ejecución de código, archivos, procesos, flujos de trabajo tipo navegador y sesiones de larga duración. Puede encajar en arquitecturas MCP donde un servidor de herramientas necesita un espacio de trabajo desechable en lugar de acceso directo a una computadora portátil de desarrollador, un host de producción o una máquina de IC compartida.

Úsalo como el límite de tiempo de ejecución para servidores que necesiten:

• Ejecutar código o comandos generados.
• Trabajar con archivos temporales y artefactos generados.
• Mantener el estado del espacio de trabajo por agente a través de tareas de varios pasos.
• Ejecutar trabajo en segundo plano que el agente pueda consultar más tarde.
• Separar la experimentación del agente del anfitrión de la aplicación.

Mantén claro el límite del producto: un servidor MCP sigue siendo tu código de aplicación. Tú todavía diseñas los permisos de herramientas, los ámbitos de credenciales, las políticas de red, el flujo de aprobación, el esquema de registro y el comportamiento de limpieza. El sandbox proporciona el entorno aislado donde se aplican esas decisiones.

Para la configuración específica del producto, usa la documentación actual de Novita en lugar de copiar fragmentos obsoletos de tutoriales anteriores. Conceptualizando, la forma es:

para cada tarea del agente:
  crear sandbox a partir de la plantilla aprobada
  montar solo el espacio de trabajo de la tarea
  inyectar solo secretos específicos de la herramienta
  iniciar el servidor MCP dentro del sandbox o conectar a una API de herramienta respaldada por sandbox
  enrutar las llamadas de herramientas a través de verificaciones de aprobación y políticas
  recopilar registros y artefactos aprobados
  detener, restablecer o pausar el sandbox según el ciclo de vida de la tarea

Esto mantiene la guía a nivel de artículo estable, mientras deja las llamadas exactas del SDK a la documentación más reciente y tu código de plataforma.

Lista de verificación de implementación

Usa esta lista de verificación antes de conectar un servidor MCP a un agente autónomo o semiautónomo:

Área	Preguntas a responder
Alcance de la herramienta	¿Qué herramientas expone el servidor y cuáles cambian el estado externo?
Ubicación	¿Debería ejecutarse el servidor en el sandbox del agente, un sandbox separado o fuera del sandbox detrás de una API estrecha?
Sistema de archivos	¿Qué directorios están montados, son de solo lectura o lectura y escritura, y cómo se bloquean las escapadas de ruta?
Secretos	¿Qué credenciales se inyectan, cómo están delimitadas y dónde pueden aparecer en registros o salidas?
Red	¿La salida está denegada por defecto, enrutada por proxy o permitida por dominio, registro y API interna?
Subprocesos	¿Qué comandos, gestores de paquetes, trabajos en segundo plano y oyentes están permitidos?
Estado	¿Cómo se manejan los espacios de trabajo por agente, instantáneas, tiempos de espera por inactividad, comportamiento de pausa/reanudación y limpieza?
Registros	¿Puedes reconstruir las llamadas a herramientas, cambios de archivos, dominios externos y artefactos sin almacenar secretos?
Revisión humana	¿Qué llamadas a herramientas requieren aprobación antes de la ejecución, exportación, despliegue o acción dirigida al cliente?
Pruebas	¿Has probado la inyección de indicaciones, el recorrido de enlaces simbólicos/rutas, la salida grande, la limpieza fallida y las rutas de salida denegadas?

MCP facilita la integración de herramientas. El sandboxing evita que esa integración se convierta en una expansión silenciosa de los privilegios del modelo. El diseño correcto suele ser una mezcla: algunos servidores en el mismo espacio de trabajo del agente, algunos en sandboxes separados y otros fuera del sandbox detrás de API con autorización estricta. Elige la ubicación que coincida con los datos, secretos, subprocesos y necesidades de red de la herramienta.

Preguntas frecuentes

¿Debería ejecutarse cada servidor MCP en un sandbox?

No. Prioriza los servidores que ejecutan código, leen o escriben archivos, usan secretos, llaman a servicios privados, lanzan navegadores, instalan paquetes o cambian el estado externo. Los servidores de solo lectura de menor riesgo aún pueden necesitar autenticación, registro y controles de red, pero pueden no necesitar un sandbox dedicado por solicitud.

¿Es stdio más seguro que HTTP para servidores MCP?

No automáticamente. Stdio puede ser simple para servidores locales, pero el servidor puede heredar el sistema de archivos local, el entorno y el acceso a la red. Los servidores basados en HTTP necesitan controles de autenticación y exposición más sólidos. La opción más segura depende de dónde se ejecuta el proceso y qué permisos de tiempo de ejecución recibe.

¿Pueden las raíces MCP reemplazar el sandboxing del sistema de archivos?

No. Las raíces ayudan a comunicar las ubicaciones previstas del espacio de trabajo entre el cliente y el servidor, pero no son un límite de tiempo de ejecución completo. Usa la validación de rutas y los controles del sistema de archivos a nivel de sandbox para mantener el servidor dentro del espacio de trabajo previsto.

¿Dónde deben almacenarse los secretos para herramientas MCP en sandbox?

Inyecta solo las credenciales que la herramienta necesita, idealmente como variables de entorno de corta duración o secretos de tiempo de ejecución delimitados. No montes carpetas amplias de credenciales de desarrollador ni pases secretos a través de indicaciones. Redáctalos de los registros y las respuestas de la herramienta.

¿Cuándo debe una herramienta MCP requerir aprobación humana?

Requiere aprobación para despliegues en producción, mensajes dirigidos al cliente, cambios de facturación o control de acceso, exportaciones grandes de datos, escrituras en infraestructura y cualquier comando o acción de red fuera de la política normal del espacio de trabajo.

Artículos recomendados

• Requisitos de sandbox para código generado por IA en aplicaciones de producción
• Construye un servidor MCP de ejecución remota de código con Novita Sandbox y la biblioteca mcp-use
• Construyendo un agente de codificación con Novita Agent Sandbox
• Cómo los Agent Sandboxes impulsan la innovación segura y escalable en IA