Ваше ИИ-приложение или агент работают. Затем отдел безопасности задает вопрос: проверяли ли вы их на соответствие списку Open Worldwide Application Security Project (OWASP) Top 10?

Заманчивый ответ — это проверка документации: «Мы прочитали список, добавили системный промпт и считаем, что всё в порядке». Служба безопасности не может этого подтвердить, поэтому проверка заходит в тупик. Этот вопрос также сложнее, чем кажется, поскольку OWASP теперь публикует два списка: OWASP Top 10 for Large Language Model (LLM) Applications, выпущенный 3 августа 2026 года, и OWASP Top 10 for Agentic Applications, опубликованный 9 декабря 2025 года с учетом мнения более 100 экспертов. Эти два списка частично совпадают, и то, какой из них применять, зависит от того, что делает ваше приложение.

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

Что хочет услышать служба безопасности

Цель — не получить 20 зеленых галочек. Руководители проектов OWASP не рекомендуют пытаться создать модель, которую невозможно обмануть. Вместо этого постройте систему вокруг модели так, чтобы при обмане модели ничего важного не сломалось.

Поэтому ответ, который ищет служба безопасности, должен быть кратким и строиться на трех вопросах:

К чему есть доступ? С какими инструментами, данными, учетными данными и системами ваше приложение взаимодействует, что оно меняет и куда отправляет информацию?
Что произойдет, если его обманут? Исходите из того, что это случится. Какое самое худшее действие оно может совершить?
Можете ли вы это показать? Есть ли доказательства, которые может проверить аудитор, помимо ваших слов?

Ответ «да, мы проверили» без этих трех ответов не пройдет проверку.

Какой список OWASP применим к вашей разработке

Решайте на основе архитектуры, а не того, как назвал список проверяющий.

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

Как проверить ваше ИИ-приложение или агента на соответствие OWASP Top 10

1. Нарисуйте схему того, что оно загружает и что может делать

Сделайте это на одной странице: модель, инструменты, источники данных, память, серверы Model Context Protocol (MCP), навыки, пакеты и учетные данные, которые использует каждый из них. Вы не можете проверить то, что не перечислили, и проверяющие потребуют это в первую очередь.

2. Оцените уровень агентности, а затем снизьте его

В списке LLM Top 10 за 2026 год приводятся два быстрых теста. «Смертельная тройка» Саймона Виллисона гласит, что агента, который имеет доступ к частным данным, принимает недоверенный контент и общается с внешними системами, можно обманом заставить отправить ваши данные злоумышленнику. OWASP добавляет, что исключение любого из этих трех факторов закрывает этот путь. «Правило двух» для агентов от Meta гласит, что агент не должен сочетать все три фактора без надзора: недоверенный ввод, доступ к конфиденциальным системам или данным, а также возможность изменять состояние или общаться с внешними системами. OWASP строго применяет это правило: любой агент со всеми тремя факторами требует одобрения человеком каждого действия.

Посчитайте, сколько из этих трех факторов есть у вашего агента. Это и будет его оценка агентности, от 0 до 3. OWASP не публикует официальную оценку; эта объединяет оба теста в одно число. Агент с оценкой 3 требует одобрения человеком каждого действия. Если недоверенный ввод сочетается с любым из двух других факторов, OWASP требует письменной оценки рисков. Снизьте уровень агентности перед тем, как что-либо тестировать. Это самое дешевое решение из всех возможных.

3. Сопоставьте свою разработку с применимыми пунктами

Вам не нужно спорить обо всех 20 пунктах. Проверьте те, которые затрагивает ваша архитектура, и объясните, почему остальные не применимы. OWASP нумерует пункты в каждом списке: LLM01–LLM10 для LLM Top 10 и ASI01–ASI10 для Agentic Top 10.

4. Тестируйте как злоумышленник, который изучил вашу защиту

Фиксированный набор тестов мало что дает. В исследовании a USENIX Security 2026 paper, на которое ссылается OWASP, Наср и соавторы протестировали 12 современных методов защиты от джейлбрейков и инъекций промптов, большинство из которых изначально показывали почти нулевой успех атак. Адаптивные злоумышленники, которые настраивали свои атаки под каждую защиту, добивались успеха более чем в 90% случаев против большинства из них. Размещайте вредоносный контент везде, где ваше приложение считывает данные, включая веб-страницы, документы, тикеты, описания инструментов и память, и смотрите, что оно делает со своими инструментами.

Сканируйте навыки, MCP-серверы и пакеты перед их использованием. Они работают с правами доступа вашего приложения, поэтому отравленное описание инструмента или пакет — это инъекция, которую вы установили сами.

5. Установите средства контроля на границе инструментов

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

6. Интегрируйте в CI и сохраняйте доказательства

Разовая проверка устаревает, как только вы меняете модель, навык или инструмент. Запускайте тесты в рамках непрерывной интеграции (CI), чтобы каждое изменение их активировало, и сохраняйте результаты.

Что предоставить для проверки безопасности

OWASP — это общий словарь, а не сертификация. Списки являются добровольными, а соответствие требованиям определяется нормативными актами, которые применимы к вам. Поэтому предоставьте доказательства:

Карта системы: оценка агентности каждого агента (0–3) и то, что вы удалили, чтобы снизить её.
Инвентаризация цепочки поставок: модели, навыки, MCP-серверы и пакеты, которые вы используете, с результатами сканирования для каждого.
Применимые пункты: пункты, которые затрагивает ваша архитектура, с кратким обоснованием для каждого исключенного пункта.
Результаты тестирования: шаги по воспроизведению для каждой находки, плюс список того, что осталось непротестированным.
Средства контроля: политики на границе ваших инструментов и то, что они блокируют.
Журналы исполнения: решения, принятые средствами контроля, если приложение уже работает.
План повторного тестирования: что инициирует повторную проверку, например, изменение модели, навыка, инструмента, MCP-сервера или пакета.

Где место Enkrypt AI

Тестирование перед выпуском, обеспечение безопасности во время выполнения и сохранение доказательств могут означать использование трех разных инструментов и трех наборов политик с пробелами между ними. Enkrypt AI от Anaconda тестирует ваше приложение или агента перед выпуском и применяет ту же политику во время работы. Большинство шагов, описанных выше, затем создают отчет, который можно передать проверяющему.

Входные данные для вашей карты системы и инвентаризации цепочки поставок: наш MCP Scanner инвентаризирует MCP-серверы и инструменты, а также помечает избыточные привилегии. За два месяца до августа 2026 года он просканировал более 268 000 инструментов на 25 000 MCP-серверах и обнаружил более 143 000 уязвимостей, затрагивающих 73% этих серверов. Skill Sentinel — это программное обеспечение с открытым исходным кодом, устанавливается через pip install skill-sentinel и сканирует навыки агентов на предмет инъекций промптов, утечки данных, командных инъекций и вредоносного ПО. Он запускается как шаг CI и требует API-ключ OpenAI (или другого поддерживаемого провайдера моделей). AI Artifacts от Anaconda предоставляет командам курируемый источник пакетов со сканированием уязвимостей, пользовательскими политиками безопасности и подписями пакетов.
Результаты тестирования и план повторного тестирования: Agent Red Teaming генерирует атаки, адаптированные к вашим политикам и графу инструментов, охватывая более 300 категорий атак. Система возвращает реестр выявленных проблем с шагами для их воспроизведения и карту покрытия того, что было и что не было протестировано. В планах Scale и Enterprise исправленные уязвимости превращаются в набор регрессионных тестов, которые можно запускать в CI. Платные планы добавляют сопоставление с требованиями соответствия стандартам NIST AI Risk Management Framework, OWASP Top 10 для приложений LLM и Закону ЕС об ИИ (EU AI Act).
Средства контроля: Agent Guardrails и open-source MCP Gateway одобряют, изменяют или блокируют вызовы инструментов до их выполнения, используя списки разрешенных объектов и принудительное применение принципа наименьших привилегий.
Журналы принудительного исполнения: Agent Guardrails регистрирует каждое решение о применении правил с указанием идентификатора политики и кода причины. Наш Agent Policy Engine преобразует политики управления в средства контроля, лежащие в основе этих решений, включая стандартные элементы управления OWASP, NIST и EU AI Act.

Выполните эти проверки для агента, который вы собираетесь выпустить, и представьте результаты на следующем аудите безопасности. Просканируйте MCP-сервер бесплатно, запросите демо или изучите вопросы безопасности ИИ и механизмы защиты на платформе Anaconda.

Часто задаваемые вопросы

Что значит «проверить» ИИ-приложение на соответствие OWASP Top 10?

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

Какие из списков OWASP Top 10 применимы к ИИ-агенту?

Оба. Первый охватывает модель как компонент вашего приложения. Второй охватывает риски, которые возникают, когда модель взаимодействует с инструментами, памятью и имеет последствия для последующих систем.

Можно ли полностью предотвратить инъекции промптов?

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

Достаточно ли пройти тест на инъекцию промптов?

Нет, если тест статичен. В исследовании адаптивные злоумышленники, знавшие принцип работы каждой защиты, обходили большинство из 12 недавних систем защиты более чем в 90% случаев, хотя изначально большинство из них сообщали о почти нулевом успехе атак. Тестируйте с помощью атак, адаптированных к вашим средствам защиты, и повторяйте их при любых изменениях.

Нужно ли проводить повторное тестирование при смене моделей или добавлении навыков?

Да. Новая модель, навык, MCP-сервер или пакет меняют область доступа вашего приложения и способы его сбоев, поэтому ваши предыдущие результаты больше не описывают работающую систему.

Что изменилось в OWASP LLM Top 10 в 2026 году?

10 категорий остались прежними, но большинство из них изменили свои позиции. «Чрезмерная агентность» (Excessive Agency) поднялась с шестого на третье место, «Неограниченное потребление» (Unbounded Consumption) — с 10-го на шестое, а «Дезинформация» (Misinformation) — с девятого на седьмое. «Неправильная обработка вывода» (Improper Output Handling) опустилась с пятого на 10-е место, а «Утечка системного промпта» (System Prompt Leakage) была переименована в «Раскрытие скрытого контекста» (Hidden Context Exposure).