Личные ИИ-агенты становятся новой проблемой управления доступом
Личные ИИ-агенты сотрудников уже могут получать доступ к корпоративным Google Workspace, Microsoft 365 и Slack через OAuth, браузерные сессии, API-ключи и рабочие ноутбуки. В материале The Hacker News этот сдвиг описан как Bring Your Own Agent: помощник действует от имени работника, но организация нередко не видит ни самого агента, ни объём его полномочий.
Речь идёт не только о чат-ботах для ответов на вопросы. Персональный агент может читать почту, календарь и файлы, работать с открытыми страницами, подключаться к рабочим сервисам и использовать сохранённые пароли. Для приложения такой вход может выглядеть как обычная авторизация сотрудника.
Почему модель BYOD не решает проблему
Сценарий напоминает Bring Your Own Device, но контрольная точка изменилась. Устройство можно зарегистрировать в системе управления, тогда как личный агент может исполняться в инфраструктуре его поставщика или на компьютере работника. Формально отдельного устройства для постановки на учёт может не быть.
Агент получает возможности через уже существующую идентичность. В лучшем случае у него есть понятный владелец и ограниченные согласования. В худшем — сервис имитирует действия сотрудника или использует учётную запись, которую сложно связать с конкретным ответственным лицом. При увольнении человека могут сохраниться ранее выданные разрешения, токены и сессии.
Какими путями агенты подключаются
Наиболее простой путь — согласие OAuth. Пользователь разрешает стороннему приложению доступ к корпоративной почте, документам или мессенджеру, если политика тенанта допускает такое согласие. Отдельная заявка в ИТ-подразделение для этого не требуется.
Другой вариант — вход через браузер и внутренний менеджер паролей агента. Для неофициальных интеграций могут использоваться API-ключи и personal access tokens, которые нередко рассчитаны на длительное использование. Локальные агенты получают доступ ко всему, что доступно машине, на которой они установлены.
В статье приводятся примеры OpenAI Dots, GrokBot от xAI, Meta Muse, Instinct и OpenClaw. Поставщики добавляют механизмы управления для корпоративных развёртываний, однако эти средства не распространяются автоматически на личные экземпляры сервисов. Meta Muse, например, работает в выделенной виртуальной машине и использует компонент Sentinel для проверки исходящих запросов, но политика при этом задаётся пользователем, а не работодателем.
Контроль следует строить вокруг идентичности
Полный запрет личных агентов не обязательно является единственным вариантом: сотрудники уже привыкают использовать такие инструменты. Более практичный подход — рассматривать агента как внешнюю сущность и контролировать ту часть взаимодействия, которая остаётся в корпоративной среде: учётные записи, выданные права и активные сессии.
Для этого необходимо составить инвентарь Shadow AI: проверить OAuth-разрешения, входы из облачной инфраструктуры поставщиков, долгоживущие ключи неизвестных клиентов и результаты средств защиты конечных устройств. Затем важно связать каждый агент с владельцем, выдать ему минимально необходимые права и отозвать гранты, токены и сессии при уходе сотрудника.
Практический вывод для бизнеса состоит в том, что личный ИИ-агент нельзя надёжно оценивать только как приложение или устройство. Управление доступом должно учитывать, кому принадлежит агент, какие корпоративные идентичности он использует и как быстро эти полномочия можно сократить или отключить.