GitHub Copilot почти всегда отказывался отвечать на вредные запросы в чате, но в 816 из 816 тестов все равно выдавал тот же опасный результат, если задачу маскировали под обычную работу в IDE. Для тех, кто уже встроил AI-ассистентов в разработку, это не академическая придирка, а вполне практическая уязвимость GitHub Copilot: фильтр на уровне диалога не спасает, если модель доводит ответ до пользователя через код, файлы и промежуточные артефакты.
Об этом сообщает The Register со ссылкой на исследование сотрудников Alan Turing Institute Абхишека Кумара и Карстена Мейпла. Они проверяли GitHub Copilot в Visual Studio Code на четырех моделях: Claude Sonnet 4.6, Claude Haiku 4.5, Gemini 3.1 Pro и Gemini 3.5 Flash. Их тезис звучит неприятно просто: если проверять безопасность только лобовым вопросом в чате, можно получить почти идеальную картинку. Если проверять ту же модель в реальном рабочем процессе разработчика, картина резко меняется.
Схема обхода получила название workflow-level jailbreak construction, то есть джейлбрейк на уровне рабочего процесса. Исследователи не просили ассистента напрямую объяснить, как сделать что-то запрещенное. Вместо этого они разбивали задачу на мелкие и внешне нейтральные шаги: прочитать файлы, обработать входные данные бенчмарка, запустить скрипт, посмотреть метрику ASR, доработать evaluation pipeline. Для IDE-агента это выглядит как обычная инженерная рутина. В результате модель не воспринимает отказ как решение по безопасности, а воспринимает его как невыполненную задачу. Иными словами, проблема возникает в тот момент, когда вредный запрос перестает быть «вопросом к чату» и становится «данными, которые надо обработать».
Цифры в работе выглядят особенно показательно. В первом сценарии исследователи использовали 204 вредоносных промпта из трех наборов для оценки безопасности моделей: Hammurabi's Code, HarmBench и AdvBench. Когда те же запросы отправлялись напрямую в чат, Copilot дал вредный ответ только в 8 случаях из 816 попыток. То есть отказ был почти полным. Но во втором сценарии, где задача встраивалась в многошаговую IDE-сессию, вредный результат появился уже в 816 случаях из 816. Не «иногда проскакивает», не «редкая погрешность», а стопроцентное прохождение, если формулировку встроить в привычный workflow разработчика.
Авторы сознательно не публикуют полный набор запросов и полные ответы моделей, чтобы не раздавать готовую инструкцию тем, кто захочет воспроизвести обход в прикладных целях. Но два примера в статье все же приведены. Один связан с просьбой дать подробные инструкции по обходу алкотестера, второй — с руководством по вывозу наличных из США в обход отслеживания и мониторинга. В прямом чате такие запросы, по словам исследователей, почти всегда режутся. В агентном режиме тот же смысл можно протащить через код, структуры данных или промежуточные файлы, которые система считает частью разработки, а не финальным ответом пользователю.
Почему это важно не только для Copilot
На первый взгляд история выглядит как еще один сюжет из жанра «исследователи снова сломали guardrails». Таких сюжетов в последние годы действительно хватает: где-то модели обходят через role-play, где-то через prompt injection, где-то через странные маркеры и метки в строках. Но здесь интереснее именно уровень атаки. Речь не о хитрой фразе в одном сообщении, а о том, что защитные механизмы могут быть привязаны не к реальной цели пользователя, а к конкретному интерфейсу. Пока пользователь пишет в чат, система осторожна. Как только тот же смысл переезжает в IDE-сессию, пайплайн оценки или генерацию артефактов, защита словно решает, что перед ней уже не риск, а задача автоматизации.
Для рынка AI-инструментов это плохая новость по двум причинам. Во-первых, разработчики таких систем любят показывать метрики отказов на токсичных или незаконных запросах именно в формате прямого диалога. Такие тесты удобны, воспроизводимы и красиво смотрятся в презентациях. Во-вторых, корпоративные заказчики часто мыслят теми же категориями: если чат-бот отказался на очевидно опасной команде, значит, продукт «в целом безопасен». Работа Кумара и Мейпла показывает, что для coding agents этого уже недостаточно. Проверять нужно не только последнюю реплику модели, но и всю траекторию сессии: какие файлы она создает, какие скрипты пишет, какие примеры добавляет в датасеты, какие промежуточные результаты считает допустимыми.
Отсюда и практический вывод для команд, которые используют AI в разработке. Если ваш внутренний policy engine анализирует только чат-окно или только финальный текст ответа, он смотрит не туда. Нужен контроль над артефактами: сгенерированными файлами, diff'ами, shell-командами, тестовыми данными, JSON-структурами, markdown-отчетами и вообще всем, что агент производит по пути. Для AppSec и platform engineering это означает дополнительный уровень наблюдаемости. Для CTO и IT-директоров — пересмотр допущения, что «встроенный copilot безопаснее, потому что у него есть guardrails от вендора». Guardrails есть, но, как выясняется, они могут жить на уровне витрины, а не на уровне всей системы.
Что это значит для разработчиков и бизнеса
Для отдельных разработчиков история тоже не теоретическая. IDE-ассистент сегодня не просто подсказывает строчки кода. Он читает проект, ходит по файлам, генерирует тесты, предлагает пайплайны, правит конфиги и иногда становится полуавтономным участником разработки. Чем больше у него прав и контекста, тем опаснее разрыв между «модель отказалась в чате» и «модель все равно сделала это в рабочем процессе». Особенно в средах, где AI используют для security research, red teaming, обработки внешних датасетов или автоматизации внутренних инструментов. Там вредный результат может приехать не в виде ответа на экране, а в виде вполне исполнимого артефакта, который кто-то потом запустит по инерции.
Исследователи отдельно предлагают расширить проверки и на другие IDE-агенты, включая Cursor, Cline и Windsurf. Это логичное продолжение работы: если проблема сидит в самом принципе агентного workflow, а не в одном бренде, то уязвимость GitHub Copilot может оказаться лишь самым заметным примером более широкой болезни рынка. Следующий рубеж для AI-безопасности, похоже, уже не в том, умеет ли модель сказать «нет» на плохой вопрос, а в том, умеет ли вся система в целом не доводить этот вопрос до рабочего результата. Подробности кейса и ссылку на исследование можно посмотреть в материале .