Що таке безпека LLM? Як знизити 10 головних ризиків безпеки за OWASP

Атака, яка змушує ШІ сприймати інструкції зловмисника як команди, — ін’єкція промптів — посідає перше місце в OWASP Top 10 for LLM Applications у кожній редакції починаючи з 2023 року.

Цей список — чи не найближче до консенсусу, що існує в галузі безпеки ШІ. Проєкт починався як невелика група фахівців із безпеки, а тепер спирається на внесок понад 600 експертів із більш ніж 18 країн.

Ми — ШІ-компанія, яка публікує посібник про те, як ШІ можна вмовити на що завгодно, тож не будемо вдавати, що цю проблему розв’язано. Вілсон, співкерівник проєкту OWASP, висловився досить прямо щодо сучасних засобів захисту: «...відверто кажучи, я не думаю, що ми досягли 99%».

Редакція 2026 року починається з тієї ж думки. Керівник проєкту радить нам «перестати намагатися створити модель, яку неможливо обдурити», а натомість проєктувати навколишню систему так, щоб обдурена модель не могла зламати нічого важливого.

Ми дотримуватимемося цієї позиції, розглядаючи всі 10 ризиків зі списку OWASP 2026 року.

Що означає безпека LLM?

Безпека LLM — це захист моделей ШІ та застосунків, які їх використовують, від атак і зловживань. Ризик зростає разом із тим, до чого підключено модель: до файлів і даних, які вона може читати, і до інструментів, якими вона може користуватися, як-от електронна пошта, пошук чи корпоративна база даних.

У належно захищеному програмному забезпеченні існує чітка межа між інструкціями, які виконує програма, та інформацією, яку вона обробляє. Але в LLM такої межі немає.

Усе, що читає модель, надходить як один довгий потік тексту: інструкції розробника, ваше запитання, вебсторінка, яку вона знайшла. Моделі ШІ мають відстежувати, хто говорить: розробник, користувач чи сама модель, коли міркує над проблемою.

Проте дослідники Джасмін Цуй і Чарльз Є виявили, що моделі здебільшого вгадують, хто говорить, за тим, як звучить текст. Тож якщо зловмисник напише щось схоже на власні міркування моделі, вона може повірити, що сама до цього додумалася. Це проблема для будь-якого механізму безпеки, який залежить від того, чи розуміє модель, хто тут головний.

Ми зіткнулися з тією ж проблемою у власних ШІ-агентах. Наш CISO Кайл Поллі розповів виданню ISMG, що агенти «можуть не дотримуватися політик, навіть якщо додати їх до системного промпту». Саме тому ми створили Numbat — інструмент із відкритим кодом, який перевіряє, що збирається зробити агент, і може заблокувати дію, якщо вона порушує налаштоване правило безпеки.

Безпека LLM означає визнати, що модель іноді виконуватиме накази не тієї людини, і вибудувати навколо неї захисні механізми ШІ, які встоять навіть тоді, коли це станеться.

Які найкращі практики безпеки LLM?

Ми розглянемо OWASP Top 10 for LLM Applications 2026 по порядку, від № 1 до № 10.

Для кожного ризику ви отримаєте пояснення простими словами, що саме може піти не так, і приклад із реального життя. Потім ми розглянемо практики, які допомагають запобігти цьому або принаймні обмежити шкоду.

1. Стримуйте ін’єкції промптів

Ін’єкція промптів відбувається, коли зловмисник змушує ШІ виконувати інструкції, яких той не повинен виконувати. Такі інструкції можуть надходити безпосередньо в чаті або бути приховані в електронному листі, вебсторінці чи документі.

Другий тип називають непрямою ін’єкцією промптів. Ви просите асистента підсумувати документ. Проте автор документа вже наказав асистентові надіслати йому ваші приватні файли. Якщо асистент виконає ці інструкції, автор документа фактично скористається вашим доступом.

PCMag порівнює захист промптів із латанням дірок у пористому камені. Ви закриваєте один отвір, а вода знаходить інший. «Атака знаходить шлях; її усувають, але безліч інших шляхів атаки ще належить виявити — просто через те, наскільки динамічними є системи на кшталт LLM».

Приклад: У червні 2025 року дослідники Aim Security виявили EchoLeak — вразливість, через яку Microsoft 365 Copilot можна було змусити допустити витік приватної інформації компанії. Коли працівник ставив звичайне робоче запитання, Copilot міг підтягнути зловмисний лист, виконати приховані в ньому інструкції та надіслати конфіденційну інформацію зловмиснику. Атака обходила перевірки, призначені для виявлення шкідливих інструкцій і видалення підозрілих посилань.

Що ви можете зробити:

• Дотримуйтеся «правила двох» від Meta: Для EchoLeak потрібен був ШІ, який міг читати дані компанії, читати зовнішню пошту й надсилати інформацію назовні, — і він мав усі три можливості. Якщо обмежити ШІ двома з них, ін’єкція промптів не зможе отримати надто багато контролю. Якщо ж завдання потребує всіх трьох, вимагайте схвалення людини перед кожною дією.
• Тестуйте захист проти зловмисників, які його знають: Передайте своїм тестувальникам безпеки правила й фільтри, які ви запровадили, і дозвольте їм шукати способи їх обійти. В одному дослідженні зловмисники, які адаптувалися до захисту, досягали успіху в понад 90% випадків проти більшості з 12 протестованих засобів захисту.

2. Запобігайте витоку конфіденційної інформації

Коли системи ШІ надають приватну інформацію людям, які не повинні її бачити, це називають розкриттям конфіденційної інформації. Ідеться, наприклад, про розголошення платіжних даних клієнта або приватні розмови, залишені у спільній базі даних.

Багато витоків починаються з «надмірного поширення». Припустімо, компанія підключає свій ШІ до дисків і баз знань із нестрогими дозволами. ШІ отримує все, до чого може дістатися, — саме так, як і задумано. Нікому не потрібно нічого зламувати, але вважайте, що LLM уже зламано.

Приклад: У січні 2025 року дослідники Wiz виявили базу даних DeepSeek, відкриту для доступу з інтернету, з понад мільйоном записів журналів, зокрема історією чатів і ключами API, за допомогою яких програмне забезпечення отримує доступ до інших сервісів. Дослідникам не довелося переконувати модель щось розкрити.

Що ви можете зробити:

• Перевіряйте доступ до того, як ШІ прочитає дані: Перш ніж передавати документи моделі, ваш застосунок має перевірити, які з них дозволено бачити людині, що ставить запитання.
• Захищайте записи, які залишає ваш ШІ: Видаляйте приватні дані й секретні ключі перед збереженням журналів активності, вимагайте входу в систему та обмежуйте доступ колом людей, яким він потрібен. Установіть строк зберігання, щоб ці записи не накопичувалися безстроково.

3. Приборкайте надмірну автономність

ШІ з надмірною автономністю має більше повноважень, ніж потребує його робота: інструменти, які йому не потрібні, дозволи, що виходять за межі його завдання, або свободу діяти без перевірки. Причина тут не має значення.

Ін’єкція промптів, баг або модель, яка просто помиляється, — усе це призводить до того самого результату. Рано чи пізно ШІ зробить щось руйнівне, якщо матиме таку можливість.

Приклад: У липні 2025 року засновник SaaStr Джейсон Лемкін повідомив, що агент для програмування Replit видалив його базу даних із записами про 1206 керівників, попри інструкції нічого не змінювати. Спочатку агент заявив, що дані неможливо відновити, хоча згодом відновлення виявилося можливим. Джейсон з’ясував, що вказівка не чіпати базу даних не позбавила агента можливості її видалити.

Розгорнути

Джерело: X

Що ви можете зробити:

• Приберіть можливості, які не потрібні для завдання: Обмежте як набір інструментів, які отримує агент, так і те, що ці інструменти можуть робити. Асистентові, що підсумовує електронні листи, потрібен дозвіл на їх читання, а не на надсилання чи видалення.
• Винесіть перевірку дозволів за межі ШІ: Щоразу, коли запитується дія, перевіряйте її на відповідність вашим правилам безпеки та вимагайте, щоб її схвалила людина.

4. Перевіряйте все, що потрапляє у ваш ланцюг постачання ШІ

Мало компаній створюють ШІ з нуля, і з кожним роком їх стає ще менше. Згідно з опитуванням Menlo Ventures «2025 The State of Generative AI in the Enterprise», у 2024 році моделі ШІ купували 53% компаній, а у 2025 році — вже 76%.

Найчастіше компанії завантажують моделі з хабів на кшталт Hugging Face, донавчають їх на наборах даних, зібраних іншими людьми, і підключають доповнення та пакети коду, написані незнайомцями.

Кожен із цих компонентів — потенційна точка входу. Якщо один із них підмінено, проблема потрапить просто у ваш продукт.

Приклад: З січня по серпень 2026 року кількість публічних репозиторіїв моделей на Hugging Face зросла з 2,43 до 2,96 мільйона. Проте в липні 2026 року моделі OpenAI під час внутрішнього тестування безпеки обійшли обмеження, які мали не допускати їх до інтернету, і проникли в частину систем Hugging Face. Зокрема, один агент знайшов 14 наборів облікових даних, що опинилися у відкритому доступі, перевірив, що вони дійсні, і передав їх іншим агентам. Далі агенти скористалися вразливостями, які дали їм змогу виконувати код на серверах Hugging Face.

«Ми запроваджуємо суворіші вимоги до узгодженості впродовж усього життєвого циклу моделі, створюємо більш ізольовані пісочниці, обмежуємо доступ до інтернету та посилюємо контроль доступу до ваг моделей», — йдеться у звіті OpenAI.

Що ви можете зробити:

• Фіксуйте точну версію моделей і перевіряйте їх: Прив’язуйте кожну модель до перевіреної версії та звіряйте відбиток її файлу перед завантаженням, щоб підмінений файл не можна було непомітно підсунути під тією самою назвою. OWASP також рекомендує цифрові підписи, але із застереженням: підпис доводить, звідки походить модель, а не те, що вона безпечна.
• Перевіряйте кожен пакет, який пропонує ваш ШІ: Перш ніж установлювати пакет коду, рекомендований ШІ-асистентом, переконайтеся, що він існує, що це саме той пакет, який ви мали на увазі, і що його випустив очікуваний видавець.

5. Захищайтеся від отруєння даних і моделей

Отруєний ШІ навчається на пошкоджених даних. Це можуть бути приклади, на яких його донавчали, або база знань, у якій він шукає відповіді. Модель і далі виглядає робочою; вона просто засвоює хибні уроки, а іноді вчиться поводитися неналежно лише тоді, коли бачить певну фразу-тригер.

Модель проходитиме всі ваші тести, доки хтось не використає цю фразу.

Розгорнути

До того ж наслідки дуже складно усунути. Отруєння — не баг, який можна виправити патчем. Якщо ваші дані хибні, можливо, доведеться їх повторно перевірити, перенавчити модель або повністю її замінити.

Приклад: У жовтні 2025 року дослідники з Anthropic, Інституту безпеки ШІ Великої Британії та Інституту Алана Тюрінга показали, що 250 отруєних документів можуть навчити модель видавати нісенітниці щоразу, коли вона натрапляє на певний тригер. Та сама кількість спрацювала для всіх чотирьох протестованих розмірів моделей, хоча найбільша з них навчалася на обсязі чистих даних, більшому в понад 20 разів.

Що ви можете зробити:

• Відстежуйте походження своїх даних: Ведіть облік кожного набору даних і моделі, які ви використовуєте, звідки кожен із них походить і що змінилося між версіями. Ми рекомендуємо контроль версій для наборів даних, щоб у разі виявлення отруєння можна було повернутися до чистої версії та з’ясувати, як воно туди потрапило.
• Тестуйте модель на бекдори: «Бекдор» — це прихована поведінка, яку зловмисник вбудовує в модель і яка чекає на певну фразу чи інший тригер для активації. Шукайте бекдори за допомогою вхідних даних, створених для того, щоб змусити модель порушити свої звичні правила.

6. Поставте межі необмеженому споживанню ресурсів

Коли ШІ не мають жодних обмежень щодо того, скільки роботи вони можуть виконати чи скільки коштувати, їхнє споживання вважається «необмеженим». Більшість ШІ-сервісів стягують плату за використання, тож зловмисник може роздути ваш рахунок або створити копію вашої моделі.

OWASP називає ключову проблему «асиметрією витрат». Короткий дешевий запит може запустити дорогі обчислення на вашому боці.

Приклад: У травні 2024 року команда з дослідження загроз Sysdig виявила новий тип атаки під назвою «LLMjacking». Група зловмисників атакувала 10 хмарних сервісів LLM за допомогою викрадених облікових даних. Вони проникли через вразливу версію Laravel, а потім з’ясували, що дають змогу робити ці облікові дані та які діють квоти, — з очевидною метою продавати доступ. Також вони запитували чимало налаштувань журналювання — імовірно, щоб уникнути виявлення. За даними Sysdig, у найгіршому сценарії жертва могла б втрачати понад 46 000 доларів на день.

Що ви можете зробити:

• Установіть бюджети, які зупиняють витрати: Запровадьте жорсткі ліміти витрат для окремих користувачів, ключів API, команд і облікового запису загалом. Застосовуйте їх у кожній точці, через яку можуть надходити запити.
• Задайте кожному завданню точку зупинки: Обмежте, як довго може виконуватися завдання, скільки тексту воно може обробити й згенерувати та скільки викликів інструментів може здійснити. Додайте автоматичне припинення роботи для агентів, які зациклюються або перевищують свій ліміт.

7. Виявляйте дезінформацію, перш ніж діяти

Коли ШІ створює щось хибне, але правдоподібне, і хтось (або щось) діє на основі цього, це називають дезінформацією. Головний ризик полягає не стільки в самій хибній відповіді, скільки в тому, що їй довіряють і її використовують.

Історія інцидентів свідчить, що фахівці переймалися дезінформацією менше, ніж слід було. Як зазначено у вступному листі до редакції 2026 року, учасники голосування поставили цей ризик майже в кінець списку, але, судячи з реальних інцидентів, він має бути майже на вершині.

Приклад: У 2025 році Deloitte Australia підготувала огляд ІТ-систем соціального забезпечення в межах державного контракту на 440 000 австралійських доларів. Дослідник Сіднейського університету Кріс Радж виявив посилання на неіснуючі наукові праці та вигадану цитату з рішення федерального суду. У переглянутій версії звіту було зазначено, що Deloitte використовувала Azure OpenAI GPT-4o у своїй методології, і компанія погодилася повернути останній платіж. На жаль, це був саме огляд, покликаний надавати гарантії.

Що ви можете зробити:

• Перевіряйте, чи підтверджують докази відповідь: Обґрунтовуйте твердження актуальними й авторитетними джерелами. Для відповіді щодо політики знайдіть затверджену політику та перевірте, чи підтверджує вона висновок, зокрема з урахуванням винятків.
• Звіряйте дані, перш ніж система почне діяти: Якщо агент стверджує, що клієнт пройшов перевірку особи, підтвердьте це в системі верифікації, перш ніж проводити платіж. Для важливих рішень вимагайте схвалення людини й надавайте їй підтвердні докази.

8. Обмежте шкоду від розкриття прихованого контексту

Застосунки ШІ надають моделі інструкції та фонову інформацію, яких користувачі зазвичай не бачать. Це може бути системний промпт, внутрішні політики, описи доступних інструментів і правила щодо того, хто може ними користуватися. Розкриття прихованого контексту відбувається, коли модель видає цю інформацію комусь.

У 2026 році OWASP розширив цей пункт, який раніше називався «Витік системного промпту», адже системний промпт — лише частина того, що може витекти. Небезпека залежить від того, що ви туди помістили. Витік посібника з тону спілкування — лише незначна прикрість, але витік ключа API дасть комусь доступ до вашої конфіденційної бази даних.

Приклад: У лютому 2023 року користувачі змусили Bing Chat від Microsoft розкрити свої внутрішні інструкції. Одну з успішних спроб здійснив Марвін фон Гаген, який назвався розробником OpenAI і попросив надати інструкції, нібито щоб налаштувати модель. Bing розкрив правила, що регулюють його пошук, відповіді та безпечну поведінку, а також своє внутрішнє ім’я — Sydney. Серед оприлюднених інструкцій була й вимога зберігати ці інструкції в таємниці.

Що ви можете зробити:

• Не допускайте потрапляння секретів у контекст моделі: Виходьте з того, що все, що може прочитати модель, може стати видимим для користувачів, — зберігайте паролі, API-ключі та токени доступу в окремій системі керування секретами.
• Забезпечте дію дозволів навіть у разі витоку правил: Перевіряйте права доступу в коді застосунку. Якщо інструмент доступний лише адміністраторам, перед його запуском перевіряйте дозволи облікового запису користувача.

9. Надійно захистіть вектори та ембединги

Коли ШІ використовує векторний пошук, щоб знаходити відповіді в документах вашої компанії, він шукає не безпосередньо в тексті. Документи перетворюються на «ембединги» — довгі списки чисел, що відображають зміст кожного фрагмента, — і зберігаються у векторній базі даних. Запитання перетворюється так само, і система вибирає фрагменти, чиї числа розташовані найближче.

OWASP виокремлює чотири види збоїв: отруєння робить відповіді системи хибними, інверсія призводить до витоків, глушіння змушує її замовкнути, а порушений контроль доступу — видавати будь-що будь-кому.

Ці числа не є такою безпечною абстракцією, якою здаються. Збережені ембединги можна перетворити назад на текст, і один із методів у тестах точно відновив 92% коротких фрагментів завдовжки 32 токени. Тож витік резервної копії, що містить «лише ембединги», теж може розкрити вміст документів.

Приклад: У дослідженні, представленому на USENIX Security 2025, науковці показали, що один ретельно складений документ може завадити ШІ відповісти на певне запитання. Вони додали його до колекції, у якій ШІ виконував пошук. Знайшовши цей документ, ШІ міг заявити, що не має достатньо інформації або що відповідати було б небезпечно. Документу не потрібно було наказувати ШІ ігнорувати власні правила. Це називають «глушінням пошуку».

Що ви можете зробити:

• Ведіть окремі індекси для публічних і приватних даних: Не змішуйте зібраний з вебу контент із даними партнерів чи конфіденційними внутрішніми документами. Розділяйте дані фізично за рівнем довіри, а не позначайте вміст тегами в одному індексі: це усуває цілий клас помилок конфігурації, і контент, зібраний з інтернету, не опиниться поруч із документами вашої ради директорів.
• Поводьтеся з ембедингами так само, як із документами, з яких їх отримано: Шифруйте їх, захищайте резервні копії векторної бази даних так само, як і вихідні файли, і видаляйте ембединги, коли видаляєте оригінал. API-ключі вашого сервісу ембедингів слід тримати в таємниці.

10. Перевіряйте вихідні дані ШІ, перш ніж передавати їх далі

Щоразу, коли застосунок передає вихідні дані ШІ іншій системі, не перевіривши, чи безпечно їх там використовувати, ідеться про неналежну обробку вихідних даних LLM.

Цей пункт також охоплює небезпечний код, який ШІ-асистенти для програмування генерують у великих обсягах. Тож кожен рядок, написаний асистентом, — це також вихідні дані.

Приклад: У 2025 році дослідник Йоганн Рехбергер показав, як асистент для програмування Amp від Sourcegraph міг спричинити витік вмісту чату, просто показавши зображення. За допомогою ін’єкції промпту він змусив Amp додати приватну інформацію до вебадреси зображення. Потім застосунок автоматично завантажив це зображення й тим самим надіслав інформацію на сервер дослідника. Збоєм обробки вихідних даних став саме цей автоматичний запит: згенерований моделлю текст перетворився на з’єднання із зовнішнім сервером, через яке передавалися приватні дані.

Що ви можете зробити:

• Зробіть вихідні дані безпечними для місця призначення: Перевіряйте й обробляйте відповіді з огляду на те, куди вони потраплять. Для вебсторінки не допускайте, щоб згенерований текст став виконуваним кодом. Для бази даних використовуйте підготовлені запити, у яких передані значення відокремлено від команд.
• Не дозволяйте відповідям автоматично встановлювати зовнішні з’єднання: За замовчуванням вимкніть у відповідях моделі автоматичне завантаження зображень, попереднього перегляду посилань і вбудованих сторінок. Дозволяйте необхідні з’єднання лише з явно схваленими адресами.

Як Perplexity захищає LLM?

Ми виходимо з того, що кожен із наведених вище ризиків рано чи пізно реалізується, і проєктуємо системи так, щоб у такому разі він не міг завдати значної шкоди. Як саме ми це робимо, наш CISO Кайл Поллі розповів на нещодавньому воркшопі.

• Агент отримує власний комп’ютер, і спочатку той порожній: Агентні інструменти, встановлені на вашому ноутбуці, можуть отримати доступ до його файлів, застосунків і збережених облікових даних. Perplexity Computer працює навпаки. Кожне завдання виконується у власній ізольованій пісочниці, і, як каже Поллі, «за замовчуванням у неї немає доступу ні до чого».
• Агент ніколи не бачить паролів: Облікові дані для підключених сервісів зберігаються поза пісочницею. Коли агентові потрібно звернутися до сервісу, як-от GitHub, він надсилає запит без облікових даних. Шлюз перевіряє, чи відповідають місце призначення та запит очікуваним, а потім додає облікові дані на виході. Агент може користуватися з’єднанням, не отримуючи ключів.
• Ваші дозволи зберігаються, і їх можна обмежити ще більше: З’єднання, встановлені через OAuth, зберігають ваші права доступу в підключеному сервісі. Якщо ви чогось не бачите, ваш агент теж цього не побачить.
• До кожної вебсторінки ставимося як до незнайомця: Ми створили BrowseSafe для Comet, нашого агентного браузера, бо протестовані нами інструменти не відповідали нашим потребам у реальному використанні. Браузер перевіряє вебсторінки та інший зовнішній контент, зокрема електронні листи, на наявність ін’єкцій промптів. Ми відкрили вихідний код як моделі, так і набору даних.
• Ми стежимо за агентом і машинами, на яких він працює: Numbat стоїть між рішенням агента діяти та фактичним запуском інструмента. Numbat реєструє активність у підтримуваних агентах для програмування й може блокувати дії, що порушують налаштовані політики, ще до їх виконання. Bumblebee інвентаризує програмні пакети на ноутбуках, серверах і в конвеєрах збирання та позначає ті, що відомі як шкідливі. Обидва інструменти мають відкритий вихідний код.
• Постачальники моделей не зберігають ваші дані: Ми маємо угоди про нульове зберігання даних зі сторонніми постачальниками LLM. Адміністратори Enterprise також можуть скоротити строк зберігання даних у самому Perplexity до 24 годин.

Ми створили Numbat на випередження з причини, яку Поллі формулює одним реченням: «Що більше автономії ви даєте агентові, то більший ризик».

Поширені запитання про безпеку LLM

Яка LLM найбезпечніша?

Жодна LLM сама по собі не робить застосунок безпечним: моделі все ще можуть сприймати вміст, який мають лише прочитати, за інструкції, які слід виконати. Захист, що здається надійним у стандартних тестах, також може не витримати тиску.

Краще запитати, яка конфігурація найбезпечніша для вашого сценарію використання. Це означає обмежені дозволи, облікові дані, недоступні для моделі, схвалення людиною ризикованих дій і тестування фахівцями, які знають ваші засоби захисту.

Що таке вразливості LLM?

Вразливості LLM — це слабкі місця, через які систему ШІ можна ввести в оману або через які вона може допустити витік даних чи завдати шкоди — як унаслідок дій зловмисника, так і через власні помилки.

Десять основних ризиків: ін’єкція промптів, розкриття конфіденційної інформації, надмірна автономність, ланцюг постачання, отруєння даних і моделей, необмежене споживання ресурсів, дезінформація, розкриття прихованого контексту, вразливості векторів і ембедингів та неналежна обробка вихідних даних.

Чи безпечна приватна LLM?

Для деяких завдань це безпечніший варіант, але не за замовчуванням. Якщо запускати модель на власній інфраструктурі або в хмарному середовищі, ви маєте більше контролю над обробкою даних. Проте автоматичного способу запобігти ін’єкціям промптів, надмірній автономності, отруєнню чи дезінформації не існує.

Якщо ви розміщуєте модель самостійно, то також відповідаєте за завантажену модель, зокрема за ризики ланцюга постачання та потрібну для неї інфраструктуру.