Зачем своя модель угроз
Стандартные корпоративные методики хорошо описывают людей и системы, но агент не вписывается ни в одну графу: он действует автономно, принимает решения вероятностно и обучается на лету. Модель угроз для агентного ИИ отвечает на четыре вопроса: какие активы агент трогает, кто и как может на него повлиять, какие последствия реализуются при захвате логики, какими контролями это ограничивается. Документ живёт вместе с системой: смена прав или инструмента — повод для ревизии.
Шаг 1. Активы и последствия
Перечислите, до чего агент может дотянуться: персональные данные клиентов, коммерческие расчёты, переписка, код, деньги, доступ к внутренним системам. Для каждого актива зафиксируйте худший сценарий: не абстрактное «нарушение конфиденциальности», а конкретное «выгрузка базы клиентов во внешний файловый сервис». Эта таблица задаёт язык общения с руководством: риски начинают измеряться в бизнес-терминах.
| Актив | Худший сценарий | Категория ущерба |
|---|---|---|
| ПДн клиентов | вывод базы через канал агента | штрафы, репутация |
| Коммерческие данные | утечка расчётов контрагенту | конкурентный ущерб |
| Корпоративная почта | массовая рассылка от имени компании | мошенничество, репутация |
| Репозитории | вредоносный коммит от имени разработчика | целостность ПО |
| Финансовые операции | несанкционированный платёж | прямой ущерб |
Шаг 2. Векторы влияния
Кто может «дёрнуть агента за ниточку». Внешний атакующий — через промпт-инъекции, внедрённые в данные, которые агент читает. Внутренний инсайдер — через подмену источника данных или инструмента. Скомпрометированная зависимость — через цепочку поставки модели и плагинов, класс LLM03. Ошибочный сценарий — самый недооценённый вектор: агент, неверно понявший задачу, наносит ущерб без всякого атакующего. Для каждого вектора оцените реалистичность: какие каналы реально доступны в вашей архитектуре.
Шаг 3. Барьеры
Модель угроз без барьеров — список страшилок. Барьеры выстраиваются по принципу эшелонированной обороны. Первый эшелон — архитектурные решения: минимальные полномочия, песочница, ограничение egress-трафика. Второй — процессные: подтверждение человеком необратимых операций, регламент изменений инструментов, ревью прав. Третий — детективные: журналирование шагов агента, алерты на аномалии, регулярные тесты на устойчивость. Для каждой строки первых двух шагов должно быть понятно, какой эшелон её ловит.
Шаг 4. Остаточный риск и приёмка
Часть рисков останется незакрытой — это нормально. Важно, чтобы остаток был явным: перечень принятых рисков с подписью владельца процесса. Формулировка «мы понимаем, что агент с доступом к почте может быть склонён к рассылке, барьер — подтверждение оператора, остаточный риск принят» защищает компанию гораздо лучше, чем отсутствие документа.
Регуляторный контур
Enterprise-агенты почти всегда касаются персональных данных, поэтому модель угроз полезно сразу сверять с 152-ФЗ, а при работе в госсекторе — с требованиями приказа ФСТЭК России № 117 от 11.04.2025 для ГИС (действует с 01.03.2026, заменил приказ № 17). Отдельный слой — закон в сфере ИИ, Федеральный закон от 26.07.2026 № 243-ФЗ: он адресован большим фундаментальным моделям, а не корпоративным агентам, но фиксирует направление регуляторного ветра; обзор — в разделе о законе 243-ФЗ. Утечки через любые каналы, включая агентные, оплачиваются штрафами за утечки персональных данных по КоАП — эти суммы стоит держать перед глазами при оценке ущерба.
Типовые ошибки моделирования
Первая — моделировать «модель», а не систему: риски живут в правах и интеграциях. Вторая — забыть вектор ошибочного сценария: большинство инцидентов первого года агентных внедрений — не атаки, а недопонимания. Третья — написать документ один раз и положить в папку: агентная система меняется каждую неделю. Четвёртая — не назначить владельца: модель угроз без владельца деградирует до фантазии.
Проверить зрелость контура до моделирования помогает тест зрелости защиты ИИ; систематизировать активы — реестр ИИ-активов. Эти два artefact'а плюс модель угроз и есть минимальный документарный фундамент агентного проекта.
Минимальный шаблон документа
Рабочая модель угроз агентного контура умещается в четыре списка. Первый — активы: данные и системы, до которых агент дотягивается, с худшим сценарием по каждому пункту. Второй — векторы: внешние инструкции в данных, инсайдер, скомпрометированная зависимость, ошибочный сценарий. Третий — барьеры: какой эшелон ловит какой вектор, с указанием конкретного механизма, а не намерения. Четвёртый — остаточные риски с владельцами и датой следующего пересмотра. Полторы страницы, обновляемые при каждом изменении прав, полезнее сорокастраничного талмуда, написанного один раз к аудиту. Если документу нечего обновлять месяцами — контур либо заморожен, либо модель угроз умерла.
Итоговое правило зрелости: модель угроз считается рабочей, когда по каждой строке рисков можно назвать конкретный барьер и человека, который этим барьером владеет. Пока ответом служат общие слова про «контроль доступа» и «мониторинг», документ остаётся декорацией. Один день честного заполнения четырёх списков экономит недели споров при первом инциденте и даёт службе безопасности готовую основу для проверки контура по существу, а не по формальным признакам.