Проверка безопасности доступа ИИ к инструментам: от выдачи прав до отзыва

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

Вымышленный сценарий — Harbor Finance. Финансовый ассистент читает счета от имени вошедших сотрудников. Ночью он также использует идентичность приложения, чтобы переносить одобренные записи в бухгалтерскую систему. Руководитель подтверждает черновик для поставщика A и счёта X. До запуска очереди черновик меняют на поставщика B и счёт Y. Затем сотрудник увольняется, а делегированные права отзывают. Проверка должна установить, выполнится ли отложенная запись, какая идентичность её разрешит, останется ли прежнее подтверждение действительным и какие токены, выгрузки, результаты задач или сессии приложения сохранятся.

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

Выясните, кто может действовать, где и как долго

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

Области доступа OAuth (scopes) обычно описывают вид разрешённых действий, но не всегда указывают конкретный экземпляр ресурса или бизнес-объект. OAuth Resource Indicators позволяют клиенту обозначить целевой ресурс, а Rich Authorization Requests — передать структурированные сведения о разрешении. Это необязательные механизмы общей экосистемы OAuth, а не свойства любой внедрённой системы. Поэтому проверка должна выяснить, что реально обеспечивают сервер авторизации, сервер ресурсов, коннектор и приложение.

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

Разделяйте делегированные полномочия и полномочия приложения

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

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

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

Для MCP через HTTP редакция спецификации авторизации от 25 ноября 2025 года требует проверять, что входящий токен выпущен именно для сервера, и запрещает передавать тот же токен дальше в целевой API. Для внешнего API нужен отдельный токен его аудитории. Сама протокольная граница подробно разобрана в руководстве по аудиту MCP-сервера; здесь полномочие прослеживается дальше — через подтверждение, отложенное исполнение, отзыв и остаточное состояние.

Связывайте подтверждение с исполняемым действием

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

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

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

1. ФормированиеСервер канонизирует идентичность, тенант, ресурс, действие и существенные параметры
2. ПодтверждениеЧеловек видит эти значения, а решение получает короткий срок и одноразовый статус
3. Повторная проверкаПеред исполнением сверяются текущие права, владелец задачи, политика, параметры и отмена
4. РезервированиеПодтверждение атомарно закрепляется за одной операцией до отправки; конкурирующие попытки отклоняются
5. СверкаВызов получает идентификатор операции; результат в целевой системе проверяется до повторной попытки

Считайте очередь и фоновую работу новым моментом авторизации

Очередь растягивает время между намерением и эффектом. За это время пользователь увольняется, роль меняется, право приложения удаляется, ресурс переезжает между тенантами, подтверждение истекает или тело задачи редактируется. Безопасный обработчик не считает принятие в очередь бессрочным разрешением на выполнение.

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

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

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

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

Измеряйте задержку отзыва и называйте объект отзыва точно

«Отозванным» может быть refresh-токен, access-токен, сессия приложения, делегированное согласие, назначение роли приложению, ресурсное разрешение, секрет обработчика или сама задача. Удаление одного объекта не доказывает прекращение остальных.

Стандарт OAuth Token Revocation требует поддержки отзыва refresh-токенов и рекомендует поддержку отзыва access-токенов. Если access-токены не отзываются, они могут работать до срока или до отказа другой точки контроля. Token Introspection позволяет серверу ресурсов узнать активность токена, но стандарт прямо описывает компромисс: кэширование снижает нагрузку и создаёт окно устаревшего состояния. Механизмы стандартов не обещают одинаковую скорость отзыва во всех продуктах.

Документация Microsoft показывает ту же границу. Блокировка пользователя и отзыв refresh-токенов препятствуют получению новых токенов, но существующий access-токен может действовать до срока, если приложение и ресурс не поддерживают механизм непрерывной оценки. Сессией, выпущенной самим приложением, управляет приложение; поставщик идентичности не может отозвать её напрямую. Права приложения принадлежат служебной идентичности, поэтому удаление пользователя не снимает их автоматически.

Проверка должна измерять, а не предполагать. Выполните допустимую безвредную контрольную операцию, запустите один вид отзыва в зафиксированное время, повторите тот же запрос со старым access-токеном, затем запросите обновление или новый токен и проверьте путь через сессию приложения и фонового обработчика. Остановитесь на заранее согласованной безопасной границе. В отчёте укажите последнюю успешную попытку и первый отказ для каждого пути, интервалы между проверками, последующие результаты, компонент-источник отказа и предел наблюдения. Серия отказов уменьшает неопределённость; один отказ не доказывает, что доступ навсегда закрыт через все серверы и маршруты. Формулировка «отказ наступил в пределах окна проверки» точнее, чем «отзыв мгновенный».

Проверяйте остаточные полномочия, секреты, задачи и артефакты

Отзыв прекращает часть будущих действий, но не стирает полученные или созданные данные. Могут сохраниться кэш документов, выгрузки, записи в векторном индексе, вложения диалога, отчёты, содержимое очереди, результаты задач, журналы, загрузки браузера и черновики в целевой системе. У обработчика может остаться refresh-токен, API-ключ, секрет клиента или cookie приложения вне изменённой системы идентификации.

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

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

Как согласовать объём проверки и принять результат

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

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

Результат включает карту полномочий, реестр выданных прав, проверку привязки подтверждений, очередей и повторов, измерения отзыва, перечень оставшихся прав и данных, а также план ретеста. Выводы ограничиваются проверенными идентичностями, продуктами, конфигурациями и окнами наблюдения. Материал о тестировании избыточной агентности пригодится для более широкого вопроса «что агента можно заставить сделать»; здесь задача — доказать, как полномочия меняются во времени.

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