Безопасен ли Cursor AI для коммерческого проекта: privacy, код, агенты и чеклист перед merge

Cursor ускоряет разработку в 3–10 раз. Но «работает быстро» ещё не значит «безопасно для продакшена». Разбираем, как устроена защита данных в Cursor, какие уязвимости были обнаружены в 2025 году и что нужно проверить до merge, чтобы AI-код не стал источником инцидента.

Почему вопрос безопасности Cursor стал острым именно сейчас

По данным Bloomberg, к январю 2025 года у Cursor было более 1 миллиона пользователей [1]. Компания заявляет, что её используют более 64% компаний из Fortune 500, включая NVIDIA, Uber, Adobe, Stripe и Coinbase [2]. В Coinbase к февралю 2025 года каждый инженер использовал Cursor в работе.

Такой масштаб означает, что вопрос безопасности AI-редактора кода перестал быть академическим. Это операционный риск, который касается IP-активов, цепочки поставок ПО, compliance и защиты production-систем.

При этом вопрос «безопасен ли Cursor» на самом деле распадается на несколько принципиально разных вопросов:

1. Безопасно ли хранение кода и данных на стороне Cursor?
2. Безопасен ли код, который генерирует Cursor?
3. Безопасен ли агентный режим с точки зрения контроля выполняемых действий?
4. Какие организационные и технические gate нужны перед merge AI-сгенерированных изменений?

Разберём каждый уровень отдельно.

Уровень 1. Что происходит с вашим кодом — Privacy Mode и архитектура данных

Как Cursor обрабатывает код

По официальной документации Cursor [3], поведение зависит от выбранного режима:

Если Privacy Mode включён: модели-провайдеры не хранят данные (Zero Data Retention, ZDR). Cursor может хранить часть данных для обеспечения отдельных функций, но код никогда не используется для дообучения моделей — ни Cursor, ни сторонними провайдерами.

Если Privacy Mode выключен: Cursor может использовать и хранить данные кодовой базы, промпты, действия в редакторе, фрагменты кода для улучшения AI-функций и дообучения моделей. Часть данных может передаваться провайдерам моделей при явном выборе их моделей.

Важный технический нюанс: даже при использовании собственного API-ключа, все запросы идут через backend Cursor для финального построения промпта [4]. Это означает, что «я подключил свой OpenAI-ключ» не делает запросы полностью локальными.

Индексация кодовой базы

Если вы включаете функцию индексации codebase, Cursor загружает код небольшими чанками на свои серверы для создания векторных эмбеддингов [3]. При этом:

• Plaintext-код не хранится после завершения запроса.
• Хранятся только эмбеддинги и метаданные (хеши, имена файлов).
• Данные кешируются временно для снижения задержки.

Это означает, что структура проекта (имена файлов, директорий, хеши) может быть в базе Cursor даже при включённом Privacy Mode.

Субпроцессоры

Список субпроцессоров публикуется на trust.cursor.com [5]. Ключевые из них:

• AWS (основная облачная инфраструктура, только US-регион).
• OpenAI — Cursor поддерживает ZDR-соглашение с OpenAI.
• Anthropic — аналогичное ZDR-соглашение.
• Inference-провайдеры (Baseten, Together AI, Fireworks) — могут временно хранить входящие и исходящие данные модели для улучшения производительности.
• MongoDB, Amplitude, Stripe, Vercel, WorkOS — для аналитики, платежей, SSO.

Cursor официально подтверждает, что не использует инфраструктуру в Китае и не работает с китайскими субпроцессорами [5].

Сертификация и compliance

Cursor имеет сертификацию SOC 2 Type II, ежегодное пентестирование сторонними специалистами, шифрование AES-256 в состоянии покоя и TLS 1.2+ при передаче [2]. Отчёт доступен на trust.cursor.com по запросу.

Cursor декларирует соответствие GDPR и CCPA [2]. Однако независимый анализ (Generative AI Strategy, октябрь 2025) уточняет важное ограничение: вся обработка происходит только на US-based инфраструктуре, EU data residency отсутствует [6]. Это означает:

• Для некритичных проектов Business-план с Privacy Mode — GDPR-допустимое решение при наличии DPA и SCCs.
• Для регулируемых отраслей (финтех, медицина, госсектор) или проектов с жёсткими требованиями локализации данных Cursor может не соответствовать требованиям уже на уровне инфраструктуры [6].

Отличие планов по уровню гарантий

Free-план: Privacy Mode отсутствует. Данные, включая код, могут использоваться для обучения. Не подходит для коммерческих проектов.

Pro-план: Privacy Mode опционален, включается пользователем вручную. Даже при включении не предоставляет тех же ZDR-гарантий, что и Business-план [6].

Business/Enterprise-план: Privacy Mode принудительно включён организационным администратором, ZDR contractually guaranteed с провайдерами моделей. Для команды проверка выполнения режима происходит каждые 5 минут [7]. Это единственный вариант для коммерческой разработки.

Уровень 2. Безопасность AI-генерируемого кода

Privacy Mode решает вопрос о том, куда уходят ваши данные. Но он не отвечает на вопрос, безопасен ли код, который Cursor написал.

Данные по уязвимостям AI-кода

Veracode в 2025 году протестировала более 100 LLM на задачах безопасного кодинга: 45% AI-генерируемых образцов кода содержали уязвимости из OWASP Top 10. По данным независимого исследования Veracode, AI-генерируемый код содержит уязвимости в 2.74 раза чаще, чем написанный человеком [8].

Apiiro, анализировавший Fortune 50-компании, зафиксировал, что CVSS 7.0+ уязвимости встречаются в 2.5x чаще в AI-генерируемом коде. К июню 2025 года AI-код добавлял более 10 000 новых security-находок ежемесячно в исследуемых репозиториях — в 10 раз больше, чем в декабре 2024 года [8].

Исследовательский проект Georgia Tech Vibe Security Radar зафиксировал 35 CVE за один месяц (март 2026 года), непосредственно связанных с AI-инструментами кодинга, причём реальное число оценивается в 5–10 раз выше [9].

Slopsquatting — галлюцинации как вектор атаки на supply chain

OWASP прямо указывает в списке рисков LLM 2025: модели могут предлагать несуществующие или небезопасные библиотеки [10]. Этот вектор получил название slopsquatting. LLM «галлюцинирует» имена пакетов, которые не существуют; злоумышленники регистрируют эти имена в PyPI, npm или других реестрах как вредоносные пакеты. Разработчики устанавливают их, не проверяя.

По данным Cloud Security Alliance (2026), slopsquatting стал прямым продолжением dependency confusion и typosquatting-атак, адаптированным под реальность AI-кодинга [9].

Cursor не верифицирует существование предлагаемых пакетов в реальном времени — это задача разработчика и CI/CD-пайплайна.

Rules File Backdoor — отравление конфигурации AI

В марте 2025 года исследователи Pillar Security раскрыли атаку Rules File Backdoor [11]. Cursor позволяет создавать файлы правил (.cursor/rules), задающие поведение AI при генерации кода. Злоумышленники могут внедрить в такие файлы скрытые инструкции с использованием Unicode-обфускации и семантического hijacking.

Особенная опасность атаки:

• Скомпрометированный rule file влияет на все последующие сессии генерации кода в проекте.
• Инструкции сохраняются при форке репозитория, создавая vector supply chain атаки на downstream-зависимости.
• Вредоносный код в генерируемых файлах не появляется в истории чата, что делает атаку практически невидимой для code review.

Cursor и GitHub Copilot, согласно официальным ответам после раскрытия, считают, что пользователи сами несут ответственность за проверку и принятие AI-предложений [11]. Это ставит ответственность на команду, а не на инструмент.

Уровень 3. Агентный режим — самый высокорисковый слой

Что делает агент

Cursor Agent может автономно выполнять многошаговые задачи: создавать, изменять и удалять файлы, выполнять команды в терминале, взаимодействовать с внешними системами через MCP-серверы (Slack, GitHub, базы данных). При Auto-Run Mode агент выполняет команды без запроса явного подтверждения пользователя.

Это значит, что агент работает с привилегиями разработчика на хост-машине. Вся мощь и весь риск напрямую зависят от того, что попало в контекст агента.

CurXecute (CVE-2025-54135, CVSS 8.6)

В августе 2025 года исследователи AIM Security раскрыли уязвимость CurXecute [12]. Атака эксплуатировала то, что Cursor не требовал подтверждения для новых записей в ~/.cursor/mcp.json — и выполнял команды немедленно, даже если пользователь отклонял предлагаемое изменение.

Сценарий атаки: злоумышленник отправляет crafted-сообщение в публичный Slack-канал. Когда разработчик просит Cursor суммировать сообщения через Slack MCP, промпт-инъекция перехватывает управление агентом и модифицирует mcp.json — запуская произвольные команды с привилегиями разработчика. Весь chain от сообщения в Slack до RCE занимал минуты [13].

AIM Security предупреждают: «Поверхность атаки — любой сторонний MCP-сервер, обрабатывающий внешний контент: issue tracker, customer support inbox, даже поисковики. Один poisoned document может превратить AI-агента в локальный shell» [12].

MCPoison (CVE-2025-54136, CVSS 7.2)

Исследователи Check Point Research в августе 2025 года раскрыли MCPoison [14]. Cursor использовал one-time approval модель для MCP-конфигураций: после одобрения конфигурации повторного запроса подтверждения не было. Злоумышленник с доступом к общему репозиторию мог закоммитить безобидный MCP-конфиг, дождаться его одобрения командой, а затем тихо подменить команды на вредоносные — без каких-либо предупреждений. Модифицированный MCP выполнялся при каждом открытии проекта [14].

Оба CVE были закрыты в Cursor 1.3 (29 июля 2025 года). Теперь любое изменение MCP-конфигурации требует явного одобрения.

CVE-2025-59944 — case-sensitivity bypass

В октябре 2025 года Lakera Research раскрыла CVE-2025-59944 [15]. Баг в проверке путей позволял через case-sensitivity mismatch (.Cursor/mcp.json вместо .cursor/mcp.json) обойти защиту чувствительных конфигурационных файлов на Windows и macOS. Уязвимость закрыта в Cursor 1.7.

Серия CVE-2025-61590–61593 — пять векторов RCE

В сентябре 2025 года была раскрыта серия из пяти высокосерьёзных уязвимостей в Cursor ≤ 1.7, эксплуатирующих различные векторы prompt injection: через OAuth, через VS Code workspace, через CLI-конфигурацию, через файловые операции агента [16]. Все они позволяли достичь RCE с привилегиями пользователя. Патч вышел в версии 2025.09.17-25b418f.

NomShub — hijack через открытие репозитория

SecurityWeek (апрель 2026) раскрыл NomShub — цепочку уязвимостей, позволявшую захватить машину разработчика через prompt injection в malicious-репозитории [17]. Для атаки не требовалось никакого взаимодействия, кроме открытия репозитория в Cursor. Использовался механизм remote tunnel в Cursor для получения shell-доступа. Закрыто в Cursor 3.0.

Что объединяет все эти CVE

Все описанные атаки эксплуатируют одну архитектурную реальность: агент работает с developer-level привилегиями, доверяет внешним данным как инструкции, действует автономно и быстро. Это не баг конкретной версии — это структурный вызов для всего класса agentic IDE, который осознанно решается только на организационном и процессном уровне, а не только патчами.

Уровень 4. Организационные риски и общая картина

Automation bias — когда доверие опережает проверку

Исследование Pillar Security фиксирует эффект automation bias: у разработчиков возникает склонность доверять AI-предложениям без критической проверки [11]. Когда скорость генерации кода вырастает в 3–10 раз, code review не успевает масштабироваться с той же скоростью. Diff дочитывают не до конца; новые зависимости принимают без проверки источника; конфиги, migration-файлы и CI/CD-скрипты проверяют хуже всего.

Именно здесь и прячется основной риск: не в том, что Cursor «сломан», а в том, что скорость AI-разработки обгоняет скорость контроля.

Отсутствие on-premise варианта

Cursor работает только в облаке. On-premise или air-gap развёртывание недоступно [2]. Для команд с требованиями полной изоляции или strict data sovereignty это полный блокер.

Чеклист безопасности Cursor для коммерческого проекта

Настройка IDE и аккаунта

1. Использовать Business или Enterprise план — только они дают принудительный Privacy Mode и ZDR-договоры с провайдерами.
2. Включить Privacy Mode на уровне организации через admin-панель (не оставлять на усмотрение разработчиков).
3. Отключить Auto-Run Mode или перевести его в режим с обязательным подтверждением каждой команды.
4. Настроить allowlist моделей — заблокировать использование непроверенных или нежелательных LLM-провайдеров.
5. Создать файл .cursorignore по аналогии с .gitignore для исключения чувствительных файлов (секреты, конфиги с credentials, .env-файлы) из контекста AI.

MCP-серверы

1. Аудитировать ~/.cursor/mcp.json и .cursor/mcp.json в каждом проекте. Включить эти файлы в scope code review.
2. Хранить MCP-конфиги в репозитории с контролируемым доступом и обязательным PR-review.
3. Использовать только проверенные, внутренние MCP-серверы для production-workload; сторонние MCP-серверы, обрабатывающие внешний контент (Slack, email, поиск), — дополнительная поверхность атаки.
4. Применять принцип минимальных привилегий к MCP-инструментам: read-only credentials для баз данных везде, где возможно.

Rules-файлы

1. Относиться к .cursor/rules как к критическому коду — с обязательным code review.
2. Проверять rules-файлы на hidden Unicode-символы и скрытые инструкции при получении из внешних источников (форумы, open-source шаблоны).
3. Ввести policy: rules-файлы из внешних источников проходят security-проверку перед включением в проект.

Зависимости и supply chain

1. Все новые зависимости, предложенные Cursor, проверять через SCA-инструменты (Snyk, OWASP Dependency Check, Dependabot, Trivy) до merge.
2. Проверять предложенные пакеты на существование в официальных реестрах и на признаки slopsquatting.
3. Использовать lock-файлы (package-lock.json, yarn.lock, poetry.lock) и pin-версии зависимостей — не допускать floating-версий в AI-генерируемом коде.
4. Для особо чувствительных проектов генерировать SBOM и проверять advisory-базы.

Code review и CI/CD

1. Ввести обязательный SAST-скан AI-генерируемого кода перед merge (SonarQube, Semgrep, CodeQL или аналоги).
2. Развернуть pre-commit-хуки для детектирования секретов (Gitleaks, TruffleHog) — AI-ассистенты иногда включают credentials в код или конфиги.
3. Не снижать планку code review для AI-генерируемых PR — дочитывать дифф до конца, уделяя особое внимание конфигам, migration-файлам и CI/CD-файлам.
4. Настроить egress-фильтрацию на машинах разработчиков и в CI/CD-окружении для детекции аномальных исходящих соединений.

Обновления и патчинг

1. Держать Cursor обновлённым до последней версии — большинство описанных CVE закрыты в актуальных релизах.
2. Подписаться на security-уведомления Cursor и отслеживать новые CVE.

Когда Cursor может не подойти

Cursor — сильный инструмент с зрелой security-программой для большинства коммерческих команд. Но есть сценарии, где его ограничения становятся блокерами:

• Проекты с требованием on-premise или air-gap развёртывания.
• Проекты в регулируемых отраслях с обязательной EU data residency.
• Работа с медицинскими данными (ePHI) без полной цепочки BAA-соглашений.
• Проекты с политикой «никакой код не покидает периметр организации».

В этих случаях стоит рассмотреть альтернативы с локальным развёртыванием моделей (например, LLaMA/Mistral через Ollama внутри VPC) или enterprise-решения с on-premise вариантом.

Роль дополнительного контроля перед merge

Перечисленные меры закрывают многое — но не всё. Главная проблема AI-кодинга в 2025–2026 годах не в самом инструменте: она в том, что скорость генерации обгоняет скорость проверки.

Рабочий PR не обязательно безопасен. Дифф из 400 строк сложнее проверить, чем из 40. Новая зависимость, транзитивный пакет или изменение в конфиге может приехать незаметно. Перед релизом нужен чёткий и короткий ответ на вопрос «что именно блокирует выпуск», а не ещё один длинный security-отчёт.

Именно для этого создан HighVibe — слой контроля безопасности AI-кодинга до merge и релиза. Он анализирует конкретные изменения в коде, конфигурации, зависимостях и служебных файлах, объясняет риск простым языком и предлагает следующий шаг: исправить, перепроверить или заблокировать merge. Это не замена SAST/SCA/SBOM — это дополнительный слой контроля, который помогает команде принять решение именно по этому изменению, именно сейчас.

Тренды: что будет дальше

Cursor активно патчит конкретные CVE, но класс угроз — prompt injection в agentic IDE — системный и с каждой новой функцией автономии растёт. OWASP в своём Agentic AI Top 10 (2025) прямо называет agent instruction file poisoning и hallucinated library injection как ключевые риски именно для coding agents [10].

Исследователи Lakera точно формулируют суть проблемы: «Как только IDE может рассуждать и действовать, её поверхность атаки расширяется: от того, что вы кодируете, к тому, что IDE ingests как данные, но интерпретирует как инструкцию, к тому, что инструмент может сделать от вашего имени» [15].

Правильный ответ на это не отказ от AI-инструментов, а зрелый governance: чёткие политики, проверка всех конфигурационных файлов как кода, обязательный security-gate перед merge и культура «AI ускоряет, человек проверяет».

Заключение

Cursor AI безопасен для коммерческого проекта — при соблюдении конкретных условий:

• Business или Enterprise план с принудительным Privacy Mode.
• Отключённый Auto-Run, аудит MCP-конфигов, .cursorignore для секретов.
• Rules-файлы в scope code review.
• SCA, SAST, secret detection и lock-файлы в CI/CD-пайплайне.
• Актуальная версия Cursor.

Всё это не делает Cursor «просто включил и забыл». Это делает его управляемым инструментом в зрелой инженерной организации. Разрыв между скоростью AI-кодинга и скоростью security-контроля — это не проблема Cursor конкретно, это вызов всего класса agentic coding tools. Те команды, которые решат его на уровне процессов и инструментов до следующего релиза, окажутся впереди.

Источники

[1] Tenable — "FAQ: CVE-2025-54135, CVE-2025-54136 vulnerabilities in Cursor (CurXecute, MCPoison)" — https://www.tenable.com/blog/faq-cve-2025-54135-cve-2025-54136-vulnerabilities-in-cursor-curxecute-mcpoison

[2] Cursor — "Enterprise" — https://cursor.com/enterprise

[3] Cursor — "Data Use & Privacy Overview" — https://cursor.com/data-use

[4] Cursor — "Privacy Policy (PDF, Scribd)" — https://www.scribd.com/document/811603458/Privacy-Policy-Cursor-The-AI-Code-Editor

[5] Cursor — "Security" — https://cursor.com/security

[6] Generative AI Strategy B.V. — "GDPR compliance: Cursor" — https://www.generativeaistrategy.com/resources/gdpr-compliance/cursor

[7] MintMCP Blog — "Cursor security: complete guide to risks, vulnerabilities & best practices" — https://www.mintmcp.com/blog/cursor-security

[8] SoftwareSeni — "AI-Generated Code Security Risks — Why Vulnerabilities Increase 2.74x" — https://www.softwareseni.com/ai-generated-code-security-risks-why-vulnerabilities-increase-2-74x-and-how-to-prevent-them/

[9] Cloud Security Alliance Labs — "CSA Research Note: AI-Generated Code Vulnerability Surge 2026" — https://labs.cloudsecurityalliance.org/research/csa-research-note-ai-generated-code-vulnerability-surge-2026/

[10] OWASP Gen AI Security Project — "LLM09:2025 Misinformation" — https://genai.owasp.org/llmrisk/llm092025-misinformation/

[11] Pillar Security — "New Vulnerability in GitHub Copilot and Cursor: How Hackers Can Weaponize Code Agents" — https://www.pillar.security/blog/new-vulnerability-in-github-copilot-and-cursor-how-hackers-can-weaponize-code-agents

[12] BleepingComputer — "AI-powered Cursor IDE vulnerable to prompt-injection attacks" — https://www.bleepingcomputer.com/news/security/ai-powered-cursor-ide-vulnerable-to-prompt-injection-attacks/

[13] SC Media — "Cursor flaw risks RCE from prompt injections on MCP server" — https://www.scworld.com/news/cursor-flaw-risks-rce-from-prompt-injections-on-mcp-server-researchers-say

[14] Check Point Research — "Cursor IDE's MCP Vulnerability (MCPoison)" — https://research.checkpoint.com/2025/cursor-vulnerability-mcpoison/

[15] Lakera — "Cursor Vulnerability (CVE-2025-59944): How a Case-Sensitivity Bug Exposed the Risks of Agentic Developer Tools" — https://www.lakera.ai/blog/cursor-vulnerability-cve-2025-59944

[16] Geordie AI — "Critical Security Vulnerabilities in Cursor AI Editor" — https://www.geordie.ai/resources/technical-advisory-multiple-vulnerabilities-in-cursor-ai-code-editor

[17] SecurityWeek — "Cursor AI Vulnerability Exposed Developer Devices" — https://www.securityweek.com/cursor-ai-vulnerability-exposed-developer-devices/

[18] Endor Labs — "Cursor Security: How to Secure AI-Generated Code in 2026" — https://www.endorlabs.com/learn/cursor-security

[19] Harini.blog — "Detailed Security and Enterprise Readiness Report: Cursor AI IDE" — https://harini.blog/2025/05/07/detailed-security-and-enterprise-readiness-report-cursor-ai-ide/

[20] Legit Security — "From Chatbot to Code Threat: OWASP's Agentic AI Top 10" — https://www.legitsecurity.com/blog/from-chatbot-to-code-threat-owasps-agentic-ai-top-10-and-the-specialized-risks-of-coding-agents