Гайд по AI-агентам с мерами митигации угроз кибербезопасности
#иб_для_ml

↗️ https://cdn-app.giga.chat/misc/0.0.0/assets/giga-landing/c02386dc_WP.pdf

✅Команда Сбера представила новый документ - гайд по практикам разработки AI-агентов. В документе масса кода и архитектурных схем, разбираться можно долго. И я однозначно рекомендую его к ознакомлению.

Но мне, конечно интересна в первую очередь кибербезопасность. И да, такой раздел в этом документе имеется. Внимание на страницы 65-69.

📝Раскрываемые темы и понятия в разделе
▪️описание ключевых с точки зрения ИБ элементов AI-агента
▪️схема этих элементов, изображающая AI-агента как объект защиты, приведен список поверхностей атаки
▪️несколько сценариев реализации угроз (например, каскадное распространение промпт-атаки)
▪️меры обеспечения кибербезопасности AI-агентов - самое интересное, на чем остановимся подробнее

🔒 Как защитить AI-агентов
На странице 69 расписано 12 различных мер.
Начинаем, конечно, с мониторинга. AI-агенты, как мы помним, сами по себе моделями не являются, соответственно ответы пользователям генерить не могут. Поэтому существуют обращения агентов к LLM, при чем как минимум - два. Первое с исходным входным текстом, чтобы сгенерировать запрос на выполнение действия (-й), второе - с результатом выполнения для генерации финального ответа. И это, по-хорошему, все надо логировать. Начиная от id потребителя и, в случае большой корпоративной системы, id фронтальной поверхности, заканчивая id сессии и id актуального коммита в памяти AI-агента на момент совершения события аудита.

Другой хорошей практикой (мерой), особенно в критичных системах, является ограничение формата вывода агентов со свободного естественного языка до набора детерминированных значений. Поможет и утечек избежать, и распространения промпт-атак, и других нежелательных последствий.

Собраны и некоторые общеизвестные, по-моему, вещи, но все-таки стоящие упоминания: проводить redteam-тестирование, ввести максимально жесткий контроль доступа, применять SAST/SCA к генерируемому агентами исполняемому коду, организовать рейтлимиты и прочие контроли надежности против спонж-атак, и несколько других пунктов.

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

👀 Итого
Берегите честь безопасность AI-агентов смолоду с ранних этапов проектирования - эта прописная истина работает и тут. И авторы дают конкретные предложения, как именно это делать. Документ отлично дополняет показанную в апреле модель угроз, покрывая агентную ее часть.


🔫 Предлагаю челлендж - будет больше 50 реакций под постом, сделаю свою версию маппинга угроз из МУ Сбера на митигации из данного гайда.

Выдержки об ИИ из приказа ФСТЭК № 117

П. 49: ИИ для мониторинга безопасности
«Допускается использование доверенных технологий искусственного интеллекта для анализа событий безопасности».
🔹ФСТЭК впервые легализовал ИИ в ИБ-мониторинге, но с ключевым ограничением – только «доверенные» (российские) решения. Это значит, что:
😶Зарубежные SIEM (Splunk, ArcSight) не подходят;
😶Нужны продукты с сертифицированными ИИ-модулями (например, Sber AI или Yandex AI);

П. 60: Запрет передачи данных
«Не допускается передача лицу, разработавшему модель ИИ, информации ограниченного доступа».
🔹Это революционное требование запрещает:
😶Дообучение моделей на чувствительных данных (гостайна, персданные);
😶Использование SaaS-ИИ (ChatGPT, Claude, DeepSeek) для обработки госинформации;
🔹Даже российские вендоры (Sber, Yandex) не получат доступ к сырым данным – только к анонимизированным датасетам.

П. 60: Защита ИИ-инфраструктуры
«Защита за счет воздействия на: наборы данных, модели, параметры, процессы обработки».
🔹ФСТЭК предписывает защищать весь ИИ-стек:
😶Данные: Шифрование (КриптоПро), DLP (Гарда DLP), БД (Гарда БД)
😶Модели: Контейнеризация (Kubernetes);
😶API: Анализ трафика (Гарда WAF и NDR);
Это сложнее, чем защита традиционных ИС.

П. 61: Контроль запросов/ответов
«Определены шаблоны запросов [...] контроль соответствия [...] разработаны критерии для выявления недостоверных ответов».
😶Фактически вводится «цензура ИИ»:
😶Для шаблонных интерфейсов – белый список команд (например, только SQL-запросы);
😶Для чат-ботов – фильтр тематик («запрещено спрашивать про гостайну»);
Ответы ИИ проверяются на галлюцинации (ложные факты) – нужны теперь встроенные детекторы в LLM.

П. 61: Реагирование на ложные ответы
«Реагирование [...] посредством ограничения области принимаемых решений».
🔹Если ИИ сгенерировал рискованный ответ (например, «удалить базу данных»), система должна:
😶Автоматически заблокировать выполнение команды;
😶Изолировать сегмент ИС;
Это требует интеграции ИИ с системами управления доступами

П. 61: Локализация ИИ
«Доверенные технологии ИИ [...] включаются непосредственно в состав ИС».
🔹Облачные ИИ-сервисы запрещены! Разрешены только:
😶Локальные (on-premise);
😶Российское ПО

Компания Pillar Security опубликовала разработанный совместно с коллегами по цеху фреймворк SAIL (Secure AI Lifecycle), представляющий собой процессно-ориентированное руководство по разработке и развертыванию безопасных ИИ-приложений🧠

По факту фреймворк представляет собой матрицу рисков, сгруппированных по семи этапам разработки и развертывания ИИ-приложений. Для каждого риска есть описание, пример небезопасной реализации, затрагиваемые компоненты ИИ-приложения, меры митигации и связанные требования/меры из фреймворков NIST AI RMF, ISO 42001, OWASP и DASF.

В размещённой на сайте брошюре можно найти разбор пары кейсов атак и примеры выборы мер митигации из фрейворка SAIL, а в самом последнем приложении — ссылки на полезные руководства и фреймворки в области ИИ.

#ai #framework #risk #sail #lifecycle