ИИ-агенту дали доступ: как ограничить права до первого сбоя

1 октября 2026 г. в 16:00|Автор: Редакция QUASA|5 мин чтения| 1

Чтобы ограничить права ИИ-агента до рабочего запуска, закрепите за ним отдельную учётную запись и конкретную задачу. Откройте только необходимые данные и инструменты, поначалу — в режиме чтения. Запись ограничьте черновиками или выбранными объектами, а отправку вовне, удаление, платёж и публикацию проводите после подтверждения человеком.

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

Закрепите за агентом личность и задачу

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

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

Заполните матрицу разрешений

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

Данные. Разрешите только нужные коллекции и поля; секреты и посторонние клиентские записи исключите. Расширение области данных утверждает владелец. Записывайте изменение области доступа и отказы в чтении данных за её пределами.
Инструменты. Перечислите разрешённые функции и допустимые параметры вызова. Новое подключение или новая функция требуют решения владельца до включения. В журнале сохраняйте название инструмента, результат проверки прав и причину отказа.
Чтение. Поиск и чтение внутри утверждённой области можно выполнять без одобрения каждого запроса. Записывайте, какие ресурсы запрошены и под какой личностью; содержимое секретов в журнал переносить не нужно.
Запись. Сначала разрешите создание черновиков или изменение записей, созданных самим агентом. Правка существующих клиентских данных требует отдельного правила; массовые изменения подтверждает человек. Записывайте идентификатор объекта, вид изменения и итог операции.
Внешняя отправка. Перед письмом, выгрузкой или запросом к внешнему адресу человек проверяет получателя и отправляемое содержимое. В журнале фиксируйте адрес назначения, идентификатор одобрения и результат отправки без полной копии личных данных.
Удаление. По умолчанию запретите его. Если задача требует удаления, выделите отдельную операцию с подтверждением конкретных объектов или партии. Записывайте их идентификаторы, решение человека и итог исполнения.
Платёж. Агент может подготовить предложение, но сумму, получателя и назначение утверждает уполномоченный человек через платёжный процесс. Не выдавайте агенту постоянное право переводить средства. В журнале нужны параметры утверждённой операции, решение и идентификатор транзакции.
Публикация. Отделите создание черновика от команды «опубликовать». Перед выпуском человек проверяет окончательную версию и канал размещения. Записывайте версию материала, канал, одобрение и фактический результат публикации.

Формулируйте разрешение на самом узком уровне, который поддерживает система: например, «читать выбранную очередь» вместо общего «доступа к почте». Документация Amazon Bedrock AgentCore Gateway описывает проверку прав перед вызовом инструмента, включая ограничения на инструмент, операцию и параметры. Это пример реализации: саму матрицу можно применить и к другой платформе.

Привяжите одобрение к точному действию

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

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

Записывайте вызовы инструментов, а не только ответы

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

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

Проверьте границы до запуска

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

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