ИИ-агенты (от англ. AI agents — программные помощники, которые сами выполняют задачи в цифровых системах) всё чаще получают доступ к корпоративным приложениям, файлам и API. Проблема в том, что службы безопасности нередко видят только вход пользователя, но не действия автономного помощника после входа. Для бизнеса это риск утечек, спорных прав доступа и провала аудита.

Почему старый контроль доступа перестал справляться

Классические системы управления учётными записями и доступом, или IAM (Identity and Access Management — управление идентификацией и доступом), проектировали под людей. Сотрудник входит в систему, подтверждает личность, получает права, работает и выходит.

ИИ-агент ведёт себя иначе. Он может работать постоянно, обращаться к нескольким приложениям, использовать API, запускать задачи по расписанию и получать новые разрешения через интеграции. Для обычного журнала событий такая активность часто выглядит как набор технических операций, а не как понятная цепочка: кто поручил, что сделал, к каким данным обратился.

Gartner в своём первом обзоре рынка guardian agents отмечает: внедрение ИИ-агентов в компаниях ускоряется быстрее, чем созревают политики контроля. Это не спор о моде на искусственный интеллект. Это вопрос инвентаризации: компания должна знать, какие цифровые помощники уже работают внутри её периметра.

Где возникает «тёмная материя» идентичностей

Компания Orchid Security называет слепую зону доступа «identity dark matter» — «тёмной материей идентичностей». По её оценке, около половины активности, связанной с корпоративными идентичностями, проходит вне централизованной видимости IAM. Причина проста: часть учётных записей и правил доступа живёт не в едином каталоге, а внутри самих приложений.

Это касается локальных администраторов, сервисных аккаунтов, токенов API, встроенных ролей в облачных сервисах и самописных интеграций. Добавьте к ним ИИ-агентов, которые бизнес-подразделения подключают ради автоматизации, — и карта доступа быстро теряет чёткость.

Для пользователя такая путаница выглядит бытовой: он ищет в браузере «discord login web» или «discord web version», входит в очередной веб-сервис и продолжает работу. Для службы безопасности важнее другое: какой токен сохранился после входа, какой бот получил доступ к файлам и кто отвечает за его действия.

Что должны видеть безопасники

Первый вопрос звучит просто: какие ИИ-агенты работают в среде компании прямо сейчас. Без ответа на него нельзя оценить риски. Агент может быть встроен в SaaS-платформу, подключён через API, создан разработчиками для внутренней автоматизации или запущен отделом продаж без отдельного согласования с ИБ.

Второй вопрос — какие права у этих агентов. Если помощник читает только открытые справочники, риск один. Если он получает доступ к персональным данным, финансовым документам, переписке с клиентами или ключам API, ситуация другая.

Третий вопрос — можно ли связать действия агента с человеком. В зрелой модели безопасности каждая операция должна иметь владельца: сотрудника, подразделение, заявку, бизнес-цель. Иначе расследование инцидента превращается в поиск неизвестного процесса среди тысяч событий.

Похожая логика нужна и для обычных утечек ключей. Ранее мы разбирали, как уязвимость Ollama могла привести к раскрытию ключей API и переписок: ИИ-инструменты становятся ценными именно потому, что подключены к данным и инфраструктуре.

Статические ключи снова стали главной мишенью

Статические учётные данные — старая боль корпоративной безопасности. Это пароли сервисных аккаунтов, долговечные токены, аварийные записи для администраторов, ключи «машина — машина». Их часто создают для нужной задачи, а потом забывают.

ИИ-агенты усиливают этот риск. Автономный помощник может пользоваться таким ключом часами или днями, выполнять операции быстрее человека и оставлять меньше понятного контекста в журналах. Если злоумышленник получит тот же токен, он сможет маскироваться под легитимную автоматизацию.

Вендоры вроде Orchid Security предлагают искать такие учётные данные не только в центральном каталоге, но и внутри приложений: в конфигурациях, локальных аккаунтах, облачных настройках, механизмах авторизации. Но покупка отдельной платформы не заменяет базовую дисциплину. Компании всё равно нужны владельцы сервисных аккаунтов, сроки пересмотра прав и запрет на бесконечные ключи без причины.

Аудит должен идти до проверки, а не после инцидента

Отдельный риск связан с соответствием требованиям безопасности. В источнике приводится пример NIST CSF (Cybersecurity Framework — модель кибербезопасности Национального института стандартов и технологий США). Для российских компаний аналогичный смысл имеют внутренние политики, отраслевые требования, договоры с заказчиками и правила по персональным данным.

Проблема не в формальном отчёте. Если приложение само хранит роли и выдаёт права, центральная система может показывать красивую картину, но не видеть реальную логику доступа. Аудитор или расследование после инцидента обнаружит разрыв слишком поздно.

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

Сетевой уровень тоже не стоит сбрасывать со счетов. Если сотрудники работают из отелей, коворкингов и кафе, компании стоит применять сервис безопасного интернет-соединения, который помогает защитить передачу данных и приватность в публичных сетях.

Практический вывод: что проверить на этой неделе

  • Составьте список всех ИИ-инструментов и автоматических агентов, которые используют подразделения, включая тестовые проекты и интеграции через API.
  • Назначьте владельца для каждого агента: человека или команду, которая отвечает за права, цель работы и отключение.
  • Проверьте сервисные аккаунты, долговечные токены и ключи API. Начните с тех, у кого есть доступ к персональным данным, финансам и административным функциям.
  • Введите срок пересмотра прав: для критичных доступов — чаще, для низкорисковых — по утверждённому графику.
  • Настройте журналы так, чтобы они показывали цепочку «владелец — агент — инструмент — действие — объект», а не только факт входа.
  • Запретите запуск новых ИИ-агентов без регистрации в реестре ИБ и краткого описания, какие данные они обрабатывают.
  • Проведите разбор одного реального бизнес-процесса с ИИ-автоматизацией и проверьте, можно ли восстановить его действия по журналам.
Поделиться: