OWASP LLM Top 10 2026: зсув, якого не помітять у новинах
Проєкт OWASP GenAI Security випустив версію Top 10 для застосунків LLM 2026 року. Ін’єкції промпту утримують перше місце, розкриття конфіденційної інформації – друге. Аналіз новин вказує на відсутність серйозних змін.
Але зрушення є, і воно знаходиться поза списком. Автори проєкту одразу закликають припинити спроби створення моделі, яку не можна обманути. Натомість треба розробляти систему навколо неї так, щоб злам моделі не руйнував нічого важливого.
Це повністю змінює суть роботи. Протягом двох років індустрія оптимізувала модель. Новий список вимагає оптимізації стримування. Головною метою стає контроль радіуса ураження, а не абсолютний захист.
З цим підходом важко не погодитися. Водночас існує неочевидний наслідок, який буде розглянуто наприкінці.
Три зміни, які заслуговують на увагу
1. Дезінформація зросла на основі даних, усупереч голосуванню
Це перша версія списку, де порядок визначався реальними даними. Голоси практиків забезпечили 75 відсотків ваги. Решта 25 відсотків базуються на 6 639 інцидентах. Дані зібрано з відкритих баз вразливостей та реєстрів збоїв штучного інтелекту.
Вплив цих 25 відсотків найяскравіше проявився в одній конкретній категорії. За результатами голосування дезінформація опинилася наприкінці списку. Аналіз інцидентів підняв її на вершину. Відбувся стрибок на дві позиції вгору.
Така розбіжність є ключовим висновком. Фокус індустрії зміщений на ризики від реальних атак: ін’єкції, витоки, отруєння. Однак статистика інцидентів показує іншу картину. Найбільших збитків завдають збої без жодного втручання зловмисників. Модель видає хибний результат, а суміжні компоненти його приймають.
Автори проєкту точно описують причину. Це вже системна помилка, а не просто проблема згенерованого тексту. Результати роботи моделі запускають інструменти, генерують код, перевіряють стан системи, дозволяють виконання дій та керують агентами. Хибний результат на старті процесу не залишається просто текстом. Він стає рішенням.
2. Наслідки перейшли від згенерованого тексту до реальних дій
Excessive Agency (надмірна автономність) посідає третє місце, і тут дані та оцінки експертів збігаються: найбільшої шкоди завдають саме агентні розгортання. Водночас категорія Unbounded Consumption (необмежене споживання) піднялася на чотири позиції, оскільки виснаження ресурсів стало конкретною цифрою в рахунках.
Поєднання цих тенденцій дає чітку картину. Найгірші збої – це не просто некоректні відповіді моделі, а виконані дії та витрачені гроші.
Позитивний момент, про який згадують надто рідко: більшість цих методів захисту не є новими. Принцип найменших привілеїв, тимчасові права доступу, ліміти використання та обов’язковий контроль людини над незворотними діями – усі ці механізми існують в AppSec двадцять років і успішно адаптуються.
Погана новина стосується базових передумов. Права доступу неможливо обмежити для неінвентаризованих компонентів. Дуже мало компаній мають надійний реєстр своїх систем ШІ із чітким розумінням того, які дії вони здатні виконувати, до чого мають доступ і ким були розгорнуті.
3. Перейменування важливіші за зміну позицій
Категорія System Prompt Leakage (витік системного промпта) стала Hidden Context Exposure (розголошенням прихованого контексту). Ін’єкції промпту тепер включає міжмодальні атаки через зображення та аудіо. Data and Model Poisoning поглинула вразливості етапу глибокого навчання. Пункт Output Handling впав на десяте місце, але розширив свій спектр.
Замість додавання нових категорій відбулася консолідація існуючих. Це вдалий підхід. Вектор цієї консолідації вказує на головне: захищати потрібно весь обсяг контексту, а не тільки поле промпту. Усе, що досягає контекстного вікна – це ненадійні дані. Формат і джерело цих даних значення не мають.
Проблема розмежування від OWASP
Версія 2026 року максимально чітко визначає свої межі. Вона розглядає ризики LLM для моделі лише як базового компонента застосунку. Якщо ж модель стає активним суб’єктом – використовує інструменти, переносить пам’ять між сесіями та ініціює подальші дії, керуватися слід уже списком Agentic Top 10.
Тому замість орієнтації на списки інвентаризація має базуватися на функціоналі. Кожен компонент ШІ потребує аналізу за трьома параметрами:
- Чи здатен він викликати інструменти або суміжні системи?
- Чи переноситься його стан між сесіями?
- До яких систем він записує дані та що знаходиться нижче по ланцюгу?
Ці відповіді вкажуть на релевантний список загроз, розмір радіуса ураження та правильне місце для ізоляції. Отримати ці дані без попереднього вивчення інфраструктури неможливо. Тому процес інвентаризації завжди розгортається перед налаштуванням засобів контролю.
План дій на наступний квартал
- Спершу проводиться інвентаризація. Фіксуються моделі, агенти, сервери MCP, помічники з кодування із правом запису в репозиторій та інструменти, розгорнуті без відома служби безпеки. Стримування, межі якого неможливо визначити, – це лише напис на слайді, а не реальний засіб контролю.
- Класифікація здійснюється за межами можливостей компонента, а не за його постачальником чи наявністю в певному списку OWASP.
- Виправлення, запропоновані ШІ, розглядаються як неперевірені дані – включно з порадами від власних інструментів. Вказівки щодо виправлень не передаються агенту з оновлень без повної впевненості в їхній безпеці.
- Необхідне впровадження моніторингу прихованих збоїв. Критерій приймання має бути змінений з «чи перестав спрацьовувати скрипт відтворення помилки» на «чи досі існує вразливий шлях».
- Важливо отримати власні локальні показники – для цього бенчмаркінг проводиться на основі вже виправлених помилок у власному коді, що дозволяє відмовитися від планування з огляду на чужі усереднені результати.
Наслідок, залишений поза увагою
Систему навколо моделі слід будувати так, щоб у разі її збою не зламалося нічого критичного. Якщо розгорнути цю думку на крок далі, постає структурне запитання: хто саме створює цю систему навколо моделі?
Це не може бути сама модель. Компонент не здатний обмежити власний радіус ураження. Це також не має бути постачальник, чия модель згенерувала вивід, який потім перевіряється тією ж родиною моделей із тими ж параметрами. У такому разі автор і контролер матимуть спільні сліпі зони.
Тут ідеться не про технічні можливості. Сучасні моделі швидко вдосконалюються, і помилки, яких вони припускаються сьогодні, стануть рідкістю вже через шість місяців. Це питання структури, а структура не покращується з наступним релізом. Аудитор не може бути автором.
Платформа Mend.io не генерує код застосунків. Вона здійснює його верифікацію – перевіряється все, що написали асистенти, незалежно від інструменту генерації.
Сьогодні на платформі Mend доступні: виявлення активів та AI-BOM для моделей, агентів і компонентів ШІ; сканування ризиків моделей та конфігурацій агентів; посилення системних промптів; Red Teaming; захист під час виконання усередині застосунку або через проксі. Усе це працює поруч зі скануванням SCA, SAST, контейнерів та IaC у самому коді.
Модель буде обмануто. А чи матиме це наслідки – залежить від того, що саме побудовано навколо неї.
