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 в самом коде.
Модель будет обманута. А будут ли у этого последствия – зависит от того, что именно построено вокруг нее.
