La apuesta de Sandbox

25 de enero de 2026: la apuesta

Dos meses después de comenzar a construir LikeClaw, tomamos la decisión que definiría el producto. Apostamos todo a la ejecución en sandbox E2B.

Hasta ese momento, nuestros agentes de IA realizaban tareas de una manera relativamente tradicional. Después de ese punto, cada tarea —cada ejecución de código, cada operación de archivo, cada trabajo en segundo plano— se ejecutaba dentro de un contenedor de sandbox E2B aislado.

No fue una característica de seguridad que añadimos. Fue una decisión arquitectónica fundamental que cambió la forma en que funcionaba toda la plataforma. Y fue la mejor decisión que hemos tomado.

Por qué el sandboxing importa más que cualquier otra cosa

Mira el panorama de los agentes de IA a principios de 2026. Un patrón se repite en todas partes: usuarios dando acceso irrestricto a sus máquinas a los agentes de IA.

OpenClaw se ejecuta en tu sistema local. Lee tus archivos. Ejecuta código con tus permisos. Almacena claves de API en texto plano. Los investigadores de seguridad han documentado vulnerabilidades generalizadas en la plataforma y su mercado, lo que ha llevado a advertencias de múltiples organizaciones de seguridad.

La causa raíz no es que OpenClaw esté mal escrito. Es que la arquitectura es fundamentalmente insegura. Cuando le das a un agente de IA acceso directo a tu sistema, cualquier error —por parte de la IA, de un autor de habilidad, de un ataque de inyección de prompt— tiene un radio de explosión ilimitado. Una mala habilidad puede instalar malware en tu máquina. Una inyección de prompt puede leer tus claves SSH. Un comando alucinado puede eliminar tus archivos.

El sandboxing elimina toda la categoría de riesgo.

Cómo funcionan nuestros sandboxes

Cuando ejecutas una tarea en LikeClaw, esto es lo que sucede:

Se crea un nuevo sandbox. Un contenedor E2B aislado se activa en menos de dos segundos. Tiene su propio sistema de archivos, su propio espacio de procesos, su propia red. Está completamente aislado de cualquier otro sandbox y de cualquier otro usuario.

Tus archivos de trabajo se sincronizan. Los archivos en tu espacio de trabajo se copian en el sandbox. La IA puede leerlos, modificarlos, crear nuevos. Pero solo dentro del sandbox.

La IA ejecuta la tarea. Dentro del sandbox, la IA tiene plenas capacidades. Puede ejecutar código, instalar paquetes, hacer solicitudes de red, leer y escribir archivos. Es un entorno completamente funcional. La diferencia es que “completamente funcional” significa el sandbox, no tu máquina.

Los resultados se sincronizan de vuelta. Cuando la tarea se completa, los archivos que la IA creó o modificó se sincronizan de vuelta a tu espacio de trabajo en nuestro almacenamiento encriptado.

El sandbox se destruye. Se acabó. Cada proceso eliminado. Cada archivo borrado. Cada conexión de red cerrada. Nada persiste. Nada se filtra. Nada queda.

Si la IA hace algo mal —ejecuta código malicioso, sigue una inyección de prompt, ejecuta una mala habilidad— el daño se limita a un sandbox que será destruido en segundos. Tu máquina, tus archivos, tus claves de API, tus credenciales nunca están en riesgo.

El desafío de ingeniería

El sandboxing suena simple. “Solo ejecútalo en un contenedor.” En la práctica, fue el desafío de ingeniería más complejo de todo el proyecto.

Sincronización de archivos. Los usuarios necesitan sus archivos dentro del sandbox, y necesitan la salida de la IA de vuelta en su espacio de trabajo. Esta sincronización bidireccional necesita ser rápida, confiable y manejar conflictos. Construimos una capa de sincronización VFS (Virtual File System) que observa cambios en ambas direcciones.

Ejecución de tareas en segundo plano. Las tareas programadas también se ejecutan en sandboxes. Una tarea que se ejecuta a las 3 AM necesita activar un sandbox, sincronizar archivos, ejecutar, sincronizar resultados de vuelta y limpiar —todo sin que un usuario esté en línea.

Rendimiento. La creación de sandboxes añade latencia. Optimizamos el tiempo de activación a menos de dos segundos. Los usuarios apenas lo notan. Pero llegar allí requirió una gestión cuidadosa de plantillas, inicialización perezosa y estrategias de precalentamiento.

Costo. Cada sandbox consume recursos de computación. Tuvimos que equilibrar la seguridad (siempre en sandbox) con la economía (los sandboxes cuestan dinero). La respuesta fueron límites de sandbox por nivel: los usuarios gratuitos obtienen un número fijo de ejecuciones, los usuarios pro obtienen más, los usuarios avanzados obtienen ilimitado.

La línea en la arena

Aquí está la cosa sobre la seguridad: no puedes hacerlo a medias.

No puedes sandboxear algunas tareas y no otras. No puedes sandboxear a los usuarios gratuitos pero dejar que los usuarios de pago ejecuten en crudo. No puedes sandboxear la ejecución de código pero no el acceso a archivos. Cualquier brecha en el modelo de sandbox se convierte en un vector de ataque.

Así que trazamos una línea: todo se ejecuta en un sandbox. Sin excepciones. Sin salidas de escape. Sin “modo experto” que eluda el aislamiento.

Esto significa que algunas cosas son ligeramente más lentas que ejecutarlas localmente. Esto significa que algunas cosas requieren un paso adicional (sincronizar archivos dentro y fuera). Esto significa que no podemos ofrecer el “acceso completo a la máquina” que proporcionan los agentes de IA locales.

Estamos bien con eso. Porque también no podemos ofrecer instalación de malware, robo de credenciales o compromiso del sistema. Y nuestros usuarios tampoco pueden.

0 habilidades maliciosas. 0 sistemas comprometidos. 0 incidentes de seguridad.

Esa es la apuesta del sandbox. Y está dando sus frutos.