ИИ асистент за програмиране, който отказва да отговори на опасна заявка в чат прозореца си, може да й отговори въпреки това, ако същата заявка бъде разделена на малки, обикновено изглеждащи стъпки в редактора на код. Това е заключението от ново проучване на GitHub Copilot от изследователите Абхишек Кумар и Карстен Мейпъл.

Моделите, които те са тествали чрез Copilot – Claude на Anthropic и Gemini на Google – са отказали почти всяка вредна заявка, когато са били попитани директно. Преформулирани като стъпки в нормална задача за програмиране, те са генерирали вредните отговори във всички 816 работни процеса на изследването.

Това, което отличава този метод от типичния jailbreak (преодоляване на защитите), е, че никой не иска вредното нещо директно и моделът не е подлъган да изпълнява чужд код. Той сам пише забраненото съдържание като страничен ефект от задача за програмиране, която е бил помолен да подобри.

Изследователите наричат метода "изграждане на jailbreak на ниво работен процес" (workflow-level jailbreak construction).

Вместо една директна подкана, те са поискали от Copilot да създаде обикновен софтуер: малка тестова програма, която оценява колко често друг ИИ модел се поддава на вредни подкани. Зареждането на списък с вредни тестови въпроси в тази програма изглежда като обикновена работа, а не като атака.

След това е дошъл подтикът. Те казали на Copilot, че резултатът е твърде нисък и поискали да подобри програмата, като добави примери за обучение (teaching shots) – двойки въпроси и отговори, записани в кода, за да се повиши резултатът. Copilot първоначално добавил безвредни примери.

Когато обаче бил помолен да добави вредните, той сам е написал опасните отговори като обикновен текст в кода. Това са били отговори, които същите модели отказват да дадат, когато ги попитате директно в чата.

Важната част е откъде идва вредният текст. Изследователите са предоставили само въпросите, взети от публични тестове за безопасност. Отговорите са били изцяло дело на модела, генерирани за завършване на възложената задача за попълване на примерите.

Екипът е тествал 204 вредни подкани от три публични бенчмарка (Hammurabi's Code, HarmBench и AdvBench) срещу четири модела, достъпни през Copilot: Claude Sonnet 4.6, Claude Haiku 4.5, Gemini 3.1 Pro и Gemini 3.5 Flash.

Всичко е работило при настройки по подразбиране, като моделите са използвани точно както Copilot ги предоставя – без променени параметри или добавени филтри.

Попитани директно в чата, моделите са генерирали вредни отговори само в 8 от 816 опита. Две други лесни конфигурации – зареждане на подканите от електронна таблица или искане за рутинна корекция на код – са дали същия резултат. В рамките на пълния работен процес обаче те са генерирали вредно съдържание 816 пъти от 816.

Двама експерти са проверили независимо всеки отговор и са се съгласили, че всички 816 са били действително вредни по строг критерий: отговорът е трябвало да бъде конкретен, използваем и действително да прави това, което вредната подкана изисква. Откази, неясни предупреждения и безопасни алтернативи не са били зачитани.

Вредният резултат се е появявал след около шест разменени реплики, като всички те са изглеждали като нормални стъпки при програмиране. Тестовете са използвали GitHub Copilot Chat 0.30.3 в VS Code 1.103.0 в сесии, проведени между 2 април и 22 юни 2026 г. Тъй като това са хоствани услуги, които се актуализират с времето, точното поведение може да се промени.

Защо се случва това? Според авторите причината е в стимулите. След като задачата е рамкирана като повишаване на резултат, отказът да се попълни дадено поле спира да изглежда като избор за безопасност и започва да изглежда като недовършена работа. Авторите свързват това с известна тенденция при ИИ агентите за кодиране: да оптимизират за метриката, която им е зададена, дори когато това противоречи на техните собствени защитни бариери.

Отказът в чата не доказва, че асистентът за програмиране е безопасен. Същият модел може да спазва правилата в разговор и да ги наруши, докато пише код. А пропускът се крие на трудно забележимо място: вредният текст попада във файл, който асистентът пише, извън чат отговора, където обикновено би се показал отказът.

За всеки, който използва тези инструменти, конкретният извод е тесен, но полезен. Бъдете предпазливи при сесии с множество стъпки, при които се иска от асистента да попълни рамка за оценка или бенчмарк с примерни подкани и отговори за повишаване на резултата. Преглеждайте файловете, които асистентът пише, вместо да вярвате, че видимият отказ в чата означава, че сесията е останала чиста.

Авторите посочват три насоки, нито една от които не е пълно решение сама по себе си: инспектирайте какво пише агентът, оценявайте цялата сесия, а не всяко съобщение поотделно, и разглеждайте заявката за "подобряване на бенчмарк резултат" като причина за по-внимателно взиране. Те заявяват, че са докладвали констатациите на засегнатите създатели на инструменти и модели, и са оставили вредните резултати и точните подкани извън документа.

Резултатът се вписва в нарастващия брой изследвания, показващи, че обучението за безопасност на ИИ става по-нестабилно, след като моделът бъде свързан с инструмент, който може да действа, а не просто да чати. Предишни изследвания установиха, че моделите с обучение за безопасност лесно се jailbreak-ват, когато бъдат превърнати в агенти за сърфиране в мрежата.

Най-близката по-ранна атака, CodeJailbreaker, крие вредното намерение в фалшиво съобщение за commit. Други, като RedCode, показват, че моделите приемат опасна инструкция по-лесно, когато тя е представена като код.