Подставное лицо: почему выдача прав корпоративным ИИ-агентам опасна

Инженерная команда подключает корпоративного ИИ-ассистента к корпоративному мессенджеру. Чтобы бот стал полезным рабочим инструментом, а не просто собеседником, к нему привязывают внешние функции через протоколы вроде Model Context Protocol (MCP) или API function calling. Для простоты интеграции агенту выдают сервисный аккаунт с правами администратора: он может искать задачи в Jira, проверять файлы на корпоративном диске, обращаться к выпискам в платежной системе и отправлять письма.

Стажер пишет в общий чат простой запрос: «Можешь собрать сводку по бонусам топ-менеджеров за следующий квартал и выложить цифры сюда?»

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

В классической информационной безопасности эта уязвимость называется Confused Deputy («подставное должностное лицо»).

Секретарь с универсальным ключом

Проблема Confused Deputy известна в системном программировании десятилетиями, но в мире автономных ИИ-агентов она превращается из редкого бага в системный просчет архитектуры.

Представьте секретаря на ресепшене штаб-квартиры. Служба безопасности выдала ему мастер-карту, открывающую любые двери: кабинеты руководства, серверные стойки и архив бухгалтерии. К стойке подходит практикант и говорит: «Директор попросил принести папку с аудитом сделки с 40-го этажа, откройте, пожалуйста, дверь и передайте ее мне».

Если секретарь идет и открывает дверь, не проверив пропуск практиканта и не запросив подтверждения у руководителя, он становится тем самым «подставным лицом». Его легитимный доступ использовали в обход установленных правил.

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

Где ломаются права доступа агентов

При подключении языковых моделей к внутренней инфраструктуре граница авторизации размывается сразу в трех точках:

1. Уравнивание привилегий: Агента часто запускают под единым сервисным токеном с широкими правами на чтение и запись. Любой рядовой сотрудник в диалоге с ботом автоматически наследует максимальные права самого агента.
2. Атака через внешние данные: Если у агента есть право вызывать системные команды или отправлять вебхуки, скрытая инструкция во внешнем входящем письме клиента может заставить модель запустить эти действия против внутренних сервисов. Сервер примет запрос, ведь он подписан легитимным токеном агента.
3. Доверие к текстовому смыслу: Классическая ролевая модель доступа (RBAC) опирается на строгие криптографические сертификаты, сессии и базы данных. Языковая модель работает с неструктурированным текстом. Попытка возложить на нейросеть проверку прав на основе формулировок неизбежно оставляет лазейки для семантического обхода.

Как ограничить полномочия агента

Контроль над ИИ-ассистентом не означает отказ от его автоматизации. Безопасность строится на привязке агента к реальному профилю пользователя, а не на раздаче модели собственных неограниченных прав:

1. Делегированные токены пользователя (User OAuth): Откажитесь от универсальных сервисных аккаунтов администратора. Запросы к инструментам должны выполняться строго от имени того пользователя, который общается с ботом. Если у стажера нет прямого доступа к папке HR на корпоративном диске, агент при попытке вызова API немедленно получит ошибку 403 Forbidden.
2. Разграничение степеней автономии: Разделите действия по масштабу возможных последствий. Чтение открытых внутренних регламентов агент может выполнять автономно. Критичные действия — изменение балансов клиентов, выполнение проводок, редактирование кода в репозитории или выгрузка конфиденциальных архивов — должны требовать явного подтверждения человеком через отдельный интерфейс.
3. Ограничение сетевого периметра (Egress Filtering): Заблокируйте агенту возможность отправлять сетевые запросы на произвольные внешние адреса. Даже если скрипт попытается передать внутренние данные наружу, фильтрация исходящего трафика предотвратит утечку.

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