Sandboxing manual sin software adicional en entornos reales

Cuando trabajas con software, agentes de IA o archivos descargados de internet, uno de los miedos más habituales es romper algo en tu sistema, infectarte con malware o filtrar datos sensibles casi sin darte cuenta. No hace falta ser paranoico: basta con que una ejecución salga mal para borrar una base de datos, fastidiar un despliegue o meter un bicho en tu equipo.

La buena noticia es que hoy tienes a tu alcance varias formas de crear un entorno aislado donde probar cosas sin jugártela, y muchas de ellas vienen integradas en el propio sistema operativo o en plataformas pensadas para agentes de código. A eso lo llamamos «sandboxing»: ejecutar código dentro de una especie de burbuja controlada, de forma que, aunque algo falle o sea malicioso, el daño quede contenido.

¿Qué es el sandboxing manual sin software adicional?

En seguridad y desarrollo, hablar de sandbox es hablar de acotar muy bien qué puede tocar un programa o un agente mientras se ejecuta. No es sólo “correrlo en otro sitio”, sino definir fronteras claras: qué ficheros puede ver, qué procesos puede lanzar, si tiene red, qué credenciales puede usar, cuánto tiempo vive ese entorno y qué pasa con su estado cuando termina.

El matiz de «manual» y «sin software adicional» tiene truco. En muchos casos puedes apoyarte en funciones ya incluidas en tu sistema operativo o en tu propia plataforma de desarrollo, como Windows Sandbox, primitivas de Linux (Landlock, seccomp) o mecanismos de macOS. No necesitas instalar una suite de virtualización completa, pero sí aprender a activar y manejar esos mecanismos integrados para que hagan de barrera entre el código que quieres probar y tu máquina real.

¿Por qué los agentes de código necesitan entornos aislados?

Los agentes de codificación modernos ya no son simples asistentes tipo chat que sugieren fragmentos de código: son entornos de ejecución acoplados a un modelo de lenguaje. Pueden leer tu repositorio, editar archivos, ejecutar comandos de terminal, instalar paquetes, construir contenedores, hablar con APIs externas e incluso abrir sesiones de navegador.

Plataformas como Claude Code, algunos «Deep Agents» de LangChain o sandboxes específicos distribuidos por Docker y otras herramientas describen explícitamente que estos agentes operan sobre sistemas de archivos reales, lanzan subprocesos y delegan tareas a subagentes especializados. Es decir, se parecen bastante a un desarrollador junior con acceso a tus herramientas… sólo que automático y muy rápido.

En ese contexto, la principal pregunta de seguridad deja de ser «¿responde bien al prompt?» y pasa a ser: «¿qué alcance tiene cuando se equivoca, está desalineado o ha sido manipulado?». Si un modelo puede, por ejemplo, ejecutar pytest, instalar paquetes npm, gestionar ramas o inspeccionar un fallo de compilación, está a pocos pasos de tocar scripts de despliegue, modificar hooks de Git o exfiltrar secretos a un servicio remoto.

La respuesta fácil suele ser exigir aprobaciones humanas para cada comando. Eso ayuda, pero tiene un problema recurrente: la fatiga de aprobación. En entornos donde los ingenieros lanzan muchos agentes o flujos en paralelo, el volumen de solicitudes hace que se acabe aprobando casi todo sin leer con atención. Cuando más del 90% de peticiones de permiso se aceptan automáticamente, ese mecanismo deja de ser un verdadero control de seguridad y se convierte en pura ceremonia.

Principales límites de un sandbox de agente de código

Un sandbox serio para agentes de codificación se basa en varios tipos de fronteras, no sólo en «otro directorio» o «otro contenedor». Cada una cubre un ángulo distinto del riesgo y conviene entenderlas si quieres hacer un sandboxing manual eficaz con lo que ya tienes.

Límite del sistema de archivos

Lo primero es decidir qué árbol de directorios puede ver y modificar el agente. En un sandbox bien montado, el agente sólo debería poder leer y escribir en el workspace o los volúmenes que le montes explícitamente. El resto del sistema (home del usuario, rutas de sistema, otros proyectos) debe quedar fuera de su alcance.

Frameworks de agentes y plataformas de sandbox lo dejan muy claro: el sandbox es la barrera que evita tocar archivos del host más allá de lo compartido. En modelos basados en microVM, la regla es aún más estricta: únicamente el directorio que montas (a menudo en lectura-escritura) cruza la frontera entre la máquina virtual y el host. Todo lo demás permanece inaccesible, salvo que lo abras tú.

Límite de proceso y kernel

El segundo límite clave es qué ve el agente a nivel de procesos y del núcleo del sistema. Si dentro del entorno aislado instala servicios, levanta contenedores o lanza subprocesos, todas esas acciones deben permanecer encapsuladas, sin compartir procesos ni un kernel desnudo con el host.

Muchas implementaciones robustas de sandbox se apoyan en microVMs o máquinas virtuales ligeras con su propio kernel Linux, reforzadas con seccomp, cgroups, namespaces y técnicas de jail. Otras usan capas como gVisor o Kata Containers para interponer una capa de virtualización o emulación entre el proceso aislado y el kernel del nodo. La idea básica: si alguien explota algo dentro, el salto al host sea mucho más difícil que en un simple contenedor de núcleo compartido.

Límite de red

Los agentes de código suelen ser muy «hambrientos» de red: quieren instalar dependencias, consultar documentación, llamar a APIs de LLM, acceder a repositorios remotos o incluso navegar por la web. Sin una política clara, un entorno «aislado» puede terminar siendo un fantástico túnel de exfiltración de datos.

Por eso cada vez más plataformas aplican una postura de denegación por defecto del tráfico saliente: HTTP/HTTPS bloqueados salvo excepciones, TCP/UDP/ICMP restringidos y, muy importante, acceso prohibido a rangos privados y direcciones locales. Sólo se permite la comunicación con hosts o dominios incluidos explícitamente en una lista de permitidos, y a menudo mediante un proxy controlado por el host.

Límite de credenciales

De poco sirve que el agente esté encerrado si, dentro de su jaula, puede leer tus claves de API, tokens de despliegue o secretos de base de datos. El diseño moderno de muchos sandboxes consiste en no inyectar nunca los secretos en bruto dentro del entorno aislado, sino hacer que un proxy en el host añada las credenciales en las cabeceras de las peticiones HTTP que el sandbox quiere lanzar.

Con este enfoque, el proceso dentro del sandbox usa las credenciales pero nunca las ve. Eso reduce mucho el impacto de un posible secuestro del agente. Ahora bien, en el momento en que guardas una clave en un archivo o variable de entorno dentro del sandbox, esa ventaja desaparece: el modelo pasa a poder leerla directamente, y cualquier inyección de instrucciones puede ordenarle que la filtre.

Límite de ciclo de vida y estado

Por último, está el límite temporal: qué se conserva y qué se destruye cuando el entorno se detiene. Los agentes no son procesos puntuales: leen, compilan, depuran, abren varias hipótesis, abandonan unas, retoman otras… Eso exige un runtime que gestione el estado de forma inteligente: inicio rápido, suspensión, instantáneas, ramificación y eliminación segura.

Algunas plataformas ofrecen instantáneas en memoria, pools de entornos precalentados y funciones de bifurcación desde un estado concreto (por ejemplo, un navegador ya autenticado o un grafo de dependencias parcialmente resuelto). Eso marca la diferencia entre un agente usable —que puede iterar de forma interactiva— y un agente que tarda siglos en repetir el mismo setup una y otra vez.

Implementaciones de sandboxing en macOS, Linux y Windows

Más allá de los productos comerciales, muchos equipos han optado por aprovechar primitivas de aislamiento ya presentes en los sistemas operativos para construir sus propios sandboxes para agentes de código, sin necesidad de añadir capas más pesadas. La clave está en entender qué aporta cada plataforma.

Sandboxing en macOS: Seatbelt y perfiles dinámicos

En macOS se han evaluado distintos modelos: App Sandbox, contenedores, máquinas virtuales y Seatbelt. Las primeras opciones tienen pegas importantes para un entorno de desarrollo: App Sandbox exige firmar cada binario que el agente podría ejecutar y hereda la confianza de la firma, lo que abre vectores de abuso si el propio agente genera o modifica binarios; los contenedores se limitan al ecosistema Linux; las VMs tradicionales añaden mucha latencia de arranque y consumo de memoria.

La alternativa práctica ha sido apoyarse en Seatbelt, accesible mediante sandbox-exec. Aunque Apple lo marca como obsoleto desde hace años, sigue siendo usado por aplicaciones críticas como Chrome. Permite ejecutar comandos bajo un perfil de sandbox que restringe el comportamiento de todo el árbol de procesos descendientes.

Ese perfil define permisos con gran granularidad: puede filtrar syscalls específicas y lecturas o escrituras sobre archivos y directorios concretos, usando un lenguaje de políticas peculiar. Hay implementaciones que generan esa política dinámicamente en tiempo de ejecución, combinando la configuración del workspace, políticas de administradores y archivos de ignore del usuario, para que el agente tenga margen de acción sin llegar a tocar zonas peligrosas.

Sandboxing en Linux: Landlock y seccomp

Linux ofrece, al mismo tiempo, más flexibilidad y más trabajo: el kernel expone primitivas como Landlock y seccomp, pero es responsabilidad del espacio de usuario combinarlas en un sandbox coherente y manejable.

En lugar de depender únicamente de proyectos externos, algunos equipos optan por usar directamente seccomp para bloquear llamadas al sistema consideradas peligrosas y Landlock para delimitar el acceso al sistema de archivos. Un patrón común consiste en montar el workspace del usuario sobre un filesystem overlay y reemplazar los archivos marcados como ignorados por copias especiales protegidas con Landlock, de modo que el proceso aislado no pueda leer ni modificar nada de lo que quieras ocultar realmente.

La parte más lenta de este enfoque suele ser localizar y volver a montar todos esos archivos, ya que Linux no ofrece una forma sencilla de conocer la ruta completa de un archivo dentro de un filtro seccomp-bpf. Aun así, el resultado es un sandbox bastante fino: el agente puede trabajar con su árbol de proyecto mientras que las rutas prohibidas quedan, de facto, fuera de su universo.

Sandboxing en Windows: apoyarse en WSL2

En Windows la historia es diferente. Crear un sandbox nativo de propósito general es mucho más complicado porque gran parte de las primitivas de aislamiento existentes están pensadas para navegadores u otro software muy específico, y no encajan bien con herramientas de desarrollo versátiles.

Una solución práctica es ejecutar un sandbox de Linux dentro de WSL2. De este modo, reciclas el arsenal de aislamiento de Linux (Landlock, seccomp, namespaces, etc.) sobre una base de virtualización que aísla la sesión de desarrollo del host Windows. En paralelo, hay trabajos coordinados con Microsoft para exponer nuevas primitivas que permitan, a la larga, un sandboxing más nativo para herramientas de desarrollo.

Windows Sandbox: un espacio aislado integrado en el sistema

Para quienes usan Windows 10 u 11 en ediciones Pro, Enterprise o Education, existe una herramienta especialmente interesante: Espacio aislado de Windows (Windows Sandbox). Es una máquina virtual ligera integrada en el propio sistema que te permite ejecutar aplicaciones no confiables o archivos sospechosos en un entorno desechable.

La idea es simple: al abrir Windows Sandbox se inicia un escritorio Windows temporal, limpio, como recién instalado. Todo lo que copies o instales dentro —programas, documentos, scripts— sólo existe en esa instancia. Si cierras la ventana, el entorno se destruye: se descartan software, archivos y estado, y la próxima vez arrancarás desde cero.

Características clave de Windows Sandbox

Esta función viene con varias propiedades muy útiles para hacer sandboxing manual sin depender de herramientas de terceros:

Parte de Windows: todo lo necesario ya está incluido en las ediciones compatibles (Pro, Enterprise, Education). No tienes que descargar imágenes ni mantener máquinas virtuales externas.
Desechable y prístino: cada ejecución es tan limpia como una instalación nueva de Windows. Nada de lo que hagas dentro se guarda en tu dispositivo una vez cierras el entorno.
Seguro por diseño: se basa en la virtualización soportada por hardware (Hyper-V) para aislar el kernel de la sandbox del kernel del host. Usa el hipervisor de Microsoft para que ambos mundos queden separados.
Eficiente: el arranque es rápido, en cuestión de segundos, con gestión inteligente de memoria y soporte de GPU virtual, ocupando menos recursos que una VM tradicional.

Técnicamente, se comporta como una pequeña máquina virtual Windows desechable, perfectamente válida para probar instaladores, visitar webs dudosas o abrir adjuntos de correo que no te fías de ejecutar en tu sistema real.

Escenarios prácticos de uso de Windows Sandbox

Hay varios escenarios típicos donde Windows Sandbox brilla como solución sencilla de sandboxing manual:

Probar software desconocido: cuando descargas una aplicación o ejecutable de internet y no estás seguro de su procedencia, puedes instalarlo primero dentro de Windows Sandbox y ver su comportamiento sin riesgo para tu equipo.
Navegación web más segura: para visitar webs potencialmente peligrosas, de malware o phishing, puedes abrir el navegador dentro del espacio aislado. Si algo va mal, con cerrar la ventana, desaparece cualquier rastro.
Abrir adjuntos y archivos no confiables: si recibes un adjunto sospechoso o un ZIP que no te inspira confianza, lo copias al sandbox, lo abres allí y, una vez revisado, decides si merece la pena extraer algo a tu sistema real.
Demostraciones y pruebas puntuales de herramientas: es perfecto para hacer demos de software, probar versiones preliminares, extensiones o complementos sin ensuciar tu instalación principal.
Mantener varios entornos de desarrollo separados: puedes crear espacios aislados diferenciados para cada stack o versión de lenguaje, por ejemplo un sandbox para cada versión de Python y sus dependencias, de manera que los experimentos no se mezclen con tu entorno estable.

Requisitos y licencias para usar Windows Sandbox

No todo el mundo puede usar Windows Sandbox, pero en bastantes entornos profesionales ya está al alcance. Para habilitarlo en tu equipo necesitas:

Edición de Windows compatible: Windows 10/11 Pro, Enterprise, Pro Education/SE o Education. La edición Home queda fuera.
Soporte de virtualización: es imprescindible tener activadas las funciones de virtualización en la BIOS/UEFI (Intel VT-x, AMD-V o equivalentes).
Recursos mínimos: al menos 4 GB de RAM (aunque se recomiendan 8 GB), 1 GB de espacio libre en disco —preferiblemente SSD— y un mínimo de 2 núcleos de CPU (idealmente 4 con hyperthreading).
Sistema operativo actualizado: a partir de ciertas compilaciones (por ejemplo, Windows 10 build 18305 y posteriores, y builds modernos de Windows 11). En ARM64 la compatibilidad llegó con builds más recientes.

En cuanto a licencias, las ediciones Pro, Enterprise y Education incluyen el derecho de uso de Windows Sandbox sin necesidad de pagar licencias adicionales por software de virtualización. Simplemente actívalo y listo.

Cuándo optimizar empeora la experiencia de tu ordenador y cómo evitarlo

Cómo activar Windows Sandbox sin herramientas extra

Para ponerlo en marcha no necesitas nada fuera del propio sistema:

Abre el menú Inicio y busca la opción «Activar o desactivar las características de Windows».
En la lista de características, marca Windows Sandbox (Espacio aislado de Windows) y confirma.
Reinicia el equipo cuando te lo pida.
Tras el reinicio, busca «Windows Sandbox» en el menú Inicio y ejecútalo.

Si prefieres una vía más técnica, también puedes habilitarlo con PowerShell usando el comando Enable-WindowsOptionalFeature -FeatureName «Containers-DisposableClientVM» -All -Online, siempre que tengas permisos de administrador. Una vez activado, el espacio aislado estará siempre disponible para cuando necesites esa «segunda máquina» segura.

Archivos de configuración y personalización

Windows Sandbox admite archivos de configuración sencillos que permiten personalizar ciertos parámetros del entorno: por ejemplo, montar carpetas del host en lectura o lectura-escritura, desactivar la red, ejecutar scripts al inicio, etc. Estos archivos están disponibles a partir de unas compilaciones concretas de Windows 10 y 11.

En la práctica, esta capacidad te ayuda a crear «recetas» de sandbox: una configuración con red deshabilitada para abrir malware, otra con una carpeta de proyectos montada en sólo lectura para revisar archivos, o una configuración orientada a pruebas de software con determinadas herramientas preinstaladas en la imagen base.

Cómo enseñar a los agentes de IA a usar el sandbox correctamente

Un sandbox sólo es realmente eficaz si el propio agente de código entiende en qué entorno se está moviendo y sabe cuándo puede operar libremente y cuándo tiene que pedir más permisos o asistencia humana.

Para lograrlo, muchas plataformas han tenido que retocar a fondo la infraestructura que describe las herramientas al modelo. Por ejemplo, actualizando las descripciones de la herramienta de shell para explicar claramente:

Qué restricciones impone el sandbox (acceso al sistema de archivos, git, red).
Cómo puede el agente solicitar una elevación de permisos cuando algo falla por falta de privilegios.
Qué tipos de comandos tienen más probabilidad de estar bloqueados.

Estos cambios no salen perfectos a la primera: suele requerir mucha prueba manual de flujos de despliegue reales, analizando dónde se rompen las expectativas del modelo y ajustando prompts e instrucciones. Al medir en benchmarks internos el comportamiento con y sin sandbox, se identifican patrones de fallo, como agentes que repiten en bucle el mismo comando que el sandbox bloquea en lugar de entender que debe pedir otros permisos o modificar su estrategia.

Una mejora práctica es mostrar en los resultados de la herramienta la razón específica del bloqueo impuesto por el sandbox e incluso sugerir explícitamente al agente que solicite permisos elevados cuando corresponda. Esta pequeña pista reduce drásticamente los reintentos ciegos y mejora la recuperación ante errores relacionados con el aislamiento, tanto en pruebas offline como en producción.

Para afianzar que el sandbox no degrada la experiencia de usuario, muchas compañías han optado por desplegarlo de forma gradual, recogiendo feedback interno y externo antes de activarlo por defecto. Los datos suelen ser claros: una fracción significativa de las solicitudes (por ejemplo, en torno a un tercio) termina ejecutándose dentro de sandbox en plataformas compatibles, con reducciones notables tanto en paradas para pedir aprobación como en tiempo de revisión manual.

Modelos de aislamiento y lecciones de seguridad del mundo real

En la práctica, no existe un único «sandbox perfecto». Hay diferencias importantes entre un contenedor de núcleo compartido, un sandbox tipo gVisor, una microVM y una VM completa. Ese matiz importa cuando hablamos de permitir al agente ejecutar Docker, instalar paquetes arbitrarios o incluso lanzar navegadores y subprocesos complejos.

Los incidentes de seguridad históricos subrayan la importancia de elegir bien: vulnerabilidades como CVE-2019-5736 o CVE-2024-21626, que permitían saltar del contenedor al host o manipular binarios del sistema, demuestran que cuando tu límite de confianza es un runtime de contenedores sobre el kernel del host, un bug severo puede derribar toda la barrera.

Esto se vuelve más delicado con agentes de codificación porque suelen ejecutar código de compilación no confiable, construir imágenes, instalar dependencias sin auditar y en general manipular inputs muy heterogéneos. Además, la presión para «darles más poderes» es fuerte: si no pueden ejecutar ciertas herramientas, a menudo no consiguen completar sus tareas.

Por eso muchos diseños modernos de sandbox para agentes tienden a reforzar el límite usando microVMs o VMs ligeras, aun a costa de algo más de complejidad. Se reduce la dependencia directa del kernel del host y se gana una capa de aislamiento adicional frente a escapes de contenedor. En entornos de multi-tenant o ejecución de código no confiable a gran escala, gVisor o Kata Container se sitúan en un punto intermedio, intercambiando compatibilidad por mayor separación.

Aprobaciones humanas, políticas y sandbox: cómo encajarlo todo

Un patrón que se repite en todas partes es que las solicitudes de permiso perennes no escalan bien. En modo demo, está bien que el agente pida permiso antes de tocar un archivo. En producción, con flujos semiautónomos y muchas acciones pequeñas, el modelo «clic en Aceptar para todo» acaba siendo un coladero.

El enfoque más maduro combina varias capas:

Sandbox fuerte para proteger al host y delimitar el entorno de ejecución.
Política de red restrictiva para controlar a qué endpoints puede hablar el agente.
Gestión de credenciales vía proxy, de forma que el modelo las use sin verlas.
Configuraciones versionadas a nivel de proyecto (permisos, hooks, servidores externos) para que los equipos tengan una única fuente de verdad en el repositorio.
Subagentes de sólo lectura para exploración y planificación, dejando las acciones de escritura a instancias más controladas.
Aprobación humana reservada a acciones realmente delicadas: publicación de paquetes, cambios de infraestructura, rotación de secretos o push a ramas críticas.

Además, conviene pensar en la superficie de control que das al agente con tus propios archivos de configuración, plugins y «skills». Guías de proveedores como OpenAI avisan claramente de que exponer catálogos abiertos de capacidades o permitir que cualquiera defina instrucciones potentes dentro del repositorio puede derivar en fugas de datos o acciones destructivas si un atacante logra inyectar instrucciones maliciosas en README, issues, documentación o ficheros de ejemplo.

En un diseño sano, el sandbox no se ve como un truco mágico que arregla la seguridad de un plumazo, sino como una frontera más dentro de una arquitectura que incluye políticas, verificación independiente, gestión cuidadosa de secretos y revisiones de configuración. Así, incluso asumiendo que algún día el agente lea instrucciones maliciosas y las obedezca, el sistema está pensado para que el impacto quede acotado: sin acceso directo a claves, sin red abierta y sin capacidad de modificar a traición scripts que luego ejecutas en tu máquina real.