ИИ-агент, действующий в подключённых учётных записях, может менять данные или запускать бизнес-процессы. Перед выбором поставщика владелец бизнес-процесса и специалист по безопасности могут сравнить контроль для одного предлагаемого рабочего процесса с письменными требованиями организации. Результат — датированная запись свидетельств. Вопрос без ответа остаётся открытым: утверждение о продукте само по себе не доказывает, что действие будет остановлено. Метод опирается на NIST AI Risk Management Framework Playbook и AI Agent Security Cheat Sheet от OWASP. Ни один из этих материалов не оценивал поставщика-кандидата.
Главное изменение
- Что изменилось: Покупка агента может означать делегирование действий в бизнес-системах. Покупателю нужно знать, кто может заставить агента действовать, с какими объектами и с чьего согласия.
- Почему это важно: Покупатель может связать каждое предлагаемое действие с конкретной мерой контроля и её свидетельствами. Это даёт владельцу бизнес-процесса и специалисту по безопасности основу для ограничения доступа или приостановки закупки.
- На что обратить внимание: Решение зависит от свидетельств для точной версии продукта и рабочего процесса. Мера, описанная в документации, может ещё потребовать демонстрации под наблюдением, прежде чем проверяющий примет её для намеченного использования.
Соберите четыре исходных материала
Используйте существующий письменный профиль рисков, утверждённый организацией. Он должен указывать владельца бизнес-процесса, ожидаемый результат, допустимые данные и места назначения, разрешённые действия, полномочия на согласование, неприемлемые последствия и условия остановки. Если его нет, попросите ответственных определить его до оценки поставщика. Это руководство не может назначить допустимый для организации риск вместо них.
Рекомендация NIST MANAGE 3.1 призывает применять допустимый для организации уровень риска к сторонним ИИ-системам и документировать их контроль. Playbook предлагает добровольные рекомендации, а не универсальный закупочный список. Вопросы о контроле действий ниже также опираются на рекомендации OWASP по безопасности агентов. Эти материалы помогают выбрать полезные вопросы, но ответить должны свидетельства самого поставщика.
Назовите одного кандидата, точный продукт и рассматриваемую версию развёртывания. Получите актуальные документы и свидетельства, которыми поставщик вправе делиться. Предоставьте доступ к сравнению специалисту по безопасности и руководителю закупки. Чувствительные сведения об архитектуре и файлы свидетельств храните в одобренном закрытом месте; таблица может содержать ссылки вместо копий секретов.
1. Превратите рабочий процесс в требования
Перечислите каждое предлагаемое действие агента, целевую систему и данные для чтения или изменения. Отделите чтение от записи, а также от внешне видимых или необратимых действий. Для каждого скопируйте соответствующее требование письменного профиля рисков: разрешённая идентичность, область инструментов и целей, согласование, журналирование, обработка данных, прерывание и восстановление. Укажите владельца профиля и дату.
Создайте отдельную строку для каждого требования. Тогда неизвестное будет видно, а не потеряется в общей оценке поставщика. Требование никогда не обращаться к конкретной учётной записи заслуживает строки не меньше, чем разрешённое действие.
2. Проследите, кто действует и что может выполняться
Спросите, какой человек, сервисная учётная запись или идентичность агента инициирует каждое действие, где хранятся учётные данные и может ли агент передать запрос другому агенту. Найдите компонент, проверяющий разрешение при выполнении. Сравните фактические права инструментов поставщика с разрешёнными инструментами, операциями, учётными записями и целями из профиля. Запросите свидетельства конфигурации или архитектуры для этой версии: фраза в запросе — слабое доказательство принудительной границы.
Для действий с согласованием спросите, что проверяющий видит перед выполнением и как согласие связано с исполнителем, точным вызовом инструмента, целью и параметрами. Узнайте, что происходит, если согласие истекло, отклонено, использовано дважды или запрошенное действие изменилось. Запишите способы отзыва доступа и кто может остановить текущий запуск. Экран согласования и проверка при выполнении отвечают на разные вопросы; требуйте оба свидетельства, если профиль требует обоих.
3. Проследите данные и запись действий
Нарисуйте предлагаемый путь от входа к модели, инструментам, внешним получателям, сохранённым копиям и журналам. Спросите, какие данные получает каждый компонент, кто может их получить и как устроены хранение и удаление. Включите значимых для профиля субобработчиков и передачи между системами. Неотвеченный вопрос о месте назначения или хранении отметьте как неизвестный. Не выводите защиту приватности из общей декларации политики.
Запросите запись выполнения для нужной версии. Может ли проверяющий связать исполнителя и версию политики с предлагаемым вызовом инструмента, согласием или отказом, точной целью и результатом? Проверьте, показывает ли запись только решение, реальное выполнение или оба. Снимок экрана, экспорт конфигурации и полный след событий доказывают разное. Отметьте скрытые фрагменты, мешающие сравнению, не помещая в таблицу учётные и персональные данные.
4. Запросите свидетельства отказов
Запросите привязанные к версии свидетельства для разрешённого действия и требуемых профилем сценариев отказа: отклонённое или истёкшее согласие, инструмент или цель вне разрешённой области, прерванное выполнение и, где применимо, сбой журналирования или проверки политики. Запишите, что проверяли, когда, при каких политиках и настройках инструментов, ожидаемый и наблюдавшийся результат. План испытаний — запрос свидетельств, а не наблюдавшийся результат.
Ответственный специалист по безопасности решает, нужна ли демонстрация под наблюдением, и разрешает её объём. Используйте разрешённые входные данные и учётные записи вне рабочей среды. Не подключайте действующие системы лишь ради заполнения закупочной таблицы. Если поставщик не даёт свидетельств, запишите пробел и следующий запрос, а не придумывайте исход испытания.
5. Запишите решение и открытые задачи
В каждой строке ставьте соответствует только если представленные свидетельства отвечают письменному требованию для этой версии и процесса. Ставьте пробел при противоречии или неизвестно при отсутствии или слабости свидетельств. Запишите противоречивые материалы и того, кто должен их согласовать. Затем владелец бизнес-процесса и ответственный специалист по безопасности фиксируют реальное решение: запросить ещё свидетельства, получить разрешение на ограниченный пилот, отложить или отклонить. Соответствие — оценка свидетельств, а не гарантия безопасности и не замена закупочной процедуры организации.
Датируйте запись и пересматривайте затронутые строки при изменении процесса, версии продукта, политики, подключённых учётных записей или мест назначения данных. Позднейшему пилоту нужны собственные разрешение, ограничения и проверка.
Требование письменного профиля | Свидетельства поставщика, версия и дата | Вид свидетельства и что оно показывает | Соответствует, пробел или неизвестно | Проверяющий и следующее действие |
|---|---|---|---|---|
[Одно требование к действию или контролю] | [Закрытая ссылка или ссылка на документ; версия; дата] | [Утверждение, конфигурация, запись события или наблюдавшаяся демонстрация; ограничение] | [Выберите одно и объясните] | [Имя, запрос свидетельств или решение] |
Заголовок записи: процесс и владелец; версия профиля рисков и дата утверждения; продукт-кандидат и версия развёртывания; дата проверки; специалист по безопасности; руководитель закупки; место хранения ограниченных в доступе свидетельств. Запись решения: решение, неразрешённые строки, принятые ограничения или компенсирующие меры, ответственный за согласование и повод следующей проверки. Оставьте поля пустыми, пока ответственные действительно их не рассмотрят.
Публичные рекомендации, использованные для этих вопросов, доступны бесплатно. Подготовка сравнения требует времени сотрудников и проверяющих. Свидетельства поставщика, конфиденциальный доступ и разрешённая демонстрация могут добавить расходы или ограничить проверку; получите реальные условия у кандидата. Работа с документами не испытывает поставщика и не устанавливает соответствие закону или универсальный порог покупки.
Источники и дополнительные материалы
- NIST AI RMF Playbook, Manage поддерживает применение собственного допустимого риска организации к сторонним ИИ-ресурсам, документирование и оценку контроля. Веб-страница сообщает об обновлении AI RMF 1.0, за которым последует Playbook; даты пересмотра страницы нет. Она не оценивает этого поставщика.
- Введение в NIST AI RMF Playbook называет предложения добровольными и сообщает, что Playbook не является списком, который нужно выполнить целиком. Таблица здесь — обобщение BIG CHANGE для заявленной задачи читателя.
- OWASP AI Agent Security Cheat Sheet охватывает ограниченные инструменты, авторизацию при выполнении, согласия, связанные с действиями, журналы, защиту данных и привязанные к версии свидетельства проверки. Текущая страница не указывает версию или дату выпуска. Рекомендации — категории свидетельств, а не доказательство внедрения у поставщика.
