Обзор безопасности
На этой странице объясняется, как устроены и защищены Cloud Agents. Здесь по шагам описано, что происходит при запуске агента, как предоставляется доступ, где хранятся код и данные, как они изолируются и шифруются, а также какие средства управления доступны вам на каждом этапе. Она отвечает на вопросы, которые обычно возникают, когда команда оценивает Cloud Agents на соответствие своим требованиям безопасности.
Справочную информацию по конфигурации, включая типы секретов, режимы сетевого доступа и диапазоны IP-адресов исходящего трафика, см. в разделе Секреты и сеть. Сведения о федерации ВМ с AWS, GCP, Azure или пользовательским верификатором без долгоживущих ключей см. в разделе Токены OIDC. На этой странице объясняется модель, лежащая в основе этих средств управления; на этих страницах — как их задать.
Это дополнение к основной документации Cursor по безопасности. Сведения о сертификациях, субобработчиках и архитектуре см. в Trust Center, а в справочнике Усиление безопасности и конфиденциальности — о средствах управления, которые находятся в вашей зоне ответственности во всем Cursor. Cursor соответствует требованиям SOC 2 Type 2 и обязуется проводить тестирование на проникновение не реже одного раза в год силами авторитетных сторонних организаций.
Как работают Cloud Agents
Cloud Agent — это агент для написания кода, который работает в виртуальной машине в облаке Cursor, а не на ноутбуке разработчика. Виртуальная машина содержит полную инфраструктуру разработки: клонированный репозиторий, установленные зависимости, настроенные секреты и сетевой доступ.
Один запуск проходит через следующие этапы:
- Start. Пользователь или интеграция запускает задачу из веб-приложения, IDE, CLI, API, Slack либо из связанной задачи или pull request.
- Provision. Cursor выделяет для этого агента изолированную виртуальную машину и клонирует в неё репозиторий, к которому предоставлен доступ.
- Run. Агент запускает код и инструменты внутри виртуальной машины и в реальном времени передаёт пользователю ход выполнения, выходные данные и артефакты.
- Persist. Состояние диалога, метаданные и артефакты сохраняются в хранилище под управлением Cursor, чтобы вы могли просмотреть и возобновить запуск.
- Hand off. Агент отправляет свою ветку и открывает черновой pull request, чтобы человек провёл ревью до слияния.
- Recycle. Ресурсы виртуальной машины переводятся в режим гибернации, а затем удаляются по таймерам жизненного цикла, когда запуск становится неактивным.
Доступ и авторизация
Cloud Agents получают доступ к вашему коду через приложение Cursor для GitHub или GitLab, а не через чьи-либо личные учётные данные.
- Администраторы устанавливают приложение. Для включения Cloud Agents требуются права администратора и в Cursor, и у вашего Git-провайдера. Администратор устанавливает приложение Cursor в вашей Git-организации и предоставляет доступ только к тем репозиториям, которые вы выберете.
- Пользователи подключают свой аккаунт. После установки приложения каждый пользователь, который хочет запустить агент, подключает свой Git-аккаунт. Это второй уровень — для пользователя — поверх установки на уровне организации.
- Доступ наследуется и никогда не расширяется. Cloud Agent может получить доступ только к тем репозиториям, к которым уже есть доступ у пользователя, который его запускает. Запуск агента никогда не даёт пользователю доступ к репозиторию, к которому у него его раньше не было.
Администраторы команд могут пойти дальше и привязать Git-организацию к вашей организации Cursor с помощью Защищённая область Git, чтобы только ваши команды могли запускать Cloud Agents для её репозиториев. Вы также можете полностью исключить конфиденциальные репозитории с помощью список блокировки репозитория.
Сотрудники Cursor не имеют доступа к коду внутри ВМ Cloud Agent. Попытки доступа отслеживает команда безопасности Cursor.
Изоляция и инфраструктура
Каждый агент работает в пределах собственной ВМ, а не в общей песочнице процесса. Один агент не может видеть код, инфраструктуру или состояние другого агента.
- Отдельные ВМ для каждого агента. Каждый агент получает выделенную инфраструктуру, изолированную от других агентов и пользователей.
- Изоляция на уровне microVM. Рабочие пространства среды выполнения работают на инфраструктуре microVM на базе Firecracker.
- Разделение на уровне аккаунтов. ВМ Cloud Agent работают в отдельном аккаунте AWS, отдельно от остальной производственной инфраструктуры Cursor, поэтому среда выполнения кода изолирована от других сервисов Cursor.
Шифрование
Cursor шифрует данные Cloud Agent при передаче и при хранении.
- При передаче. TLS 1.2 или выше для трафика между сервисами и между клиентом и сервисом.
- При хранении. AES-256 и отдельные ключи для каждого агента, поэтому данные сессии каждого агента шифруются своим ключом.
- Ключи, управляемые клиентом. Enterprise-команды могут использовать KMS-ключ, управляемый клиентом (CMEK/BYOK), для серверного шифрования Cloud Agent, чтобы самостоятельно контролировать ротацию ключей и доступ. См. Шифрование данных.
Какие данные хранятся, где и как долго
Cloud Agent работает с четырьмя типами данных. Каждый из них хранится в отдельном месте и подпадает под собственные правила хранения.
| Данные | Что содержат | Где хранятся | Срок хранения |
|---|---|---|---|
| Рабочее пространство runtime | Извлечённый репозиторий, артефакты сборки и контекст выполнения инструментов для активного запуска | Изолированная VM Cloud Agent | Автоматически очищается после того, как запуск переходит в состояние idle; таймер сбрасывается, когда вы отправляете follow-up промпты |
| VM snapshots | Копии диска VM на определённый момент времени (включая клонированный код), используемые для запуска и возобновления без повторного клонирования | Зашифрованный слой snapshots и кэша вне активной VM | Скользящее окно 90 дней неактивности; каждый запуск или возобновление продлевает срок, после чего данные удаляются автоматически |
| Conversation state | Промпты, ответы модели, вызовы инструментов, контекст диффа и демонстрационные артефакты, составляющие transcript | Backend Cursor, зашифрованный отдельными ключами для каждого агента | По умолчанию хранится бессрочно, чтобы вы могли возвращаться к запускам и возобновлять их; можно удалить по запросу |
| Секреты и токены | Секреты Cloud Agent, токены OAuth и учётные данные API, которые вы настраиваете | Зашифрованные хранилища учётных данных в backend Cursor | Хранятся, пока вы их не удалите |
Delete Agent API по запросу удаляет transcript диалога агента и артефакты. Snapshots нельзя удалить по запросу; для них действует указанное выше окно в 90 дней неактивности. Команды Enterprise также могут ограничивать срок хранения диалогов с помощью retention policies. Подробнее о сроках хранения и удалении см. в разделе Data retention.
Конфиденциальность и данные моделей
Cloud Agents работают в режиме конфиденциальности. Когда режим конфиденциальности включён, Cursor никогда не использует для обучения код, к которому Cloud Agents получают доступ, а также промпты и ответы, создаваемые в ходе их работы. Большинство моделей также работают в рамках соглашений Cursor о нулевом хранении данных, поэтому провайдеры не хранят запросы и ответы и не обучаются на них. См. Конфиденциальность и управление данными для подробной информации по каждой модели и сведений об исключениях.
Устаревший режим конфиденциальности не поддерживается для Cloud Agents, потому что агентам нужно хранить код и данные инфраструктуры в облаке во время работы. Включите стандартный режим конфиденциальности для всей организации, чтобы каждый запуск наследовал гарантии нулевого хранения данных.
Автономность и промпт-инъекция
Cloud Agents автоматически запускают терминальные команды, чтобы можно было итерировать по тестам без запроса одобрения на каждом шаге. Это более автономно, чем foreground-агент, и меняет модель рисков: злоумышленник, который внедрит инструкции в контент, читаемый агентом (атака с помощью промпт-инъекции), может попытаться заставить агента вывести код на внешний хост. См. объяснение OpenAI о рисках промпт-инъекции для облачных агентов.
Уровни защиты, снижающие этот риск:
- Контроль исходящего сетевого трафика. Ограничьте исходящий трафик стандартным набором адресов и вашим allowlist либо только вашим allowlist, чтобы у скомпрометированного агента не было возможности отправить данные. Администраторы Enterprise могут зафиксировать эту политику для всей организации. См. Сетевой доступ.
- Скрытые runtime-секреты. Помечайте секреты как Runtime Secrets, чтобы их значения удалялись из транскрипта, выходных данных инструментов и коммитов и никогда не попадали в модель.
- Исключение файлов. Добавьте конфиденциальные пути в
.cursorignore, чтобы они не попадали в контекст агента. - Передача человеку для проверки. Agents создают черновые pull request. Ничего не будет слито, пока человек не проверит изменения.
- Подписанные коммиты. Каждый коммит агента подписывается ключом Ed25519 с поддержкой HSM и получает значок "Verified", поэтому изменения, созданные агентом, можно однозначно связать с источником и использовать там, где для защиты веток требуется подпись коммитов. См. Подписанные коммиты.
Для более глубокой защиты используйте это вместе с хуками, чтобы применять политики и вести журнал активности на этапах жизненного цикла агента, а также проверяйте выходные данные агента с помощью Bugbot или Security Agents перед выпуском.
Оценка рисков
| Риск | Меры снижения |
|---|---|
| Вся кодовая база в облаке | Изолированные ВМ для каждого Agent, шифрование AES-256 и автоматическое удаление ВМ и снимков по таймерам жизненного цикла. |
| Доступ третьих лиц или сотрудников | Сотрудники Cursor не имеют доступа к коду в ВМ Agent, а попытки доступа отслеживаются. ВМ работают в отдельном аккаунте AWS, изолированном от других сервисов Cursor. |
| Автономность Agent | Объём действий ограничен репозиторием и правами доступа пользователя, который запустил Agent. Внешние действия ограничены настроенными инструментами и терминальными командами, контролируются средствами управления исходящим сетевым трафиком и проходят ревью через черновики PR. |
| Сетевой доступ и эксфильтрация | Доступ в интернет включён по умолчанию, но его можно ограничить доменами из allowlist, вплоть до режима только allowlist, и заблокировать на уровне всей организации. |
| Утечка секретов | Зашифрованное хранилище секретов, runtime-секреты с маскировкой, не передаваемые модели, и секреты только для сборки, доступные лишь в рамках Docker build, и токены OIDC для кратковременной облачной федерации. |
Аудируемость
Активность облачного агента фиксируется в журналах, и для каждого действия можно определить источник.
- Логирование сессий. Запуски логируются, а администраторы команды могут просматривать активность в дашборде облачных агентов.
- Изменения с указанием автора. Каждый коммит и pull request, созданные агентом, имеют указанного автора и видны в вашей истории Git; коммиты при этом подписаны и верифицированы.
- Журналы аудита. События аутентификации и административные события поступают в ваши журналы аудита, которые команды Enterprise могут передавать в SIEM, webhook или S3.
- Run Diagnostics. Встроенный Cursor Cloud MCP предоставляет транскрипты, события запуска, сведения об инфраструктуре и логи настройки для запуска.
Удаление данных
| Механизм | Что удаляет | Как |
|---|---|---|
| Архивация | Скрывает агента на дашборде | В дашборде |
| Delete Agent API | Запись диалога агента и артефакты | Delete Agent API |
| Срок действия снимков | Снимки VM и кэшированный код | Автоматически после 90 дней бездействия |
| Политика хранения (Enterprise) | Диалоги старше выбранного вами срока | Политики хранения |
| Удаление аккаунта | Аккаунт и связанные с ним данные | Удалить аккаунт |
FAQ
У них другой профиль рисков, но не более высокий. Запуск агента без присмотра в изолированной песочнице с ограничениями на исходящий трафик и минимальными правами доступа может быть безопаснее, чем на ноутбуке разработчика, у которого обычно есть полный доступ к интернету и повышенные привилегии.
Нет. Cursor клонирует репозиторий для запуска агента, и эта копия может сохраняться в снимках VM, чтобы ускорить будущие запуски, но не хранится бесконечно. Снимки удаляются после 90 дней бездействия.
Нет. Доступ определяется правами Git того разработчика, который запустил агента. Облачный агент не может получить доступ к репозиторию, к которому у разработчика изначально не было доступа.
Да. Облачные агенты могут получать доступ только к тем репозиториям, которые вы разрешили через подключение к вашему Git-провайдеру. Вы сами определяете, какие репозитории доступны, а администраторы могут фиксировать области доступа с помощью Защищённая область Git или исключать репозитории с помощью blocklist.
Настройте секреты на вкладке Secrets в вашем дашборде. Они шифруются при хранении с помощью KMS, шифруются при передаче и передаются как переменные среды во время выполнения. Помечайте чувствительные значения как Runtime Secrets, чтобы они не попадали в транскрипт, tool output и коммиты. На практике секреты лучше не хранить в репозитории; если конфиденциальные файлы всё же должны там находиться, добавьте их в .cursorignore. Для облачных ролей создавайте токены OIDC из VM вместо хранения долгоживущих ключей доступа.
Да. Сеансы логируются, администраторы могут просматривать активность в дашборде, а каждый коммит и pull request, созданный агентом, отражается в вашей истории Git. Команды Enterprise могут передавать журналы аудита в SIEM.
Архивируйте агента в дашборде или используйте Delete Agent API, чтобы удалить его транскрипт и артефакты. Полное удаление аккаунта и политики хранения Enterprise удаляют данные по более широкому графику.
Связанные страницы
- Секреты и сеть — о типах секретов, режимах сетевого доступа, диапазонах исходящих IP-адресов и подписанных коммитах.
- Токены OIDC — о краткосрочных JWT и облачной федерации.
- Конфиденциальность и управление данными — о потоках данных, режиме конфиденциальности и шифровании.
- Усиление безопасности и конфиденциальности — о мерах защиты, которые вы настраиваете в Cursor.
- Trust Center — о сертификациях, субпроцессорах и архитектуре.
