AI-агент, которому дали корпоративный токен сотрудника, может читать, менять и запускать действия с теми же правами — а аудит-лог запишет их на человека, а не на модель. Учётные данные AI-агентов быстро становятся вопросом не удобства, а ответственности: для российских разработчиков, ИБ-команд и руководителей это означает необходимость пересмотреть привычную схему «подключили ассистента к API и посмотрим».
Автор The New Stack проверил, что именно получает агент при аутентификации от имени пользователя, и пришёл к неприятно практичному выводу: речь идёт не о размытой «делегации интеллекта», а о токене с конкретными разрешениями. Агент не приобретает отдельную цифровую личность автоматически. Если ему передали пользовательские полномочия, внешняя система видит запрос как действие владельца этих полномочий. В журнале аудита останется знакомое имя — даже если операцию инициировал агентный сценарий.
На первый взгляд это ожидаемое свойство OAuth, API-ключей и сессионных токенов. Но с генеративными агентами меняется масштаб проблемы. Обычный скрипт обычно выполняет заранее известный набор операций. Агент получает цель на естественном языке, выбирает инструменты, строит последовательность вызовов и может учитывать данные из переписки, документов или подключённых сервисов. Права остаются прежними, а количество путей к рискованному действию заметно растёт.
Особенно остро вопрос встаёт в связке с Model Context Protocol. MCP упрощает подключение моделей к корпоративным источникам данных и инструментам: репозиториям, таск-трекерам, базам знаний, облачным консолям. Это полезно для внутренних помощников и инженерных платформ, но само наличие MCP-сервера не создаёт безопасный контур. Если агенту доступны широкие пользовательские токены, он может использовать возможности подключённого инструмента в пределах этих разрешений. Ограничение «ассистенту нельзя вредить» в системном промпте не заменяет контроль доступа на стороне сервиса.
Для расследований инцидентов это создаёт двойную проблему. Во-первых, сложно быстро отличить действие, которое сотрудник выполнил сам, от вызова, сделанного агентом в его сессии. Во-вторых, владелец токена формально оказывается связан с операцией, хотя не обязательно видел конкретную команду или её последствия. Нужны более детальные события: какой агентный workflow работал, какой инструмент был вызван, с каким идентификатором сессии, по чьему запросу и требовалось ли подтверждение человека. Без этого аудит превращается в журнал, который фиксирует исполнителя по документам, но не реальную цепочку принятия решений.
Практический вывод для команд разработки — не выдавать агентам постоянный доступ «как у разработчика» только ради быстрого прототипа. Учётные данные AI-агентов лучше отделять от учётных записей людей: создавать сервисные идентичности, выдавать короткоживущие токены и ограничивать их конкретными задачами. Для операций с публикацией, изменением прав, удалением данных, платежами и production-инфраструктурой разумно оставить явное подтверждение человека. Полезна и сегментация инструментов: агенту, который ищет информацию в документации, не нужен тот же набор разрешений, что и агенту для CI/CD.
Бизнесу придётся договориться и о границах ответственности. Нельзя одновременно требовать от сотрудников использовать автономных помощников и считать каждую запись с их именем безусловным доказательством личного действия. Политики доступа, правила хранения логов и процесс реагирования на инциденты должны учитывать агентный слой. Иначе удобная автоматизация станет источником спорных расследований, а попытка выяснить, кто именно изменил настройку или отправил данные наружу, закончится поиском виноватого владельца токена.
Следующий этап зрелости агентных систем — не более убедительные ответы модели, а понятная идентичность каждого участника цепочки: человек дал поручение, агент спланировал шаги, инструмент выполнил операцию, сервис проверил права. Пока эта цепочка скрыта за одним пользовательским токеном, учётные данные AI-агентов будут расширять доступ быстрее, чем компании успеют доказать, кто и зачем им воспользовался.