Servidores MCP en Entornos Aislados: Compromisos entre Sistema de Archivos, Secretos y Red

Los servidores MCP deberían ejecutarse con montajes de sistema de archivos acotados, 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 entorno aislado es útil cuando un servidor MCP puede leer archivos, crear subprocesos, instalar paquetes, llamar a APIs 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 Protocolo de Contexto de Modelo (MCP) ofrece 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 cada servidor MCP en un límite de política. 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 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 de confianza 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 lo que el proceso del servidor MCP puede tocar incluso si el agente, la descripción de la herramienta o la cadena de instrucciones realiza una solicitud inapropiada.

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 se aprueban	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 acceso al anfitrión porque se ejecuta demasiado cerca de recursos de producción

El objetivo no es hacer que todos los servidores MCP no sean confiables de la misma manera. Una herramienta de consulta de 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 en 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 más probabilidades de convertir un error de indicación normal en un incidente más amplio.

Candidatos prioritarios para el aislamiento incluyen:

• Herramientas de ejecución de código que ejecutan comandos de shell, Python, Node.js, compiladores, pruebas o cuadernos.
• Herramientas del sistema de archivos que leen o escriben 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 y CI 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 o URLs 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 colocación comunes. Ninguno es universalmente correcto.

Colocació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 acotados
Sandbox separado por servidor MCP o grupo de herramientas	La herramienta necesita un aislamiento más fuerte del espacio de trabajo del agente, maneja diferentes credenciales o realiza ejecuciones de mayor riesgo	La transferencia de archivos entre sandboxes y la latencia pasan a ser parte del diseño del producto
Fuera del sandbox detrás de una API acotada	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 administrativa 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 propio espacio de trabajo 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. 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 en realidad no son “herramientas de tiempo de ejecución”. Una consulta de facturación, lectura de indicadores de funcionalidad o búsqueda en un rastreador de incidencias 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 de 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-escritura solo para las salidas.
• Separa las salidas generadas de los archivos fuente confiables.
• Evita montar carpetas de credenciales como .ssh, directorios de configuración en la nube, perfiles de navegador o archivos de autenticación del administrador 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 un servidor debe operar, 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 rutas para que las solicitudes no puedan escapar del espacio de trabajo previsto mediante 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-escritura	Archivos generados, informes, parches, gráficos o capturas de pantalla
/workspace/tmp	Lectura-escritura, desechable	Caché de compilación, caché de instalación de paquetes, archivos temporales
/workspace/secrets	Evitar montajes de archivos si es posible	Si es inevitable, montar un archivo de secreto acotado con una vida útil estricta 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, entrégale la credencial más limitada que pueda completar la acción de la herramienta.

Usa credenciales separadas para servidores MCP separados. Un servidor de búsqueda de incidencias de GitHub puede necesitar acceso de solo lectura a incidencias. 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.

Un buen manejo de secretos para servidores MCP se ve así:

• Inyecta secretos al inicio del sandbox o del proceso, no a través de indicaciones.
• Usa tokens de corta duración o revocables cuando el proveedor lo admita.
• Acota las credenciales por herramienta, inquilino, entorno y acción.
• Redacta 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 instrucciones.

Evita un antipatrón común: un archivo de entorno para todo uso montado en cada sesión de agente. Facilita el desarrollo local y 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 locales y HTTP Streamable 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 verificar 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í solo	Lista blanca, lista negra, proxy, política DNS o sin salida
¿Puede el servidor obtener paquetes o páginas web?	No es suficiente por sí solo	Listas blancas de registros, listas blancas de URL, caché y registro
¿Puede otro proceso alcanzar el servidor?	Detalles de enlace y autenticación	Firewall de entrada y límite de red del sandbox

Para servidores stdio locales, el riesgo suele ser el acceso heredado al 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 con 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 a la red y la separación entre inquilinos. Utiliza autorización del lado del servidor, TLS, comprobaciones 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 denegar por defecto es más fácil de razonar que el permitir 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 APIs internas, expón 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 requieren aprobación.
• Si los gestores de paquetes pueden acceder a Internet público.
• 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 desviación del estado. Un servidor que vive horas puede acumular archivos, credenciales, cookies de 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
ID de sandbox por agente	Evita que el estado de la herramienta de un agente se convierta en el contexto de otro agente
Tiempo de inactividad	Limpia 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
Cierre 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.

Registro, 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 el nombre de la herramienta, la identidad de la persona que llama, el ID del sandbox, el ID del espacio de trabajo, la categoría del comando, los archivos leídos o escritos, los dominios externos contactados, los nombres de paquetes instalados, el estado de salida y las rutas de artefactos.

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

Algunas acciones de MCP deben permanecer revisadas por humanos incluso dentro de un sandbox:

• Publicar o desplegar en producción.
• Enviar correos electrónicos, chats, tickets, facturas o mensajes dirigidos al cliente.
• Modificar el control de acceso, la facturación, los datos del usuario o la 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 APIs 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 un portátil de desarrollador, un host de producción o una máquina CI compartida.

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

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

Mantén el límite del producto claro: un servidor MCP sigue siendo tu código de aplicación. Tú aún diseñas los permisos de las herramientas, los alcances de las credenciales, la política 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 desactualizados de tutoriales antiguos. Conceptualment.e, la forma es:

para cada tarea de agente:
  crear sandbox a partir de 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 herramientas respaldada por sandbox
  enrutar llamadas de herramientas a través de comprobaciones de aprobación y políticas
  recopilar registros y artefactos aprobados
  detener, reiniciar 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 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?
Colocació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-escritura, y cómo se bloquean las fugas de ruta?
Secretos	¿Qué credenciales se inyectan, cómo se acotan y dónde pueden aparecer en registros o salidas?
Red	¿La salida es denegar por defecto, enrutada por proxy, o en lista blanca 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, las instantáneas, los tiempos de inactividad, el comportamiento de pausa/reanudación y la limpieza?
Registros	¿Puedes reconstruir 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 instrucciones, 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 sandbox evita que esa integración se convierta en una expansión silenciosa de los privilegios del modelo. El diseño correcto suele ser una combinación: algunos servidores en el mismo espacio de trabajo del agente, otros en sandboxes separados y otros fuera del sandbox detrás de APIs con autorización estricta. Elige la colocación que coincida con los datos, secretos, subprocesos y necesidades de red de la herramienta.

Preguntas frecuentes

¿Debería cada servidor MCP ejecutarse 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 ejecute el proceso y qué permisos de tiempo de ejecución reciba.

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

No. Las raíces ayudan a comunicar las ubicaciones de espacio de trabajo previstas entre cliente y servidor, pero no son un límite de tiempo de ejecución completo. Utiliza 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 acotados. 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 las herramientas.

¿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, grandes exportaciones 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

• Build a Remote Code Execution MCP Server with Novita Sandbox and mcp-use Library
• Building a Coding Agent with Novita’s Agent Sandbox
• How Agent Sandboxes Power Secure, Scalable AI Innovation