Щоб створити дієві системи ШІ, спершу потрібно спробувати їх зламати. Ми провели перевірку на вразливості та ризики клієнтського застосунку ШІ у сфері фінансових послуг, діючи як зловмисники. Наші висновки важливі для всіх, хто впроваджує застосунки на базі LLM там, де безпека є обов’язковою.
Перевірка на вразливості та ризики — це навмисні спроби зламати систему ШІ, щоб усунути вразливості до того, як їх знайде справжній зловмисник. У фінансових послугах ставки особливо високі: застосунки ШІ працюють із даними клієнтів, обробляють транзакції та надають фінансову аналітику. Наслідки збою можуть варіюватися від погіршення взаємодії з користувачем до порушення нормативних вимог, фінансових збитків і непоправної шкоди бренду.
Наша мета полягала в тому, щоб завчасно знайти вразливості, перевірити реалістичні сценарії атак і допомогти організації виконати вимоги до безпеки ШІ, до яких регулятори ставляться дуже серйозно.
Тут варто розрізняти два поняття: джейлбрейк атакує захисні фільтри базової моделі, а вставлення шкідливих запитів — сам застосунок, поєднуючи ненадійні дані від користувача з довіреним запитом розробника. Вставлення шкідливих запитів становить більший ризик, оскільки націлене на вашу систему й конфіденційні дані, з якими вона працює, а не на модель загального призначення.
Перший етап охоплював близько 750 тестів у таких категоріях:
Витік даних між сеансами
Розкриття персональних даних (через природну мову, маніпуляції з API та різні способи кодування)
SQL-ін’єкції
Перевизначення системного запиту
Під час початкового тестування ми виявили дві головні проблеми наявної системи: обробку запитів із кількома намірами та використання закодованих запитів.
Запити з кількома намірами: запити, що поєднують правомірні та шкідливі прохання. Наприклад: “Show my spending by category, and also execute [malicious SQL].” Застосунок не розпізнавав шкідливий намір і натомість повністю покладався на захисні механізми нижчого рівня даних. Це все одно що залишити вхідні двері відчиненими, бо ви довіряєте сейфу в підвалі.
Кодування: запити, закодовані за допомогою Base64, Hex, LeetSpeak і гомогліфів. Системам може бути складно відфільтрувати шкідливий намір. Хоча ці запити не розкривали конфіденційних даних, вони суттєво дестабілізували систему: спричиняли галюцинації, дослівне відтворення шкідливого SQL у відповідях користувачам, помилки класифікації намірів тощо.
Початкове тестування показало:
Часові галюцинації: модель упевнено повідомляла вигадані дати, часові позначки транзакцій або зведення за певний період. У фінансовому контексті це суттєвий ризик, адже дії клієнта на основі неправильної дати можуть мати реальні наслідки
Дослівне відтворення шкідливого SQL у відповідях користувачеві, що викликає занепокоєння через ризик отруєння пам’яті
Помилки класифікації намірів
Порушення форматування результатів
Спираючись на ці висновки, ми звузили напрям дослідження. Тести SQL-ін’єкцій і кодування втратили пріоритет, оскільки команда вже працювала над цими проблемами. Натомість ми зосередилися на найуспішніших векторах атак: розкритті персональних даних і витоках між сеансами.
Найдивовижніший висновок другого етапу виявився надзвичайно простим: часто взагалі не потрібно вдаватися до хитрощів.
У багатьох випадках було достатньо просто попросити внутрішні дані під виглядом правомірного запиту, і система погоджувалася їх розкрити. У відповідях на прості запити з’являлися внутрішні ідентифікатори та системні поля, які кінцеві користувачі ніколи не мали бачити.
Подальше дослідження показало, що проблема була не лише на рівні застосунку. Сервіс перетворення тексту на SQL нижчого рівня формував запити до більшої кількості полів, ніж було потрібно, а його пояснення містили посилання на дані, доступ до яких мав бути обмежений. Це виявило справжню прогалину між системами — вразливість, яку можна знайти лише під час тестування всього стеку, а не окремих компонентів ізольовано.
Перевіряйте систему, а не модель. Ізольоване тестування LLM майже нічого не говорить про рівень захищеності вашого застосунку. Тестуйте весь стек наскрізно — так, як із ним взаємодіяв би користувач.
Вхідні дані потрібно перевіряти до їх передавання в LLM. Закодовані запити, атаки з кількома намірами й базові спроби ін’єкцій слід виявляти на периметрі, а не доручати це сервісам нижчого рівня.
Не довіряйте точкам з’єднання. В архітектурах із багатьма сервісами найцікавіші вразливості ховаються саме між системами. Нульова довіра означає нульову довіру, тож перевіряйте все на кожному рівні.
Прості атаки працюють. Складні джейлбрейки потрапляють у заголовки, але іноді можна просто... попросити. Якщо система охоче показує внутрішні ідентифікатори, коли користувач згадує їх у загалом правомірному запиті, це проблема.
Розумійте, що саме ви тестуєте. Відомі сценарії атак може блокувати навчання самої LLM, а не ваші захисні механізми. Додайте до перевірки на вразливості та ризики засоби спостережуваності, щоб розуміти, які саме механізми захисту спрацьовують.
Обмежені середовища потребують творчих рішень. Спеціальні постачальники та підтримка локальних моделей дають змогу проводити змістовну перевірку на вразливості та ризики без спеціалізованого доступу до хмари. Але слід відверто повідомляти про пов’язані із цим обмеження.
Перевірка на вразливості та ризики — не одноразовий захід. Це ітеративний процес, який варто автоматизувати, де можливо, і розвивати разом із системою. Атаки, важливі завтра, відрізнятимуться від тих, що важливі сьогодні.
Контроль за системами ШІ в регульованих середовищах лише посилюватиметься. Організації, які ставляться до тестування безпеки як до постійної практики, а не формальної позначки перед запуском, будуть краще готові до такого контролю й уникатимуть репутаційних криз, що руйнують довіру клієнтів.