Кодинг-агент работает с вашими секретами, сетью и данными. Вопрос «где именно исполняется код, который пишет агент» для команды не менее важен, чем качество этого кода: облако вендора, локальная машина разработчика и пул машин внутри вашей сети дают разные границы безопасности, комплаенса и стоимости. 2 сентября 2026 года Cursor добавил к этой картине третий вариант — Self-Hosted Machines: cloud-агенты исполняются на динамически выделяемых пулах машин внутри вашей сети (cursor.com/blog/self-hosted-machnes).
Этот текст — практический гайд по контролю исполнения кодинг-агентов. Разбираем, почему место исполнения вообще имеет значение, какие варианты существуют на сентябрь 2026 года, как настроить Cursor self-hosted и чем он отличается от локального запуска и обычного облака. Если с настройкой нужна помощь, решить задачу поможет умный чат от ТекстГуру.
Почему место исполнения стало вопросом безопасности
Агент — единственная программа, которой вы отдаёте терминал, файловую систему, git и сеть, а потом разрешаете действовать без подтверждения на каждом шаге. Сюжеты августа–сентября 2026 показали, чем это грозит: Johann Rehberger довёл Claude Code в auto mode до выполнения кода с вероятностью 60–80%, исследователи Manifold Security нашли класс git-атак, где агент выполняет код до запроса о доверии к репозиторию (manifold.security).
Контроль исполнения — отдельный слой поверх этих атак. Он отвечает не на вопрос «что агент задумал», а на вопрос «где его действия физически происходят и кто владеет этой машиной»:
- Что видит агент. Если исполнение в облаке вендора — агенту доступно то, что вы туда смонтировали: код из репозитория, секреты окружения. Если на своей машине — вся ваша файловая система и сеть.
- Что покидает контур. Логи, диффы, вывод терминала уходят туда, где живёт agent-loop. Для компаний с data residency это юридический вопрос, а не технический.
- Кто владеет железом. Облако вендора — zero-ops, но код исполняется на чужих машинах. Свои машины — ответственность за образы, патчи и масштабирование, зато код не покидает ваш контур.
- Где находятся внутренние сервисы. Доступ к приватному Git, БД и API — это вопрос не прав агента, а сетевой топологии: может ли машина исполнения вообще дотянуться до вашей сети.
Именно поэтому появилась схема, где инференс остаётся у вендора, а исполнение инструментов уезжает к вам. Разберём три варианта, которые есть у команды на момент публикации.
Три варианта: облако вендора, self-hosted пулы, локальный запуск
1. Облако вендора (по умолчанию)
Облачные агенты Cursor исполняются на выделенных VM внутри облака Cursor: сессия получает собственную машину с установленными зависимостями и сетевыми правилами. Вендор берёт на себя провижининг, снапшоты, изоляцию и уборку.
Изоляция на агента, редактирование секретов, egress-контроль и подписанные коммиты закрывают требования большинства команд. По данным Cursor, managed-режим покрывает требования более 80% клиентов. Доступ к приватным сервисам решается через AWS PrivateLink, Cloudflare Tunnel или Tailscale внутри окружения — без переноса исполнения.
Ограничение одно, но принципиальное: код и данные уходят в облако вендора. Для части команд это неприемлемо само по себе.
2. Self-hosted пулы (Cursor Workers / Pools)
С 2 сентября 2026 года cloud-агенты Cursor умеют исполняться на машинах под вашим управлением:
«Cursor cloud agents can execute on dynamically scheduled pools of machines inside your network. You manage the underlying infrastructure, while agents are still started and managed from Cursor. This gives teams more control over where agents execute and what infrastructure they use.»
«Cloud-агенты Cursor могут исполняться на динамически выделяемых пулах машин внутри вашей сети. Инфраструктурой управляете вы, агенты по-прежнему запускаются и управляются из Cursor. Это даёт командам больше контроля над тем, где исполняются агенты и какую инфраструктуру они используют.»
Исполнение инструментов (правки файлов, команды, браузер, локальные MCP-серверы) уезжает на воркер в вашей сети. Agent-loop, инференс и планирование остаются в облаке Cursor. Разбор этой возможности как кейса — в соседней статье про self-hosted cloud-агенты для команд.
3. Локальный запуск
Третий вариант — не облачный агент, а CLI на машине разработчика: Claude Code, Codex, OpenCode. Здесь и agent-loop, и исполнение живут локально; модель вызывается по API. Контекст ограничен машиной, сеть и файлы — под вашим контролем.
Локальный запуск не решает командные задачи: нет общей инфраструктуры, очередей, контроля версий окружения. Вопрос «где исполняются агенты» для команды из десяти разработчиков превращается в десять разных ответов. Поэтому для изоляции локальных агентов используют песочницы — Docker, sandbox runtime, VM.
Сравнение: что вы контролируете в каждом варианте
| Параметр | Облако вендора | Self-hosted пулы | Локальный запуск |
|---|---|---|---|
| Где agent-loop и инференс | Облако вендора | Облако вендора | Ваша машина |
| Где исполняются инструменты | VM вендора | Воркеры в вашей сети | Ваша машина |
| Кто управляет железом | Вендор | Ваша команда | Разработчик |
| Доступ к приватным сервисам | PrivateLink / Tunnel / Tailscale | Прямой, из вашей сети | Прямой, с машины |
| Код покидает контур | Да | Нет (но логи — да) | Нет |
| Командная инфраструктура (очереди, пулы) | Есть | Есть | Нет |
| Стоимость инфраструктуры | Включена в использование | Плюс ваши машины | Нет доп. затрат |
| Операционная нагрузка | Минимальная | Образы, патчи, масштабирование | Гигиена машины |
Главный вывод из таблицы: self-hosted не заменяет managed-режим и не даёт «полностью офлайн». Он переносит исполнение ближе к данным и сервисам, но планирование и инференс остаются в облаке Cursor. Если требование — полная независимость от облака вендора, это не ваш инструмент.
Cursor формулирует порог прямо: managed-облако — рекомендованный путь для большинства команд, к своим машинам переходить, только когда ограничения облачной модели не влезают в ваши требования.
Как устроен Cursor self-hosted: термины и механика
Три понятия из документации определяют всю схему:
| Термин | Определение | Пример |
|---|---|---|
| Worker | Машина под вашим управлением, зарегистрированная в Cursor через CLI. Здесь агент правит файлы, запускает команды и ходит в код | Linux-VM в вашем AWS-аккаунте или Mac mini на столе |
| Team Pool | Именованная очередь воркеров, которую можно выбрать в клиенте Cursor. Чаты ждут в очереди, пока свободный воркер их не заберёт | Пул gpu обслуживает только машины с GPU; пул ios — только Mac |
| Controller | Код, который вы запускаете и который подстраивает ёмкость пула под спрос | Пришёл запрос, свободных воркеров нет — контроллер поднимает новую машину |
Воркер запускается командой agent worker start и открывает долгоживущее исходящее HTTPS-соединение к облаку Cursor. Когда начинается сессия, agent harness в Cursor делает инференс и планирование, затем шлёт вызовы инструментов выделенному воркеру; тот возвращает результаты для следующего раунда. Cursor никогда не инициирует соединение внутрь вашей сети:
Воркеры бывают двух конфигураций:
- My Machines — одна машина (ноутбук, devbox, удалённая VM) привязана к аккаунту. Личные сценарии, проба перед пулом.
- Team Pools — командный пул с сервис-аккаунтом, общая ёмкость, маршрутизация по меткам. Enterprise-функция.
Масштабирование пула происходит автоматически: контроллер следит за очередью и по спавн-скрипту команды поднимает машины под всплеск спроса. Свободный воркер забирает запрос; если свободных нет — запрос ждёт появления ёмкости. Команде не нужно держать заранее рассчитанный флот. Пулы не привязаны к репозиториям: один пул обслуживает много репозиториев.
Как начать: пошагово
Шаг 1. Установите Cursor CLI на машину-воркер
curl https://cursor.com/install -fsS | bash
Шаг 2. Личный сценарий — My Machines
agent login
agent worker start
Процесс долгоживущий: держит соединение, пока вы его не остановите. После этого в окружениях агента появляется ваша машина.
Шаг 3. Командный сценарий — Team Pools
Пул требует enterprise-план Cursor, сервис-аккаунт API-ключ и админскую настройку в дашборде Cloud Agents. Два переключателя у администратора: Allow Self-Hosted Machines (разрешить пользователям опт-ин) и Require Self-Hosted Machines (маршрутизировать каждый запуск Cloud Agent на ваши воркеры):
export CURSOR_API_KEY="<сервис-аккаунт-ключ>"
agent worker --pool gpu --idle-release-timeout 600 start
Для Kubernetes есть шаблон anysphere/k8s-workers: контроллер поднимает pod на запрос (--spawn) или держит тёплые pod’ы (--warm-idle).
Шаг 4. Computer use на Linux и Mac
Чтобы агент кликал и управлял браузером на Linux-воркере, поставьте desktop-пакеты:
sudo apt-get install -y --no-install-recommends \
dbus-x11 ffmpeg tigervnc-standalone-server \
x11-utils x11-xserver-utils xdotool xfce4
На macOS первый запуск ставит helper-приложение Cursor Computer Use, которому нужны права Accessibility и Screen Recording.
Что именно даёт контроль исполнения
Документация и анонс называют три сценария, ради которых команды переносят исполнение к себе:
1. Код и сервисы не могут покидать периметр. Агент должен исполняться внутри сети с прямым доступом к приватному source control, внутренним API и реестрам пакетов. Cursor предлагает сначала попробовать managed-агентов с приватной связностью (PrivateLink, Cloudflare Tunnel) — когда этого мало, воркер внутри сети решает вопрос напрямую.
2. Особое «железо» и ОС. GPU-машины, настоящие Mac для iOS-сборок, Kubernetes, управляемые VM. Свой контур позволяет подключать к агентам то, чего нет в стандартном build-образе Cursor.
3. ОС и пайплайны, которые не упаковываются в Cloud Agent build. Нестандартная ОС или внутренний сборочный конвейер, которые сложно повторить в облачном образе.
Партнёрская экосистема покрывает провайдеров песочниц: AWS Lambda (microVM в вашем аккаунте), Cloudflare, Coder, Daytona, E2B, Modal, Namespace (Mac на Apple silicon), Vercel — воркеры оркеструются там, где уже живут ваши песочницы.
Границы данных: что остаётся у вас, а что уходит
Разбор границы данных — причина, по которой на self-hosted смотрят в первую очередь.
Остаётся на вашей машине: полный checkout репозитория, build-кэш, локальные credentials.
Уходит в Cursor во время работы: содержимое файлов, вывод терминала, диффы, скриншоты, результаты локальных MCP-серверов и routing-метаданные — воркер шлёт Cursor то, что нужно агенту для следующего шага инференса. Артефакты (скриншоты, видео, ссылки на логи) загружаются в управляемое хранилище Cursor, чтобы попадать в PR и дашборд.
Сеть: воркеру нужен исходящий HTTPS к api2.cursor.sh и api2direct.cursor.sh, для артефактов — к cloud-agent-artifacts.s3.us-east-1.amazonaws.com. Входящих портов, публичных IP и VPN-туннелей не требуется. Если загрузка артефактов не нужна — блокируйте исходящий трафик к S3-хосту, сессия продолжит работать.
Privacy Mode распространяется и на self-hosted: при включении код, уходящий с воркера, не используется для обучения ни Cursor, ни провайдерами моделей.
Чек-лист внедрения self-hosted
Прежде чем переносить исполнение на свои машины, пройдите по пунктам:
- Проверьте managed-режим с приватной связностью. Если нужен только доступ к приватному Git или сервисам в VPC — PrivateLink, Cloudflare Tunnel и Tailscale закрывают это без своего флота.
- Определите, что именно не влезает в облачную модель. Контроль железа? GPU? Data residency? ОС? — от ответа зависит, нужен ли вам self-hosted вообще.
- Начните с My Machines. Подключить одну машину — 10 минут. На ней удобно понять границы данных до enterprise-пула.
- Спланируйте образы и гигиену. Воркер — это машина, которой владеет команда: патчи, чистые состояния между сессиями, ротация credentials.
- Настройте idle-timeout и hibernation. Машина, работающая при простаивающем агенте, стоит денег. Гибернация со снапшотом останавливает машину и восстанавливает её при follow-up в окне переподключения.
- Не путайте «исполнение у вас» с «секреты в безопасности». Воркер шлёт Cursor вывод терминала и файлы. Секреты должны жить вне tool-вывода и артефактов — это написано в доках прямо.
- Проверьте, кто администрирует пул. Контроллер, мониторинг, обработка падений хостов — операционная ответственность остаётся командой, а не вендором.
Ограничения на момент публикации (12.09.2026)
Team Pools — только на Enterprise-плане. Пул для команды требует Cursor Enterprise, сервис-аккаунт API-ключ и админ-настройку. My Machines доступна на обычных платных планах, но общая командная ёмкость — enterprise-история.
Agent-loop остаётся в облаке Cursor. Self-hosted — не «полностью офлайн» и не способ убрать зависимость от облака Cursor. Он решает вопрос контроля над исполнением и данными внутри контура.
Артефакты всё равно идут в Cursor. Скриншоты, видео и логи загружаются в хранилище Cursor — код исполняется у вас, но артефакты уходят. Отключение загрузки возможно, но тогда артефакты не появятся в PR и дашборде.
Операционная нагрузка — на команде. Воркеры нужно патчить, обновлять, перезагружать между сессиями и мониторить. Вендор в анонсе прямо называет партнёрские шаблоны «reference architecture»: образ, секреты, политику масштабирования и прод-валидацию вы владеете сами.
Одна сессия — один воркер. Пока агент работает, воркер занят. Для параллельности пул нужно масштабировать.
Лимиты регистрации. До 200 воркеров на пользователя и 1000 на команду; большие развёртывания обсуждаются с Cursor отдельно.
Новизна. Функция анонсирована 02.09.2026 — на момент публикации ей десять дней. Поведение, лимиты и список интеграций могут измениться.
Блок российских реалий
Cursor в целом работает из РФ без VPN — сайт и приложение доступны, блокировок на момент публикации нет. Проблема традиционная — оплата.
Оплата. Cursor принимает Visa, Mastercard, American Express. Российские карты Visa/Mastercard не работают для международных платежей, Mir и UnionPay официально не поддерживаются. Рабочие пути (из обсуждений в русскоязычном сообществе и предыдущих статей):
— карта иностранного банка (Казахстан, Армения, Турция и др.);
— UnionPay российских банков — работает нестабильно, зависит от банка-эквайера;
— посредники по оплате зарубежных подписок — комиссия 10–30%.
Платные планы Cursor — обязательное условие для Cloud Agents; enterprise-пул и подавно недоступен без платёжеспособного аккаунта.
Self-hosted на российской инфраструктуре. Схема воркеров не требует ничего специфичного: машина с исходящим HTTPS к api2.cursor.sh. Технически воркер можно поднять на виртуалке в Yandex Cloud или VK Cloud — соединение исходящее, блокировок этих хостов со стороны российских провайдеров на момент публикации не зафиксировано. Ограничение то же, что и для обычного Cursor: доступ к сервису и оплата Enterprise-подписки.
Русскоязычные материалы. Опыта развёртывания self-hosted-воркеров Cursor на российской инфраструктуре в рунете на момент публикации нет — тема новая, даже англоязычные разборы только появляются. Русскоязычные дискуссии об оплате и работе Cursor из РФ ведутся в r/cursor и на форуме. Если у вас есть опыт — делитесь в комментариях, тема остаётся белым пятном.
Вывод
Контроль исполнения кодинг-агентов — это выбор места, где код агента физически работает, и ответ на вопрос, кто владеет этой машиной. На сентябрь 2026 года у команды три варианта: облако вендора (по умолчанию, покрывает более 80% сценариев), self-hosted пулы Cursor (исполнение в вашей сети при инференсе в облаке) и локальный запуск с песочницами.
Self-Hosted Machines показателен тем, что разделяет agent-loop и исполнение инструментов: вендор не отдаёт «мозг», но отдаёт «руки» под ваш контроль. Для команд с приватной инфраструктурой, особым железом и требованиями к data residency это снимает главный барьер облачных агентов. Для команд из РФ барьер остаётся не техническим, а финансовым: воркер на российской VM возможен, но оплата Cursor и enterprise-функции требуют зарубежного платёжного контура.
Связанные статьи
- Кейс: Cursor на ваших машинах — self-hosted cloud-агенты для команд — разбор анонса, настройка пулов и провайдеры.
- Кейс: Cursor Cloud Agents без репозитория — старт агента с нуля, Origin repo.
- Как пользоваться Cursor — установка, правила, режимы агента.
- Безопасность ИИ-агентов — цепочка угроз и уровни защиты.
- Песочницы для ИИ-агентов — изоляция исполнения как слой защиты.
