AIREITERДаже если worker находится за вашим файрволом, он всё равно может отправлять Cursor фрагменты исходного кода, вывод терминала, diff-файлы и скриншоты. Cursor Self-Hosted Machines — это self-hosted-исполнение, а не self-hosted-агент и не изолированная от интернета установка Cursor.
В этом обзоре разбираем, какие данные пересекают границу инфраструктуры и что на самом деле меняют доступные настройки. За основу взяты анонс Cursor от 2 сентября 2026 года, документация Self-Hosted Machines и политика использования данных.
Где проходит граница данных: краткая таблица
Cursor делит запуск Cloud Agent между своим облаком и worker, которым управляете вы. Слово «self-hosted» описывает место исполнения, но не означает, что все системы и потоки данных находятся внутри вашей инфраструктуры.
| Данные или система | Где выполняется или хранится | Может попасть в Cursor? | Что важно учитывать |
|---|---|---|---|
| Цикл работы агента, inference и планирование | Облако Cursor | Уже находятся в Cursor | Self-Hosted Machines их не переносит. |
| Изменение файлов и команды терминала | Ваш worker | Результаты могут возвращаться | Инструменты запускаются на worker. |
| Полная рабочая копия и build cache | Ваш worker | Не передаются автоматически | Полный checkout остаётся локальным. |
| Учётные данные на машине | Ваш worker | Не передаются автоматически | Не допускайте попадания секретов в команды, вывод и артефакты. |
| Содержимое файлов и diff-файлы | Ваш worker, затем контекст и результаты агента | Да, когда это необходимо | Privacy Mode регулирует использование для обучения, а не сам факт передачи. |
| Вывод терминала и результаты локального MCP | Ваш worker, затем результаты инструментов | Да, когда возвращаются агенту | В результатах может быть код или чувствительные данные. |
| Скриншоты и трансляция рабочего стола | Ваш worker, затем Cursor, когда данные создаются или передаются | Да | Сессии computer use могут передавать изображение рабочего стола агента. |
| Видео, скриншоты и ссылки на логи | Хранилище артефактов под управлением Cursor | Да, по умолчанию | Чтобы отключить загрузку, заблокируйте хост артефактов. |
| Запросы к модели с API-ключом | Через инфраструктуру обработки Cursor | Да | BYOK не обходится без backend Cursor. |
Ключевое различие простое: весь репозиторий может оставаться на вашей машине, но отдельные фрагменты его содержимого всё равно будут передаваться по сети для inference. Это частичный контроль над исполнением, а не гарантия отсутствия исходящего трафика.
Что именно Cursor переносит в вашу инфраструктуру
Self-Hosted Machines переносят на контролируемую заказчиком машину исполнение инструментов. Worker может редактировать файлы, запускать команды, обращаться к внутренним сервисам, управлять браузером и подключаться к локальным MCP-серверам. При этом цикл работы агента, inference, планирование и оркестрация сессии остаются в облаке Cursor.
Worker запускается командой Cursor CLI agent worker start. После этого он открывает постоянное исходящее HTTPS-соединение с Cursor. По документации Cursor, соединение инициируется самим worker: не нужны ни входящий порт, ни публичный IP-адрес, ни VPN-туннель.
Заявленный сценарий сессии выглядит так:
- Пользователь запускает сессию Cloud Agent в интерфейсе Cursor.
- Облачный цикл агента Cursor планирует следующее действие.
- Cursor отправляет вызов инструмента через соединение с worker.
- Worker выполняет команду, редактирование, действие в браузере или операцию MCP.
- Worker возвращает результат для следующего шага inference.
Worker всё равно должен иметь исходящий доступ к api2.cursor.sh и api2direct.cursor.sh; обновления CLI и некоторые сценарии computer use также могут требовать доступа к downloads.cursor.com. Модель с исходящим соединением избавляет от необходимости открывать входящий доступ в сеть, но не превращает worker в автономную среду запуска модели.
Cursor предлагает такую архитектуру для приватных репозиториев и сервисов, недоступных hosted-worker, а также для специализированного оборудования — например, GPU или Mac — и нестандартных операционных систем и build-образов. Если вам нужна только приватная связность, руководство Cursor по выбору runtime сначала рекомендует рассмотреть управляемые Cloud Agents с allowlist, сети наподобие Tailscale, AWS PrivateLink или Cloudflare Tunnel.
Какие данные уходят с worker и что меняет Privacy Mode
В документации Cursor прямо перечислены содержимое файлов, вывод терминала, diff-файлы, скриншоты, результаты локального MCP и служебные данные маршрутизации — worker может отправлять их наружу. При оценке приватности важно разделять три разных вопроса: что именно передаётся, используется ли это для обучения и как долго данные хранятся.
Privacy Mode ограничивает обучение, но не исходящий трафик
На странице Data Use & Privacy Overview, обновлённой 28 августа 2026 года, Cursor сообщает, что Privacy Mode запрещает использовать Customer Data для обучения Cursor, а также заявляет о соглашениях с провайдерами, предусматривающих нулевое хранение данных. Но там же есть важное уточнение: классификаторы рисков могут сохранять prompts или переписки для расследований, а временное кэширование файлов возможно ради снижения задержек и оптимизации сетевого обмена.
Cursor описывает кэшированные файлы как зашифрованные ключами, сгенерированными на стороне клиента; сами ключи хранятся на серверах Cursor на время выполнения запроса. Это заявление Cursor об удержании и защите данных, а не доказательство того, что запрос вообще не попадает на серверы Cursor.
Важен и нюанс с API-ключами. Cursor прямо говорит, что использование собственного ключа провайдера не обходит его backend: запросы всё равно проходят через Cursor для финальной сборки prompt. BYOK может изменить сторону, которая авторизует использование модели, но не превращает соединение в прямой приватный маршрут от клиента к провайдеру.
Один из пользователей, разбирая эту функцию, провёл ту же архитектурную границу:
«Важная граница: self-hosted machines в Cursor переносят исполнение, а не весь агент. Cursor говорит, что inference и планирование остаются в его облаке; результаты инструментов возвращаются обратно и могут содержать код. При проверке безопасности относитесь к этому как к self-hosted-исполнению, а не к self-hosted-агенту». — @ham_zax, X
Отключение артефактов не создаёт воздушный зазор
Cursor документирует узкий способ остановить загрузку артефактов: заблокировать исходящий HTTPS-трафик к cloud-agent-artifacts.s3.us-east-1.amazonaws.com. Вызовы инструментов и их результаты продолжат работать, но скриншоты, видео и ссылки на логи не появятся в pull request или на панели Cursor.
Это полезно, если организации не нужны визуальные артефакты. Но полноценным решением для приватности такая блокировка не является: содержимое файлов, вывод терминала, diff-файлы, скриншоты, использованные во время inference, и результаты MCP всё ещё могут возвращаться через соединение сессии агента.
У MCP-транспорта есть ещё одна важная особенность. В документации Cursor о Team Pools сказано, что MCP-серверы, запускаемые командой, то есть stdio-серверы, работают на worker и могут обращаться к приватным сетям. HTTP/SSE MCP-серверы обрабатываются backend Cursor для OAuth, кэширования сессий и аутентификации. Поэтому для приватной MCP-точки нужно проверять не только расположение хоста, но и используемый транспорт.
Выбирайте runtime по ограничению, а не по названию
Cursor предлагает три варианта runtime. Self-hosting имеет смысл, когда контролируемая граница исполнения, конкретное оборудование или особая среда — это формальное требование, а не просто предпочтение.
| Runtime | Где выполняются вызовы инструментов | Когда подходит | Что остаётся на вашей стороне |
|---|---|---|---|
| Управляемые Cursor Cloud Agents | Изолированная VM под управлением Cursor | Большинству команд, которым подходят управляемая сеть и стандартные среды на базе Ubuntu | Cursor управляет жизненным циклом VM, ёмкостью, изоляцией и удалением после настройки вашей среды. |
| My Machines | Ноутбук, devbox, Mac или VM отдельного пользователя | Персональный рабочий процесс, репозиторий с локальным состоянием или быстрый proof of concept | Вы отвечаете за доступность машины, credentials, зависимости, очистку и checkout. |
| Team Pools | Worker, которыми управляет организация | Корпоративные парки машин, GPU, Mac, Kubernetes, маршрутизация по labels и централизованная ёмкость | Команда управляет хостами, образами, секретами, масштабированием, мониторингом, сбросом состояния и сбоями. |
Выбирайте managed Cloud Agents, если нужна только приватная связность
Managed Cloud Agents могут оказаться достаточными, если организация может задать границу через права доступа к репозиториям, сетевые allowlist, клиент наподобие Tailscale или поддерживаемое приватное подключение. В руководстве по выбору runtime Cursor рекомендует управляемую инфраструктуру большинству команд и называет её вариантом с меньшими операционными затратами.
Так вы не берёте на себя эксплуатацию парка worker, сохраняя управляемый Cursor жизненный цикл VM и эластичную параллельность. Это не означает, что managed agents не передают данные; лишь средой исполнения управляет Cursor, а не ваша команда.
Выбирайте My Machines для одного пользователя и контролируемой среды
My Machines подключает персональную машину к индивидуальному аккаунту Cursor. Вариант удобен, когда у разработчика уже настроены Mac, devbox или удалённая VM с локальными зависимостями и сетевым доступом, которые было бы сложно воспроизвести в другом месте.
Компромисс — операционная нагрузка. Для активных сессий машина должна оставаться онлайн, а пользователь отвечает за очистку, актуальность checkout, состояние диска, credentials и восстановление зависимостей. В документации Cursor по self-hosted сказано, что на одной машине могут работать несколько агентов, но это всё же не централизованная модель командного парка.
Выбирайте Team Pools, только если централизованный контроль оправдывает сложность
Team Pools рассчитаны на команды Enterprise. Они используют аутентификацию через service account, общую ёмкость worker, labels и масштабирование на основе controller. Pool с label gpu может направлять задачи на GPU-машины, а pool ios — на Mac. Cursor документирует до 200 worker на пользователя и 1 000 worker на команду; для более крупных развёртываний потребуется отдельное обсуждение масштабирования.
Pools могут масштабироваться до нуля и использовать persistent-, containerized-, Kubernetes- или partner-hosted worker. Cursor сообщает, что восстановление освобождённого workspace может занимать несколько минут. Такая гибкость полезна для неравномерных нагрузок, но управление образами, сбросом worker, планированием ёмкости, ротацией секретов и мониторингом ложится на заказчика.
Стоимость — это инфраструктура плюс использование моделей
В документации Self-Hosted Machines и на странице Cursor Models & Pricing описано, кто отвечает за модели, тариф и инфраструктуру, но отдельная плата за каждый worker Self-Hosted Machines не указана. Заявленная модель расходов такова: вы по-прежнему платите Cursor за выбранную модель, а дополнительно оплачиваете машину, контейнер, кластер, хранилище, сеть, мониторинг и эксплуатацию, которые запускаете сами.
Поэтому self-hosting — слабый аргумент для экономии, если у вас нет особых требований к сети или оборудованию. Динамические pools и гибернация могут сократить расходы на простаивающие ресурсы, но точка окупаемости зависит от характера нагрузки, времени запуска и объёма состояния, которое приходится восстанавливать; универсального расчёта Cursor не публикует.
Чек-лист безопасности перед включением
Пройдите этот список вместе с ответственными за безопасность, платформу или compliance. Само слово «self-hosted» не должно автоматически считаться основанием для одобрения.
- Точно сформулируйте границу. Определите, что именно по политике должно оставаться внутри периметра: полный checkout, исполнение инструментов, credentials, inference-запросы, артефакты или всё сразу. Self-Hosted Machines помещает под ваш контроль только worker исполнения и полное локальное состояние.
- Классифицируйте возвращаемый контекст. Содержимое файлов, diff-файлы, вывод терминала, скриншоты и результаты MCP могут отправляться в Cursor. Проверьте, могут ли они содержать исходный код, данные клиентов, токены, внутренние URL или ответы production-систем.
- Осознанно включите Privacy Mode. Он меняет заявленные Cursor правила использования данных для обучения и хранения у провайдеров, но не запрещает обработку запросов, временное кэширование или работу механизмов выявления рисков.
- Правильно учитывайте BYOK. Согласно странице Cursor об использовании данных, API-ключ не убирает backend Cursor из цепочки запроса.
- Отдельно решите вопрос с артефактами. Разрешите или заблокируйте
cloud-agent-artifacts.s3.us-east-1.amazonaws.comв зависимости от того, приемлемы ли для вас скриншоты, видео и ссылки на логи в PR и на панели. Если файрвол поддерживает точные правила, используйте правило для конкретного хоста. - Составьте allowlist исходящих соединений. Разрешайте только документированные endpoints Cursor и те хосты обновлений или computer use, которые вы намеренно включили. Worker не должен требовать ни входящего порта, ни публичного IP.
- Проверьте транспорт MCP. Используйте worker-side stdio MCP, если серверу необходимо обращаться к приватному сервису, и отдельно оцените возвращаемые результаты. Не считайте, что HTTP/SSE MCP остаётся внутри вашей сети только потому, что сам сервис приватный.
- Изолируйте worker и настройте сброс. Для Team Pools заранее определите, как машины очищаются или пересоздаются между агентами, как передаются credentials и как контролируются логи. Руководства и шаблоны Cursor — это эталонные архитектуры, а не полностью управляемый production-парк.
- Проверьте сценарии отказа. Убедитесь, что произойдёт при недоступности endpoints Cursor, хранилища артефактов, worker, приватного registry или MCP-сервера. Блокировку хоста артефактов нельзя путать с блокировкой сессии агента.
- Откажитесь от решения для air-gapped-нагрузок. Если требуется запретить любую исходящую передачу контекста модели или исключить inference в стороннем облаке, эта архитектура не подходит. Цикл работы агента остаётся в облаке Cursor.
| Ваше реальное требование | Решение |
|---|---|
| Команды, локальное состояние или специализированное оборудование должны работать в вашей среде | Используйте Self-Hosted Machines с контролем передачи контекста и артефактов. |
| Агентам нужен доступ к приватным сервисам, но исполняться они могут в управляемой VM | Начните с managed Cloud Agents и поддерживаемого приватного подключения. |
| Контекст модели не должен покидать сеть или inference должен работать офлайн | Откажитесь от этой архитектуры: она по-прежнему зависит от облака Cursor. |
FAQ о приватности Cursor Self-Hosted Machines
Cursor Self-Hosted Machines полностью self-hosted?
Нет. Цикл работы агента, inference, планирование и оркестрация остаются в облаке Cursor. Ваша машина размещает исполнение инструментов и локальное рабочее состояние.
Исходный код покидает self-hosted-машину?
Отдельные фрагменты содержимого файлов, diff-файлы, вывод терминала, скриншоты и результаты локального MCP могут покидать worker как входные данные или результаты инструментов для агента. Cursor говорит, что полный checkout и build cache остаются на worker, поэтому граница здесь частичная, а не абсолютная.
Privacy Mode не даёт данным пересекать сеть?
Нет. Privacy Mode описывается как запрет на использование данных Cursor и провайдерами моделей для обучения в рамках заявленных Cursor условий хранения. Но он не мешает worker отправлять контекст, необходимый для inference.
BYOK обходит Cursor?
Нет. На странице Cursor об использовании данных сказано, что запросы с API-ключом всё равно проходят через backend для финальной сборки prompt. BYOK нельзя считать прямым соединением между вашим worker и провайдером модели.
Можно ли запретить загрузку скриншотов и видео?
Можно заблокировать исходящий доступ к cloud-agent-artifacts.s3.us-east-1.amazonaws.com. Исполнение инструментов продолжится, но артефакты не появятся в pull request или на панели Cursor. При этом другие данные сессии агента всё ещё могут возвращаться в Cursor.
Нужно ли worker входящее правило файрвола или VPN?
Cursor документирует модель с исходящим соединением. По его данным, входящий порт, публичный IP и VPN-туннель не требуются, хотя worker по-прежнему должен иметь исходящий доступ к документированным endpoints Cursor и сервисам, которые он использует.
Можно ли использовать Team Pools на персональном или более дешёвом тарифе?
Cursor позиционирует Team Pools для Enterprise и требует API-ключ service account. Для персонального worker предусмотрен My Machines; не следует рассчитывать, что персональный API-ключ сможет запустить worker Team Pool.
Можно ли полностью работать с Cursor Self-Hosted Machines офлайн?
Нет. Цикл работы агента и inference остаются в облаке Cursor, а worker требует исходящего соединения. Для офлайн- или air-gapped-сценария нужна другая архитектура с локальными оркестрацией и inference модели.
Используйте Cursor Self-Hosted Machines, если команде нужны контролируемое заказчиком исполнение, доступ к приватной сети, специализированное оборудование или постоянная среда. Если же задача — не выпускать AI-трафик в облако, выбирайте другую архитектуру: эта функция меняет место выполнения команд, но не место, где агент «думает».