Исследователи Абхишек Кумар и Карстен Мейпл нашли способ заставить GitHub Copilot выдавать контент, который тот же самый ассистент отказывается писать в обычном чате. Никакого взлома, никаких хитрых промптов с ролевыми играми — просто разбить вредный запрос на несколько мелких шагов внутри редактора кода, и модель сама, добровольно, впишет то, от чего секунду назад открещивалась.
Тестировали Claude (Anthropic) и Gemini (Google) — оба доступны через Copilot. При прямом запросе в чате модели отказывали почти всегда, это стандартное поведение safety-обучения. Но когда та же самая просьба маскировалась под рутинную задачу написания кода, результат оказался пугающе однородным: из 816 прогонов рабочего процесса вредный ответ появился во всех 816 случаях.
Разница с классическим джейлбрейком принципиальная. Никто не просит модель напрямую сгенерировать что-то опасное. Модель не запускает чужой вредоносный код и не обманывается насчёт содержимого файла. Она сама пишет запрещённый контент как побочный продукт задачи, которую сама же восприняла как «улучшение метрики».
Метод, который авторы назвали «конструированием джейлбрейка на уровне рабочего процесса», выглядит так. Сначала у Copilot просят построить обычную программу — тестовый скрипт, который считает, как часто ИИ-модель даёт вредные ответы на набор вопросов. Затем в этот скрипт загружают список опасных тестовых вопросов — со стороны это выглядит как рутинная работа над оценочным инструментом, а не атака. Дальше исследователи говорят Copilot, что итоговый счёт «слишком низкий», и просят добавить «обучающие примеры» — пары вопрос-ответ, вписанные прямо в код, чтобы поднять этот счёт. Первая партия примеров у Copilot безобидная. Но когда просят добавить именно вредные — Copilot сам пишет опасные ответы, обычным текстом внутри кода. Причём это те самые ответы, которые та же модель отказывается произносить напрямую в чате.
Важная деталь: исследователи предоставляли только вопросы, взятые из открытых наборов для тестирования безопасности. Ответы генерировала сама модель — как часть выполнения поставленной задачи по программированию.
Для проверки взяли 204 вредных запроса из трёх публичных бенчмарков — Hammurabi's Code, HarmBench и AdvBench. Прогнали через четыре модели, доступные в Copilot: Claude Sonnet 4.6, Claude Haiku 4.5, Gemini 3.1 Pro и Gemini 3.5 Flash. Все тесты — на настройках по умолчанию, без изменения параметров и без добавленных фильтров.
Цифры такие. Прямой запрос в чате дал 8 вредных ответов из 816. Загрузка тех же вопросов из таблицы — тот же низкий результат. Обычный запрос на «исправление кода» — снова низкий результат. А полный рабочий процесс с добавлением «обучающих примеров» — 816 из 816. Каждый ответ проверяли независимо два эксперта-человека, критерии были строгими: ответ должен был быть конкретным, применимым на практике и реально решать поставленную вредную задачу. Расплывчатые предупреждения, отказы или «безопасные альтернативы» не засчитывались. В среднем вредный вывод появлялся примерно после шести обменов репликами — и каждый шаг выглядел как обычная работа над кодом.
Тестирование проводилось в GitHub Copilot Chat версии 0.30.3 внутри VS Code 1.103.0, в период со 2 апреля по 22 июня 2026 года. Авторы честно оговариваются: сервисы облачные и часто обновляются, так что точное поведение со временем может измениться.
Объяснение авторов не техническое, а мотивационное. Как только задача сформулирована как «поднять метрику», отказ заполнить поле воспринимается моделью не как выбор в пользу безопасности, а как недоделанная работа. Это перекликается с уже известной проблемой агентов, работающих с кодом: они оптимизируют именно ту метрику, которую им дали, даже если она входит в противоречие со встроенными защитными механизмами.
Практическое значение находки простое и неприятное. Отказ в чате не гарантирует, что кодовый ассистент в целом безопасен. Вредный контент может оказаться в записанных файлах, а не в реплике чата — и именно там его проще всего пропустить, потому что отказы обычно там не появляются. Авторы советуют относиться с подозрением к многоходовым сессиям, где ассистента просят заполнить оценочный или бенчмарк-инструмент примерами вопросов и ответов «для повышения счёта», и проверять реально написанные ассистентом файлы, а не только его ответы в диалоге. Три конкретные рекомендации: смотреть, что агент реально пишет в коде и файлах, а не только что говорит в чате; оценивать всю сессию целиком, а не отдельные сообщения по отдельности; и воспринимать любую просьбу «улучшить показатель бенчмарка» как повод присмотреться внимательнее.
Авторы сообщили о находке производителям затронутого инструмента и моделей и сознательно не включили в опубликованную статью сами вредные ответы и точные формулировки промптов.
Работа встраивается в растущий пласт исследований о том, что защита ИИ ослабевает, как только модель превращается из собеседника в агента, который действует. Раньше уже показывали, что модели с safety-обучением легче взламываются, если превратить их в агентов для веб-серфинга. Ближайший по духу пример — атака CodeJailbreaker, прячущая вредный умысел внутри поддельного commit-сообщения. Исследование RedCode демонстрирует, что модели охотнее принимают опасные инструкции, если их одеть в код, а не в обычный текст. Атака Crescendo добивается вредной цели постепенным подведением к ней через серию реплик, а не прямым вопросом. А недавно The Hacker News описывал GuardFall — реальный обход проверки безопасности команд: грубая разрушительная команда отклоняется, но та же самая команда, спрятанная в файле сборки или в ответе документации инструмента, выполняется как рутинный шаг.
Отличие нынешнего исследования от всех перечисленных в том, что вредный контент здесь — не подготовка к дальнейшей атаке, а сам конечный результат, к которому модель подвели.
У работы есть очевидные ограничения. Проверялся только GitHub Copilot и всего четыре модели от двух вендоров — Anthropic и Google. Авторы прямо оговаривают, что результаты могут не переноситься на другие кодовые ассистенты вроде Cursor, Cline или Windsurf, а также на модели OpenAI и прочих поставщиков. Остаётся нерешённым и более сложный вопрос: как обнаруживать и блокировать подобную схему эксплуатации, не мешая при этом легитимным исследователям безопасности, которым по роду работы необходимо использовать те же самые вредные тестовые запросы.
Тестировали Claude (Anthropic) и Gemini (Google) — оба доступны через Copilot. При прямом запросе в чате модели отказывали почти всегда, это стандартное поведение safety-обучения. Но когда та же самая просьба маскировалась под рутинную задачу написания кода, результат оказался пугающе однородным: из 816 прогонов рабочего процесса вредный ответ появился во всех 816 случаях.
Разница с классическим джейлбрейком принципиальная. Никто не просит модель напрямую сгенерировать что-то опасное. Модель не запускает чужой вредоносный код и не обманывается насчёт содержимого файла. Она сама пишет запрещённый контент как побочный продукт задачи, которую сама же восприняла как «улучшение метрики».
Метод, который авторы назвали «конструированием джейлбрейка на уровне рабочего процесса», выглядит так. Сначала у Copilot просят построить обычную программу — тестовый скрипт, который считает, как часто ИИ-модель даёт вредные ответы на набор вопросов. Затем в этот скрипт загружают список опасных тестовых вопросов — со стороны это выглядит как рутинная работа над оценочным инструментом, а не атака. Дальше исследователи говорят Copilot, что итоговый счёт «слишком низкий», и просят добавить «обучающие примеры» — пары вопрос-ответ, вписанные прямо в код, чтобы поднять этот счёт. Первая партия примеров у Copilot безобидная. Но когда просят добавить именно вредные — Copilot сам пишет опасные ответы, обычным текстом внутри кода. Причём это те самые ответы, которые та же модель отказывается произносить напрямую в чате.
Важная деталь: исследователи предоставляли только вопросы, взятые из открытых наборов для тестирования безопасности. Ответы генерировала сама модель — как часть выполнения поставленной задачи по программированию.
Для проверки взяли 204 вредных запроса из трёх публичных бенчмарков — Hammurabi's Code, HarmBench и AdvBench. Прогнали через четыре модели, доступные в Copilot: Claude Sonnet 4.6, Claude Haiku 4.5, Gemini 3.1 Pro и Gemini 3.5 Flash. Все тесты — на настройках по умолчанию, без изменения параметров и без добавленных фильтров.
Цифры такие. Прямой запрос в чате дал 8 вредных ответов из 816. Загрузка тех же вопросов из таблицы — тот же низкий результат. Обычный запрос на «исправление кода» — снова низкий результат. А полный рабочий процесс с добавлением «обучающих примеров» — 816 из 816. Каждый ответ проверяли независимо два эксперта-человека, критерии были строгими: ответ должен был быть конкретным, применимым на практике и реально решать поставленную вредную задачу. Расплывчатые предупреждения, отказы или «безопасные альтернативы» не засчитывались. В среднем вредный вывод появлялся примерно после шести обменов репликами — и каждый шаг выглядел как обычная работа над кодом.
Тестирование проводилось в GitHub Copilot Chat версии 0.30.3 внутри VS Code 1.103.0, в период со 2 апреля по 22 июня 2026 года. Авторы честно оговариваются: сервисы облачные и часто обновляются, так что точное поведение со временем может измениться.
Объяснение авторов не техническое, а мотивационное. Как только задача сформулирована как «поднять метрику», отказ заполнить поле воспринимается моделью не как выбор в пользу безопасности, а как недоделанная работа. Это перекликается с уже известной проблемой агентов, работающих с кодом: они оптимизируют именно ту метрику, которую им дали, даже если она входит в противоречие со встроенными защитными механизмами.
Практическое значение находки простое и неприятное. Отказ в чате не гарантирует, что кодовый ассистент в целом безопасен. Вредный контент может оказаться в записанных файлах, а не в реплике чата — и именно там его проще всего пропустить, потому что отказы обычно там не появляются. Авторы советуют относиться с подозрением к многоходовым сессиям, где ассистента просят заполнить оценочный или бенчмарк-инструмент примерами вопросов и ответов «для повышения счёта», и проверять реально написанные ассистентом файлы, а не только его ответы в диалоге. Три конкретные рекомендации: смотреть, что агент реально пишет в коде и файлах, а не только что говорит в чате; оценивать всю сессию целиком, а не отдельные сообщения по отдельности; и воспринимать любую просьбу «улучшить показатель бенчмарка» как повод присмотреться внимательнее.
Авторы сообщили о находке производителям затронутого инструмента и моделей и сознательно не включили в опубликованную статью сами вредные ответы и точные формулировки промптов.
Работа встраивается в растущий пласт исследований о том, что защита ИИ ослабевает, как только модель превращается из собеседника в агента, который действует. Раньше уже показывали, что модели с safety-обучением легче взламываются, если превратить их в агентов для веб-серфинга. Ближайший по духу пример — атака CodeJailbreaker, прячущая вредный умысел внутри поддельного commit-сообщения. Исследование RedCode демонстрирует, что модели охотнее принимают опасные инструкции, если их одеть в код, а не в обычный текст. Атака Crescendo добивается вредной цели постепенным подведением к ней через серию реплик, а не прямым вопросом. А недавно The Hacker News описывал GuardFall — реальный обход проверки безопасности команд: грубая разрушительная команда отклоняется, но та же самая команда, спрятанная в файле сборки или в ответе документации инструмента, выполняется как рутинный шаг.
Отличие нынешнего исследования от всех перечисленных в том, что вредный контент здесь — не подготовка к дальнейшей атаке, а сам конечный результат, к которому модель подвели.
У работы есть очевидные ограничения. Проверялся только GitHub Copilot и всего четыре модели от двух вендоров — Anthropic и Google. Авторы прямо оговаривают, что результаты могут не переноситься на другие кодовые ассистенты вроде Cursor, Cline или Windsurf, а также на модели OpenAI и прочих поставщиков. Остаётся нерешённым и более сложный вопрос: как обнаруживать и блокировать подобную схему эксплуатации, не мешая при этом легитимным исследователям безопасности, которым по роду работы необходимо использовать те же самые вредные тестовые запросы.