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