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

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

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

Именно поэтому одних инфраструктурных мер недостаточно и для 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.

Источник: Cloudflare Firewall for AI Explainer and Demo (YouTube)

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

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

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

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

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

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

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

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

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

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

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

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

Защита строится вокруг управления тем, как модель получает, хранит и использует информацию. О рисках вокруг AI и LLM уже много говорят. Например, в OWASP Top 10 для LLM-приложений и OWASP Top-10 для agentic-приложений описаны основные угрозы и даны базовые рекомендации по их снижению. Но единого стандарта пока нет, и практики во многом формируются на ходу. Я выделил, на мой взгляд, самые важные меры по защите 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 — настройку реакции модели на сомнительные запросы. Например, если пользователь просит обойти ограничения доступа, модель должна вежливо отказать.

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

«К основным мерам защиты предиктивных моделей я бы отнес контроль доступа к наборам данных, результатам RnD-экспериментов, хранилищам моделей. И, что актуально и для генеративного ИИ, нужно уделять особое внимание всем 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 фиксирует состав и версии компонентов приложения, так и здесь полезно иметь «паспорт» релиза модели — перечень всех компонентов, которые влияют на поведение системы, с версиями и контрольными суммами.

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). Важно не ставить один жесткий лимит «на всех», а делать разные квоты для доверенных интеграций и внешних пользователей — так защита меньше мешает нормальной работе.

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

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

Борис Захир, независимый эксперт, автор канала «Борис_ь с 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? Соберем список в комментариях.

Источник