El sandboxing para agentes de IA se volvió 100 veces más rápido con la nueva apuesta de Cloudflare
La Inteligencia Artificial llegó a un punto donde los agentes no solo piensan, sino que también escriben y ejecutan código en tiempo real. Eso lo cambia todo, pero trae una pregunta que nadie puede ignorar: ¿dónde se ejecuta ese código de forma segura?
La respuesta más común hoy son los containers, pero tienen un problema serio de rendimiento y costo que empieza a molestar cuando la escala aumenta. Cientos de milisegundos para inicializar y cientos de megabytes de memoria para funcionar terminan creando un cuello de botella real en ambientes de producción que manejan múltiples agentes simultáneamente.
Cloudflare entró en esta conversación con una solución que va mucho más allá de lo que el mercado estaba acostumbrado a ver, y el resultado es impresionante: un entorno de sandboxing que puede ser hasta 100 veces más rápido que los enfoques tradicionales basados en containers. 🚀
En este artículo vas a entender cómo funciona el Dynamic Worker Loader, por qué TypeScript se convirtió en el lenguaje favorito de los agentes de IA para este tipo de tarea, qué bibliotecas auxiliares acompañan el ecosistema, cómo empresas ya están usando esta tecnología y qué significa todo esto en la práctica para quienes están construyendo productos con código generado por IA hoy.
El problema que nadie quería admitir
Durante mucho tiempo, la industria tecnológica trató la ejecución de código generado por Inteligencia Artificial como un detalle de implementación, algo que vendría después, cuando el modelo fuera lo suficientemente bueno. Lo que pasó fue lo contrario: los modelos se volvieron muy buenos muy rápido, y la infraestructura para ejecutar ese código con seguridad se quedó atrás. Hoy, cualquier agente de IA mínimamente capaz puede escribir un script funcional en segundos, pero poner ese script a correr en producción sin crear un riesgo de seguridad sigue siendo un desafío real para la mayoría de las empresas.
Simplemente usar un eval() en el código generado por la IA directamente en la aplicación está fuera de discusión. Un usuario malintencionado podría fácilmente inducir al modelo a inyectar vulnerabilidades en el código. Por eso el concepto de sandbox es tan central: un lugar aislado para ejecutar código, completamente separado de la aplicación principal y del resto del mundo, excepto por las capacidades específicas que el código necesita acceder.
Los containers Docker surgieron como la respuesta estándar para este problema, y por buenas razones: aíslan el entorno, controlan los recursos y ofrecen una capa de seguridad razonable. El problema es que los containers necesitan tiempo para inicializar, consumen memoria considerable incluso cuando están ociosos, y cuando estás manejando decenas o cientos de ejecuciones simultáneas de código generado por IA, el costo operativo escala de forma alarmante. La propia Cloudflare reconoce este escenario al ofrecer su container runtime y su Sandbox SDK, pero también señala que, para agentes a escala de consumidor, donde cada usuario final puede tener uno o varios agentes y cada agente escribe código, los containers simplemente no son suficientes.
Existe también una cuestión más sutil que suele pasar desapercibida: la latencia percibida por el usuario final. Cuando un agente de IA termina de generar un fragmento de código y el sistema necesita esperar algunos segundos para inicializar un container antes de ejecutarlo, esa espera rompe completamente la sensación de fluidez que hace que la experiencia con IA sea tan poderosa. El usuario pierde el contexto, la confianza en el producto disminuye, y la propuesta de valor de la herramienta empieza a cuestionarse. Resolver el sandboxing no es solo una cuestión técnica, es una cuestión de experiencia de producto.
De dónde salió el Dynamic Worker Loader
La historia empieza allá por septiembre del año pasado, cuando Cloudflare presentó el concepto de Code Mode: la idea de que los agentes de IA deberían realizar tareas no haciendo llamadas de herramientas individuales, sino escribiendo código que llama APIs directamente. La empresa demostró que simplemente convertir un servidor MCP en una API TypeScript lograba reducir el uso de tokens en un 81%. Además, mostraron que el Code Mode podía operar tanto delante como detrás de un servidor MCP, resultando en el nuevo servidor MCP de Cloudflare que expone toda la API de la empresa con apenas dos herramientas y menos de 1.000 tokens.
Escondida en ese mismo anuncio de septiembre había una funcionalidad experimental: el Dynamic Worker Loader API. Esta API permite que un Cloudflare Worker instancie un nuevo Worker, en su propio sandbox, con código especificado en tiempo de ejecución, todo dinámicamente. Ahora, esta funcionalidad salió del estatus experimental y entró en beta abierto, disponible para todos los usuarios de pago de Workers.
Cómo el Dynamic Worker Loader cambia las reglas del juego
El Dynamic Worker Loader es la tecnología central detrás de la solución de sandboxing presentada por Cloudflare, y funciona de una forma bastante diferente a lo que estamos acostumbrados a ver. En vez de inicializar un container completo para cada ejecución, el sistema utiliza Workers aislados que se cargan dinámicamente, aprovechando la infraestructura distribuida de la red de Cloudflare para crear entornos de ejecución extremadamente ligeros y rápidos. Cada Worker corre en su propio contexto aislado, sin compartir memoria ni estado con otros Workers, lo que garantiza el nivel de aislamiento necesario para la ejecución segura de código generado por Inteligencia Artificial.
La magia técnica aquí está en el mecanismo de aislamiento utilizado. Mientras los containers tradicionales dependen de virtualización a nivel de sistema operativo, el modelo de los Dynamic Workers usa isolates, que son instancias del motor de ejecución JavaScript V8 de Google, el mismo que corre en Chrome. Este es el mismo mecanismo que sostiene toda la plataforma Cloudflare Workers desde su lanzamiento, hace ocho años. Cada isolate es esencialmente un contexto V8 separado, con su propio heap de memoria y sin acceso al entorno externo, a menos que esto sea explícitamente permitido.
Reciba el mejor contenido sobre innovación en su correo electrónico.
Todas las noticias, consejos, tendencias y recursos que buscas, directamente en tu bandeja de entrada.
Al suscribirte al boletín informativo, aceptas recibir comunicaciones de Método Viral. Nos comprometemos a proteger y respetar siempre tu privacidad.
Los números son impresionantes: un isolate tarda apenas unos milisegundos en arrancar y usa solo unos pocos megabytes de memoria. Esto representa cerca de 100 veces más velocidad y entre 10 y 100 veces más eficiencia de memoria que un container típico. En la práctica, esto significa que es perfectamente viable crear un nuevo isolate para cada solicitud de usuario bajo demanda, ejecutar un único fragmento de código y descartarlo después, sin preocuparse por costo ni rendimiento.
El flujo práctico funciona así: el agente de IA genera el código, generalmente en TypeScript o JavaScript, ese código se envía al sistema de sandboxing, el Dynamic Worker Loader crea un contexto aislado en milisegundos, ejecuta el código dentro de ese contexto con los permisos y límites de recursos definidos previamente, retorna el resultado y descarta el Worker. Todo este ciclo puede ocurrir en decenas de milisegundos, comparado con varios segundos en el modelo basado en containers. Para productos que dependen de ejecución de código en tiempo real, esta diferencia es transformadora. 🔥
Escalabilidad sin límites artificiales
Muchos proveedores de sandbox basados en containers imponen límites globales de sandboxes simultáneos y de tasa de creación de sandboxes. El Dynamic Worker Loader no tiene esos límites. No los necesita, porque es simplemente una API para la misma tecnología que siempre sostuvo la plataforma de Cloudflare, que siempre permitió que los Workers escalaran de forma transparente a millones de solicitudes por segundo.
¿Quieres procesar un millón de solicitudes por segundo donde cada solicitud individual carga un sandbox Dynamic Worker separado, todos corriendo simultáneamente? Sin problema.
Latencia cero en la comunicación
Los Dynamic Workers de uso único generalmente corren en la misma máquina, e incluso en el mismo hilo, del Worker que los creó. No hay necesidad de comunicarse a través del mundo para encontrar un sandbox precalentado. Los isolates son tan ligeros que pueden simplemente correr donde llegó la solicitud. Los Dynamic Workers están soportados en cada una de las cientos de ubicaciones de Cloudflare alrededor del mundo.
Por qué TypeScript se convirtió en la lengua franca de los agentes de IA
Si sigues el ecosistema de desarrollo en los últimos años, probablemente ya notaste que TypeScript fue gradualmente tomando el espacio que JavaScript ocupaba como lenguaje estándar para desarrollo web. Lo que tal vez no sea tan obvio es que este movimiento también se refleja de forma muy clara en el comportamiento de los agentes de Inteligencia Artificial cuando el tema es generación de código.
Cloudflare es bastante directa al respecto: técnicamente, los Workers, incluyendo los dinámicos, soportan Python y WebAssembly, pero para pequeños fragmentos de código generados bajo demanda por un agente, JavaScript y TypeScript cargan y se ejecutan mucho más rápido. Y mientras nosotros los humanos tenemos preferencias fuertes sobre lenguajes de programación, los agentes de IA no las tienen. Los LLMs son especialistas en todos los lenguajes principales, y sus datos de entrenamiento en JavaScript son inmensos. Además, JavaScript, por su naturaleza en la web, fue diseñado para ejecutarse en sandbox. Es el lenguaje correcto para el trabajo.
La razón de la preferencia por TypeScript específicamente es más técnica de lo que parece. El sistema de tipos de TypeScript ofrece una capa de verificación estática que permite que tanto humanos como sistemas automatizados validen la corrección de un fragmento de código antes incluso de ejecutarlo. Cuando un agente de IA genera código en Python o JavaScript puro, los errores de tipo solo aparecen en tiempo de ejecución, lo que significa que el sandboxing necesita manejar fallos inesperados de forma reactiva. Con TypeScript, una parte significativa de estos problemas puede detectarse antes de que el código llegue al entorno de ejecución aislado.
TypeScript consume menos tokens que OpenAPI
Si queremos que nuestro agente haga algo útil, necesita comunicarse con APIs externas. La cuestión es: ¿cómo le informamos al agente sobre las APIs a las que puede acceder? MCP define schemas para llamadas de herramientas simples, pero no para APIs de programación. OpenAPI ofrece una forma de expresar APIs REST, pero es verboso tanto en el schema como en el código necesario para llamarlo.
Para APIs expuestas a JavaScript, la respuesta es una sola: TypeScript. Una interfaz TypeScript describiendo una API de sala de chat, por ejemplo, puede expresarse de forma concisa en pocas líneas, mientras que la especificación OpenAPI equivalente es tan larga que necesitas hacer scroll para verla completa. Menos tokens significan menos costo de inferencia y mejor comprensión por parte del modelo, tanto para agentes como para humanos.
El Dynamic Worker Loader facilita la implementación de una API TypeScript en tu propio Worker y pasarla al Dynamic Worker como parámetro de método o en el objeto env. El runtime de los Workers configura automáticamente un puente RPC entre el sandbox y el código anfitrión, para que el agente pueda invocar tu API a través de la frontera de seguridad sin siquiera darse cuenta de que no está usando una biblioteca local.
Filtrado HTTP e inyección de credenciales
Para quienes prefieren proporcionar APIs HTTP a los agentes, el soporte es completo. Usando la opción globalOutbound de la API del worker loader, es posible registrar un callback que será invocado en cada solicitud HTTP. En ese callback, puedes inspeccionar la solicitud, reescribirla, inyectar claves de autenticación, responder directamente, bloquear o hacer cualquier otra cosa necesaria.
Esto permite implementar inyección de credenciales: cuando el agente hace una solicitud HTTP a un servicio que requiere autorización, las credenciales se agregan automáticamente en la salida. De esta forma, el agente nunca conoce las credenciales secretas y, por lo tanto, no puede filtrarlas. Aun así, Cloudflare refuerza que, en ausencia de un requisito de compatibilidad, las interfaces RPC en TypeScript son superiores a HTTP por requerir menos tokens, ser más fáciles de restringir y más simples de proteger.
Seguridad probada en batalla
Proteger un sandbox basado en isolates no es trivial. Aunque todos los mecanismos de sandboxing tienen bugs, las fallas de seguridad en V8 son más comunes que en hypervisors típicos. Cuando se usan isolates para hacer sandbox de código potencialmente malicioso, capas adicionales de defensa en profundidad son fundamentales.
Cloudflare tiene casi una década de experiencia protegiendo su plataforma basada en isolates. Los sistemas de la empresa aplican parches de seguridad de V8 en producción en cuestión de horas, más rápido que el propio Chrome. La arquitectura de seguridad incluye un sandbox de segunda capa personalizado con aislamiento dinámico de tenants basado en evaluaciones de riesgo. La empresa extendió el propio sandbox de V8 para aprovechar recursos de hardware como MPK, colaboró con investigadores para desarrollar defensas innovadoras contra Spectre y cuenta con sistemas que escanean código en busca de patrones maliciosos, bloqueándolos automáticamente o aplicando capas adicionales de sandboxing.
Cuando usas Dynamic Workers en Cloudflare, toda esta infraestructura de seguridad viene incluida. 🛡️
Bibliotecas auxiliares que facilitan la vida
Cloudflare construyó un conjunto de bibliotecas para facilitar el trabajo con Dynamic Workers, y vale la pena conocer cada una de ellas.
Code Mode SDK
El paquete @cloudflare/codemode simplifica la ejecución de código generado por modelos de IA contra herramientas usando Dynamic Workers. En el centro está el DynamicWorkerExecutor(), que construye un sandbox a medida con normalización de código para manejar errores de formato comunes y acceso directo a un fetcher globalOutbound para controlar el comportamiento de fetch dentro del sandbox.
El SDK también proporciona dos funciones utilitarias del lado del servidor: una que envuelve un servidor MCP existente reemplazando su superficie de herramientas por una única herramienta de código, y otra que, dada una especificación OpenAPI y un executor, construye un servidor MCP completo con herramientas de búsqueda y ejecución, más adecuado para APIs más grandes. En ambos casos, el código generado por el modelo corre dentro de Dynamic Workers.
Bundling con @cloudflare/worker-bundler
Los Dynamic Workers esperan módulos preempaquetados. El paquete @cloudflare/worker-bundler resuelve esto automáticamente: proporcionas archivos fuente y un package.json, y él resuelve dependencias npm del registro, empaqueta todo con esbuild y retorna el mapa de módulos que el Worker Loader espera. También soporta aplicaciones full-stack, empaquetando un Worker servidor, JavaScript del lado del cliente y assets estáticos juntos, con servicio de assets integrado que maneja content types, ETags y enrutamiento SPA.
Manipulación de archivos con @cloudflare/shell
El paquete @cloudflare/shell le da a tu agente un sistema de archivos virtual dentro de un Dynamic Worker. El código del agente llama a métodos tipados en un objeto state, incluyendo lectura, escritura, búsqueda, reemplazo, diff, glob, consulta y actualización JSON y archivado, con entradas y salidas estructuradas en vez de parsing de strings.
El almacenamiento está respaldado por un Workspace durable basado en SQLite y R2, así que los archivos persisten entre ejecuciones. Operaciones como búsquedas en múltiples archivos y reemplazos por lotes minimizan los round-trips de RPC. Las escrituras por lotes son transaccionales por defecto: si cualquier escritura falla, las anteriores se revierten automáticamente.
Quién ya lo está usando y cómo
El uso práctico del Dynamic Worker Loader ya está ocurriendo en escenarios variados y bastante interesantes.
Herramientas que usamos a diario
Code Mode en producción
Los desarrolladores quieren que sus agentes escriban y ejecuten código contra APIs de herramientas, en vez de hacer llamadas de herramientas secuenciales una por una. Con Dynamic Workers, el LLM genera una única función TypeScript que encadena múltiples llamadas de API, se ejecuta en un Dynamic Worker y retorna el resultado final de vuelta al agente. Solo el resultado, y no cada paso intermedio, va a la ventana de contexto. Esto reduce tanto la latencia como el uso de tokens y produce mejores resultados, especialmente cuando la superficie de herramientas es grande.
El propio servidor MCP de Cloudflare fue construido exactamente de esta forma: expone toda la API de Cloudflare a través de apenas dos herramientas, búsqueda y ejecución, en menos de 1.000 tokens, porque el agente escribe código contra una API tipada en vez de navegar por cientos de definiciones de herramientas individuales.
Automatizaciones personalizadas
Zite, por ejemplo, está construyendo una plataforma de aplicaciones donde los usuarios interactúan a través de una interfaz de chat. El LLM escribe TypeScript entre bastidores para construir apps CRUD, conectarse a servicios como Stripe, Airtable y Google Calendar y ejecutar lógica de backend, todo sin que el usuario vea una línea de código. Cada automatización corre en su propio Dynamic Worker, con acceso solo a los servicios y bibliotecas específicos que el endpoint necesita.
Según Antony Toron, CTO y cofundador de Zite, la empresa necesitaba una capa de ejecución que fuera instantánea, aislada y segura, y los Dynamic Workers cumplieron los tres requisitos, superando a todas las demás plataformas que evaluaron en velocidad y soporte a bibliotecas. Zite ahora procesa millones de solicitudes de ejecución diariamente gracias a los Dynamic Workers.
Aplicaciones generadas por IA
Los desarrolladores también están construyendo plataformas que generan aplicaciones completas a partir de IA, ya sea para sus clientes o para equipos internos construyendo prototipos. Con Dynamic Workers, cada app puede iniciarse bajo demanda y luego ponerse en almacenamiento frío hasta que sea invocada nuevamente. Los tiempos de arranque rápidos facilitan la visualización de cambios durante el desarrollo activo, y las plataformas pueden bloquear o interceptar cualquier solicitud de red que el código generado haga.
Cuánto cuesta todo esto
Los Dynamic Workers se cobran a US$ 0,002 por Worker único cargado por día, además del precio habitual de tiempo de CPU e invocaciones de los Workers regulares. Para casos de uso de Code Mode, donde cada Worker es de uso único, esto significa US$ 0,002 por Worker cargado más CPU e invocaciones, un costo típicamente insignificante comparado con los costos de inferencia para generar el código.
Durante el período de beta, el cobro de US$ 0,002 está suspendido. Como los precios pueden cambiar, siempre vale consultar la documentación oficial de pricing de los Dynamic Workers para información actualizada.
Qué significa esto en la práctica para quienes desarrollan con IA
Hablando de forma bien concreta: si estás construyendo cualquier producto donde un agente de Inteligencia Artificial necesita ejecutar código como parte de su flujo de trabajo, ya sea un asistente de análisis de datos, una herramienta de automatización, un copiloto de desarrollo o cualquier otra aplicación similar, la forma en que resuelves el problema de sandboxing va a impactar directamente la experiencia de tu usuario y el costo de tu infraestructura.
El enfoque del Dynamic Worker Loader abre una tercera vía que antes no existía de forma accesible: sandboxing rápido, seguro y con costo proporcional al uso real, sin la necesidad de mantener una infraestructura compleja de containers. Para startups y equipos pequeños, esto es especialmente relevante porque elimina una barrera técnica significativa que antes requería ingenieros especializados o soluciones costosas de terceros. Para empresas más grandes, la ganancia de rendimiento y la reducción de costo a escala pueden representar una ventaja competitiva real, principalmente en productos donde la velocidad de ejecución de código es parte de la propuesta de valor central.
Es importante también mencionar que esta no es una solución mágica que resuelve todos los problemas de seguridad relacionados con la ejecución de código generado por Inteligencia Artificial. El sandboxing resuelve el aislamiento de ejecución, pero la validación del código antes de la ejecución, los límites de acceso a recursos externos y la política de qué puede o no ejecutarse aún necesitan ser definidos por el equipo que está construyendo el producto. El Dynamic Worker Loader ofrece la infraestructura, pero la arquitectura de seguridad completa aún depende de decisiones de diseño que van más allá de la elección de la plataforma de ejecución. Lo que cambia es que ahora la parte más difícil, el aislamiento rápido y confiable, ya está resuelta de forma bastante elegante. ⚡
La combinación de TypeScript, sandboxing basado en isolates V8 y el Dynamic Worker Loader representa una de las evoluciones más prácticas e inmediatas para quienes están construyendo con Inteligencia Artificial hoy, y vale mucho la pena seguir de cerca cómo este ecosistema se va a desarrollar en los próximos meses.
