Cloudflare publie son « OS » open source pour créer des agents et applications IA
Cloudflare ouvre le code de son espace de travail pour créer des agents et mini-applications IA avec des permissions et des accès encadrés.
Cloudflare vient de publier le code source de Cloudflare OS, un environnement de travail consacré aux agents IA et à la création d’applications. Le projet était initialement développé pour un usage interne et serait maintenant utilisé quotidiennement par une partie importante des salariés de l’entreprise.
Malgré son nom, Cloudflare OS n’est pas un système d’exploitation destiné à remplacer Windows, macOS ou Linux. Il s’agit plutôt d’une plateforme de productivité permettant de discuter avec des agents, de leur confier des tâches et de générer de petites applications adaptées aux besoins d’une entreprise.
Cloudflare OS rassemble trois composants principaux.
Le premier est une interface de discussion dans laquelle les utilisateurs peuvent lancer des agents IA. Ceux-ci peuvent recevoir des informations sur le fonctionnement de l’entreprise et être reliés à des services comme GitHub, Google, Notion, Slack, Confluence, Home Assistant ou l’API Cloudflare.
Le deuxième composant concerne les « Gadgets ». Cloudflare utilise ce terme pour désigner de petites applications générées à la demande par une intelligence artificielle.
Un utilisateur peut, par exemple, demander la création d’une présentation, d’un tableau de bord GitHub, d’un tableau blanc collaboratif ou d’un outil interne répondant à un besoin très précis.
Contrairement à une application SaaS traditionnelle partagée par tous les clients, chaque Gadget est créé comme une instance séparée. Son propriétaire peut ensuite modifier son fonctionnement avec l’aide de l’agent ou le partager avec d’autres utilisateurs.
Des modèles appelés « Blueprints » permettent également de réutiliser la structure d’une application sans partager les données qu’elle contient.
Un Gatekeeper peut gérer l’authentification OAuth, limiter l’accès à une ressource précise, enregistrer les opérations effectuées et demander une confirmation avant une action ayant des conséquences réelles.
Un agent relié à GitHub ne reçoit donc pas automatiquement un accès général à l’ensemble des dépôts de l’utilisateur. Une ressource doit lui être présentée explicitement et les autorisations peuvent être limitées aux opérations nécessaires.
Cloudflare adopte ici un modèle de sécurité basé sur les capacités. Par défaut, un agent ou un Gadget ne dispose d’aucun accès. Il reçoit ensuite uniquement les ressources et les opérations indispensables à la tâche demandée.
Ce fonctionnement diffère des configurations dans lesquelles plusieurs serveurs MCP sont connectés en permanence à tous les agents, avec des permissions parfois beaucoup trop larges.
Avec un système classique, un agent doit interrompre son travail dès qu’une opération nécessite une confirmation. L’utilisateur peut ainsi revenir plusieurs minutes plus tard et constater que l’agent attend toujours l’autorisation de réaliser sa première action.
Les Gatekeepers peuvent simuler le résultat de certaines opérations sensibles. L’agent continue alors son raisonnement avec un résultat provisoire, tandis que les actions réelles sont placées dans une file d’attente.
Lorsque le travail est terminé, l’utilisateur peut examiner les opérations proposées et les accepter ou les refuser individuellement ou en groupe.
Cette approche évite de donner automatiquement tous les droits à l’agent simplement pour ne plus être dérangé par les demandes de confirmation. Elle devra toutefois être éprouvée en conditions réelles : une simulation incorrecte pourrait influencer les étapes suivantes et produire un résultat différent de celui attendu.
Chaque espace de travail utilise son propre Durable Object, tandis que les Gadgets sont exécutés dans des Dynamic Workers séparés. Le code côté serveur d’un Gadget ne peut pas contacter librement Internet sans recevoir une autorisation explicite.
La partie affichée dans le navigateur fonctionne également dans une iframe isolée, avec une politique de sécurité destinée à limiter ses communications.
Cette architecture est particulièrement importante lorsque le code de l’application est produit par une intelligence artificielle. Même si le modèle génère un comportement dangereux ou vulnérable, les possibilités de ce code doivent rester limitées par son environnement d’exécution.
Cela ne signifie pas que les applications générées sont impossibles à compromettre ou automatiquement fiables. Les sandboxes et les permissions réduisent la surface d’attaque, mais elles ne remplacent pas la vérification du code ni la surveillance des accès accordés.
L’agent intégré utilise une approche appelée « Code Mode ». Au lieu d’enchaîner uniquement de nombreux appels d’outils, il peut écrire et exécuter du code pour traiter des données ou réaliser plusieurs opérations.
Cloudflare affirme que cette méthode peut réduire le nombre d’appels et la consommation de tokens pour certaines tâches. Les performances dépendront cependant du modèle choisi, de la complexité du contexte fourni et des services connectés.
Le projet peut être lancé localement avec Wrangler et le runtime open source workerd. Ce mode stocke les données sur la machine et permet de découvrir l’interface sans effectuer immédiatement un déploiement complet.
Il ne s’agit toutefois pas encore de la méthode recommandée pour une utilisation en production. La documentation permettant d’installer proprement Cloudflare OS sur son propre serveur avec workerd est toujours en préparation.
Une procédure permet déjà de déployer la plateforme sur un compte Cloudflare. Il faut alors tenir compte du coût des Workers, Durable Objects et Dynamic Workers utilisés. Les Dynamic Workers sont actuellement réservés à l’offre Workers payante.
La configuration des Gatekeepers demandera également quelques connaissances techniques. Les intégrations avec Google, GitHub ou d’autres services nécessitent souvent de créer des applications OAuth et de gérer leurs identifiants.
Cloudflare avertit enfin que cette publication correspond à la version 2 du projet, issue d’une réécriture complète. Elle reste proposée en accès anticipé et comporte encore plusieurs limitations.
L’idée la plus importante reste néanmoins l’encadrement des agents. Leur donner accès aux données et aux services d’une entreprise sans définir précisément leurs permissions représente un risque considérable.
Avec ses Gadgets isolés, ses Gatekeepers et ses validations différées, Cloudflare OS propose plusieurs pistes intéressantes pour éviter de transformer un agent IA en utilisateur disposant de droits illimités.
Le projet est encore trop jeune pour juger sa fiabilité ou sa facilité de déploiement. Son code source constitue cependant une base intéressante pour étudier la manière dont Cloudflare envisage l’exécution et la sécurisation des agents IA en entreprise.
Consulter le dépôt de Cloudflare OS
Découvrir et déployer Cloudflare OS
Lire la présentation officielle de Cloudflare
← Retour aux posts
Malgré son nom, Cloudflare OS n’est pas un système d’exploitation destiné à remplacer Windows, macOS ou Linux. Il s’agit plutôt d’une plateforme de productivité permettant de discuter avec des agents, de leur confier des tâches et de générer de petites applications adaptées aux besoins d’une entreprise.
Un environnement de travail pour les agents IA
Cloudflare OS rassemble trois composants principaux.
Le premier est une interface de discussion dans laquelle les utilisateurs peuvent lancer des agents IA. Ceux-ci peuvent recevoir des informations sur le fonctionnement de l’entreprise et être reliés à des services comme GitHub, Google, Notion, Slack, Confluence, Home Assistant ou l’API Cloudflare.
Le deuxième composant concerne les « Gadgets ». Cloudflare utilise ce terme pour désigner de petites applications générées à la demande par une intelligence artificielle.
Un utilisateur peut, par exemple, demander la création d’une présentation, d’un tableau de bord GitHub, d’un tableau blanc collaboratif ou d’un outil interne répondant à un besoin très précis.
Contrairement à une application SaaS traditionnelle partagée par tous les clients, chaque Gadget est créé comme une instance séparée. Son propriétaire peut ensuite modifier son fonctionnement avec l’aide de l’agent ou le partager avec d’autres utilisateurs.
Des modèles appelés « Blueprints » permettent également de réutiliser la structure d’une application sans partager les données qu’elle contient.
Des Gatekeepers pour contrôler les permissions
La partie la plus intéressante de Cloudflare OS concerne probablement les Gatekeepers. Ces composants contrôlent la communication entre les agents, les Gadgets et les services externes.Un Gatekeeper peut gérer l’authentification OAuth, limiter l’accès à une ressource précise, enregistrer les opérations effectuées et demander une confirmation avant une action ayant des conséquences réelles.
Un agent relié à GitHub ne reçoit donc pas automatiquement un accès général à l’ensemble des dépôts de l’utilisateur. Une ressource doit lui être présentée explicitement et les autorisations peuvent être limitées aux opérations nécessaires.
Cloudflare adopte ici un modèle de sécurité basé sur les capacités. Par défaut, un agent ou un Gadget ne dispose d’aucun accès. Il reçoit ensuite uniquement les ressources et les opérations indispensables à la tâche demandée.
Ce fonctionnement diffère des configurations dans lesquelles plusieurs serveurs MCP sont connectés en permanence à tous les agents, avec des permissions parfois beaucoup trop larges.
Des actions simulées avant leur validation
Cloudflare cherche également à améliorer le fonctionnement des validations humaines.Avec un système classique, un agent doit interrompre son travail dès qu’une opération nécessite une confirmation. L’utilisateur peut ainsi revenir plusieurs minutes plus tard et constater que l’agent attend toujours l’autorisation de réaliser sa première action.
Les Gatekeepers peuvent simuler le résultat de certaines opérations sensibles. L’agent continue alors son raisonnement avec un résultat provisoire, tandis que les actions réelles sont placées dans une file d’attente.
Lorsque le travail est terminé, l’utilisateur peut examiner les opérations proposées et les accepter ou les refuser individuellement ou en groupe.
Cette approche évite de donner automatiquement tous les droits à l’agent simplement pour ne plus être dérangé par les demandes de confirmation. Elle devra toutefois être éprouvée en conditions réelles : une simulation incorrecte pourrait influencer les étapes suivantes et produire un résultat différent de celui attendu.
Chaque application fonctionne dans une sandbox
Cloudflare OS repose sur Cloudflare Workers, Durable Objects, Dynamic Workers et Facets.Chaque espace de travail utilise son propre Durable Object, tandis que les Gadgets sont exécutés dans des Dynamic Workers séparés. Le code côté serveur d’un Gadget ne peut pas contacter librement Internet sans recevoir une autorisation explicite.
La partie affichée dans le navigateur fonctionne également dans une iframe isolée, avec une politique de sécurité destinée à limiter ses communications.
Cette architecture est particulièrement importante lorsque le code de l’application est produit par une intelligence artificielle. Même si le modèle génère un comportement dangereux ou vulnérable, les possibilités de ce code doivent rester limitées par son environnement d’exécution.
Cela ne signifie pas que les applications générées sont impossibles à compromettre ou automatiquement fiables. Les sandboxes et les permissions réduisent la surface d’attaque, mais elles ne remplacent pas la vérification du code ni la surveillance des accès accordés.
Plusieurs modèles IA peuvent être utilisés
Cloudflare OS n’impose pas un modèle de langage unique. Le projet annonce une compatibilité avec plusieurs fournisseurs importants ainsi qu’avec des modèles auto-hébergés.L’agent intégré utilise une approche appelée « Code Mode ». Au lieu d’enchaîner uniquement de nombreux appels d’outils, il peut écrire et exécuter du code pour traiter des données ou réaliser plusieurs opérations.
Cloudflare affirme que cette méthode peut réduire le nombre d’appels et la consommation de tokens pour certaines tâches. Les performances dépendront cependant du modèle choisi, de la complexité du contexte fourni et des services connectés.
Un projet open source, mais encore expérimental
Cloudflare OS est publié sous licence Apache 2.0. L’entreprise explique que l’objectif n’est pas nécessairement d’utiliser la plateforme telle quelle, mais de permettre aux organisations de l’adapter pour créer leur propre environnement de travail.Le projet peut être lancé localement avec Wrangler et le runtime open source workerd. Ce mode stocke les données sur la machine et permet de découvrir l’interface sans effectuer immédiatement un déploiement complet.
Il ne s’agit toutefois pas encore de la méthode recommandée pour une utilisation en production. La documentation permettant d’installer proprement Cloudflare OS sur son propre serveur avec workerd est toujours en préparation.
Une procédure permet déjà de déployer la plateforme sur un compte Cloudflare. Il faut alors tenir compte du coût des Workers, Durable Objects et Dynamic Workers utilisés. Les Dynamic Workers sont actuellement réservés à l’offre Workers payante.
La configuration des Gatekeepers demandera également quelques connaissances techniques. Les intégrations avec Google, GitHub ou d’autres services nécessitent souvent de créer des applications OAuth et de gérer leurs identifiants.
Cloudflare avertit enfin que cette publication correspond à la version 2 du projet, issue d’une réécriture complète. Elle reste proposée en accès anticipé et comporte encore plusieurs limitations.
Une approche intéressante pour la sécurité des agents
Cloudflare OS ne manque pas d’ambition : l’entreprise imagine un environnement dans lequel chaque salarié peut demander à une IA de créer l’outil dont il a besoin, sans attendre le développement d’une nouvelle application centralisée.L’idée la plus importante reste néanmoins l’encadrement des agents. Leur donner accès aux données et aux services d’une entreprise sans définir précisément leurs permissions représente un risque considérable.
Avec ses Gadgets isolés, ses Gatekeepers et ses validations différées, Cloudflare OS propose plusieurs pistes intéressantes pour éviter de transformer un agent IA en utilisateur disposant de droits illimités.
Le projet est encore trop jeune pour juger sa fiabilité ou sa facilité de déploiement. Son code source constitue cependant une base intéressante pour étudier la manière dont Cloudflare envisage l’exécution et la sécurisation des agents IA en entreprise.
Consulter le dépôt de Cloudflare OS
Découvrir et déployer Cloudflare OS
Lire la présentation officielle de Cloudflare