Три слоя AI-рисков, о которых говорили на Black Hat и DEF CON
Сезон конференций Black Hat и DEF CON традиционно заканчивается волной обновлённых чек-листов по безопасности. В этом году один из них — обновление OWASP LLM Top 10 — набрал особенно много внимания. Проблема в том, что команды безопасности, которые ограничатся только им, готовятся к прошлой войне: рядом уже созрели ещё два фреймворка, покрывающие риски, которых в классическом LLM Top 10 просто нет.
Расширение границ
В августе OWASP выпустил обновлённую версию LLM Top 10 — на этот раз опирающуюся на анализ тысяч реальных инцидентов, а не только на экспертные прогнозы. Промпт-инъекции и раскрытие чувствительной информации по-прежнему занимают первое и второе места, следом идут утечка системного промпта, некорректная обработка вывода модели и неограниченное потребление ресурсов.
Сам факт, что рейтинг теперь построен на массиве реальных зафиксированных случаев, а не только на теоретическом моделировании угроз, важен сам по себе: он показывает, что промпт-инъекции и утечки данных через модель — это уже не гипотетический риск для конференционных докладов, а повседневная практика атакующих, с которой команды безопасности сталкиваются в проде.
Но, как отмечают авторы разбора на Security Boulevard, LLM Top 10 описывает риски отдельно взятой модели — а современные ИИ-системы давно вышли за рамки «модель отвечает на вопрос». Поэтому параллельно существуют ещё два фреймворка. Первый — OWASP Top 10 for Agentic Applications, вышедший в декабре 2025 года, описывающий риски именно агентских систем: захват цели агента (goal hijack), злоупотребление инструментами, злоупотребление привилегиями идентификации, отравление памяти и контекста, небезопасная коммуникация между агентами и «беглые агенты» (rogue agents), действующие вне заданных границ.
Второй — OWASP MCP Top 10, пока в статусе беты, посвящённый протоколу Model Context Protocol, через который агенты подключают внешние инструменты. В нём отдельно выделены командные инъекции (агент выполняет системные команды, собранные из недоверенного ввода), отравление описаний инструментов (tool poisoning, когда модель доверяет описанию инструмента, а скомпрометированное описание меняет поведение агента без каких-либо подозрительных признаков), недостаточная аутентификация между MCP-серверами, инструментами и агентами, и теневые MCP-серверы — неавторизованные развёртывания вне контроля службы безопасности, часто с настройками по умолчанию.
Один за всех
Три фреймворка описывают три разных уровня одной и той же системы: сама модель, агент, который эту модель использует для принятия решений и действий, и протокол, через который агент подключается к внешним инструментам. Организация, которая проверяет свою ИИ-систему только по LLM Top 10, оставляет непроверенными два целых слоя рисков — а именно на уровне агентов и MCP-коннекторов сегодня происходит наибольший рост реальных инцидентов, потому что именно там у ИИ-системы появляются реальные полномочия: доступ к файлам, базам данных, внутренним API.
Для российских компаний, которые в 2025–2026 годах массово подключают агентские сценарии — от автоматизации техподдержки до ИИ-агентов, работающих с внутренними системами через MCP, — это означает, что закупочные и аудиторские требования к безопасности ИИ, ограниченные только классическим LLM Top 10, систематически недооценивают риск. Если агент с недостаточной аутентификацией или теневой MCP-сервер получит доступ к персональным данным клиентов или сведениям, составляющим коммерческую тайну, это прямой риск по ФЗ-152 и ФЗ-98 — независимо от того, что сама языковая модель была защищена от промпт-инъекций.
Практическое следствие для CISO: вопрос к вендору «блокируете ли вы промпт-инъекции?» больше не достаточен. Нужно спрашивать про покрытие всех трёх фреймворков сразу — модели, агента и протокола подключения инструментов.
Есть и бюджетное следствие. Три фреймворка — это не значит, что нужно закупать три разных инструмента и три отдельных процесса сертификации: чаще всего они пересекаются на уровне архитектуры, потому что модель, агент и MCP-инструменты в реальной системе связаны единым потоком запросов и вызовов. Но если планировать бюджет на безопасность ИИ, ориентируясь только на LLM Top 10, легко получить ситуацию, когда деньги потрачены, аудит модели пройден, а реальный инцидент происходит на уровне агента или MCP-сервера, который вообще не рассматривался как объект защиты.
Что дальше
Первый шаг — пересобрать модель угроз ИИ-систем компании с учётом всех трёх уровней, а не только классического LLM Top 10. Это означает инвентаризацию не только используемых моделей, но и всех агентов, действующих от их имени, и всех MCP-серверов и инструментов, к которым эти агенты подключены — включая теневые, о которых служба безопасности может не знать.
Второй шаг — контроль, который применяется не постфактум (после инцидента или в рамках разового аудита), а непрерывно, в реальном времени, на каждом запросе к модели и каждом вызове инструмента.
Именно так устроен Strazh LLM Firewall: INPUT-guardrails детектируют промпт-инъекции и блокируют запросы, нарушающие политику, до того как они дойдут до модели. OUTPUT-guardrails фильтруют чувствительную информацию и модерируют контент в ответах. Отдельный модуль валидирует каждый вызов инструмента или MCP-функции перед выполнением — что напрямую закрывает риски command injection, tool poisoning и недостаточной аутентификации из MCP Top 10, а защита RAG-конвейера блокирует отравленные документы до того, как они повлияют на ответ модели. Это покрытие построено именно вокруг OWASP Top 10 for LLM и логично расширяется на смежные агентские и MCP-риски — потому что в реальной инфраструктуре компании эти три слоя всегда работают вместе, и защищать их нужно тоже вместе, а не по отдельности.