Data poisoning довгий час обговорювали переважно в контексті adversarial ML, training datasets та контрольованих дослідницьких сценаріїв як теоретичну можливість, реалізація якої вимагатиме значних ресурсів і складних умов. Ще на початку 2025 більшість команд сприймали його як академічну дискусію — важливу для дослідницького середовища, але не завжди пріоритетну для захисту production-систем.
З того часу ситуація стрімко ескалювала. З’явилися реальні та дослідницьки продемонстровані кейси: backdoor через коментарі в GitHub-репозиторіях, прихована інструкція в описі MCP-інструменту, отруєний контент у пошукових результатах, які агент використовує як довірене джерело. Poisoning вийшов за межі training pipeline і почав з’являтися там, де моделі отримують контекст під час роботи.
Отже, для команд, які розробляють або інтегрують GenAI-рішення, це означає, що захист від data poisoning не можна відкладати «на потім».
Що змінилося
Класична модель data poisoning була відносно зрозумілою: у training set додаються маніпульовані або шкідливі приклади, які згодом впливають на поведінку моделі. Це могло призводити до backdoor-поведінки, систематичних помилок класифікації, bias або деградації якості.
Сьогодні модель рідко працює ізольовано. Вона звертається до RAG, корпоративних knowledge bases, векторних баз, API, зовнішніх інструментів, MCP-серверів, synthetic data pipelines і внутрішніх бізнес-систем: тобто поверхня атаки не обмежується training pipeline, ризик виникає в будь-якій точці, де система отримує зовнішній контекст або використовує дані для прийняття рішень.
Poisoned data може потрапити у fine-tuning dataset через open-source repository — непомітно, разом із легітимним кодом або документацією. «Отруєні дані» можуть бути проіндексовані RAG-системою через веб-джерела чи внутрішні файли, які система за замовчуванням вважає довіреними, або приховуватись в описі інструменту, завантаженому агентом як trusted tool, — і спрацьовувати вже після деплою. Нарешті, вони можуть поширюватися через synthetic data: тиражуючи помилки, якщо згенерований контент повторно потрапляє у навчальні вибірки.
Чому Data poisoning критично саме для агентних рішень
Data poisoning стає значно небезпечнішим явищем, коли модель має не лише інформаційний, а й операційний контур.
LLM-агент, який відповідає на запитання в ізольованому середовищі, має обмежений потенціал шкоди. Але агент, який може виконувати SQL-запити, працювати з CRM, запускати workflow, взаємодіяти з файловими сховищами, ticketing-системами або фінансовими сервісами, стає частиною корпоративної операційної інфраструктури. У такому випадку, «отруєна» інструкція або контекст визначає вже не відповідь моделі, а реальну дію, яку вона виконає в системі.
Саме тут проходить межа між «помилкою моделі» і виконнням небажаної/ небезпечної дії системою.
Окремої уваги потребує RAG. Корпоративна база знань не має стати довіреним джерелом автоматично, лише тому, що вона внутрішня. Важливо визначити, хто може додавати, змінювати або видаляти документи, як відбувається перевірка на актуальність, чи зберігається простежуваність даних, чи можуть приховані інструкції потрапити у контекст запиту.
Власне tool layer також має розглядатися як частина поверхні атаки. Якщо агент отримує опис інструменту, endpoint або доступний action як частину контексту, ці елементи потребують перевірки, контролю версій і обмеження прав.
Коментар експерта
Data poisoning є відносно новим поняттям, і тільки в поточному році ми побачили реальні кейси реалізації відповідних ризиків. Механізми захисту активно розробляються. Є цікаві підходи, але наразі немає «золотого стандарту», який повністю унеможливлює цю проблему.
Для корпоративних клієнтів, або в будь-якій іншій ситуації, де витік даних чи небажана дія агента можуть мати серйозний негативний вплив, критичною стає гігієна у розробці й впровадженні агентних рішень. Якщо агент не здатен завдати шкоди (наприклад, не має доступу до інтернету поза заздалегідь затвердженими ендпоінтами, взаємодіє з базами даних виключно через read-only API, тощо), однією з ключових поверхонь атаки з потенціалом операційної шкоди залишається людина, яка може взаємодіяти з цим агентом.
— AI/ML Architect, AM-BITS
Як мінімізувати ризики
Для enterprise-сценаріїв максимальна автономність агента не завжди є перевагою. У багатьох випадках цінність AI-рішення полягає в тому, щоб агент контрольовано прискорював окремі етапи: знаходив інформацію, готував висновок, класифікував запит, формував рекомендацію або пропонував наступний крок, не виконуючи самостійно весь процес – від аналізу до дії. Обмеження автономності агентів є дієвим способом мінімізувати ризики системних помилок LLM-агентів, зокрема, атак на основі data poisoning.
На етапі тестування, окрім «нормального сценарію», необхідно оцінювати «найгірший сценарій», за умови, що retrieved context, tool metadata або user input будуть скомпрометовані. Під час red teaming варто перевіряти не лише prompt injection, а й отруєний контекст у документах, описах інструментів, метаданих, вибірках або синтетичних даних.
Обов’язковим елементом підвищення безпеки є фаховий тренінг для співробітників, які працюють з агентами.
На жаль, жоден із цих підходів не дає повного захисту, а Data poisoning не має універсальної протиотрути. Водночас, вплив можна суттєво зменшити, якщо на етапі архітектури чітко визначити доступ агента, ступінь самостійності і точки людського контролю.
