Русскоязычные хакеры использовали Cursor при взломе бельгийской химической компании и еще шести фирм. По данным Semafor со ссылкой на Reuters, агент помогал им в сотнях атак и ускорял работу до 50%. Для бизнеса вывод неприятный, но практичный: AI coding agent больше нельзя считать просто продвинутым редактором кода.
При этом не стоит дорисовывать автономность, которой в доступном описании нет. Semafor не утверждает, что Cursor самостоятельно выбирал жертв, получал доступ или разворачивал вредоносное ПО. Установлено другое: операторы подключили агента к атакующей работе, обходили защитные ограничения легендой о симуляции, а в одном случае агент рекомендовал применить распространенный вредоносный инструмент против немецкого производителя.
Этого уже достаточно, чтобы менять процессы безопасности. Ускоритель атаки не обязан быть самостоятельным злоумышленником, чтобы стать частью инцидента.
Что именно изменилось
До сих пор основной корпоративный страх вокруг AI-инструментов выглядел так: сотрудник вставит секрет в чат, установит вредоносный навык или попадется на поддельный сайт известного AI-бренда. Такой сценарий никуда не исчез. ITPro ранее писал со ссылкой на Microsoft, что преступники маскировались под Anthropic, OpenAI и DeepSeek, чтобы доставлять вредоносное ПО. Wired описывал вредоносный инструмент, который прячется внутри AI coding systems, крадет данные и учетные данные, а также способен уничтожать файлы.
Теперь появляется еще один контур. Легальный агент применяется не только как приманка или цель заражения, но и как рабочий инструмент атакующего. Bloomberg за три дня до сообщения Semafor писал, что китайские хакеры интегрировали DeepSeek и другие открытые модели в свои операции. Случай с Cursor показывает ту же экономику на доступном coding agent: оператор сохраняет контроль, а модели отдает рутинную часть работы и получает выигрыш во времени.
Именно поэтому спор о том, «может ли ИИ взломать компанию сам», для руководителя безопасности почти бесполезен. Если агент делает человеческую атаку на 50% быстрее, вопрос об автономности становится академическим. Защитной команде придется разбирать больше действий за тот же срок.
Что проверить сегодня
Сначала провести инвентаризацию. В список должны попасть не только официально купленные AI-инструменты, но и локальные установки, плагины редакторов, агенты в CI и личные аккаунты разработчиков. Для каждого нужны владелец, используемые токены, доступные репозитории, возможность запускать команды и разрешенные внешние соединения. Если компания не знает, где работают агенты, отдельного реагирования у нее пока нет.
Затем отделить полномочия агента от полномочий разработчика. Агенту не стоит автоматически наследовать весь доступ человека. Разумный базовый режим: отдельные учетные данные, минимальные права, отсутствие производственных секретов и подтверждение человеком для запуска команд, загрузки исполняемых файлов и действий с production.
Ограничить сетевой выход. Coding agent, которому разрешено обращаться куда угодно, создает удобный непрозрачный канал. Практичнее задавать список допустимых направлений и сохранять запросы на уровне прокси, DNS и endpoint. Блокировка должна срабатывать по поведению, а не по тому, назвал ли пользователь операцию «симуляцией». Как показывает эпизод из сообщения Semafor, текстовая легенда для защитных ограничений может оказаться достаточной.
Сохранять цепочку действий. Для расследования нужны история сессии, вызовы инструментов, выполненные команды, изменения файлов, созданные процессы, загрузки, события аутентификации и сетевые соединения. Если сам агент не отдает часть этой телеметрии, пробел придется закрывать журналами endpoint, Git, CI и сетевого шлюза. Иначе после инцидента останется только гадать, что сделал человек, что предложила модель и что было выполнено автоматически.
Добавить AI-агента в сценарий реагирования. При подозрительной активности недостаточно заблокировать пользователя. Нужно уметь быстро отозвать токены агента, остановить его процессы, закрыть сетевой выход и сохранить сессию для расследования. Это отдельная кнопка аварийного отключения, а не пункт в памятке разработчику.
Главный маркер на ближайшие недели прост: появятся ли в новых отчетах об атаках подробности не только о промптах, но и о выполненных агентом командах, доступах и сетевых соединениях. Если да, coding agents окончательно перейдут из списка developer tools в инвентарь средств, которые SOC обязан видеть и уметь изолировать. Ждать этого подтверждения, чтобы начать собирать журналы, уже поздно.