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

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

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

Это список 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 говорит, что любому агенту со всеми тремя нужно подтверждение человека для каждого действия.

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

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

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

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

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

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

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

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

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

Шесть мер, и все они код, которым вы владеете, закрывают большинство из десяти рисков. Эти лучшие практики безопасности ИИ взяты прямо из разделов 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% относится к запрещённым практикам, а не к пробелам в безопасности. Оба текста прочитаны на EUR-Lex 07.10.2026.

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

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

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

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