Суть позиции
Избыточные полномочия — это ситуация, когда модели, агенту или плагину выданы функции, доступы и права сверх тех, что необходимы для решаемой задачи. OWASP описывает три типовых проявления: чрезмерную функциональность — агент умеет больше, чем требует сценарий; чрезмерные права — доступ к данным и системам шире рабочего множества; чрезмерную автономию — действия выполняются без человеческого контроля там, где он обязателен по смыслу операции.
Проблема выглядит административной, а не технической, и потому систематически недооценивается. Между тем именно она превращает досадные инциденты в катастрофические: одна и та же успешная промпт-инъекция в системе с правами только на чтение приводит к испорченному ответу, а в системе с правом рассылки — к оттоку данных и компрометации клиентов.
Почему права раздаются щедро
Причины почти всегда организационные. Агента собирают в спешке пилота — и выдают сервисную учётку с широкими правами, потому что узкую создавать дольше. Функционал растёт — права прежнего пилота остаются. Удобство разработчика: единая учётка на все интеграции проще, чем пять отдельных. Отсутствие владельца: никто не отвечает за то, какие доступы у ассистента есть сейчас.
Отдельная ловушка — «права по умолчанию» готовых платформ: коннектор к почте запрашивает полный доступ к ящику, плагин к файлам — ко всему хранилищу. Согласившись один раз, команда получает агента, формально работающего в рамках купленного решения, фактически — с ключами от всего.
Матрица типовых ограничений
| Тип права | Риск без ограничения | Рабочее ограничение |
|---|---|---|
| Чтение данных | доступ к чужим данным через контекст | выборка только своего домена, фильтры по уровням |
| Запись в системы | порча и подмена записей | staging-подтверждение, журнал изменений, откат |
| Отправка наружу | эвакуация информации | белый список адресатов, лимит на сессию |
| Платёжные операции | прямой финансовый ущерб | только человек-аппрувер, отдельный канал подтверждения |
| Управление доступами | закрепление атакующего | вне списка функций агента полностью |
| Исполнение кода | компрометация хоста | песочница без сети и секретов, ограничение по времени |
Две строки заслуживают комментария. Управление доступами никогда не должно быть автономной функцией: история с агентом, который по вежливой просьбе «подними мне роль» повышает привилегии пользователя, — не гипотеза, а стандартный сюжет тестов на проникновение. Исполнение кода допустимо только в изолированной среде: полноценная песочница без сети и секретов сокращает радиус поражения до самой задачи.
Архитектурные принципы
Наименьшие привилегии. Каждому инструменту агента — свой минимальный токен на свой ресурс. Не «доступ к хранилищу», а «чтение папки X». Не «полномочия почтового ящика», а «создание черновиков без права отправки».
Одно действие — один инструмент. Вместо универсального «выполни операцию в CRM» — узкие функции: создать задачу, обновить статус, приложить файл. Узкий интерфейс — это и барьер, и журнал: каждая операция видна отдельной строкой.
Человек в контуре для необратимого. Отправка вовне, платёж, удаление, изменение прав — по умолчанию требуют подтверждения человеком через интерфейс, который модель не контролирует. Кнопка подтверждения должна существовать вне генерируемого моделью контента.
Квоты и скорость. Лимит операций за сессию и в единицу времени превращает массированную атаку в серию прерванных попыток и даёт мониторингу время среагировать.
Разделение сред. Агент разработки не видит продакшен-данные; агент продакшена не умеет менять конфигурацию. Переток между средами — отдельная привилегия с человеком-аппрувером.
Проверка и поддержание
Аудит полномочий — быстрое и благодарное упражнение: выпишите все инструменты и доступы каждого агента, отметьте используемые фактически, сравните списки. Разница — кандидат на немедленное сужение. Повторяйте при каждом изменении функций агента и раз в квартал: права дрейфуют незаметно, как и везде в ИТ.
В тестах на проникновение ИИ-контура попытки расширения привилегий через уговоры модели — обязательный раздел: вежливая просьба, ссылка на несуществующее распоряжение, «служебный режим». Устойчивость к ним проверяется так же регулярно, как и сами промпт-инъекции.
Как организовать подтверждение человеком
Кнопка подтверждения работает только тогда, когда она честная. Три условия. Независимость: интерфейс подтверждения живёт вне генерируемого моделью контента — модель не рисует сама кнопку и не описывает её текст; в противном случае инъекция подделывает и подтверждение. Информативность: сотрудник видит суть операции в терминах бизнеса — «перевод столько-то на такой-то счёт», «письмо такому-то адресату с вложением», — а не техническую команду. Отсутствие давления: лимит времени и красные формулировки «подтвердите немедленно» — почва для социальной инженерии; у оператора должно быть право и время отложить операцию и проверить вторым каналом.
Параллельно стоит измерять долю подтверждений: если сотрудник подтверждает всё подряд, контур выродился в формальность. Здоровые сигналы — периодические отклонения и вопросы операторов; их отсутствие — повод упростить поток операций, а не радоваться послушанию.