Един-единствен невидим коментар в pull request (PR) в Azure DevOps може да обърне собствения AI агент на проверяващия срещу него, насочвайки го към проекти, до които атакуващият няма права за достъп, и безшумно да източи информацията, която открие.
Уязвимостта се намира в официалния Azure DevOps MCP сървър на Microsoft. Тя съществува, тъй като един от неговите инструменти връща описания на pull request-и без защита срещу инжектиране на подкани (prompt-injection), каквато компанията вече е приложила за други свои инструменти.
Фирмата за офанзивна сигурност Manifold Security детайлизира тази уязвимост от типа „объркан заместник“ (confused-deputy) тази седмица. Microsoft доставя сървъра, за да могат AI агентите да четат и управляват Azure DevOps от името на потребителя – обхващайки pull request-и, конвейери (pipelines), уики страници и работни елементи, при това с личните права на самия потребител. В това се крие и целият проблем: съдържание, написано от други хора, може да се превърне в инструкции, които AI агентът да изпълни.
Описанията на PR в Azure DevOps поддържат Markdown, което позволява използването на HTML коментари. В уеб интерфейса даден HTML коментар (<!-- ... -->) не се визуализира, така че проверяващият, преглеждайки описанието, вижда само стандартна промяна. REST API интерфейсът обаче го връща буквално и сървърът предава този текст директно на агента.
Това разминаване между онова, което вижда човекът, и онова, което получава моделът, служи като механизъм за доставка: атакуващият никога не комуникира директно с агента, а вместо това залага инструкции в съдържание, за което знае, че ще бъде прочетено от агента по-късно.
Когато проверяващият поиска от своя агент да прегледа даден PR, скритият текст може да пренапише целта на агента. Тъй като агентът носи идентификационните данни на проверяващия, той може да извършва действия в проекти, до които атакуващият няма права за достъп.
От Manifold посочват, че този достъп достига до изходен код, тайни (secrets) и работни елементи, а не само до уики страницата, използвана в тяхната демонстрация за потвърждение на концепцията (PoC). Фирмата определя тази ескалация като типичен сценарий, тъй като проверяващите често имат по-високи нива на достъп от потребителя, създал pull request-а. Атакуващият не получава нищо директно; той заема достъпа на проверяващия чрез текст, който проверяващият никога не вижда.
Пътят на pull request-а е пропуснал защитната бариера
Това, което издига този случай над стандартно предупреждение за инжектиране на подкани, е фактът, че Microsoft вече е внедрила защита срещу него. Анализирайки изходния код на сървъра, Manifold установява, че той използва техниката „spotlighting“ – метод от официалните насоки на Microsoft за борба с индиректно инжектиране на подкани. Тази техника обвива ненадеждното съдържание в разделители, за да може моделът да направи разлика между данните и инструкциите, които трябва да следва.
Компанията е добавила тази защита в PR #1062, където инструментите за уики страници и регистрационни файлове от компилации (build-log) преминават през споделен помощен модул – createExternalContentResponse. Инструментът обаче, който връща pull request – repo_get_pull_request_by_id, никога не го извиква, поради което предава описанието в суров вид, предоставяйки точно онази повърхност за атака, която злонамереният субект използва.
Медията The Hacker News потвърди, че същият път е останал незащитен в настоящия изходен код към 21 юли.
В демонстрацията на Manifold, изпълнена върху локална компилация на версия v2.7.0, сътрудник в даден проект отваря на пръв поглед нормален PR, чийто скрит коментар съдържа злонамерен код. След като агентът започне прегледа, проследяването на инструментите изпълнява верига от действия: задейства конвейер в друг проект, прочита поверителна уики страница, до която атакуващият няма достъп, и публикува тази страница обратно като коментар в PR-а, където атакуващият може да я прочете.
Един скрит коментар управлява цялата последователност и всяко извикване в нея е било разрешено за агента. Проблемът, според изследователите, се крие в „последователността и намерението, продиктувани от текст, който човек никога не е виждал“. Екипът възпроизвежда атаката както с Copilot CLI, така че и с Claude Code, което показва, че тя не е обвързана с конкретен AI агент.
Тази верига от действия обаче изисква определени предпоставки: текст в PR, написан от атакуващ, работен процес, който го подава към агент, проверяващ с по-високи права от тези на атакуващия, и агент, оторизиран да изпълнява инструменти без изрично потвърждение.
Manifold потвърди, че е тествала последната част в режим на автоматично одобрение без подкани за отделните инструменти – контролната точка, която в противен случай би позволила на проверяващия да забележи необичайното стартиране на конвейер в друг проект, преди то да се случи. Комбинацията от широкоспектърен токен за достъп и този режим на работа е мястото, където се концентрира рискът.
Демонстрацията предполага, че човек инициира прегледа, но от Manifold отбелязват накъде се насочват екипите: автоматизиран преглед, триаж и резюмета, задействани от системни събития, без човешка намеса при всяко изпълнение или преглед на резултатите. При такава конфигурация заложеният злонамерен код се активира сам, а изтичането на данни продължава по-дълго, преди някой да го забележи.
Този модел не е нов. През май 2025 г. Invariant Labs показа същия клас атака срещу MCP сървъра на GitHub, използвайки публична тема (issue), за да накара агента да прочете частно хранилище и да източи информацията чрез pull request. Оттогава същата техника се прилага и срещу автоматизирани работни процеси с агенти в GitHub.
Този случай е един от примерите, които Саймън Уилисън посочи при дефинирането на „смъртоносната триада“: агент с достъп до лични данни, излагане на ненадеждно съдържание и метод за изпращане на данни навън. Всеки агент, който притежава и трите характеристики, може да бъде обърнат срещу своя собственик чрез един-единствен блок от текст, а повечето наистина полезни агенти разполагат и с трите.
Говорител на Microsoft благодари на Manifold за докладването на поведението в рамките на процеса за координирано разкриване на уязвимости и го нарече „известен клас риск при изкуствения интелект“, който подпомага текущата работа на компанията по нейните защитни механизми.