Cloudflare открыла исходный код платформы Cloudflare OS для ИИ-агентов с контролем доступа

Cloudflare открыла исходный код переработанной версии своей внутренней платформы Cloudflare OS, как компания её описывает, «операционной системы» для ИИ-агентов, приложений и работы. Теперь любая организация может развернуть Cloudflare OS у себя, подключить её к собственным внутренним системам и настроить под свои процессы. Первую версию платформы Cloudflare ещё в мае этого года дала всем своим сотрудникам: по словам компании, ею каждый день пользуются тысячи людей во всех подразделениях, включая тех, кто далёк от разработки, они создают документы и презентации, автоматизируют повторяющиеся задачи и собирают небольшие приложения для визуализации данных.

Первая версия строилась вокруг того, что один человек работает с агентом в личном рабочем пространстве: приложения были статичными, а не живым софтом, подключённым к внутренним системам, и многие детерминированные задачи всё равно приходилось запускать заново как сессию агента, расходуя токены модели. Настоящую проблему обнажила совместная работа. Доступ к серверу MCP (Model Context Protocol) показывал, какие инструменты агент может вызвать, но не то, какие данные он уже успел увидеть. Когда сотрудники начали делиться рабочими пространствами, приложениями и результатами, встал вопрос: как сделать так, чтобы совместная работа не раскрывала информацию тем, кому её видеть не положено. Поэтому Cloudflare пересобрала платформу на новом фундаменте, с расчётом, что безопасность встроена в саму платформу, а не остаётся на совести каждого, кто пишет приложение или пользуется агентом.

Новая Cloudflare OS сочетает три части: рабочее пространство агента, опирающееся на контекст и навыки, которые собрала компания, с изолированной средой, где агент пишет и выполняет код; новую систему контроля доступа и управления для безопасной работы с внутренними данными и сервисами; и платформу для личных, изменяемых приложений, которые люди создают и которыми делятся. Начинается всё как разговор в браузере, как и во многих других инструментах на основе ИИ, хотя какие именно, Cloudflare не уточняет, а превратиться может в документ, приложение или рабочий процесс, который потом продолжает работать сам.

Рабочее пространство рассчитано на любого сотрудника, а не только на разработчиков: пользоваться им можно прямо в браузере, без терминала и без знания кода. Внутри, сессии с агентом, сохранённое состояние, файлы и результаты, доступ к ресурсам и изолированная среда для выполнения кода. Пространство сразу нагружено контекстом и навыками, которые собрала команда или компания: если один человек нашёл лучший способ сделать что-то, эту практику получают все остальные, и не нужно заново объяснять модели один и тот же процесс и терминологию. С рабочим пространством можно изучать вопрос и задавать ему вопросы, агент пишет код, чтобы искать, фильтровать, объединять и анализировать данные, вместо того чтобы затягивать в контекстное окно модели весь набор данных целиком; превращать исследование в документ, презентацию или таблицу, которые не обязаны оставаться статичным файлом, они могут быть связаны с живыми данными, обновляться вслед за источником и экспортироваться в привычные форматы или сервисы вроде Google Drive; собирать совместные приложения со своим интерфейсом, логикой и состоянием, если документа или таблицы уже не хватает; и превращать типовую последовательность действий в детерминированный процесс, где код отвечает за предсказуемые шаги, а модель подключается только там, где нужно её суждение, такие процессы можно запускать вручную, по расписанию или по событию в подключённой системе. Доступ агентов и приложений к основным системам компании идёт через модули Gatekeeper, а к уже существующим у организации MCP-серверам, через порталы для MCP-серверов (MCP Server Portals).

Когда компании начинают пробовать ИИ на рабочих задачах, первая просьба сотрудников, обычно ключи API к внутренним системам. Cloudflare прямо называет это опасной практикой, которая не масштабируется: такие ключи почти всегда дают широкий и долгоживущий доступ, который трудно ограничить, безопасно передать и потом проверить. Протокол MCP даёт способ получше, сервер MCP хранит учётные данные сам и открывает агенту только определённый набор инструментов, не передавая ключ напрямую. Но, по словам Cloudflare, контроля над тем, какие инструменты агент может вызвать, недостаточно: MCP не показывает, какие данные агент уже увидел. Агент может объединить сведения из разных систем, отправить их куда-то с менее строгим контролем или показать через приложение людям, которым исходные данные видеть не положено, то есть право доступа должно учитывать и то, куда данные способны уйти дальше.

Кто может войти в Cloudflare OS, решает сервис Cloudflare Access. А внутри у каждого агента и каждого приложения по умолчанию нет доступа ни к чему: агент может запросить доступ к конкретному ресурсу, а человек, выдать его или отказать. Сгенерированный код получает такой ресурс в виде типизированной привязки, а сами учётные данные остаются полностью изолированными от агента и любого написанного им кода. Серверный код выполняется в Dynamic Worker с полностью отключённым исходящим доступом в интернет, клиентский, в изолированной песочнице в браузере: ни тот, ни другой не может обратиться во внешний мир иначе как через явно выданные права.

За доступ к внешним сервисам и действия над ними отвечают модули Gatekeeper. Каждый такой модуль, отдельный Worker для конкретного сервиса, который стоит между Cloudflare OS и этим сервисом, понимает его API, его ресурсы и допустимые операции над ними. Дать агенту доступ ко всему аккаунту GitHub целиком, скорее всего, слишком широко, вместо этого Gatekeeper может ограничить его одним репозиторием, разрешить читать issues, но не исходный код, скрыть отдельные поля, наложить лимиты на частоту запросов и потребовать подтверждения человека перед тем, как pull request будет принят. Сам агент и приложения видят лишь небольшой TypeScript-интерфейс, а Gatekeeper берёт на себя OAuth-авторизацию, хранит учётные данные, следит за соблюдением политики, записывает, что именно было прочитано, и опосредует любое действие с эффектом, видимым снаружи.

Контролировать только первое чтение данных недостаточно, объясняет Cloudflare: если агент прочитал закрытую таблицу в хранилище данных и построил на её основе живой дашборд, расшарить этот дашборд не должно означать расшарить и саму таблицу тем, у кого не было к ней прямого доступа. Поэтому Cloudflare OS ведёт запись каждого ресурса, который увидел агент, и привязывает эту историю к самому агенту и его работе: когда кто-то ещё открывает рабочее пространство, общается с агентом или смотрит на то, что он сделал, Gatekeeper заново проверяет, есть ли у этого человека доступ к ресурсам, которые агент уже видел. Тот же журнал наблюдений определяет и то, когда агенту вообще можно обращаться вовне: например, после чтения чувствительных данных агенту может быть закрыта запись в определённые источники, приглашение новых участников, передача задачи другому агенту или любой исходящий запрос. По словам Cloudflare, людям, которые пользуются агентами или собирают приложения, больше не нужно самим следить за такими ошибками, это берёт на себя платформа.

Третья часть Cloudflare OS, конструктор личных приложений. В большинстве офисных пакетов набор программ фиксирован: документы, таблицы, презентации. В Cloudflare OS каждый «файл» может быть отдельным приложением, которое агент написал для одного человека, проекта или команды, и это не прототип, который потом нужно куда-то ещё выгружать и разворачивать: у каждого такого приложения есть клиентский код, серверный код, API и устойчивое состояние. По умолчанию приложения приватны, но ими можно делиться так же, как документами.

Технически каждое такое приложение, это Worker. Агент пишет две части: клиентский код, который рисует интерфейс в браузере, и серверный код, который хранит состояние и реализует логику. Сервер подгружается по требованию как Dynamic Worker и разворачивается как Durable Object Facet, обе технологии Cloudflare создала специально для этого проекта; Facet даёт приложению собственную базу SQLite, отдельную от среды выполнения самой Cloudflare OS. А поскольку Dynamic Worker использует лёгкие V8-изоляты, у каждого приложения, своя изолированная среда выполнения без выделенного сервера или контейнера. Браузерный клиент обращается к серверу через Cap'n Web, открытую RPC-систему Cloudflare на основе модели объектных полномочий (систему удалённого вызова процедур): серверный метод можно вызвать с клиента как обычную функцию JavaScript. Особенность в том, что тот же метод может вызвать и сам агент, то есть если человек умеет собрать инструмент для своей задачи, агент потом может пользоваться этим же инструментом, чтобы выполнять эту задачу за него.

Поделиться приложением можно двумя способами: расшарить сам работающий экземпляр, тогда другие люди совместно работают с тем же состоянием в реальном времени, либо расшарить его «чертёж» (blueprint), из которого другой человек создаёт собственную независимую копию. Копия, созданная из чертежа, наследует код исходного приложения, но не его базу SQLite, историю переписки с агентом, учётные данные или подключённые ресурсы, у неё всегда собственное, независимое состояние и ресурсы.

Отдельно об этом пишет ИТ-директор (CIO) Cloudflare Сэм Рея, в своём блоге он рассказывает, чему компания научилась, обкатывая первую версию платформы у себя внутри.

Ключевые факты

Cloudflare открыла исходный код переработанной версии Cloudflare OS; первую версию платформы компания с мая раздала всем своим сотрудникам, и, по её словам, ею каждый день пользуются тысячи людей во всех подразделениях.
Новая версия впервые умеет безопасно подключаться к внутренним системам организации, в первой версии приложения были статичными и не были связаны с живыми данными.
Доступ агентов и приложений к внешним сервисам идёт через модули Gatekeeper: по умолчанию доступа нет ни к чему, а Gatekeeper может, например, ограничить агента одним репозиторием на GitHub, разрешить читать issues без доступа к коду и потребовать подтверждения человека перед слиянием pull request.
Cloudflare OS ведёт запись того, какие ресурсы видел агент, и при попытке другого человека открыть результат его работы заново проверяет его доступ к этим ресурсам, так расшаренный дашборд не превращается в способ увидеть закрытую таблицу, на основе которой он построен.
Пользователи собирают в Cloudflare OS собственные приложения, каждое технически Worker со своей базой SQLite, и делятся либо готовым экземпляром с общим состоянием, либо его «чертежом» (blueprint) для независимой копии без исходных данных и учётных данных.

Почему это важно

В этой истории Cloudflare выступает не поставщиком модели, а архитектором целой корпоративной среды для ИИ-агентов, по сути, операционной системы для работы с агентами внутри компании. Важен сам путь к релизу: Cloudflare сначала раздала первую версию платформы собственным сотрудникам, на практике столкнулась с конкретной проблемой, совместная работа с агентами размывает контроль над тем, кто что может увидеть и куда эти данные могут утечь дальше, и только после этого пересобрала платформу вокруг новой модели безопасности и открыла её код. Это делает историю не демонстрацией концепта, а системой, уже отработавшей на живой организации, чья архитектура контроля доступа теперь доступна как референс любой компании, которая хочет дать сотрудникам ИИ-агентов, не потеряв контроль над тем, что они могут увидеть.

Кому это важно

В первую очередь, ИТ- и security-командам компаний, которые хотят раскатить корпоративных ИИ-агентов, но упираются в вопрос доступа: раздавать агентам ключи API к внутренним системам Cloudflare прямо называет опасной практикой, которая не масштабируется. Готовая архитектура, модули Gatekeeper для внешних сервисов, журнал того, что агент уже видел, и политика, которая следует за этим журналом, избавляет от необходимости придумывать это с нуля. Во вторую очередь, командам, которые уже строят на инфраструктуре Cloudflare (Workers, Durable Objects): платформа показывает, как из этих же примитивов, Dynamic Worker, Durable Object Facet, RPC-система Cap'n Web, собрать многопользовательскую среду с приложениями, которые пишет сам агент. И в третью, рядовым сотрудникам компаний, которые получат агента как рабочий инструмент: часть текста прямо посвящена не разработчикам, а людям, которые захотят изучить данные, собрать таблицу или небольшое приложение, не открывая терминал.

Как это применить

Разворачивать Cloudflare OS может любая организация. Подключить платформу к своим внутренним системам можно двумя путями: написать собственный модуль Gatekeeper, это отдельный Worker для конкретного сервиса, который знает его API, ресурсы и допустимые операции над ними, либо переиспользовать уже существующие MCP-серверы компании через порталы для MCP-серверов. По умолчанию агенты и приложения не получают доступа ни к чему: администратор выдаёт права на каждый ресурс отдельно, а Gatekeeper может ограничить доступ предельно точно, например, дать агенту доступ только к одному репозиторию на GitHub, разрешить читать issues, но не код, скрыть отдельные поля и потребовать подтверждения человека перед слиянием pull request. Дальше сотрудники используют рабочее пространство в браузере: просят агента изучить вопрос по внутренним данным, превратить исследование в документ или таблицу, которая остаётся живой и обновляется вслед за источником, собрать небольшое совместное приложение или превратить рутинную последовательность действий в детерминированный процесс, запускаемый по расписанию или по событию. Готовым приложением можно поделиться целиком, с общим состоянием в реальном времени, или его «чертежом» (blueprint), тогда получатель разворачивает собственную независимую копию без данных, истории переписки и учётных данных оригинала.

Можно ли доверять

Всё, что известно о Cloudflare OS на данный момент, это описание самой Cloudflare в собственном блоге: независимого аудита безопасности, отзывов сторонних исследователей или сравнения с альтернативами в доступном тексте нет. Утверждения об изоляции, что серверный и клиентский код не могут обратиться в интернет иначе как через явно выданные права, и описание работы модулей Gatekeeper, это архитектура, как её представляет сам разработчик, а не результат независимой проверки. В тексте нет ни названия лицензии, под которой публикуется код, ни точной численности сотрудников (только «тысячи»), ни цены или условий развёртывания для сторонних организаций. При этом сама компания признаёт: у первой версии были проблемы, статичные приложения, недостаточный контроль над тем, что видел агент, и именно это стало поводом для полной переработки. То есть перед нами вторая, только что открытая версия платформы, а не проверенная временем зрелая система.

Риски и подводные камни

Ключевые строительные блоки Cloudflare OS, Dynamic Worker и Durable Object Facet, в тексте прямо названы технологиями, которые Cloudflare создала специально для этого проекта. Судя по этому описанию, развёртывание платформы завязано на инфраструктуру самой Cloudflare (Workers, Durable Objects), а не является независимым от конкретного облачного провайдера. Сама идея журнала того, что видел агент, который потом решает, кому можно показать результат его работы, это новая и довольно сложная поверхность атаки: ошибка в логике Gatekeeper или в записи наблюдений способна раскрыть данные сразу по всей организации, а не одному человеку, как это было бы при утечке одного API-ключа. Наконец, сравнение «начинается как разговор в браузере, как и во многих других ИИ-инструментах», это формулировка самой Cloudflare, а не независимая оценка: какие именно инструменты имеются в виду, компания не называет.

«Внутри каждый агент и каждое приложение по умолчанию не имеют доступа ни к чему.»

— блог Cloudflare, анонс Cloudflare OS