AI-security развивается, но единого стандарта пока нет: как бизнесу защищать ML-модели и AI-агентов

Привет! Меня зовут Борис Мацаков, я Data Science инженер в Cloud.ru ^[1]. Хочу поговорить о сравнительно новом направлении кибербезопасности — защите AI-систем и агентов.

Каждая команда понимает безопасность AI-моделей по-своему, а за ее основу часто берут подходы классического DevSecOps. Но проблема в том, что классический DevSecOps защищает периметр, зависимости, инфраструктуру и доступы, а атаки на модели происходят совсем в других слоях: в данных, контексте и самой логике ^[2] работы модели.

Именно поэтому одних инфраструктурных мер недостаточно и для AI-агентов нужно закладывать отдельный контур безопасности поверх базовых методов DevSecOps. В еще молодой области AI-security появляются фреймворки, типологии атак и практические рекомендации, но единого стандарта и «общего ГОСТа» пока нет. Зато есть рамки, на которые уже можно опереться: OWASP Top 10 для LLM-приложений и отдельный Top 10 для agentic-приложений, SAIF-карта рисков, MITRE ATLAS как база техник атак на AI. Этого достаточно, чтобы выстроить практичную защиту и не изобретать ее с нуля. Давайте разбираться, почему DevSecOps здесь не хватает и какие контуры защиты нужны AI-системам на практике.

Почему классический кибербез не защищает от AI-специфичных атак

В обычных IT-системах все довольно прямолинейно: есть уязвимость в коде, конфигурации или инфраструктуре — ее используют для взлома. А AI-специфичные атаки бьют по данным и логике модели — это просто другой слой, который DevSecOps по умолчанию не покрывает.

Модель может быть полностью защищена на уровне API и инфраструктуры (WAF, SAST/DAST, IAM), но при этом принимать вредные решения или выдавать некорректные ответы, потому что на уровне HTTP/инфраструктуры запрос может выглядеть абсолютно легитимным: «просто текст». А внутри контекста он становится инструкцией, которая конфликтует с правилами приложения, подменяет смысл задачи или провоцирует утечку или действие.

В случае с LLM это в основном чревато репутационными рисками: модель может нагрубить или выдать персональные данные. Но если атакуют AI-агента, который подключен к другим инструментам, БД или CI/CD-пайплайну, это прямая угроза инфраструктуре. Злоумышленники могут добиться подмены артефактов, заставить агента выполнить вредоносный код или удалить что-нибудь важное.

Именно поэтому на рынке выделился отдельный класс AI firewall (LLM firewall) — решения, которые инспектируют вход и выход LLM-эндпоинтов и пытаются детектировать prompt injection, джейлбрейки и утечки чувствительных данных. Например, у Cloudflare и Akamai это так и называется — Firewall for AI.

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

Какие принципы работы AI-моделей делают их уязвимыми

Большие компании по безопасности вроде OWASP ^[4] и MITRE ^[5] систематизируют и классифицируют уязвимости AI-систем, и уже можно насчитать несколько десятков разных вариантов. Самое интересное, что большинство из них сводится к базовым свойствам самих моделей.

AI воспринимает любой ввод как часть задачи. В LLM-системах с RAG модель не различает инструкцию и контент, факт и манипуляцию. На уровне Chat-API системные инструкции, пользовательский ввод и retrieved-контент передаются как разные роли. Но перед инференсом они обычно сериализуются в единый вход модели — последовательность токенов со служебными маркерами ролей и границ. Именно поэтому retrieved-контент нужно считать не инструкциями, а недоверенными данными. Эту проблему пытаются смягчить подходами вроде hierarchical prompting/instruction hierarchy, где модель обучают приоритизировать privileged-инструкции над пользовательским вводом и стор��нним контентом. Но это не «жесткая изоляция», поэтому архитектурное правило все равно остается прежним: retrieved-контент — untrusted data.

Из-за этого возможен, например, indirect prompt injection, когда вредоносная директива встраивается в retrieved-документ, который RAG подгружает в контекст. Например, злоумышленник добавляет в корпоративную базу знаний документ с «аналитикой», в котором указывает, что спорные транзакции нужно считать согласованными, если они не обновляются дольше трех дней. RAG по семантическому сходству определяет этот фрагмент документа как релевантный и добавляет в контекст. В результате модель считает сомнительные операции со статусом завершенными.

AI с памятью ^[6] хранит контекст взаимодействия и использует его при следующих обращениях. Само по себе это удобно: модель запоминает предыдущие разговоры и потом отвечает точнее, но эта функция открывает новую точку для атак. Злоумышленник может сместить поведение ^[7] модели — так происходит context poisoning.

Допустим, в компании есть AI-ассистент, который собирает финансовые отчеты. Если злоумышленник получит к нему доступ, то через память модели сможет постепенно сместить тон ответов. Например, заставить ассистента акцентировать позитивные тенденции и игнорировать падения. В итоге отчеты сглаживают проблемы и становятся необъективными.

AI не способен пересмотреть усвоенные связи. После обучения ^[8] все закономерности из датасета становятся частью внутренней логики модели. Если есть вредоносные шаблоны, модель будет воспроизводить их до следующего переобучения, файнтюнинга или обновлен��я данных в RAG.

Это свойство эксплуатирует атака data poisoning — намеренная порча обучающих данных. Например, в антифрод‑модель целенаправленно подмешивают транзакции, где мошеннические операции помечены как «нормальные». Если такой набор проходит в обучение, модель начинает «учиться» на искаженной картине и со временем пропускает все больше похожих операций в проде, пока ее явно не переобучат на очищенных данных.

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

Современные модели более устойчивы к таким атакам, но полностью уязвимость не исчезла. Злоумышленники подбирают сложные цепочки промптов, которые шаг за шагом уводят модель от изначальных ограничений. Сейчас это уже не «одна простая фраза», а комбинации ролей, контекстов и обходных формулировок, которые эксплуатируют конфликт ^[9] между целями safety и helpfulness.

Как защищать AI-агентов и LLM

Защита строится вокруг управления тем, как модель получает, хранит и использует информацию. О рисках вокруг AI и LLM уже много говорят. Например, в OWASP Top 10 для LLM-приложений ^[10] и OWASP Top-10 для agentic-приложений ^[11] описаны основные угрозы и даны базовые рекомендации по их снижению. Но единого стандарта пока нет, и практики во многом формируются на ходу. Я выделил, на мой взгляд, самые важные меры по защите AI, а еще спросил мнения у знакомых специалистов. В итоге получился шорт-лист мер безопасности, который условно можно разделить на несколько контуров.

Данные и пайплайн обучения

В этом разделе собрал все, что происходит до выхода модели в прод: какие данные в нее попадают, как они обрабатываются. Любые искажения здесь сказываются на том, как модель потом будет себя вести.

Контроль происхождения данных. Чтобы снизить риск отравления данных и внедрения бэкдоров, стоит проверять data provenance и data lineage. Если у набора можно раскопать историю изменений, стоит проверить, кто добавлял данные, как обрабатывал и как менял метки.

Источники данных могут быть доверенные и внешние. К доверенным я бы относил те, где путь данных можно проследить полностью: внутренние выгрузки из сервисов компании, хранилища, очереди, корпоративные BI-системы. В таких контурах проще вычислить происхождение и понять, откуда пришел набор, потому что инфраструктура хранит логи и версии выгрузок. Проверять их на целостность и аномалии все равно нужно — просто глубина аудита может быть меньше, чем для внешних датасетов. А вот датасеты из открытых репозиториев вроде Hugging Face смотреть под лупой.

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

Дифференциальная приватность (DP-SGD). Она помогает снизить риск того, что через инверсионные атаки или membership inference кто-то восстановит исходные записи. Для этого в процессе обучения применяют gradient clipping и добавляют небольшой шум к усредненным градиентам. Грубо говоря, модель запоминает закономерности, а не конкретные примеры. Минус в том, что сильный шум может немного сбить точность, так что приходится искать баланс между безопасностью и качеством.

Был у меня такой случай: пробовали внедрить DP-SGD в модель для анализа обращений пользователей банка, и первые эксперименты обрушили F1 с 0,88 до 0,74. Оказалось, что ε < 6, то есть clipping был слишком агрессивным. Мы увеличили бюджет приватности и добави��и адаптивный clipping по батчу. После этого метрики почти вернулись к исходным значениям, а тест на membership inference показал, что извлечь исходные записи стало невозможно.

Защита на этапе обучения. Модель имеет смысл заранее познакомить с разными типами вредоносных запросов. Для этого используют adversarial training: в обучающий цикл добавляют типичные промпт‑атаки и RAG‑подмены. Так модель научится распознавать атаки и фильтровать их.

Сюда же можно отнести safety finetuning — настройку реакции ^[12] модели на сомнительные запросы. Например, если пользователь просит обойти ограничения доступа, модель должна вежливо отказать.

Борис Захир ^[13], независимый эксперт, автор канала «Борис_ь с ml»

«К основным мерам защиты предиктивных моделей я бы отнес контроль доступа к наборам данных, результатам RnD-экспериментов, хранилищам моделей. И, что актуально и для генеративного ИИ, нужно уделять особое внимание ^[14] всем open source материалам: данным и файлам моделей.

Думаю, оптимально хранить модели в форматах safetensors для нейросетей и json-форматах для классики (у LightGBM, CatBoost и XGBoost, например, они свои). А если уж использовать форматы вроде pickle, то прогонять их через инструменты наподобие picklescan».

Егор Богомолов, основатель и CEO Singleton Security и CyberEd

«В первую очередь стоит выстроить жесткий контроль доступа и секретов вокруг всего ML-пайплайна + изоляцию окружений. Такой Zero Trust для ML: минимальные права, отдельные роли, сервисные аккаунты, запрет лишнего исходящего трафика, отдельные реестры/ключи, аудит.

От чего это может защитить в первую очередь:

• data poisoning через подмену датасетов/фичей и «тихие» правки в пайплайне;

• model tampering: подмена/подгрузка чужого артефакта модели, подмена весов, бэкдоров;

• supply chain в MLOps: компрометация registry/хранилища/CI;

• утечки датасетов / фичей / промежуточных артефактов (а это почти всегда коммерческая инфа)».

Сама модель

В этом блоке собрал методы защиты внутрянки модели: весов, конфигураций и связей.

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

Когда модель уже собрана и прошла все тесты, важно зафиксировать именно ту версию, которая пойдет в прод. На практике лучше подписывать не только веса, но и весь релизный пакет: weights + config + tokenizer + шаблоны промптов/политик + (если есть) версии RAG-индекса и список подключенных инструментов агента. При деплое система должна сверять подпись с эталоном и останавливать выкладку, если хеши не совпадают. Это похоже на идею SBOM в классическом DevSecOps: как SBOM фиксирует состав и версии компонентов приложения, так и здесь полезно иметь «паспорт» релиза модели — перечень всех компонентов, которые влияют на поведение ^[15] системы, с версиями и контрольными суммами.

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

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

Интерфейсы и интеграции

Этот раздел про взаимодействие модели с миром: пользователями, БД и внешними системами.

Разделение контекста. Модель должна понимать, откуда пришла информация, поэтому источники стоит передавать раздельно с явными тегами (system, user, context). В системах с RAG контент из базы знаний нужно помечать как внешний и не смешивать с промптом, чтобы модель не воспринимала его как часть своих правил. Так контексты не пересекаются — и системные команды не путаются с пользовательскими запросами.

Было дело, что мы как-то прикручивали RAG к корпоративной базе. Один из документов содержал кусок SQL-запроса, и модель восприняла его как инструкцию и попыталась исполнить, благо у нее не было тулов для доступа к БД. Но сам факт насторожил: она спутала системный слой с пользовательским контекстом. Мы добавили явные теги в промпт, и модель перестала реагировать на служебные куски из базы.

Для AI-агентов критично разделять не только контекст, но и права на действия. Как только модель получает инструменты (shell, Git, CI/CD, БД, почта, платежи), промпт-атака превращается из неправильного текста в риск инцидента. Именно поэтому инструменты агента стоит строить по принципу least privilege / capability-security: выдавать только нужные инструменты, по умолчанию делать их read-only, ограничивать allow-листами (команды/эндпоинты/таблицы), использовать scoped-tokens с коротким TTL и включать Human-in-the-Loop для возможно необратимых действий.

Дополнительно нужен слой action validation: кроме текста ответа модели, проверять сам план действий / аргументы tool-call (схема параметров, запрещенные команды и флаги, лимиты, соответствие политике). Это тот контур, который чаще всего решает исход атаки на агентную систему.

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

• интеншн-классификатор проверяет, нет ли у запроса скрытых намерений,

• контекстный анализатор смотрит, соответствует ли запрос теме диалога,

• этический валидатор оценивает, не нарушает ли запрос этические принципы модели,

• риск-оценщик вычисляет, не принесет ли вреда выполнение запроса.

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

Валидация ответов. Даже если модель прошла adversarial training и на нее навешали цепочку классификаторов, всё равно остается вероятность, что она не сможет распознать хитро замаскированную инъекцию и выдать безопасный ответ. Так что полезно проверять не только что скармливают модели, но и что она отдает на выходе.

Для этого стоит выстроить отдельный пайплайн валидации. Ответ можно прогонять через цепочку гардрейлов. Например, один гардрейл сопоставляет фактические утверждения с retrieved-контекстом, чтобы модель не галлюцинировала; другой контролирует, чтобы ответ соответствовал внутренним политикам и не сливал конфиденциальную информацию; третий проверяет ответ на токсичность. Похоже на цепочку классификаторов на входе, только тут мы уже проверяем не ввод, а вывод.

Ограничение числа запросов для защиты от model extraction. Злоумышленники могут нападать на модель массовыми запросами, выкачивая поведение, промпты или чувствительные фрагменты, а также перегружать систему дорогими запросами. Такие атаки можно отсечь, используя rate-limit по ключам/пользователям/сессиям, квоты на токены и отдельные лимиты на опасные операции (например, tool-calls). Важно не ставить один жесткий лимит «на всех», а делать разные квоты для доверенных интеграций и внешних пользователей — так защита меньше мешает нормальной работе.

Евгений Кокуйкин ^[16], CEO HiveTrace, Core Team Member, OWASP GenAI Agentic Security Initiative

«Лимиты помогают предотвратить сценарии, когда кто-то пытается использовать приложение не по назначению, например запросить неограниченное количество токенов или перегрузить инференс».

Борис Захир ^[13], независимый эксперт, автор канала «Борис_ь с ml»

«Для генеративных сетей основная поверхность атаки — на этапе эксплуатации.

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

А если уж необходимо реализовать такой критичный для безопасности сценарий, то в первую очередь нужно ставить базовые гардрейлы на входе и выходе агента. Это ограничение по длине входящих/выходящих сообщений, white-листы/black-листы слов или n-грамм, отклонение от заданной темы по эмбеддингам, ну и, возможно, легкие ML-модели, обученные под конкретное детектирование».

Мониторинг и логирование

Это не отдельный контур безопасности, а скорее постоянный процесс. В поведении модели стоит отслеживать неожиданные изменения в структуре, логике и тоне ответов — это один из сигналов компрометации.

Ловить такие отклонения позволяет baseline — представление о том, как модель ведет себя в норме. Его можно собрать из достаточно легковесных данных, которые система логирует в штатном режиме: длина ответов, латентность, эмбеддинг текста, хеш контекста и версия системных инструкций.

Когда одна из метрик выходит за допустимый диапазон, например резко меняется длина последовательности, система фиксирует это событие. В этот момент хорошо бы триггерить расширенное логирование: сохранить полные тексты запросов и ответов, retrieved-документы, хеши контекста и параметры генерации. Они помогут воспроизвести ситуацию и проверить, что именно пошло не так.

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

Кто должен отвечать за безопасность ML-модели

В классическом IT-контуре все более-менее понятно: безопасники отвечают за периметр, доступы и инциденты, инженеры — за код и инфраструктуру, продакт — за бизнес-логику. В случае с AI-системами эта схема начинает немного ломаться.

С одной стороны, атаки на модели редко выглядят как инциденты в привычном смысле. Искажение поведения и смещение логики сложно отнести исключительно к зоне ответственности ИБ.

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

Именно это я и хотел бы обсудить: как все-таки разделить ответственность за безопасность ML-модели? Моя версия такая:

• ML-команда отвечает за веса и конфигурацию, платформенная команда — за деплой. Мастхэв практик в этом контуре: подпись артефактов модели и проверка подписи при выкладке, тесты на бэкдоры и скрытые триггеры.

• Архитекторы и платформенные команды совместно с безопасниками отвечают за встраивание модели в общую систему. Как минимум за разумные лимиты и гардрейлы для агентов, которые могут что‑то менять во внешних системах.

• AI-Security/AI-Safety инженеры проверяют модели и агентов на прочность перед выходом в прод и смотрят, как система сопротивляется целевым атакам. «Плохие» кейсы сохраняют в защитный датасет.

• Мониторинг я бы доверил безопасникам: baseline по ключевым метрикам и эмбеддингам, триггеры на аномалии с расширенным логированием при срабатывании и понятный маршрут эскалации, если модель внезапно начинает вести себя не так, как ожидалось.

А вот если в схеме никто формально не отвечает хотя бы за один из контуров, это означает, что цельной безопасности ML просто нет, вместо нее — набор разрозненных мер вокруг DevSecOps и надежда, что пронесет.

Как вам кажется, как лучше разграничить ответственность за безопасность AI-систем? И какие практики в итоге зафиксируются как best practice в AI-security? Соберем список в комментариях.