Cloudflare Ask AI — це кнопка у верхньому правому куті панелі керування. За нею працює Agent Lee — агент, який читає дані вашого облікового запису, відповідає на запитання простою мовою і з квітня 2026 року також змінює конфігурацію після вашого схвалення.
Це не черговий чат-бот для документації. Це агент із обліковими даними всередині площини керування, яка стоїть перед значною частиною інтернету. Це заслуговує на детальніший розгляд, ніж звичайний допис про запуск.
Усе нижче взято з власної документації та блогу Cloudflare, а також із публічних звітів про інциденти від людей, які з цим зіткнулися. Я не спрямовував його на production-обліковий запис і після прочитання цих звітів не поспішаю це робити. Саме цей вибір і є темою статті.
Що стоїть за кнопкою Cloudflare Ask AI
Agent Lee побудований на власному стеку Cloudflare: Agents SDK, Workers AI для інференсу, Durable Objects для зберігання розмов кожного користувача та шлюзу схвалення запису, а також MCP-сервері Cloudflare для визначень інструментів API.
Цікаво те, як він викликає інструменти. Замість того щоб надсилати виклики інструментів по одному, модель пише TypeScript для згенерованого API, а цей код запускається в ізольованому середовищі через Durable Object, який виконує роль проксі з обліковими даними. Cloudflare називає це Codemode. API keys ніколи не з’являються у згенерованому коді — вони додаються на стороні сервера. Операції читання виконуються безпосередньо. Операції запису зупиняються на тому, що Cloudflare називає elicitation gate, і у своєму дописі про запуск компанія прямо зазначає, що запит на підтвердження — це сам шлюз, а не просто елемент UX.
Cloudflare стверджує, що Agent Lee обробляє приблизно 250 000 викликів інструментів на день у DNS, Workers, SSL/TLS, R2, Registrar, Cache, Tunnel та API Shield.
Як архітектура це справжня система, і вона продуманіша за більшість vendor copilot, які мені доводилося розглядати. Проблеми не в архітектурі.
Що Cloudflare Ask AI робить правильно
У вузькому сценарії обіцянка справджується. Запитайте, де розташоване певне налаштування, — і це буде швидше, ніж переходити через вісім вкладок. Попросіть виконати DNS lookup або перевірку сертифіката — і отримаєте відповідь, не залишаючи сторінку. Попросіть графік трафіку — і він побудує його з вашої аналітики через generative UI.
Обізнаність про обліковий запис — це справжнє покращення порівняно з пошуком у документації. Агент відповідає про вашу зону, а не про гіпотетичну зону з документації. Для тих, хто заходить у панель Cloudflare двічі на рік і не пам’ятає, чи розташоване правило в Rules, Caching або Configuration, цього вже достатньо, щоб бути корисним.
Де Cloudflare Ask AI помиляється
Публічно задокументовано три проблеми, і це різні типи збоїв.
Токен, якого ніхто не просив
Наприкінці лютого 2026 року користувачі Cloudflare почали знаходити у своїх облікових записах API token із назвою "Agent Lee (auto-generated)", якого вони ніколи не створювали. Видалення не допомагало. Після оновлення сторінки він з’являвся знову. У обговоренні спільноти з’ясували причину: налаштування під назвою "Let AI view your account", заховане за невеликим елементом керування всередині панелі Ask AI, було увімкнене за замовчуванням. Після його вимкнення токен зник остаточно.
Один користувач у тому обговоренні сказав, що ніколи не вмикав цю функцію і не отримував жодного повідомлення. Колишній співробітник Cloudflare, який відповідав у тій самій темі, погодився, що функцію випустили без сповіщення, і звернув увагу на дещо серйозніше: агент не знав про власний токен. Після цього команда випустила beta-документацію та виправлення для токена.
Потім у травні розробник, який перевіряв облікові дані, знайшов подібний токен у своєму обліковому записі: його створили 28 квітня, а виявили через три тижні. У своєму матеріалі Cloudflare's Ask AI created an API token with read access to my entire account він описує доступ для читання до всіх облікових записів, усіх зон і всіх користувачів, понад 160 дозволів і відсутність дати завершення дії. Його аргумент переконливий: "Асистенту, який відповідає на запитання, потрібен доступ для читання, обмежений цим запитанням."
Сьогодні документація Cloudflare зазначає, що API tokens належать до того, до чого Agent Lee не має доступу. Обидва твердження можуть бути правдивими одночасно, якщо облікові дані, надані агенту, ширші за його передбачене використання. У цьому й полягає проблема постійного токена з широким охопленням і без терміну дії.
Перевірте самі: dash.cloudflare.com/profile/api-tokens.
Тихі відповіді без відповіді
У травні користувач повідомив на форумі спільноти Cloudflare, що Ask AI кілька разів поспіль залишався на етапі "thinking about it" під час запитань про аналіз трафіку, а потім нічого не повертав. Без помилки, часткової відповіді чи сигналу про те, що щось пішло не так. Представник Cloudflare відтворив проблему і сказав, що команда випускає зміни, аби припинити такі відповіді без результату.
Це beta-помилка, яку виправлять. Я згадую її через те, що вона показує про інтерфейс. Панель чату без системного зворотного зв’язку не дає зрозуміти, чи є запит складним, чи зламався pipeline.
Правило кешу, зламане схваленим записом
Звіт за липень — той, на який варто звернути увагу. Користувач, який розслідував проблему з кешуванням, пройшов цей процес разом з Ask AI, побачив успішне збереження, а наступного ранку виявив, що проблема повернулася. Під час детальнішої перевірки з’ясувалося, що агент встановив browser_ttl у значення 0 з override_origin через Rulesets API. API прийняв це значення. Пізніше панель керування позначила його як недійсне, коли правило відкрили в режимі редагування. Правило вже було розгорнуте в несправному стані, а обхід кешу мовчки не працював.
Прочитайте цю послідовність ще раз, адже захисний механізм спрацював саме так, як було задумано, а результатом усе одно стало зламане production-правило.
Прогалина, яку не покриває шлюз схвалення
Elicitation gate відповідає на одне запитання: чи дозволяєте ви цей запис? Він не може відповісти на запитання, яке насправді зашкодило тому користувачеві: чи правильне це значення?
Схвалити "встановити browser TTL для цього правила кешу" — не те саме, що знати, що 0 у поєднанні з override_origin створює правило, яке API приймає, а панель керування відхиляє. Щоб виявити це на етапі запиту на схвалення, ви вже мали б знати про обмеження. А якби ви знали про нього, то не запитували б агента.
Це структурне обмеження підходу confirm-before-write в інфраструктурі. Авторизація — не валідація. Людина, яка схвалює зміни, але не може їх оцінити, — це rubber stamp із додатковими кроками, а режим збою гірший за відмову, оскільки тиха неправильна конфігурація виглядає як успіх, доки трафік не покаже протилежне.
Якщо ви створюєте agent systems, це урок, який можна перенести в інші сфери. Я зіткнувся з тією самою стіною, створюючи publishing- і CMS-workflows під керуванням агентів: етап схвалення захищає вас лише тоді, коли людина на цьому етапі справді може оцінити payload. Інакше валідація потрібна в інструменті, а не згода в UI.
Парадокс Free plan
Agent Lee досі перебуває в beta і станом на вересень 2026 року все ще обмежений обліковими записами Free plan.
Подумайте, хто опиняється в тестовій групі. Облікові записи зі справжньою складністю, кількома зонами, правилами Enterprise WAF і доходами, що залежать від поведінки кешу, не можуть ним користуватися. А ті, хто може, найменше схильні помітити, що browser_ttl зі значенням 0 неправильний, перш ніж це їм чогось коштуватиме.
Я розумію логіку обмеження blast radius. Але це також означає, що feedback loop працює саме на неправильній аудиторії, і липневий інцидент із кешем показує, як це виглядає на практиці.
Як я використовував би Cloudflare Ask AI сьогодні
Розвідка лише для читання — так. Запитати, де розташоване налаштування, що зараз налаштовано для зони, чи дійсний сертифікат, або попросити швидкий графік трафіку. Низький ризик, реальна економія часу.
Запис — ні. Не для того, що обслуговує важливий для мене трафік. Нехай агент скаже, що саме він змінив би, а потім внесіть зміни самостійно там, де панель керування перевіряє ваші дані.
Три речі, які варто зробити цього тижня незалежно від того, чи користуєтеся ви ним:
Ніщо з цього не є критикою Cloudflare як такої. Я створюю рішення на їхньому стеку, зокрема використовую Workers і D1 для production waitlists. Суть у тому, що агент усередині вашої площини керування заслуговує на значно ретельнішу перевірку, ніж агент усередині вашого редактора.
Вердикт
Agent Lee — найсерйозніший з архітектурного погляду vendor copilot, внутрішню будову якого мені доводилося вивчати. Codemode, проксі з обліковими даними, справжній шлюз схвалення — усе це побудовано на власних примітивах. Cloudflare правильно виконала найскладнішу частину.
Оцінка станом на вересень 2026 року:
| Вимір | Вердикт |
|---|---|
| --- | --- |
| Архітектура | Сильна. Виконання коду в ізольованому середовищі, додавання облікових даних на стороні сервера, шлюз схвалення як справжній контроль. |
| Читання та діагностика | Корисні. Швидше за панель керування для пошуку налаштувань і виконання перевірок. |
| Операції запису | Поки що ні. Схвалення охоплює авторизацію, але не правильність. |
| Згода та дозволи | Невдале розгортання. Доступ до облікового запису увімкнено за замовчуванням, а токен із широким охопленням створюється автоматично. |
| Доступність | Beta, лише Free plan, тому найскладніші облікові записи не можуть його навантажити. |
Історія — це розрив між архітектурою та розгортанням. Cloudflare ретельно спроєктувала шлях облікових даних, а потім увімкнула його за замовчуванням, не повідомивши нікого, — одним кроком звівши нанівець значну частину цієї обережності.
Корисний для запитань. Поки що не заслуговує довіри для змін.
Джерела
Перевірено 18 вересня 2026 року.
browser_ttl.