--- title: "Cloudflare OS lleva los agentes de IA a un entorno empresarial con permisos y sandbox" description: "Cloudflare ha publicado 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 llevar a e..." url: https://revistacloud.com/cloudflare-os-lleva-los-agentes-de-ia-a-un-entorno-empresarial-con-permisos-y-sandbox/ date: 2026-09-03 modified: 2026-08-30 author: "Nota de Prensa" image: https://revistacloud.com/wp-content/uploads/2026/08/cloudflare-os-q3-planning-workspace.png categories: ["Inteligencia artificial", "Noticias"] tags: ["agentes", "Cloudflare", "Inteligencia Artificial"] type: post lang: es --- # Cloudflare OS lleva los agentes de IA a un entorno empresarial con permisos y sandbox Cloudflare ha publicado como **[open source Cloudflare OS](https://github.com/cloudflare/cloudflare-os)**, una plataforma que la compañía define como un «sistema operativo» para la productividad con inteligencia artificial. El nombre puede llevar a engaño: no pretende competir con Linux, Windows o macOS. Su objetivo es proporcionar un entorno donde empleados y agentes de IA puedan crear aplicaciones, consultar recursos corporativos y ejecutar acciones bajo un [modelo de aislamiento](https://noticias.ai/la-ia-se-esta-rebelando-kimi-k3-tambien-encontro-una-salida-de-su-sandbox/), permisos específicos y aprobación humana. La propia Cloudflare asegura que una parte importante de su plantilla ya utiliza internamente esta tecnología. **Las claves de Cloudflare OS en 20 segundos** - Cloudflare ha publicado el código de una plataforma de IA desarrollada originalmente para uso interno. - Los usuarios pueden pedir a agentes que creen pequeñas aplicaciones, denominadas Gadgets. - Los Gatekeepers limitan qué recursos externos puede utilizar cada aplicación o agente. - Las acciones sensibles pueden quedar pendientes de aprobación humana. - Cloudflare OS v2 continúa en early access y su despliegue autónomo todavía tiene partes pendientes de documentación. La propuesta resulta especialmente interesante porque aborda uno de los problemas que aparece cuando los agentes de IA dejan de limitarse a responder preguntas. Un chatbot que genera texto supone un riesgo relativamente controlable. Un agente capaz de leer repositorios, modificar documentos, consultar aplicaciones internas o ejecutar acciones necesita un sistema de permisos mucho más preciso. Cloudflare OS intenta construir ese entorno alrededor de tres componentes principales: **Agent Workspaces, Gadgets y Gatekeepers**. La analogía con un sistema operativo procede precisamente de esta separación entre usuarios, aplicaciones, recursos y permisos. ## Gadgets: aplicaciones pequeñas que la IA puede crear y modificar Uno de los conceptos más particulares de Cloudflare OS son los **Gadgets**. La idea se aleja del modelo 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 pedir: ``` Create a collaborative whiteboard app. ``` El agente genera el Gadget correspondiente y esa aplicación se ejecuta dentro de 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 contienen únicamente información sino el código de una aplicación completa. La diferencia aparece cuando el usuario necesita algo que la aplicación todavía no hace. En lugar de enviar una petición al desarrollador, puede pedir al agente que modifique el código de su propia copia. Cloudflare considera que la IA puede hacer viable un modelo donde cada empleado disponga de versiones personalizadas de herramientas relativamente pequeñas. La arquitectura intenta evitar que esa libertad termine convirtiéndose en un problema de seguridad. Cada Gadget se ejecuta dentro de un [sandbox independiente](https://revistacloud.com/citrix-lleva-los-agentes-de-ia-a-espacios-de-desarrollo-aislados-y-gestionados/). El código de servidor funciona mediante un Dynamic Worker sin acceso directo y general a Internet. Para comunicarse con servicios externos necesita recursos que hayan sido autorizados expresamente. El cliente se ejecuta además dentro de un `iframe` aislado, con restricciones mediante Content Security Policy y las capacidades de sandbox disponibles en el navegador. El proyecto describe el modelo con una idea sencilla: **una aplicación recién creada no recibe automáticamente acceso a los sistemas de la empresa**. Ese comportamiento resulta especialmente relevante cuando el código puede haber sido escrito automáticamente por un modelo. ## Gatekeepers: permisos específicos para agentes y aplicaciones La segunda pieza son los **Gatekeepers**. Cloudflare los compara con servidores [Model Context Protocol (MCP)](https://revistacloud.com/nutanix-abre-su-infraestructura-hibrida-a-los-agentes-de-ia-con-un-servidor-mcp/) más controlados. Su función es situarse entre el agente o Gadget y los servicios externos. Cuando un usuario quiere permitir que un agente trabaje, por ejemplo, con un repositorio concreto, el acceso se realiza mediante un Gatekeeper. Este componente se ocupa de varias tareas: - autenticación y autorización, incluido OAuth cuando corresponde; - limitar el acceso al recurso concreto autorizado por el usuario; - registrar las operaciones realizadas; - proporcionar una API al agente; - solicitar aprobación humana para acciones con efectos externos. Esta última característica es una de las partes técnicamente más llamativas del proyecto. Los sistemas de agentes suelen encontrarse con un problema cuando necesitan aprobación humana. Si el agente intenta ejecutar una operación sensible, puede quedar detenido esperando que alguien pulse «aprobar». Eso funciona mientras el usuario permanece delante de la pantalla. Pierde bastante utilidad cuando se pretende dejar trabajando al agente durante varios minutos. Cloudflare plantea un mecanismo diferente. El Gatekeeper puede **simular localmente el resultado de una acción pendiente de autorización**. El agente recibe una respuesta simulada y puede continuar trabajando sobre esa hipótesis. Si posteriormente necesita consultar el resultado de aquella acción, vuelve a recibir información simulada. Cuando termina el trabajo, el usuario puede revisar las operaciones pendientes y aprobarlas o rechazarlas individualmente o en bloque. Esto permite separar dos momentos que normalmente están unidos: el razonamiento del agente y la ejecución real de acciones con consecuencias externas. El enfoque tampoco elimina el riesgo. Si el usuario aprueba indiscriminadamente todas las operaciones, el control pierde buena parte de su utilidad. Pero evita que la única alternativa práctica sea proporcionar permisos permanentes o recurrir a opciones equivalentes a saltarse las confirmaciones. ## Los agentes tampoco deberían recibir todos los permisos del usuario Cloudflare OS adopta además un modelo de seguridad basado en capacidades. Cada agente y cada Gadget empieza sin acceso a recursos externos. Aunque la organización haya configurado integraciones corporativas, esas credenciales no aparecen automáticamente disponibles para cualquier conversación. El usuario debe «presentar» explícitamente el recurso al agente. Puede ocurrir, por ejemplo, al proporcionar el enlace de un repositorio concreto. El agente recibe entonces acceso a ese recurso a través del Gatekeeper correspondiente, en lugar de heredar permisos generales sobre todos los repositorios disponibles para el usuario. El planteamiento intenta aplicar **mínimo privilegio** a los agentes. La diferencia es importante frente a configuraciones donde un servidor MCP se añade globalmente al entorno y todas sus herramientas quedan disponibles durante cualquier sesión. Cloudflare argumenta que un agente no debería considerarse simplemente otro usuario. Debe actuar bajo la responsabilidad de una persona, pero con sus propios permisos restringidos. En su analogía con un sistema operativo tradicional, Cloudflare establece estas correspondencias: | Sistema operativo tradicional | Cloudflare OS | | --- | --- | | Kernel | Workshop backend | | Drivers | Gatekeepers | | Shell | Workshop frontend | | Procesos | Gadgets | | Ejecutables | Blueprints | | Usuarios | Usuarios | | ACL | Permisos compartidos | | — | Agentes | La comparación tiene límites, pero ayuda a entender por qué Cloudflare ha elegido la palabra OS. No está intentando gestionar CPU, memoria y dispositivos como Linux. Está creando una capa encargada de relacionar **personas, agentes, aplicaciones y recursos corporativos manteniendo fronteras de seguridad entre ellos**. ## Construido sobre Workers, Durable Objects y workerd Cloudflare OS utiliza ampliamente tecnologías que la compañía ya emplea en su plataforma de ejecución. Cada workspace funciona como un **Durable Object**. Los Gadgets utilizan Dynamic Worker Facets y los Gatekeepers también se incorporan al workspace para gestionar el acceso a recursos remotos. El proyecto utiliza además Cap’n Web RPC para las comunicaciones entre cliente y servidor de los Gadgets. Esta decisión tiene otra consecuencia: las aplicaciones creadas disponen de una interfaz que los propios agentes pueden utilizar. Un usuario podría pedir primero: ``` Create an issue dashboard for this repository. ``` y después solicitar al agente que trabaje con la aplicación generada sin tener que construir específicamente un servidor MCP para ella. Cloudflare denomina **Code Mode** al enfoque utilizado por su agente: genera pequeños fragmentos de código y los ejecuta para realizar las tareas. La plataforma tampoco está limitada a un único proveedor de modelos. El proyecto indica que puede utilizar diferentes grandes modelos de lenguaje (LLM), incluidos modelos autoalojados, aunque la compatibilidad concreta depende de la configuración. ## Puede probarse localmente Cloudflare ha publicado el proyecto y sus instrucciones para ejecutarlo localmente. Después de instalar `pnpm`, el procedimiento básico es: ``` pnpm run-local ``` La interfaz queda disponible por defecto en: ``` http://localhost:8787 ``` Esta modalidad utiliza `wrangler` y `workerd` y está destinada principalmente a probar el proyecto, **no a ejecutar una instalación de producción**. Los datos locales se almacenan dentro del directorio `.wrangler`. También existe un procedimiento para desplegar Cloudflare OS dentro de una cuenta de Cloudflare. Hay aquí un matiz importante respecto a la independencia de la plataforma. Cloudflare explica que estar construido sobre Workers no significa necesariamente que Cloudflare OS tenga que ejecutarse siempre sobre su infraestructura. `workerd`, el runtime de Workers, también es open source y puede funcionar en servidores propios. Sin embargo, **a fecha de la publicación de agosto de 2026, las instrucciones y herramientas para desplegar Cloudflare OS sobre `workerd` en servidores propios todavía están marcadas como «Coming Soon»**. Por tanto, esa posibilidad forma parte de la arquitectura del proyecto, pero todavía no dispone del mismo camino documentado que el despliegue dentro de una cuenta de Cloudflare. ## Un proyecto abierto, pero todavía en early access Cloudflare no presenta la versión actual como un producto terminado. La compañía identifica la publicación de agosto de 2026 como **Cloudflare OS v2**, una reescritura completa realizada a partir de lo aprendido con la primera versión. El repositorio la considera suficientemente funcional para experimentar con ella, pero reconoce que todavía existen numerosos aspectos por pulir y utiliza expresamente la denominación early access. También resulta curioso el enfoque adoptado respecto a las contribuciones. Aunque el código es abierto, Cloudflare no está buscando actualmente contribuciones externas de gran tamaño. El proyecto explica que la IA ha reducido el coste de escribir código, mientras que revisar cambios, mantener la calidad y conservar la coherencia del producto continúa requiriendo trabajo humano. Sí acepta correcciones pequeñas y fácilmente verificables, mientras recomienda utilizar las discusiones del repositorio para propuestas de mayor alcance. Más allá del nombre, la parte interesante de Cloudflare OS está probablemente en el problema que intenta resolver. Las empresas empiezan a pasar de empleados que consultan chatbots a **agentes que pueden ejecutar código y actuar sobre sistemas corporativos**. En ese escenario ya no basta con conectar un modelo a todas las herramientas disponibles. Hace falta decidir qué agente puede acceder a qué recurso, aislar el código generado, registrar sus acciones y establecer cuándo debe intervenir una persona. Cloudflare OS propone una arquitectura para organizar esas relaciones. Todavía está en una fase temprana y varias piezas continúan evolucionando, pero sus Gadgets, Gatekeepers y modelo de permisos muestran una dirección interesante para una pregunta que cada vez tendrán que responder más equipos de sistemas y seguridad: **cómo permitir que los agentes hagan trabajo real sin entregarles las llaves completas de la infraestructura**. ## 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 con 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 individuales que pueden ser creadas y modificadas con ayuda de agentes de IA. Cada instancia se ejecuta de forma aislada y no obtiene acceso general a Internet o a recursos corporativos por defecto. ### ¿Para qué sirven los Gatekeepers? Los Gatekeepers controlan la conexión entre agentes o Gadgets y servicios externos. Gestionan autorización, restringen los recursos disponibles, registran operaciones y pueden exigir aprobación humana para acciones con efectos externos. ### ¿Se puede instalar Cloudflare OS en servidores propios? La arquitectura permite utilizar `workerd`, el runtime open source de Workers, y el proyecto puede probarse localmente. Sin embargo, en la versión publicada en agosto de 2026, la documentación y herramientas específicas para un despliegue de producción sobre servidores propios todavía figuran como pendientes.