Модель угроз для ИИ-агента — это список того, что может пойти не так: какие данные утекут, какие действия агент выполнит без спроса, через какие каналы уйдёт информация. Строить её нужно до подключения агента к рабочему контуру, а не после первого инцидента.
В отличие от классической модели угроз для ИТ-системы, здесь есть специфика: агент работает с языковой моделью, имеет доступ к корпоративным данным и может выполнять действия в CRM, почте или мессенджере. Один некорректный промпт — и агент отправит клиенту внутреннюю переписку или изменит сделку без согласования.
Из чего состоит модель угроз ИИ-агента
Модель угроз покрывает пять областей: данные, которые видит агент; доступы к системам; каналы связи с внешними моделями; действия, которые агент может выполнить; и сценарии, при которых агент отказывает или работает некорректно.
Каждая область проверяется отдельно. Данные — на предмет утечки и нерелевантности. Доступы — на предмет избыточности. Внешние модели — на предмет того, какие классы информации уходят за пределы контура. Действия — на предмет необратимости. Сценарии отказа — на предмет того, что произойдёт, если агент получит некорректный ввод или потеряет связь с моделью.
Данные и доступы: что нужно проверить до подключения
Первый блок угроз связан с тем, какие данные агент видит и к каким системам подключён. Типичная ошибка — дать агенту доступ ко всей базе знаний, когда для задачи достаточно одного раздела. Или подключить его к CRM с правами на удаление сделок, когда достаточно прав на чтение и создание черновиков.
До подключения нужно зафиксировать три вещи:
- Классы данных. Какие документы, базы и справочники видит агент. Что из этого можно передавать внешней модели, а что нельзя. Это фиксируется в политике данных и согласуется с ИБ.
- Минимальные права. Доступы под конкретную задачу, отдельные учётные записи для агентов. Отзыв доступа — одним действием.
- Хранение секретов. Ключи, пароли и токены — в защищённом хранилище на сервере, а не в коде и не в документации.
Пример. Компания подключает ИИ-агента к почте отдела продаж для формирования черновиков ответов клиентам. Без модели угроз агент получает доступ ко всей почте руководителя, включая переписку с юристами и финансовую отчётность. С моделью угроз агент работает только с папкой «Входящие отдела продаж», а отправка писем требует подтверждения сотрудника.
Внешние модели и каналы: где граница контура
Второй блок угроз — каналы, через которые данные покидают сервер компании. Когда агент отправляет запрос во внешнюю LLM-модель, текст запроса проходит через инфраструктуру провайдера. Если в запрос попадают персональные данные, коммерческая тайна или внутренние документы — это инцидент.
Три вопроса, которые решаются до запуска:
- Что именно уходит наружу. Тексты документов или только эмбеддинги? Полные запросы или обезличенные? Классы данных, разрешённые для внешних моделей, фиксируются письменно.
- Через какой канал. Прямое подключение к API провайдера, VPN-туннель, прокси. Канал согласуется с ИТ и ИБ.
- Что делать при недоступности провайдера. Запасной маршрут: другая модель, локальная модель, остановка агента с уведомлением администратора.
При настройке инфраструктуры эмбеддинги для базы знаний считаются локальной моделью на сервере заказчика. Тексты документов наружу не уходят. Это снижает угрозу, но не отменяет необходимости фиксировать, какие данные разрешены для внешних моделей.
Права, журналы и необратимые действия
Третий блок — контроль того, что агент делает внутри контура. Даже если данные не покидают сервер, агент может выполнить действие, которое сложно отменить: отправить письмо, изменить статус сделки, удалить запись.
Модель угроз для этой области включает:
- Список необратимых операций. Какие действия агент выполняет сам, какие — только с подтверждением сотрудника. Этот список входит в настройку прав и сценариев подтверждения.
- Журнал действий. Что агент прочитал, что изменил, кто подтвердил. Журнал должен быть открыт администратору и руководителю. Без журнала инцидент невозможно расследовать.
- Разделение доступов. Отдельные учётные записи для агентов разных отделов. Если агент отдела продаж не должен видеть данные бухгалтерии — он их не видит, даже если модель «попросит».
При сопровождении проверка контрольных границ — прав доступа для ИИ-агентов — выделена в отдельный вид работ. Журнал действий разбирается при каждом обращении: что произошло, почему агент принял такое решение, нужно ли менять правила.
Сценарии отказа и проверка перед запуском
Четвёртый блок — ситуации, в которых агент работает некорректно или отказывает. Их нужно моделировать до того, как агент попадёт в рабочий отдел.
Типовые сценарии:
- Некорректный ввод. Сотрудник формулирует задачу двусмысленно, агент выбирает неверную интерпретацию и выполняет лишнее действие.
- Изменившаяся интеграция. CRM обновилась, API изменился, агент перестал видеть часть данных или начал получать ошибки.
- Перегрузка контекста. Агент получает слишком длинный запрос или слишком большой объём документов и отвечает нерелевантно.
- Сбой провайдера. Внешняя модель недоступна, агент не может обработать запрос.
Перед выпуском в отдел агент работает в стендовой группе. Прогоняются типовые, ошибочные и рискованные сценарии. Настраиваются журналы, права и передача спорных случаев человеку. Это часть работ по проверке качества перед запуском.
Как внедрить модель угроз в рабочий процесс
Модель угроз — не отдельный документ на полке. Она встраивается в этапы внедрения и проверяется при каждом значительном изменении.
Порядок действий:
- На этапе оценки — определить, какие данные и системы нужны агенту, какие классы информации допустимы для внешних моделей.
- На этапе договора — зафиксировать площадку, каналы, классы данных и права. Согласовать с ИТ и ИБ.
- На этапе сборки — настроить минимальные права, журналы, сценарии подтверждения необратимых действий.
- На этапе проверки — прогнать сценарии отказа, убедиться, что журнал работает, что спорные случаи передаются человеку.
- После запуска — пересматривать модель угроз при каждой новой интеграции, смене модели, подключении нового отдела.
Модель угроз для ИИ-агента — это не про паранойю, а про понимание границ. До подключения к рабочему контуру вы знаете, какие данные видит агент, что он может сделать, через какие каналы уходит информация и что произойдёт при сбое. После запуска — проверяете это по журналу и корректируете правила. Если нужна помощь с разбором конкретного процесса, начните с описания задачи — оценим, какие угрозы релевантны, и предложим порядок работ.
Частые вопросы
Нужно ли строить модель угроз, если ИИ-агент работает только внутри компании?
Да. Даже при работе в закрытом контуре агент получает доступ к данным, системам и может выполнять действия от имени сотрудника. Модель угроз помогает заранее определить, что именно может пойти не так, и настроить защиту до инцидента.
Кто в компании отвечает за модель угроз ИИ-агента?
Ответственность обычно разделяют между руководителем проекта, ИТ-службой и службой информационной безопасности. Руководитель определяет бизнес-риски, ИТ — технические угрозы, ИБ — требования к данным и доступам. Без этого треугольника модель угроз остаётся формальностью.
Можно ли запустить ИИ-агента без формальной модели угроз?
Технически можно, но риски возрастают: агент может получить лишние доступы, отправить данные во внешнюю модель или выполнить действие без подтверждения. Модель угроз не обязательно оформлять в отдельный документ — достаточно чек-листа, проверенного перед запуском.
Как часто нужно пересматривать модель угроз?
При каждом значительном изменении: новая интеграция, смена модели, подключение нового отдела, изменение регламента. При сопровождении ИИ-решений проверка контрольных границ входит в регулярные работы.
Официальные материалы по теме
Для терминов, возможностей интерфейсов и требований безопасности используем первичные материалы разработчиков и профильных организаций.