Секреты и сеть
Cloud Agents доступны в режиме конфиденциальности. Мы никогда не обучаем ИИ на вашем коде и храним его только на время работы агента. Подробнее о режиме конфиденциальности.
Описание архитектуры и защиты Cloud Agents, включая жизненный цикл запуска, модель доступа, изоляцию, шифрование и обработку данных, см. в разделе Обзор безопасности. Эта страница содержит справочную информацию по конфигурации описанных в нём элементов управления.
Режим конфиденциальности (устаревшая версия) не поддерживается. Устаревший режим конфиденциальности блокирует облачное хранение данных, а Cloud Agents необходимо хранить код и данные инфраструктуры в облаке во время работы. Перед использованием Cloud Agents переключитесь в режим конфиденциальности в Дашборд → Cloud Agents.
Защита секретов
Секреты, передаваемые Cloud Agents, шифруются при хранении и передаче. Они доступны только пользователю Cloud Agent.
Секреты можно задать как переменные среды, секреты времени выполнения или секреты сборки.
Переменные среды
Секреты типа Environment Variable доступны облачному агенту. Их лучше использовать для неконфиденциальных настроек, которые могут быть полезны агенту, например флагов или общедоступных URL. Как и другие типы секретов, они по-прежнему шифруются при хранении и передаче.
Секреты времени выполнения
Ранее Runtime Secrets назывались Redacted Secrets.
Секреты типа Runtime Secret по-прежнему загружаются как переменные среды, но их содержимое скрывается в результатах вызовов инструментов агента, истории чата, коммитах и сообщениях коммитов и заменяется строкой-заполнителем [REDACTED]. Они лучше всего подходят для конфиденциальных учетных данных, которые не должны быть доступны агенту и никогда не должны попадать в репозиторий.
Хотя Runtime Secrets по-прежнему работают как переменные среды, они не отображаются агенту, но видны пользователям, взаимодействующим со средой агента через Терминал.
Секреты сборки
Секреты типа Build Secret доступны только процессу сборки Docker (если он настроен) и не передаются в среду запущенного Agent. Они лучше всего подходят для приватных реестров пакетов или учётных данных, используемых при сборке и не предназначенных для Agent.
Чтобы безопасно использовать Build Secret в Dockerfile, укажите его на шаге RUN с помощью монтирования секрета Docker, например:
RUN --mount=type=secret,id=MY_TOKEN,env=MY_TOKEN,required=true \ ./scripts/install-private-deps.shТокены идентификации OIDC
Для облачных ролей и внутренних API вместо долгосрочных ключей в секретах предпочтительно использовать краткосрочные токены OIDC. Облачный агент может через локальный socket выпустить JWT, подписанный Cursor, и предъявить его AWS, GCP, Azure, Vault или любому средству проверки OIDC.
Подписанные коммиты
Cloud Agents подписывают каждый коммит ключом Ed25519, защищённым HSM. На GitHub и GitLab такие коммиты помечаются значком «Verified», чтобы ваша команда могла убедиться, что коммит создан Cursor.
Это автоматически работает для всех Cloud Agents. Настройка не требуется.
Если в вашем репозитории действуют правила защиты веток, требующие подписанных коммитов, PR от Cloud Agent соответствуют этим правилам без дополнительной настройки.
Защищённая область Git
Администраторы команд могут связать организацию Git с вашей организацией Cursor, чтобы только ваши команды могли запускать облачных агентов в её репозиториях. См. Защищённая область Git.
Что нужно знать
- Предоставьте нашему GitHub app права на чтение и запись для репозиториев, которые хотите редактировать. Это нужно, чтобы клонировать репозиторий и вносить изменения.
- Ваш код выполняется в изолированных виртуальных машинах нашей инфраструктуры AWS и хранится на дисках ВМ, пока агент доступен.
- По умолчанию агент имеет доступ к интернету. Вы можете настроить контроль исходящего сетевого трафика для пользователей, команд и сохранённых инфраструктур, чтобы ограничить доступные агенту домены.
- Агент автоматически выполняет все терминальные команды, благодаря чему может многократно запускать тесты. В отличие от него, агент на переднем плане требует одобрения пользователя для каждой команды. Автоматическое выполнение создаёт риск утечки данных: злоумышленники могут провести промпт-инъекцию и обманом заставить агента загрузить код на вредоносные сайты. См. объяснение OpenAI о рисках промпт-инъекций для облачных агентов.
- Если режим конфиденциальности отключён, мы собираем промпты и среды разработки, чтобы улучшать продукт.
- Если при запуске облачного агента отключить режим конфиденциальности, а затем включить его во время работы агента, до завершения работы агент будет работать с отключённым режимом конфиденциальности.
Хранение данных
Cloud Agents хранят два типа данных для каждого запуска:
- История диалога. Промпты, ответы модели, вызовы инструментов и демонстрационные артефакты, из которых состоит транскрипт агента. Эти данные отображаются при открытии агента в веб-версии или настольном клиенте.
- Снимки инфраструктуры. Зашифрованные копии диска виртуальной машины на определённый момент времени. Снимки позволяют настраивать инфраструктуру VM и запускать или возобновлять работу агентов без повторного клонирования репозитория и выполнения настройки.
По умолчанию история диалога хранится бессрочно, чтобы вы могли возвращаться к прошлым запускам и возобновлять их. Снимки инфраструктуры хранятся не более 90 дней с момента последнего использования. Каждый раз, когда агент запускается или возобновляет работу из снимка, срок его хранения продлевается ещё на 90 дней. Если снимок не используется в течение 90 дней, он удаляется автоматически — независимо от тарифа или политики.
Чтобы явно удалить историю диалога облачного агента, используйте Delete Agent API. Эта конечная точка удаляет транскрипт диалога и связанные с ним артефакты. Снимки инфраструктуры она не удаляет: их нельзя удалить по запросу, и для них действует указанный выше срок хранения.
Политики хранения данных облачных агентов
Пользовательские сроки хранения в раннем доступе для некоторых команд Enterprise. Свяжитесь с отделом продаж, чтобы запросить доступ.
Администраторы команд Enterprise могут ограничить срок хранения данных Cloud Agent своей команды в Настройках команды на дашборде Cloud Agents. Доступны следующие сроки: Бессрочно и 90 дней.
Если установить срок 90 дней:
- Фоновая задача удаляет диалоги, срок хранения которых превышен.
- Снимки инфраструктуры по-прежнему следуют описанному выше скользящему 90-дневному периоду неактивности.
- Политика применяется ко всем запускам агентов команды, включая запуски из сохранённых инфраструктур и через API.
При переключении обратно на Бессрочно дальнейшее удаление диалогов прекращается, но уже удалённые данные не восстанавливаются.
Сетевой доступ
Настройте, к каким сетевым ресурсам могут получать доступ ваши Cloud Agents. Эти настройки доступны на дашборде Cloud Agents для отдельных пользователей, сохранённых инфраструктур и администраторов команд.
Доступ к приватной сети
Cloud Agents не обязательно запускать на вашем оборудовании, чтобы получать доступ к приватным ресурсам. Для сервисов в VPC или интрасети используйте пользовательскую сеть Tailscale, Cloudflare Tunnel или аналогичный клиент для приватной сети в среде Cloud Agent. Примечания по настройке см. в разделах Running Tailscale и Запуск Cloudflare Tunnel.
При использовании Tailscale или Cloudflare Tunnel вашим приватным сервисам не нужно принимать входящий трафик из публичного интернета. Агент подключается по аутентифицированному сетевому пути, а сервис остаётся в вашей приватной сети.
Cloudflare Tunnel подходит, если агент может обращаться к приватному сервису через аутентифицированное HTTPS-имя хоста. Коннектор в вашей сети устанавливает исходящее подключение к Cloudflare, а Cloud Agent обращается к этому имени хоста как к любому другому внешнему URL. Вы можете защитить имя хоста сервисными токенами Cloudflare Access, сохранить значения токенов в Cursor Secrets и добавить имя хоста в allowlist Cloud Agent.
Для TCP-целей, таких как приватные базы данных, используйте клиент туннеля, который открывает локальный TCP-порт в среде агента. Затем агент подключается к localhost, а туннель перенаправляет трафик к приватному источнику.
Для приватных GitHub Enterprise Server, GitLab Enterprise, API систем контроля версий, реестров пакетов, таких как Artifactory или Nexus, и связанного трафика webhook команды Enterprise могут использовать приватное подключение с AWS PrivateLink или Cloudflare Tunnel.
Режимы доступа
Три режима определяют исходящий сетевой доступ для облачных агентов:
| Режим | Поведение |
|---|---|
| Allow all network access | Облачные агенты могут подключаться к любому внешнему хосту. Ограничения на домены отсутствуют. |
| Default + allowlist | Облачные агенты могут подключаться к доменам по умолчанию, а также к любым доменам, добавленным вами в allowlist. |
| Allowlist only | Облачные агенты могут подключаться только к доменам, явно добавленным вами в allowlist. |
Даже в режиме Allowlist only небольшой набор доменов остаётся доступным для работы облачных агентов. К ним относятся собственные сервисы Cursor и провайдеры систем управления исходным кодом (SCM).
Загрузка артефактов
Cloud Agents загружают артефакты (скриншоты, видео и ссылки на журналы, отображаемые в PR) на cloud-agent-artifacts.s3.us-east-1.amazonaws.com.
Если вы используете Default + allowlist или Allowlist only, добавьте в allowlist точный хост, чтобы загрузка артефактов работала. Не расширяйте запись до *.s3.us-east-1.amazonaws.com: подстановочный знак открывает исходящий доступ ко всем бакетам в регионе и создаёт канал для эксфильтрации данных агентом с внедрённым промптом. Блокировка хоста отключает загрузку; сессии агентов и другие вызовы инструментов продолжат работать.
Настройки на уровне пользователя
Пользователи могут настроить режим сетевого доступа на дашборде Cloud Agents в разделе Безопасность. Эта настройка применяется ко всем создаваемым вами Cloud Agents.
При выборе режима с allowlist (По умолчанию + allowlist или Только allowlist) под этим параметром появится раздел настройки allowlist, где можно добавить пользовательские домены.
Настройки на уровне инфраструктуры
Сохранённые инфраструктуры могут иметь собственный режим сетевого доступа и allowlist. Используйте настройки на уровне инфраструктуры, если для одного репозитория или группы репозиториев требуется более строгий исходящий доступ, чем для остальной команды.
Например, для инфраструктуры, близкой к production, можно выбрать режим Allowlist only, а для менее чувствительной — Default + allowlist. Agents, использующие более строгую инфраструктуру, наследуют эти ограничения.
Настройки на уровне инфраструктуры предусматривают два варианта наследования:
| Режим | Поведение |
|---|---|
| Наследовать настройки | Использует применимый параметр сетевого доступа пользователя или команды. |
| Наследовать настройки + allowlist инфраструктуры | Использует применимый параметр пользователя или команды и добавляет домены из allowlist инфраструктуры. |
Можно также напрямую задать для инфраструктуры режим Allow all network access, Default + allowlist или Allowlist only.
Настройки на уровне команды
Администраторы команды могут задать режим сетевого доступа по умолчанию для всей команды в том же дашборде. Allowlist на уровне команды — это тот же allowlist, который администраторы настраивают для allowlist сети по умолчанию в песочнице. Отдельно управлять allowlist не нужно: один allowlist контролирует и сетевой доступ облачного агента, и настройки песочницы по умолчанию.
Если задан параметр уровня команды:
- Если для инфраструктуры задан собственный режим, к агентам, использующим эту инфраструктуру, применяется настройка инфраструктуры.
- Если инфраструктура наследует настройки, а пользователь настроил собственный параметр, настройка пользователя имеет приоритет.
- Если ни для инфраструктуры, ни для пользователя не задан параметр, применяется настройка команды по умолчанию.
Блокировка параметра (Enterprise)
Блокировка доступна только для команд Enterprise.
Администраторы команд Enterprise могут заблокировать параметр сетевого доступа с помощью опции Lock Network Access Policy. После блокировки:
- Параметр на уровне команды применяется ко всем участникам независимо от их личных предпочтений.
- Пользователи не могут изменить заблокированный параметр в своём дашборде.
Это даёт администраторам полный контроль над сетевым доступом облачных агентов во всей организации.
Связь с политикой сетевого доступа песочницы
Домены «Default» в режиме Default + allowlist совпадают с сетевым allowlist по умолчанию, используемым в песочнице Agent для Desktop. Allowlist на уровне команды также общий: когда администратор настраивает allowlist в дашборде, он применяется как к сетевому доступу облачного агента, так и к политике сетевого доступа песочницы.
Диапазоны исходящих IP-адресов
Cloud Agents подключаются к внешним сервисам, API или репозиториям с IP-адресов из определённых диапазонов.
API endpoint
Диапазоны IP-адресов доступны через конечную точку JSON API:
curl https://cursor.com/docs/ips.jsonФормат ответа
{ "version": 1, "modified": "2025-09-24T16:00:00.000Z", "cloudAgents": { "us3p": ["100.26.13.169/32", "34.195.201.10/32", "..."], "us4p": ["54.184.235.255/32", "35.167.37.158/32", "..."], "us5p": ["3.12.82.200/32", "52.14.104.140/32", "..."] }, "gitEgressProxy": ["184.73.225.134/32", "3.209.66.12/32", "52.44.113.131/32"]}- version: Номер версии схемы ответа API
- modified: Метка времени ISO 8601 последнего обновления диапазонов IP-адресов
- cloudAgents: Объект с диапазонами IP-адресов, сгруппированными по кластерам
- gitEgressProxy: IP-адреса, используемые прокси исходящего Git-трафика
Диапазоны IP-адресов публикуются в нотации CIDR. При необходимости можно использовать онлайн-инструмент для преобразования нотации CIDR в диапазоны IP-адресов.
Использование диапазонов IP-адресов
Cloud Agents могут использовать опубликованные диапазоны IP-адресов для следующего:
- Клонирования удалённых репозиториев и отправки в них изменений (если не используется прокси исходящего Git-трафика)
- Загрузки пакетов и зависимостей
- Выполнения API-вызовов к внешним сервисам
- Доступа к веб-ресурсам во время работы агента
Если в вашей организации для управления сетевым доступом используются правила брандмауэра или allowlist IP-адресов, возможно, потребуется добавить эти диапазоны IP-адресов в allowlist, чтобы Cloud Agents могли корректно обращаться к вашим сервисам.
Важно:
- Мы периодически меняем IP-адреса для масштабирования и других операционных задач.
- Не рекомендуем использовать allowlist IP-адресов в качестве основного механизма безопасности.
- Если вам необходимо использовать эти диапазоны IP-адресов, настоятельно рекомендуем регулярно отслеживать конечную точку JSON API.
Прокси исходящего Git-трафика и список разрешённых IP-адресов
Cursor поддерживает похожую, но отдельную функцию: использование прокси исходящего Git-трафика для списка разрешённых IP-адресов. Этот прокси направляет весь Git-трафик через более ограниченный набор IP-адресов и работает со всеми Git-хостами, включая GitHub, GitLab, Azure DevOps и Bitbucket.
Для Git-хостов мы рекомендуем конфигурацию списка разрешённых IP-адресов, описанную по ссылке выше, поскольку она напрямую интегрируется с приложением Cursor для GitHub.
Если вам нужно добавить IP-адреса прокси непосредственно в allowlist, используйте следующие адреса:
184.73.225.1343.209.66.1252.44.113.131IP-адреса Origin
Если ваша команда использует облачные агенты вместе с Origin, добавьте в allowlist следующие IP-адреса в дополнение к указанным выше IP-адресам прокси исходящего Git-трафика:
34.192.39.18250.16.106.25544.217.29.1243.223.245.20154.164.185.1034.194.133.2335.170.116.221Эти IP-адреса постоянны. Если список изменится, команды, использующие списки разрешённых IP-адресов, будут заранее уведомлены о добавлении или удалении адресов.
Корпоративные клиенты с приватными развёртываниями GitHub Enterprise Server или GitLab Enterprise могут использовать варианты приватного подключения, чтобы облачные агенты и Bugbot могли получать доступ к приватным системам контроля версий.
