Безопасность LLM в 2026 году: OWASP Top 10 с мерами защиты и тестами

Безопасность LLM - это умение построить систему вокруг языковой модели так, чтобы обманутая модель не сломала ничего важного. Саму модель неуязвимой не сделать: инструкции и данные она читает как один поток токенов, и руководство OWASP 2026 года прямо говорит, что надёжной защиты от промпт-инъекций сегодня нет. Поэтому работа переносится в код вокруг неё. Сузьте то, до чего модель может дотянуться, проверяйте каждое запрошенное ею действие вне модели, ограничьте то, что она может потратить, и считайте написанное ею недоверенным вводом. Большинство команд работает по чек-листу OWASP Top 10 для LLM-приложений, его редакция 2026 года вышла в августе. Ниже для каждого из десяти рисков показано, как он выглядит в реальном приложении, какая мера его ограничивает и какой тест можно прогнать до релиза.

Какие риски входят в OWASP Top 10 для LLM-приложений в 2026 году?

Порядок официальный, по genai.owasp.org на 07.10.2026. Меры и тесты мы сжали из разделов OWASP о снижении рисков и оставили только то, что под силу небольшой команде.

Список описывает модель как компонент внутри вашего приложения. Когда модель начинает действовать сама, с инструментами, памятью между сессиями и последующими действиями, OWASP отсылает ко второму списку, Top 10 для агентных приложений, опубликованному в декабре 2025 года. Большинству работающих агентов нужны оба.

Что изменилось в списке 2026 года и почему это важно?

Редакция 2026 года первая, сверенная с данными об инцидентах. Проект собрал 7 714 инцидентов из открытых баз уязвимостей и базы вреда от ИИ, классифицировал 6 639, по которым хватало подробностей, и дал этим данным четверть веса, а остальные три четверти пришлись на голосование практиков.

Порядок сдвинулся сильнее, чем в прошлые годы:

• Excessive Agency поднялся на третье место. OWASP считает это главным изменением списка, потому что ущерб приходится именно на агентов.
• Unbounded Consumption поднялся на четыре места, до шестого. Практики теперь считают расходы и исчерпание ресурсов опаснее, чем выходило по старому месту.
• Improper Output Handling опустился с пятого на десятое и теперь охватывает ещё и небезопасный код, который ассистенты генерируют в больших объёмах.
• System Prompt Leakage превратился в Hidden Context Exposure, который кроме системного промпта охватывает схемы инструментов, инструкции разработчика и текст политик.
• Misinformation на седьмом месте, но руководители проекта OWASP выделяют его особо: голосующие поставили его почти в конец, а данные об инцидентах почти в начало.

Перед тем как планировать бюджет, учтите, что при ранжировании только по сырым данным об инцидентах промпт-инъекция выпадает из первой десятки. OWASP объясняет это тем, что защита работает: команды упорно борются с инъекциями, поэтому до открытых баз доходит меньше чистых эксплойтов. Первое место она сохраняет, потому что поверхность атаки есть везде, где модель читает недоверенный ввод.

Какие три главных риска безопасности ИИ?

По списку 2026 года: промпт-инъекция, раскрытие чувствительной информации и избыточные полномочия. Читать их лучше как одну цепочку.

Инъекция попадает через содержимое, которое читает модель: обращение в поддержку, веб-страницу, приглашение в календарь, заголовок задачи. Что она сможет сделать дальше, зависит от того, какие данные видит модель (второй риск) и что модель может сделать (третий риск). Статья OWASP о промпт-инъекциях говорит, что большинство зафиксированных серьёзных инцидентов стали такими потому, что инъекция попала в систему, где инструменты или права доступа позволяли модели действовать с привилегиями пользователя.

Отсюда проверка, которую можно провести у доски. Саймон Уиллисон называет это смертельной триадой (lethal trifecta), Meta называет свой вариант правилом двух (Rule of Two), и документ OWASP ссылается на оба: у агента, который может читать недоверенное содержимое, дотягиваться до закрытых данных и общаться с внешним миром (или менять состояние), есть всё, что нужно атакующему. Уберите одно из трёх условий, и худший исход станет скромнее. OWASP говорит, что любому агенту со всеми тремя нужно подтверждение человека для каждого действия.

Почему фильтр промптов не решает проблему промпт-инъекций?

Потому что атакующий подстраивается, а фильтр нет. Это показали Nasr с соавторами (2025): против 12 недавних защит атаки, которые в статических тестах почти никогда не срабатывали, срабатывали больше чем в 90% случаев против большинства из них, как только атакующий мог подстроиться под защиту. Схемы структурного разделения вроде StruQ обходили так же.

Управляемые guardrails показывают ту же картину на границе ввода. ML6 проверила четыре из них на 80 000 промптов на нидерландском языке в пропорции 63/37 между безобидными и вредоносными, с настройками по умолчанию или близкими к ним (опубликовано 22 июня 2026 года):

Язык важен (ML6 намеренно взяла нидерландский), и с настроенными параметрами результаты были бы другими, но вывод верен для любого языка: guardrail - это один слой, который снижает долю успешных атак. Исходите из того, что часть инъекций пройдёт, и проектируйте так, чтобы обманутая модель мало что могла сделать.

Что пентест упускает в LLM-приложении?

Обычный веб-пентест по-прежнему важен: аутентификация, работа с сессиями, инъекции в ваши собственные API и инфраструктура касаются и LLM-приложения. Чего он обычно не проверяет:

• Непрямую инъекцию: тестировщики печатают в окно чата. Опасные инструкции приходят через документы, извлечённые страницы, письма и результаты инструментов, которые модель читает сама.
• Права инструментов: пентест проверяет, авторизован ли эндпоинт. Он редко спрашивает, должна ли модель вообще его вызывать и с какими правами.
• Постоянство в памяти и RAG: инъекция, записанная в долговременную память или векторное хранилище, влияет на каждую последующую сессию, которая оттуда читает. Одна тестовая сессия этого не покажет.
• Расходы: исчерпание вашего бюджета на вывод модели - атака из списка 2026 года. Мало какой пентест включает тест расходов.
• Адаптивных атакующих: фиксированный набор промптов измеряет, чего добиваются статические атаки, а Nasr с соавторами показали, насколько это занижает возможности атакующего, который подстраивается.
• Места, куда уходит вывод: вывод модели, который попадает в браузер, терминал, базу данных или другому агенту, требует той же проверки, что и пользовательский ввод, и часто не входит в объём пентеста.

Заказывая пентест, впишите эти пункты в техническое задание поимённо и попросите список использованных нагрузок. Если тестировщик не может рассказать, как он добрался до модели через извлечённое содержимое, непрямой путь не проверяли.

Какие лучшие практики безопасности ИИ закрывают большую часть списка?

Большинство из десяти рисков закрывают шесть мер, и все шесть - ваш собственный код. Эти лучшие практики безопасности ИИ взяты прямо из разделов OWASP о снижении рисков.

1. Авторизация вне модели. Модель предлагает, код решает. Каждый вызов инструмента проходит проверку пользователя, действия и его аргументов, OWASP называет это полным посредничеством (complete mediation). Это ограничивает сразу инъекции, избыточные полномочия и раскрытие скрытого контекста, потому что промпт сам по себе ничего не разрешает. Та же привычка, из-за которой сервисный ключ попадает в клиентский бандл, заносит API-ключи в системные промпты, и вычищают их одинаково.
2. Минимальные привилегии для каждого инструмента. Инструмент, который пересказывает почту, получает доступ на чтение, а не на отправку или удаление. Сервис рекомендаций товаров получает доступ на чтение к одной таблице. Избегайте открытых инструментов (shell, загрузка любого URL), когда хватило бы узкого. Если вы строите MCP-сервер, этот принцип прямо применяет поэтапный запуск из MCP-сервера за 90 дней: сначала только чтение, а действия с подтверждением человека потом.
3. Проверка доступа внутри извлечения. Фильтруйте по клиенту и правам на документ в запросе к индексу, до того как вернутся результаты. Это закрывает и раскрытие чувствительной информации, и случай с чужими клиентами в слабостях векторов.
4. Жёсткие потолки, которые применяет код. Лимиты токенов на пользователя и в минуту, потолки расходов, которые останавливают вывод модели, и лимиты шагов, рекурсии и времени для агентов.
5. Вывод - недоверенный ввод. Кодируйте под место, куда он попадает, используйте параметризованные запросы, блокируйте автоматически отображаемые Markdown-картинки и превью ссылок и вычищайте управляющие символы, прежде чем вывод попадёт в терминал или лог. Код, который модель пишет для вас, тоже вывод и проходит ту же проверку.
6. Необратимое подтверждает человек. Платежи, внешние сообщения, удаления. Показывайте проверяющему точное действие, которое выполнится, а не пересказ. Где провести эту границу и сколько это стоит, разобрано в тексте о том, что вашему ИИ решать нельзя.

Первый пункт мы проверили на себе. На нашем сайте работает конвейер, который собирает письма из чисел нашего аудита, и правило в промпте там не сработало. Модель, писавшая по нашим же замерам, перевернула процент, сложила два отдельных замера в один и поставила две цифры в обратном порядке. Запрет в промпте не пережил и двух его переписываний. Помог код, который до отправки сверяет каждое утверждение с исходными данными. Это приём OWASP «утверждение, проверка, действие» (claim-check-act) против дезинформации.

Как проверить LLM-приложение перед релизом?

Относитесь к проверке как к регрессионному набору, который прогоняется при каждом изменении промпта, модели, инструментов или источников для извлечения.

• Соберите набор нагрузок на каждый риск, взяв за план таблицу выше: внедрённые инструкции в каждом типе содержимого, которое вы загружаете, запросы через границу клиентов, попытки извлечь системный промпт, слишком большие вводы, вывод, который выполнится в вашем рендерере. Начните с нескольких случаев на риск, лишь бы они шли по путям вашего собственного приложения.
• Для охвата берите открытые инструменты: garak от NVIDIA описывает себя как сканер уязвимостей LLM. PyRIT от Microsoft - открытый фреймворк для поиска рисков в генеративных ИИ-системах. promptfoo запускает red team и сканирование уязвимостей по декларативным конфигам и встраивается в CI. Статья OWASP 2026 года называет AgentDojo и JailbreakBench как базовые наборы. В Web Security Academy от PortSwigger есть практические лабораторные по атакам на веб-LLM, если ваша команда ещё ни одной не проводила.
• Затем тестируйте адаптивно: дайте специалисту red team полное описание вашей защиты и позвольте ему итерировать. OWASP советует не принимать цифры успешности атак, полученные только в статических тестах.
• Проверяйте радиус поражения, а не только саму инъекцию: для каждого инструмента спросите, что будет, если модель вызовет его с худшими допустимыми аргументами. Если ответ неприемлем, исправлять нужно права или подтверждение, правка промпта тут не поможет.
• Привяжите к этому релиз: проваленный случай блокирует деплой так же, как проваленный юнит-тест. Перезапускайте после каждого обновления модели: новая версия модели - новая зависимость.

Если ваш продукт ещё и открывает страницы или действия внешним ИИ-агентам, текст про SaaS, готовый к браузерным агентам, разбирает, каких согласий и журналов аудита эти агенты от вас ждут.

Что AI Act ЕС требует для безопасности LLM?

Для ИИ-систем высокого риска статья 15(5) AI Act требует устойчивости к попыткам изменить использование системы, её вывод или работу, с мерами против отравления данных, отравления модели, состязательных примеров, атак на конфиденциальность и дефектов модели. Это ложится на LLM05 (отравление), LLM02 (конфиденциальность) и LLM01 (ввод, составленный так, чтобы модель ошиблась).

В 2026 году сроки сдвинулись. Регламент (ЕС) 2026/1744, Digital Omnibus по ИИ, устанавливает, что требования к высокому риску применяются с 2 декабря 2027 года для систем из Приложения III (занятость, образование, кредиты и похожие применения) и со 2 августа 2028 года для ИИ, встроенного в продукты, на которые распространяются законы о безопасности из Приложения I. За нарушение обязанностей поставщика штраф может составить до 15 млн евро или 3% мирового годового оборота, смотря что больше. Уровень в 7% относится к запрещённым практикам, а не к пробелам в безопасности. Источники: сообщение Европейской комиссии об AI Omnibus и статья 99 Регламента (ЕС) 2024/1689.

Ассистент поддержки клиентов или инструмент внутреннего поиска обычно не относится к высокому риску по Приложению III. Меры OWASP всё равно стоит внедрить, а если позже вы перейдёте к применению высокого риска, отчёты о тестах станут вашими доказательствами.

С чего начать небольшой команде?

Если вы выпускаете первую функцию на LLM или унаследовали такую, собранную наспех, такой порядок снижает риск сильнее всего при минимуме работы:

Дальше прогоняйте набор при каждом изменении модели, промпта или инструмента и пересматривайте список рисков, когда OWASP его обновляет. Если после запуска за системой в команде никто не отвечает, для этого есть Care: мы принимаем систему, собранную своими силами, стабилизируем её и дальше за ней следим.