Cloudflare temporary accounts для AI-агентов

По состоянию на 20 июня 2026 года Cloudflare temporary accounts: это временные аккаунты Cloudflare Workers, через которые AI-агент может развернуть Worker без предварительной регистрации пользователя и вернуть claim URL человеку. Cloudflare объявила эту функцию 19 июня 2026 года и привязала её к Wrangler: команда выглядит просто, wrangler deploy --temporary.

Главная идея не в том, чтобы убрать человека из продакшена. Идея уже: убрать регистрацию из короткого цикла код - развёртывание - проверка. Агент может написать Worker, выкатить временную версию, проверить ответ через URL и отдать человеку ссылку, по которой тот заберёт аккаунт в обычный Cloudflare.

Это важная деталь для рынка агентной инфраструктуры. В материале про Cloudflare Agent Cloud и OpenAI мы уже разбирали, зачем агентам нужна управляемая среда выполнения. Temporary accounts закрывают более узкое, но болезненное место: агент умеет писать код, но обычно стопорится там, где сервис просит открыть браузер, пройти OAuth, нажать кнопку в панели управления или скопировать API-токен.

Что именно запустила Cloudflare

Temporary Cloudflare Accounts for Agents позволяют агенту развернуть Worker на временном preview account. Такое развёртывание живёт 60 минут. В течение этого окна агент может проверять результат и повторно выкатывать изменения. Если человек открывает claim URL, входит или регистрируется в Cloudflare и подтверждает перенос, временный аккаунт становится постоянным. Если этого не сделать, Cloudflare удаляет временный аккаунт и его развёртывания.

В changelog Cloudflare описывает тот же сценарий как первый запуск развёртывания: агент выкатывает Worker без существующих учётных данных Cloudflare, получает рабочий Worker URL и claim URL, а затем человек решает, забрать ли результат в постоянный аккаунт.

Как работает wrangler deploy --temporary

По документации Cloudflare, сценарий требует Wrangler 4.102.0 или новее. Агент сначала может запустить обычный wrangler deploy. Если у CLI нет учётных данных Cloudflare, Wrangler печатает подсказку: чтобы продолжить без входа, нужно перезапустить команду с --temporary. Это важно: агенту не обязательно заранее знать новый флаг, он может обнаружить его из вывода CLI.

После запуска wrangler deploy --temporary Cloudflare создаёт или переиспользует temporary preview account, разворачивает Worker на workers.dev и печатает claim URL. Пока окно в 60 минут не истекло, Wrangler кэширует temporary account. Поэтому агент может снова вызвать deploy и обновить тот же Worker, а не начинать с нуля.

Cloudflare прямо фиксирует границу: это сценарий для развёртываний, которые создаёт AI-агент, фоновых агентных сессий, быстрых прототипов и первой оценки Workers. Для продакшена и CI/CD компания рекомендует обычный постоянный аккаунт через wrangler login или Cloudflare API token.

Почему это важно для AI-агентов, которые пишут код

У AI-агентов для кода проблема не только в качестве кода. Даже сильный агент плохо проходит контуры, сделанные для человека: браузерный OAuth, MFA, настройки в панели управления, ручные токены, подтверждения в течение короткого окна. Для интерактивного помощника это раздражение. Для фонового агента это стоп.

Cloudflare пытается дать агенту короткий цикл проверки. Он пишет код, разворачивает Worker, делает запрос к рабочему URL, видит ошибку или правильный ответ, меняет код и повторяет. Такой цикл похож на обычную разработку, только без этапа «позвать человека, чтобы он создал аккаунт».

Здесь есть связь с тем, зачем OpenAI покупала Ona: Codex нужен постоянный облачный контур, где агент может жить дольше одной вкладки. У Cloudflare ход другой: не постоянное облако для агента, а временная цель для развёртывания, которую можно быстро показать человеку и при необходимости забрать в нормальный аккаунт.

Ограничения: 60 минут, claim URL и не продакшен

Temporary accounts нельзя воспринимать как обход нормальной безопасности. Это короткий мост от агентного прототипа к человеческому владению. У него есть несколько жёстких ограничений.

• Temporary preview account удаляется через 60 минут, если человек его не забрал.
• --temporary работает только без авторизации. Если Wrangler уже может использовать OAuth, CLOUDFLARE_API_TOKEN или global API key, флаг вернёт ошибку.
• Перед созданием temporary account Cloudflare требует proof-of-work check; Wrangler проходит его автоматически, но возможна задержка.
• Cloudflare ограничивает скорость создания временных аккаунтов и применяет дополнительные проверки против злоупотреблений.
• Claim URL даёт владение temporary preview account, поэтому его нужно считать чувствительной ссылкой.

Последний пункт легко недооценить. Если агент пишет код, устанавливает зависимости и отдаёт наружу ссылку владения аккаунтом, риски уже не теоретические. В соседнем материале мы разбирали prompt injection и supply-chain атаки на LLM-агентов. Temporary accounts не отменяют эти риски. Они просто делают развёртывание быстрее, а значит, требования к логам, зависимостям и проверке действий агента становятся жёстче.

Какие продукты поддерживаются

Cloudflare Docs подчёркивает: temporary preview accounts поддерживают не весь Cloudflare. По состоянию на 20 июня 2026 года список ограничен несколькими продуктами и лимитами.

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

Что это меняет для агентной инфраструктуры

Cloudflare temporary accounts показывают, как платформы начинают подстраиваться под агентов, а не только под людей. Раньше сервисы оптимизировали регистрацию и первый запуск под человека: форма, письмо, панель управления, токен. Теперь появляется второй путь: агент получает ограниченный, короткоживущий контур, делает работу, а человек подтверждает владение постфактум.

Для разработчиков это удобно не потому, что стало меньше кнопок. Ценность в другом: агент может принести проверяемый результат, а не только текстовый diff. Рабочий URL резко снижает неопределённость. Можно открыть страницу, сделать curl, посмотреть ответ API и проверить, что Worker вообще работает.

Для платформ это новый баланс. С одной стороны, меньше трения значит больше пробных развёртываний. С другой стороны, temporary accounts требуют защиты от спама, вредоносного кода и случайных утечек claim URL. Поэтому Cloudflare сочетает удобство с proof-of-work, лимитами скорости, короткоживущими аккаунтами и ограниченным набором ресурсов.

Коротко по главным вопросам

Что делает wrangler deploy --temporary?
Создаёт или переиспользует temporary preview account, разворачивает Worker на Cloudflare и печатает claim URL.

Сколько живёт временное развёртывание?
60 минут. Если человек не заберёт аккаунт через claim URL, Cloudflare удалит temporary preview account и развёртывания.

Можно ли использовать это в продакшене?
Cloudflare говорит нет. Для продакшена и CI/CD нужен постоянный аккаунт, wrangler login или API token.

В чём риск claim URL?
Claim URL даёт владение temporary preview account. Его нельзя публиковать как обычную ссылку на демо.

Итог

Cloudflare temporary accounts не делают AI-агента полноценным владельцем инфраструктуры. И правильно. Они дают ему узкий временный коридор: написать Worker, развернуть, проверить, показать человеку. Дальше человек должен забрать результат в нормальный аккаунт или дать ему исчезнуть через 60 минут.

Для агентного кодинга это практичный шаг. Меньше демонстраций застревает на регистрации, больше идей доходит до рабочего URL. Но вместе с этим растёт ответственность команд: если агент может быстро выкатить код наружу, нужно заранее решить, кто проверяет зависимости, кто видит логи и кто имеет право нажать claim.

Читайте также

• Cloudflare Agent Cloud OpenAI: зачем агентам боевой контур
• OpenAI покупает Ona: зачем Codex постоянное облако
• Prompt injection и supply-chain атаки на LLM-агентов