Идентификация, права и аудит ИИ-агентов: запись действия и проверка доступа

Начните с записи, которую можно проверить

Чтобы проверить действие ИИ-агента, свяжите запрос с исполнителем, разрешенной операцией, одобрением и фактическим результатом. Начинать стоит не с общего ответа «агенту доверяем», а с конкретного вопроса: кто получил доступ к какому объекту и что с ним произошло?

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

Например, назначьте запросу условный идентификатор REQ-041, чтению — ACT-041-1, подготовке черновика — ACT-041-2. Это обозначения для предлагаемой записи. Они помогают показать, что чтение и подготовка — два шага одной задачи, но не две одинаковые операции. Если позже появится запрос на отправку, ему нужны собственные сведения о получателе, разрешении и результате.

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

Не сохраняйте секретный ключ, полный документ или весь черновик только ради аудита. Обычно полезнее идентификатор объекта, ссылка на разрешенный источник и краткое описание операции. Отдельно отметьте, кто и когда проверил результат. Фраза модели «готово» и подтверждение проверяющего — разные сведения.

Выберите идентичность и объем корпоративных прав

В правилах авторизации Microsoft Entra Agent ID различаются делегированные права и права приложения. При делегированном доступе агент действует от имени пользователя в пределах соответствующих разрешений и доступных ресурсов. Права приложения предоставляются администратором и используются приложением без такого пользовательского контекста. Это устройство конкретной платформы, а не универсальная схема всех ИИ-агентов.

Для задачи Марии сначала определите ресурс: где находится документ, кто имеет к нему доступ и какая операция нужна. Чтение одного файла не обосновывает выдачу права изменять все документы. В документации приведен пример делегированного Files.Read для чтения пользовательского файла; выбирайте область доступа по фактическому ресурсу и ограничениям системы.

Microsoft отдельно различает роли ресурсов Azure, роли каталога Entra и разрешения Microsoft Graph. Доступ к ресурсу Azure не равнозначен праву управлять каталогом, а роль каталога не следует считать разрешением на любую операцию с файлами. Для идентичностей агентов действуют ограничения на высокопривилегированные роли и API-разрешения.

1. Назовите нужный ресурс и операцию: чтение, создание, изменение или отправка.
2. Определите, под какой идентичностью выполняется обращение.
3. Выберите делегированный доступ или права приложения по устройству задачи.
4. Проверьте фактически предоставленную область, а не только запрошенную.
5. Отдельно установите порядок одобрения значимых действий.

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

У подключения должен быть понятный владелец. Если политика организации предусматривает спонсора агента, срок доступа или периодический пересмотр, внесите эти сведения в запись. API-ключ сам по себе не организует такой контроль. Требования к владельцам, устройствам и рабочим данным рассматриваются в статье Безопасность корпоративных ИИ-агентов на телефоне.

Собирайте сведения о входе и действии отдельно

Документация Microsoft по журналам Entra Agent ID показывает, как соотносятся события идентичностей: действия шаблона агента отображаются как события приложения, идентичности агента — как события субъекта-службы, а учетной записи пользователя агента — как события пользователя. Поле agentType помогает распознать участие агента, а blueprintId — связать экземпляр с шаблоном.

Для просмотра входов в центре администрирования Entra нужна как минимум роль Reports Reader. Путь проходит через Entra ID → «Мониторинг и работоспособность» → «Журналы входа», где доступны фильтры по агентам. Описанные в документации запросы к журналам агентов через Microsoft Graph используют /beta; учитывайте это при разработке собственного сбора сведений.

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

Для REQ-041 сопоставьте действующую идентичность и время обращения с записью чтения выбранного документа. Затем отдельно найдите результат ACT-041-2: создан ли черновик, где он находится и не был ли отправлен. Не предполагайте, что все системы автоматически используют один идентификатор: если сквозной связи нет, зафиксируйте способ сопоставления вручную.

• Проверьте идентичность исполнителя и целевой ресурс.
• Сверьте идентификаторы операций, время и часовой пояс.
• Найдите результат в приложении, которое выполняло бизнес-операцию.
• Отметьте пробелы: отсутствующий ответ, неясный объект или неподтвержденное состояние.

Близкое время двух событий помогает поиску, но не доказывает причинную связь. Если подтверждения результата нет, сохраняйте статус «не установлено», а не «успех». Доступ к журналам и сроки хранения задавайте по политике организации. Для дополнительных навыков отдельно проверяются источник и полномочия; этому посвящен материал Безопасность навыков AI-агентов: почему телефону нужны проверки разрешений.

Различайте четыре возможных результата

Следующие записи — предложенные примеры для собственной проверки, а не выполненные испытания. В каждой отделяйте разрешенную область, одобрение, попытку и итог. Полезный статус описывает наблюдение, а не намерение агента.

Успешное чтение. Для ACT-041-1 область — чтение выбранного документа; согласование относится к этой задаче. Приложение подтвердило чтение нужного объекта, а проверяющий связал результат с запросом. Запись: «чтение подтверждено; изменение и отправка не выполнялись». Если доступна только запись успешного входа, такой статус пока нельзя поставить.

Подготовку ответа фиксируйте отдельно. Ссылка на черновик подтверждает его наличие, но не правильность содержания. Проверяющий может отметить «черновик существует, содержание еще не проверено». Это точнее общего «задача выполнена», особенно когда текст готовится для внешнего адресата.

Ожидание одобрения записи. Агенту предложено создать событие календаря. Дата, время и напоминание уточнены, но применяемая политика требует одобрения, которое еще не получено. Запись: «параметры подготовлены; ожидается решение; выполнение операции не подтверждено». Открытый запрос на одобрение не является созданным событием. После решения нужно дополнить запись результатом попытки.

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

Неопределенный итог после частичного сбоя. Разрешение и одобрение есть, запрос на запись был отправлен, но соединение оборвалось до получения результата. Запись: «попытка выполнена; итог неизвестен; повтор приостановлен». Если событие уже появилось, подтвердите его параметры и завершите проверку без дублирования. Если часть цепочки завершена, например черновик создан, а дальнейшая операция не установлена, укажите состояние каждого шага.

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

Исправление записи тоже должно быть понятным: добавьте новое наблюдение с временем, не заменяя неизвестный итог догадкой об успехе. Отдельно укажите, требуется ли следующий шаг. Одобренное действие может завершиться ошибкой; отказанное действие может оставлять ранее созданный объект.

Примените те же вопросы к телефону

На Android вопросы остаются теми же, но средства контроля другие. В FoneClaw запрос «Покажи заряд батареи» можно связать с инструментом device_battery_status. Он читает состояние батареи и энергосбережения, не меняя настройки устройства. В ручной записи укажите запрос, используемый инструмент, время и фактически возвращенные сведения.

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

Для calendar_create_event проверка строже: это создание данных календаря. Предположим, пользователь просит событие «Обсуждение проекта» 12 ноября 2026 года с 10:00 до 10:30 по часовому поясу телефона, с напоминанием за 15 минут. Это предлагаемый пример. Если время окончания или напоминание не заданы, сначала уточните их, а не добавляйте по предположению.

Инструменту передаются локальные начало и конец; для заданных дат используются startLocalDateTime и endLocalDateTime. После создания сверяйте возвращенные actualStart и actualEnd, затем откройте событие в календаре и проверьте название, время и напоминание. Для события на весь день применяются локальная полночь начала и исключающая полночь следующего дня, а не произвольно рассчитанная длительность.

Если пользователь назвал место, этого достаточно для locationName: поиск точного адреса нужен только при отдельном запросе на уточнение. Явно выбранный календарь учитывается; при отсутствии выбора используется предусмотренный инструментом вариант по умолчанию. Для создания предусмотрено требование одобрения по умолчанию, однако проверяется фактическая общая и индивидуальная политика.

Разрешения Android, включение инструмента и учетные данные провайдера модели — разные уровни. Онлайн-модель может обрабатывать переданный контекст; локальная запись действия этого не описывает полностью. Поддерживаемые операции перечислены на странице возможностей FoneClaw. Предлагаемая ручная запись не является встроенным неизменяемым экспортом или подключением к Entra.

Проверьте отказ и отзовите лишний доступ

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

В ручной записи отметьте отключенный инструмент, запрос, наблюдаемый отказ и отсутствие подтвержденного нового чтения через него. Если агент повторил старое значение из беседы, это не новое измерение. Не требуйте, чтобы сам процент заряда оставался прежним: батарея меняется независимо от запроса. Проверяется доступ к инструменту, а не неподвижность состояния телефона.

Если поведение не соответствует ограничению, остановите дальнейшие задачи и проверьте, какой инструмент или источник использован. Не восстанавливайте доступ автоматически ради завершения запроса. После проверки возвращайте только действительно нужные настройки, записав причину.

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

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

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