Cloudflare OS ouvre en source sa plateforme d’agents auto-hébergeable
Cloudflare publie le 5 août 2026 Cloudflare OS, sa plateforme interne d’agents IA, sous licence Apache-2.0 et auto-hébergeable sur workerd avec des LLM locaux via Ollama. Le modèle de sécurité — agents à accès initial nul et Gatekeepers par ressource — est la vraie nouveauté, mais le runtime exige un plan Workers payant.
5 août 2026. Cloudflare ouvre en source la plateforme d’agents qu’elle a d’abord construite pour elle-même. Mai 2026. C’est la date à laquelle chaque employé du groupe a reçu la première version de l’outil. Des milliers. C’est le nombre de personnes qui l’utilisaient chaque jour en août, et pas seulement des ingénieurs. Le tout est publié sous Apache-2.0 sous le nom Cloudflare OS, une plateforme que toute organisation peut auto-héberger.
Ce qui rend la sortie digne d’attention n’est pas l’interface de chat — tout le monde en a une. C’est l’architecture de sécurité qui l’entoure, et le fait que la personne qui l’a conçue, Kenton Varda, a déjà tenté ce pari il y a dix ans avec Sandstorm.io. Il appelle lui-même Cloudflare OS « Sandstorm, avec de l’IA ».
Les trois briques de la plateforme
Cloudflare OS assemble trois éléments plutôt que d’en juxtaposer trois produits.
Un espace de travail d’agents. Une interface navigateur, sans code requis, préchargée avec une bibliothèque partagée de contexte et de compétences propres à l’entreprise. Quand un collaborateur documente une meilleure façon de faire, la procédure devient une instruction que tous les agents de l’organisation peuvent suivre. Les agents peuvent écrire du code pour chercher et filtrer des données internes au lieu de charger des jeux entiers dans le contexte, produire des documents et des diapositives liés à des données vivantes, ou exécuter des workflows en grande partie déterministes.
Des Gatekeepers. C’est la couche de gouvernance qui médiatise l’accès de chaque agent aux systèmes internes et externes. C’est la partie à comprendre en détail, parce que c’est elle qui distingue la plateforme des frameworks d’agents classiques.
Des Gadgets. La plateforme applicative : chaque application construite par un agent ou un humain tourne comme une instance isolée avec sa propre base SQLite, plutôt que dans un serveur mutualisé multi-tenant.
Le modèle de sécurité : zéro accès par défaut
Le cœur du projet tient en une phrase : chaque agent et chaque application démarre avec accès à rien. Cloudflare Access contrôle qui peut entrer dans Cloudflare OS. Une fois à l’intérieur, pour utiliser une ressource — un dépôt GitHub, une table d’entrepôt de données, un canal Slack — l’agent doit en demander l’accès, et un humain doit l’accorder ou le refuser.
Une fois accordé, l’accès devient un binding typé injecté dans le code généré, de la forme :
const issues = await env.PROJECT.listIssues({
teamId: "ENG",
state: "open",
});env.PROJECT est une capacité : la permission d’utiliser une ressource précise sous une politique précise. Le secret sous-jacent ne touche jamais l’agent ni le code qu’il écrit. Le code serveur s’exécute dans un Dynamic Worker dont tout réseau sortant est désactivé par défaut ; le code client tourne dans un cadre navigateur isolé. Ni l’un ni l’autre n’atteint l’internet ouvert, sauf via des capacités explicitement fournies.
Le Gatekeeper est un Worker dédié, placé entre Cloudflare OS et un service précis. Il comprend l’API du service assez finement pour restreindre l’accès bien plus étroitement qu’un jeton global : lecture seule sur un dépôt, masquage de champs, limites de débit, approbation humaine avant toute écriture. Il détient le secret OAuth, journalise chaque lecture et médiatise chaque action à effet réel.
Le suivi de contamination (taint tracking) boucle la logique. La plateforme journalise chaque ressource qu’un agent a observée, et cet historique reste attaché à l’agent et à tout ce qu’il produit. Si une seconde personne ouvre l’espace de travail ou consulte une sortie, les Gatekeepers revérifient ses propres droits sur chaque ressource touchée en chemin. Un tableau de bord partagé ne devient pas un canal de contournement vers une table à laquelle le destinataire n’a pas accès directement.
Auto-hébergement : ce qui est vrai et ce qui coûte
Sur le papier, Cloudflare OS est réellement auto-hébergeable. Le dépôt est sous Apache-2.0, bâti sur workerd, le runtime Workers open source de Cloudflare, et il supporte les LLM locaux via Ollama. Varda lui-même précise que tourner en local est, selon ses mots, « honnêtement… plus rapide ».
Le revers se trouve dans le runtime. Les Gadgets et le code serveur s’exécutent dans des Dynamic Workers, une primitive récente du runtime Workers. Les retours de la communauté indiquent que les Dynamic Workers exigent le plan Workers Paid — le palier gratuit ne suffirait pas à les faire tourner. Concrètement, l’auto-hébergement ne signifie pas « zéro coût » : il signifie que vous portez la charge d’un plan Workers et que vous acceptez un verrouillage sur les primitives Cloudflare (workerd, Durable Objects), pas sur vos conteneurs habituels.
La comparaison assumée avec Sandstorm éclaire ce point. En 2015, Sandstorm proposait le même principe de granularité par instance — un « Grain » isolé par document. Le projet a échoué, de l’aveu de Varda, parce que trop peu de gens avaient le temps ou la patience de modifier leur propre logiciel. Son pari aujourd’hui est que les agents IA lèvent ce goulot : chacun peut demander à son agent d’ajouter la fonctionnalité manquante à sa propre copie d’une application.
Verdict
Si vous voulez héberger des agents avec un vrai moindre privilège, Cloudflare OS mérite un pilote. Le modèle « zéro accès par défaut + Gatekeeper par ressource + taint tracking » répond à un problème réel — l’exfiltration par agent et l’injection de prompt — que les frameworks d’agents classiques traitent à peine. C’est le point fort de la plateforme, et il n’a pas d’équivalent simple ailleurs.
Si vous cherchez une solution zéro coût ou indépendante de Cloudflare, tempérez : l’auto-hébergement suppose un plan Workers Paid et un engagement sur workerd et les Durable Objects. Vérifiez ce point de tarification avant de bâtir un prototype, et mesurez si votre charge d’agents justifie la dépendance à un fournisseur de runtime.
La règle simple reste : pilotez pour le modèle de sécurité, pas pour l’interface. Si le moindre privilège par ressource est votre problème, Cloudflare OS est l’une des rares réponses sérieuses en open source. Si ce n’est pas votre problème, vous n’avez pas encore besoin de la complexité.