Cloudflare ha lanzado como open source Cloudflare OS, una plataforma que la compañía define como un «sistema operativo» para la productividad con inteligencia artificial. El nombre puede inducir a error: no busca competir con Linux, Windows o macOS. Su finalidad es ofrecer un entorno donde empleados y agentes de IA puedan crear aplicaciones, consultar recursos corporativos y ejecutar acciones bajo un modelo de aislamiento, permisos específicos y aprobaciones humanas. Cloudflare asegura que una parte importante de su plantilla ya utiliza internamente esta tecnología.
Resumen en 20 segundos de Cloudflare OS
- Cloudflare ha publicado el código de una plataforma de IA desarrollada originalmente para uso interno.
- Los usuarios pueden solicitar a agentes que creen pequeñas aplicaciones, llamadas Gadgets.
- Los Gatekeepers limitan los recursos externos que cada aplicación o agente puede utilizar.
- Las acciones sensibles pueden quedar en espera de aprobación humana.
- Cloudflare OS v2 aún está en early access y su despliegue autónomo todavía requiere documentación adicional.
La propuesta es especialmente interesante porque aborda uno de los problemas que surgen cuando los agentes de IA dejan de limitarse a responder preguntas. Un chatbot que genera texto plantea un riesgo relativamente controlable. Sin embargo, un agente capaz de leer repositorios, modificar documentos, consultar aplicaciones internas o ejecutar acciones requiere un sistema de permisos mucho más preciso.
Cloudflare OS intenta construir este entorno en torno a tres componentes principales: Agent Workspaces, Gadgets y Gatekeepers. La analogía con un sistema operativo proviene precisamente de esta separación entre usuarios, aplicaciones, recursos y permisos.
Gadgets: pequeñas aplicaciones que la IA puede crear y modificar
Uno de los conceptos más singulares de Cloudflare OS son los Gadgets.
Este modelo se aparta del esquema tradicional de software como servicio (SaaS), donde una aplicación centralizada es utilizada simultáneamente por miles de usuarios.
En Cloudflare OS, cada usuario puede tener su propia instancia de una aplicación.
Por ejemplo, alguien puede solicitar:
Create a collaborative whiteboard app.El agente genera el Gadget correspondiente y esa aplicación se ejecuta en su propio entorno aislado.
También puede solicitarse:
Make slides for my upcoming meeting with a customer.En este caso, Cloudflare OS utiliza uno de sus Blueprints, plantillas que no solo contienen información, sino también el código completo de una aplicación.
La diferencia surge cuando el usuario necesita algo que la aplicación aún no realiza. En lugar de acudir a un desarrollador, puede solicitar al agente que modifique su propio código.
Cloudflare considera que la IA hace viable un modelo donde cada empleado disponga de versiones personalizadas de herramientas relativamente pequeñas.
La arquitectura busca evitar que esa libertad se convierta en un problema de seguridad.
Cada Gadget se ejecuta en un sandbox independiente. Su código funciona en un Dynamic Worker sin acceso directo y general a Internet. Para comunicarse con servicios externos, necesita recursos explícitamente autorizados.
El cliente funciona dentro de un iframe aislado, con restricciones mediante Content Security Policy y las capacidades de sandbox del navegador.
El diseño del modelo es sencillo: una aplicación recién creada no recibe automáticamente acceso a los sistemas empresariales.
Este comportamiento es especialmente relevante si el código ha sido generado automáticamente por un modelo de IA.
Gatekeepers: permisos específicos para agentes y aplicaciones
La segunda pieza esencial son los Gatekeepers.
Cloudflare los compara con servidores Model Context Protocol (MCP) más controlados, situados entre el agente o Gadget y los servicios externos.
Cuando un usuario desea permitir que un agente use, por ejemplo, un repositorio concreto, el acceso se gestiona mediante un Gatekeeper.
Este componente realiza varias tareas:
- Autenticación y autorización, incluyendo OAuth cuando sea necesario;
- Limitar el acceso al recurso específico autorizado por el usuario;
- Registrar las operaciones realizadas;
- Proveer una API al agente;
- Solicitar aprobación humana para acciones con efectos externos.
Esta última función es una de las más interesantes desde el punto de vista técnico.
Los sistemas de agentes enfrentan generalmente el problema de la aprobación humana. Si un agente intenta realizar una operación sensible, puede quedar en espera de que alguien apruebe manualmente.
Eso funciona mientras el usuario está presente. Pero pierde utilidad si el agente debe seguir operando durante minutos sin intervención.
Cloudflare propone un enfoque diferente.
El Gatekeeper puede simular localmente el resultado de una acción pendiente de autorización. El agente recibe una respuesta simulada y puede seguir operando bajo esa hipótesis.
Si posteriormente necesita confirmar el resultado, puede consultar la simulación previa.
Al finalizar, el usuario puede revisar las operaciones pendientes y aprobarlas o rechazarlas individualmente o en bloque.
Esto permite separar dos fases que normalmente se unen: el razonamiento del agente y la ejecución real de acciones con impacto externo.
El método no elimina el riesgo, ya que si el usuario aprueba sin filtros, el control se reduce. Pero evita que la única opción sea dar permisos permanentes o saltarse las confirmaciones.
Los agentes no deberían tener todos los permisos del usuario
Cloudflare OS adopta además un modelo de seguridad basado en capacidades.
Cada agente y Gadget inicia sin acceso a recursos externos.
Aunque existan integraciones corporativas, esas credenciales no están disponibles automáticamente para cualquier interacción.
El usuario debe «presentar» explícitamente el recurso al agente, como proporcionar un enlace a un repositorio específico. De esta forma, el agente obtiene acceso a través del Gatekeeper correspondiente, sin heredar permisos globales sobre todos los recursos.
Este enfoque aplica el principio de mínimo privilegio.
Es una diferencia importante respecto a configuraciones donde un servidor MCP se añade globalmente y sus herramientas están siempre disponibles en cualquier sesión.
Cloudflare argumenta que un agente no debería considerarse simplemente otro usuario. Debe actuar con responsabilidad, pero con permisos restringidos.
En su analogía con un sistema operativo, la correspondencia sería:
| Sistema operativo tradicional | Cloudflare OS |
|---|---|
| Kernel | Workshop backend |
| Drivers | Gatekeepers |
| Shell | Workshop frontend |
| Procesos | Gadgets |
| Ejecutables | Blueprints |
| Usuarios | Usuarios |
| ACL | Permisos compartidos |
| — | Agentes |
Aunque la comparación tiene sus límites, facilita entender por qué Cloudflare emplea el término OS.
No se trata de gestionar CPU, memoria o dispositivos como Linux. Se centra en crear una capa que relacione personas, agentes, aplicaciones y recursos corporativos, manteniendo fronteras de seguridad entre ellos.
Basado en Workers, Durable Objects y workerd
Cloudflare OS se apoya en tecnologías que la compañía ya usa en su plataforma de ejecución.
Cada workspace funciona como un Durable Object. Los Gadgets usan Dynamic Worker Facets, y los Gatekeepers también forman parte del workspace para gestionar el acceso a recursos remotos.
El proyecto emplea además Cap’n Web RPC para las comunicaciones entre cliente y servidor de los Gadgets.
Esta elección tiene otra implicación: las aplicaciones creadas ofrecen una interfaz que los propios agentes pueden usar.
Por ejemplo, un usuario podría pedir:
Create an issue dashboard for this repository.y luego solicitar al agente que interactúe con esa aplicación sin necesidad de desarrollar un servidor MCP específico.
Cloudflare llama Code Mode a este enfoque: el agente genera pequeños fragmentos de código y los ejecuta para completar tareas.
La plataforma no está limitada a un único modelo de IA. Puede integrar diferentes grandes modelos de lenguaje (LLM), incluyendo modelos autoalojados, dependiendo de la configuración concreta.
Se puede probar localmente
Cloudflare ha publicado el código y las instrucciones para ejecutarlo en un entorno local.
Tras instalar pnpm, el proceso básico es:
pnpm run-localLa interfaz estará disponible en:
http://localhost:8787Esta modalidad usa wrangler y workerd, y está destinada principalmente a probar el proyecto, no para producción. Los datos locales se almacenan en el directorio .wrangler.
También existe un procedimiento para desplegar Cloudflare OS en una cuenta de Cloudflare.
Un aspecto importante es que, estar basado en Workers, no significa necesariamente que Cloudflare OS tenga que correr en su infraestructura propia. workerd, el runtime de Workers, también es open source y puede funcionar en servidores propios.
No obstante, hasta agosto de 2026, las instrucciones y herramientas para desplegar Cloudflare OS sobre workerd en servidores personales aún están como «Coming Soon».
Por lo tanto, esta opción forma parte de la arquitectura del proyecto, pero todavía no está completamente documentada ni disponible para implementación independiente.
Un proyecto abierto, pero todavía en early access
Cloudflare no presenta la versión actual como un producto final.
La compañía denomina la publicación de agosto de 2026 como Cloudflare OS v2, una revisión completa basada en las lecciones aprendidas en la primera versión.
El repositorio la considera lo suficientemente avanzada para experimentar, pero admite que aún hay aspectos por perfeccionar y califica el proyecto como en early access.
También llama la atención su enfoque respecto a contribuciones externas.
Aunque el código es abierto, Cloudflare actualmente no busca contribuciones externas de gran tamaño. Argumentan que el uso de IA ha reducido el coste de escribir código, pero la revisión, el mantenimiento y la coherencia siguen requiriendo esfuerzo humano.
Aceptan correcciones pequeñas y verificables, y recomiendan usar las discusiones del repositorio para propuestas de mayor alcance.
Más allá del nombre, lo interesante de Cloudflare OS está en el problema que busca resolver.
Las empresas comienzan a pasar de empleados que consultan chatbots a agentes capaces de ejecutar código y actuar sobre sistemas corporativos. En ese escenario, ya no basta con conectar un modelo a todas las herramientas disponibles.
Es necesario definir qué agentes pueden acceder a qué recursos, aislar el código generado, registrar sus acciones y determinar cuándo debe intervenir una persona.
Cloudflare OS propone una arquitectura para gestionar estas relaciones. Aunque todavía está en fase inicial y varias piezas están en evolución, sus Gadgets, Gatekeepers y modelo de permisos muestran una dirección prometedora para responder a la pregunta que cada vez más equipos de sistemas y seguridad deberán abordar: cómo permitir que los agentes hagan trabajo real sin entregarles las llaves completas del sistema.
Preguntas frecuentes
¿Qué es Cloudflare OS?
Cloudflare OS es un entorno open source para trabajar con agentes de IA, crear pequeñas aplicaciones y conectarlas de forma controlada a recursos corporativos. Pese a su nombre, no es un sistema operativo convencional como Linux o Windows.
¿Qué son los Gadgets de Cloudflare OS?
Los Gadgets son aplicaciones independientes que pueden ser creadas y modificadas con ayuda de agentes IA. Cada instancia se ejecuta de forma aislada y no tiene acceso general a Internet ni a recursos corporativos por defecto.
¿Para qué sirven los Gatekeepers?
Los Gatekeepers gestionan la conexión entre agentes o Gadgets y servicios externos. Controlan la autorización, restringen recursos, registran operaciones y pueden requerir aprobación humana para acciones con impacto externo.
¿Se puede instalar Cloudflare OS en servidores propios?
La arquitectura permite usar workerd, el runtime open source de Workers, y es posible realizar pruebas locales. Sin embargo, en la versión publicada en agosto de 2026, la documentación y las herramientas para desplegar Cloudflare OS en servidores propios todavía no están disponibles, están en camino («Coming Soon»).