Сотрудник поддержки просит AI-агента отменить подписку клиента. Агент находит нужный инструмент, вызывает API — всё работает. Для демонстрации этого достаточно. Для рабочей системы возникает вопрос: от чьего имени выполнена отмена?
Если запрос прошёл под технической учётной записью с широкими правами, сервис может вообще не знать, имел ли сотрудник право отменять эту подписку. А иногда не знает даже, кто инициировал действие.
Проблему permissions часто пытаются решить инструкцией для модели. Но это вопрос идентификации и авторизации. Те же правила мы применяем к обычным приложениям. Почему-то, когда интерфейс становится разговорным, о них легко забыть.
Удобная учётка для демо становится проблемой в production
На этапе прототипа один API-ключ со всеми полномочиями экономит недели работы. Можно показать сразу несколько сценариев, не строя систему ролей и разрешений.
В рабочем продукте такой ключ превращает ошибку в потенциально массовое действие. Агент не туда посмотрел, перепутал клиента, принял текст из документа за инструкцию — и backend послушно выполнил запрос.
Модели даже не обязательно совершать что-то необычное. Интеграция заранее дала ей больше возможностей, чем требовалось для задачи.
У пользователя и агента не должны случайно появляться разные права
Сначала надо определить роль агента. Он помогает конкретному сотруднику? Работает от имени подразделения? Или запускает заранее определённый автоматический процесс? Это три разных режима полномочий.
Если сотрудник не имеет доступа к чужому договору, запрос к ИИ не должен становиться обходным способом прочитать этот договор. Если он не вправе согласовать возврат, агент не может делать это за него только потому, что у приложения есть технический ключ.
Автономным процессам тоже нужны владелец, отдельная роль и ограниченный набор действий. Универсальная учётка «для всего AI» — плохой ответ на вопрос об ответственности.
И главное: разрешение проверяет сервис, который выполняет операцию. Модель может предложить вызов инструмента. Сервис решает, допустим ли этот вызов с такими параметрами и в таком контексте.
Инструменту нужна конкретная работа
Представим API manage_customer. Через него можно посмотреть профиль, изменить адрес, расторгнуть договор и провести возврат денег. Для разработчика удобно иметь одну универсальную функцию. Для безопасности слишком много разных полномочий спрятано за одним именем.
Гораздо проще контролировать отдельные операции: прочитать разрешённую карточку, подготовить изменение, отправить запрос на согласование. Перед изменением данных приложение проверяет конкретный объект, организацию, права на операцию и действующие лимиты.
Где возможно, полезны короткоживущие токены с узким набором прав. Если старая система не умеет так работать, проверку можно вынести в ограниченный backend, через который проходит каждый вызов. Самой модели широкий секрет вообще не нужен.
Это обычный принцип минимально необходимых привилегий. Для AI-агента он особенно важен: ошибка выбора операции может быть вполне корректным API-запросом.
Подтверждение человеком не заменяет проверку прав
Согласование крупной операции полезно. Но тот факт, что руководитель нажал «Подтвердить», ещё не означает, что агент имел право читать все исходные данные.
Доступ к информации, право на изменение и право согласования — разные вещи. Один сотрудник может подготовить возврат, другой — подтвердить, и ни одному не требуется полный доступ ко всем клиентским записям.
Я бы фиксировал всю цепочку: кто запросил действие, под какой ролью оно выполнялось, что предложила модель, какой политикой разрешено или отклонено, кто подтвердил и что реально изменилось.
Это частный случай более широкой темы AI Guardrails. Ограничения описывают границы автоматизации, а permissions проверяют конкретное право совершить конкретное действие.
Проверяйте сценарий с неправильным клиентом
Не самый эффектный, зато очень полезный тест: агент выбирает не тот заказ, счёт или договор. При этом он умеет корректно вызвать API и получает успешный ответ.
Для необратимых действий может понадобиться подтверждение карточки с явными идентификаторами. При неоднозначном поиске система должна запросить уточнение, а не угадывать. Желательно заранее понимать, как отменить операцию или хотя бы восстановить её историю.
Журналировать нужно фактические вызовы инструментов. Фраза модели «Подписка отменена» — всего лишь текст. Ответ API и запись об изменении данных — уже проверяемое событие.
Когда детальная настройка прав начинает казаться неудобной, это полезный сигнал. Скорее всего, команда наконец увидела, сколько полномочий собиралась выдать ради красивой демонстрации.