МИР НЕ СТОИТ НА МЕСТЕ.RSS
BIG CHANGE.

Версия Markdown

AI-translated from English; not yet reviewed by a fluent editor.

# Сравните меры контроля действий у поставщика ИИ-агентов до закупки

> Перед решением о покупке сравните идентификацию, согласования, права инструментов, журналы, потоки данных и свидетельства отказов одного поставщика ИИ-агентов с письменным профилем рисков.

By BIG CHANGE Editorial

Published: 2026-10-19T15:30:34.881Z
Updated: 2026-10-19T15:30:34.881Z
Canonical: https://bigchange.ai/blog/ai-agent-vendor-action-controls-evidence

![Conceptual charcoal illustration of a completely blank five-column comparison worksheet clipped to an angled wooden reading stand, beside a closed unmarked folder.](https://bigchange.ai/api/media/file/agent-vendor-blank-comparison-worksheet-v1.png)
AI-generated conceptual illustration by BIG CHANGE; no actual vendor evidence, security finding, audit, test or purchase decision is depicted.

ИИ-агент, действующий в подключённых учётных записях, может менять данные или запускать бизнес-процессы. Перед выбором поставщика владелец бизнес-процесса и специалист по безопасности могут сравнить контроль для **одного предлагаемого рабочего процесса** с письменными требованиями организации. Результат — датированная запись свидетельств. Вопрос без ответа остаётся открытым: утверждение о продукте само по себе не доказывает, что действие будет остановлено. Метод опирается на [NIST AI Risk Management Framework Playbook](https://airc.nist.gov/airmf-resources/playbook/) и [AI Agent Security Cheat Sheet от OWASP](https://cheatsheetseries.owasp.org/cheatsheets/AI_Agent_Security_Cheat_Sheet.html). Ни один из этих материалов не оценивал поставщика-кандидата.

## Главное изменение

- **Что изменилось:** Покупка агента может означать делегирование действий в бизнес-системах. Покупателю нужно знать, кто может заставить агента действовать, с какими объектами и с чьего согласия.
- **Почему это важно:** Покупатель может связать каждое предлагаемое действие с конкретной мерой контроля и её свидетельствами. Это даёт владельцу бизнес-процесса и специалисту по безопасности основу для ограничения доступа или приостановки закупки.
- **На что обратить внимание:** Решение зависит от свидетельств для точной версии продукта и рабочего процесса. Мера, описанная в документации, может ещё потребовать демонстрации под наблюдением, прежде чем проверяющий примет её для намеченного использования.

## Соберите четыре исходных материала

Используйте существующий письменный профиль рисков, утверждённый организацией. Он должен указывать владельца бизнес-процесса, ожидаемый результат, допустимые данные и места назначения, разрешённые действия, полномочия на согласование, неприемлемые последствия и условия остановки. Если его нет, попросите ответственных определить его до оценки поставщика. Это руководство не может назначить допустимый для организации риск вместо них.

[Рекомендация NIST MANAGE 3.1](https://airc.nist.gov/airmf-resources/playbook/manage/) призывает применять допустимый для организации уровень риска к сторонним ИИ-системам и документировать их контроль. Playbook предлагает добровольные рекомендации, а не универсальный закупочный список. Вопросы о контроле действий ниже также опираются на рекомендации OWASP по безопасности агентов. Эти материалы помогают выбрать полезные вопросы, но ответить должны свидетельства самого поставщика.

Назовите одного кандидата, точный продукт и рассматриваемую версию развёртывания. Получите актуальные документы и свидетельства, которыми поставщик вправе делиться. Предоставьте доступ к сравнению специалисту по безопасности и руководителю закупки. Чувствительные сведения об архитектуре и файлы свидетельств храните в одобренном закрытом месте; таблица может содержать ссылки вместо копий секретов.

## 1. Превратите рабочий процесс в требования

Перечислите каждое предлагаемое действие агента, целевую систему и данные для чтения или изменения. Отделите чтение от записи, а также от внешне видимых или необратимых действий. Для каждого скопируйте соответствующее требование письменного профиля рисков: разрешённая идентичность, область инструментов и целей, согласование, журналирование, обработка данных, прерывание и восстановление. Укажите владельца профиля и дату.

Создайте отдельную строку для каждого требования. Тогда неизвестное будет видно, а не потеряется в общей оценке поставщика. Требование никогда не обращаться к конкретной учётной записи заслуживает строки не меньше, чем разрешённое действие.

## 2. Проследите, кто действует и что может выполняться

Спросите, какой человек, сервисная учётная запись или идентичность агента инициирует каждое действие, где хранятся учётные данные и может ли агент передать запрос другому агенту. Найдите компонент, проверяющий разрешение при выполнении. Сравните фактические права инструментов поставщика с разрешёнными инструментами, операциями, учётными записями и целями из профиля. Запросите свидетельства конфигурации или архитектуры для этой версии: фраза в запросе — слабое доказательство принудительной границы.

Для действий с согласованием спросите, что проверяющий видит перед выполнением и как согласие связано с исполнителем, точным вызовом инструмента, целью и параметрами. Узнайте, что происходит, если согласие истекло, отклонено, использовано дважды или запрошенное действие изменилось. Запишите способы отзыва доступа и кто может остановить текущий запуск. Экран согласования и проверка при выполнении отвечают на разные вопросы; требуйте оба свидетельства, если профиль требует обоих.

## 3. Проследите данные и запись действий

Нарисуйте предлагаемый путь от входа к модели, инструментам, внешним получателям, сохранённым копиям и журналам. Спросите, какие данные получает каждый компонент, кто может их получить и как устроены хранение и удаление. Включите значимых для профиля субобработчиков и передачи между системами. Неотвеченный вопрос о месте назначения или хранении отметьте как **неизвестный**. Не выводите защиту приватности из общей декларации политики.

Запросите запись выполнения для нужной версии. Может ли проверяющий связать исполнителя и версию политики с предлагаемым вызовом инструмента, согласием или отказом, точной целью и результатом? Проверьте, показывает ли запись только решение, реальное выполнение или оба. Снимок экрана, экспорт конфигурации и полный след событий доказывают разное. Отметьте скрытые фрагменты, мешающие сравнению, не помещая в таблицу учётные и персональные данные.

## 4. Запросите свидетельства отказов

Запросите привязанные к версии свидетельства для разрешённого действия и требуемых профилем сценариев отказа: отклонённое или истёкшее согласие, инструмент или цель вне разрешённой области, прерванное выполнение и, где применимо, сбой журналирования или проверки политики. Запишите, что проверяли, когда, при каких политиках и настройках инструментов, ожидаемый и наблюдавшийся результат. План испытаний — запрос свидетельств, а не наблюдавшийся результат.

Ответственный специалист по безопасности решает, нужна ли демонстрация под наблюдением, и разрешает её объём. Используйте разрешённые входные данные и учётные записи вне рабочей среды. Не подключайте действующие системы лишь ради заполнения закупочной таблицы. Если поставщик не даёт свидетельств, запишите пробел и следующий запрос, а не придумывайте исход испытания.

## 5. Запишите решение и открытые задачи

В каждой строке ставьте **соответствует** только если представленные свидетельства отвечают письменному требованию для этой версии и процесса. Ставьте **пробел** при противоречии или **неизвестно** при отсутствии или слабости свидетельств. Запишите противоречивые материалы и того, кто должен их согласовать. Затем владелец бизнес-процесса и ответственный специалист по безопасности фиксируют реальное решение: запросить ещё свидетельства, получить разрешение на ограниченный пилот, отложить или отклонить. Соответствие — оценка свидетельств, а не гарантия безопасности и не замена закупочной процедуры организации.

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

| Требование письменного профиля | Свидетельства поставщика, версия и дата | Вид свидетельства и что оно показывает | Соответствует, пробел или неизвестно | Проверяющий и следующее действие |
| --- | --- | --- | --- | --- |
| [Одно требование к действию или контролю] | [Закрытая ссылка или ссылка на документ; версия; дата] | [Утверждение, конфигурация, запись события или наблюдавшаяся демонстрация; ограничение] | [Выберите одно и объясните] | [Имя, запрос свидетельств или решение] |

**Заголовок записи:** процесс и владелец; версия профиля рисков и дата утверждения; продукт-кандидат и версия развёртывания; дата проверки; специалист по безопасности; руководитель закупки; место хранения ограниченных в доступе свидетельств. **Запись решения:** решение, неразрешённые строки, принятые ограничения или компенсирующие меры, ответственный за согласование и повод следующей проверки. Оставьте поля пустыми, пока ответственные действительно их не рассмотрят.

Публичные рекомендации, использованные для этих вопросов, доступны бесплатно. Подготовка сравнения требует времени сотрудников и проверяющих. Свидетельства поставщика, конфиденциальный доступ и разрешённая демонстрация могут добавить расходы или ограничить проверку; получите реальные условия у кандидата. Работа с документами не испытывает поставщика и не устанавливает соответствие закону или универсальный порог покупки.

## Источники и дополнительные материалы

1. [NIST AI RMF Playbook, Manage](https://airc.nist.gov/airmf-resources/playbook/manage/) поддерживает применение собственного допустимого риска организации к сторонним ИИ-ресурсам, документирование и оценку контроля. Веб-страница сообщает об обновлении AI RMF 1.0, за которым последует Playbook; даты пересмотра страницы нет. Она не оценивает этого поставщика.
2. [Введение в NIST AI RMF Playbook](https://airc.nist.gov/airmf-resources/playbook/) называет предложения добровольными и сообщает, что Playbook не является списком, который нужно выполнить целиком. Таблица здесь — обобщение BIG CHANGE для заявленной задачи читателя.
3. [OWASP AI Agent Security Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/AI_Agent_Security_Cheat_Sheet.html) охватывает ограниченные инструменты, авторизацию при выполнении, согласия, связанные с действиями, журналы, защиту данных и привязанные к версии свидетельства проверки. Текущая страница не указывает версию или дату выпуска. Рекомендации — категории свидетельств, а не доказательство внедрения у поставщика.

## Sources

- [NIST AI RMF Playbook, Manage](https://airc.nist.gov/airmf-resources/playbook/manage/) — MANAGE 3.1 поддерживает применение допустимого для организации риска к сторонним ИИ-ресурсам и документирование контроля. Текущая страница AI RMF 1.0 Playbook сообщает о предстоящем пересмотре без его даты. Она не подтверждает поставщика.
- [NIST AI RMF Playbook](https://airc.nist.gov/airmf-resources/playbook/) — Введение говорит о добровольных предложениях, а не полном списке или обязательной последовательности. Сравнительная таблица статьи — редакционное обобщение.
- [OWASP AI Agent Security Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/AI_Agent_Security_Cheat_Sheet.html) — Разделы 1, 4, 6, 8 и 9 помогают сформулировать вопросы об ограниченных инструментах, согласовании конкретных действий, журналах, данных и испытаниях для определённой версии. Текущая страница без версии и даты выпуска; рекомендации не доказывают действенность поставщика.