Cloudflare выпустила Cloudflare One stack — open-source библиотеку навыков для AI-агентов, которые помогают проектировать, разворачивать и сопровождать Zero Trust-среды. Для российских команд, которые живут между VPN, политиками доступа и вечной миграцией с одного вендора на другого, новость интересна не модным словом «агенты», а куда более приземлённой вещью: Cloudflare обещает сократить переход с чужих платформ с месяцев до часов.
Речь не о большой платформе «под ключ», а о наборе agent skills — по сути, структурированных инструкций и логики, которые агент может подгрузить и применить к конкретной задаче. Как пишет InfoQ, Cloudflare отгружает два лёгких файла: cloudflare-one для работы с собственным стеком и cloudflare-one-migration для перевода конфигураций от других поставщиков. Во втором случае заявлена явная логика миграции из Zscaler и Palo Alto Networks. И это уже звучит не как маркетинговая сказка про «AI всё автоматизирует», а как попытка упаковать накопленную экспертизу в повторяемый инструмент.
Самый прикладной сценарий — перенос приложений и политик доступа. Cloudflare утверждает, что агент с этим навыком умеет взять определения приложений из Zscaler Private Access, сопоставить их с эквивалентами в Cloudflare Access, преобразовать группы пользователей и политики, создать нужные ресурсы через API Cloudflare и собрать отчёт: что перенесено автоматически, а что требует ручной проверки. Для безопасников и сетевых инженеров здесь важен не только темп, но и форма результата. Автоматизация в инфраструктуре доступа полезна ровно до того места, где она не оставляет следов. Если после неё нет понятного summary, diff и списка спорных мест, это не ускорение, а новый источник аварий.
Cloudflare отдельно подчёркивает, что в основу миграционного навыка положена та же логика, которую компания использует в программах Descaler и Deskope. По словам компании, эти программы уже переводили корпоративных заказчиков с Zscaler и Netskope на Cloudflare «за часы, а не месяцы». Тонкий момент здесь в том, что в open-source-формате Cloudflare фактически выносит наружу часть того, что раньше выглядело как сервисная экспертиза партнёров и presale-команд. Для рынка это важный сдвиг: вендоры всё чаще продают не просто продукт, а способ быстрее доехать до внедрения, причём желательно силами клиента или интегратора, без длинной цепочки согласований и дорогих workshop.
Не только миграция, но и полный цикл
У Cloudflare One stack есть и вторая половина, менее шумная, но, возможно, более важная на длинной дистанции. Навык cloudflare-one закрывает не только миграцию, но и эксплуатационный цикл: замену VPN через Cloudflare Access, контроль пользовательского и сетевого трафика через Gateway, подключение через Tunnel, Mesh и WAN, диагностику с помощью набора Digital Experience Monitoring (DEX), а также рекомендации по правилам на основе трафика, который наблюдается в живом аккаунте. То есть идея в том, чтобы агент не просто отвечал на вопрос «какую кнопку нажать», а строил пошаговый сценарий внедрения с привязкой к существующей инфраструктуре.
Cloudflare приводит показательный кейс: если попросить агента заменить VPN-инфраструктуру, тот сначала инвентаризирует существующие приложения, затем сопоставит каждое с нужным примитивом Cloudflare, после чего предложит последовательность развёртывания с минимальными рисками при cutover. И только потом сформирует сводку конфигурации для проверки командой. Это важная деталь. В корпоративной безопасности проблема обычно не в отсутствии API и не в дефиците YAML-файлов. Проблема в том, что между «мы хотим уйти от VPN» и «политики доступа применены без массового самоубийства helpdesk» лежит огромный слой контекста: кто к чему подключается, какие группы существуют реально, где исторические исключения, какие приложения вообще никто не помнит, но выключить страшно. Если этот слой начинает понимать агент, инструмент становится заметно интереснее.
Технически вся конструкция усиливается при связке с MCP-сервером Cloudflare code mode. В таком режиме агент получает типизированный интерфейс к Cloudflare API: может читать конфигурацию аккаунта, проверять политики и вносить изменения через заранее определённые workflow, а не набор случайных API-вызовов из серии «сейчас попробуем и посмотрим». Отдельно подчёркивается, что учётные данные не попадают в контекст модели: их обслуживает сам MCP-сервер. Для корпоративных заказчиков это, вероятно, одно из ключевых условий. AI-автоматизация в безопасности перестаёт быть игрушкой в тот момент, когда вопрос доступа к продовой конфигурации решён не через копипаст токенов в чат, а через нормальную прослойку с разграничением полномочий.
Главный вопрос не в AI, а в границах доверия
И всё же Cloudflare аккуратно оставляет человека у рубильника. Архитектура стека построена по схеме review before apply: агент предлагает изменения и готовит сводку, но финальное утверждение остаётся за специалистом. Это, пожалуй, самая здравая часть всей истории. Ошибка в Gateway-политике или неверное сопоставление Access-приложения — не тот класс проблем, который хочется разбирать постфактум. В материале InfoQ приводится и показательная реакция одного из практиков в X: речь не о замене security-команды, а о сжатии дистанции между намерением и настроенной политикой. Для IT-директоров и руководителей безопасности формулировка почти идеальная: агент не отменяет процесс, а убирает ручную рутину между запросом и внедрением.
Отсюда и практический вывод для рынка. Партнёрам Cloudflare такой стек даёт возможность быстрее внедрять Cloudflare One, точнее диагностировать проблемы и меньше времени тратить на ручной «перевод» между вендорами. Для внутренних команд это сигнал ещё интереснее: знания о сетевой и Zero Trust-инфраструктуре начинают поставляться не только в виде документации, сертификаций и часов консультантов, но и как машиночитаемый слой, который можно встроить в агентные workflow. Если модель реально умеет не болтать о Zero Trust, а разбирать действующие политики, строить план миграции и показывать спорные места до применения, у корпоративной автоматизации появляется шанс выйти из демо-зоны. Но критерий зрелости здесь жёсткий: у каждого изменения должен быть владелец, понятный diff, маршрут согласования и откат. Иначе даже самый умный агент быстро превращается в очень дорогой способ ошибиться быстрее. Подробнее о релизе — в материале .