Теневой ИИ в компании: как найти агентов до утечки данных

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

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

Что считать теневым ИИ

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

Документация Microsoft 365 о неуправляемых агентах указывает среди рисков утечку данных, уязвимости и отсутствие аудита. Описанная функция доступна в публичной предварительной версии, обнаруживает только перечисленные Microsoft агенты, а блокировка действует на управляемых устройствах Windows, зарегистрированных в Intune. Поэтому эта панель не заменяет проверку всей корпоративной среды.

Риск определяется не наличием слова «ИИ» в названии, а связью инструмента с данными и полномочиями. Чат без корпоративного входа требует одного уровня контроля, а агент, способный читать облачный диск, обращаться к репозиторию, запускать команды или отправлять сообщения от имени сотрудника, — другого.

Шаг 1. Соберите следы в единый реестр

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

1. Журналы входа. Найдите сторонние приложения, в которые сотрудники входили с рабочей учётной записью, новые подключения единого входа и активность сервисных учётных записей.
2. Разрешения приложений. Выгрузите согласия OAuth и перечень установленных интеграций. Зафиксируйте, кто предоставил доступ, какие области разрешены и с какой учётной записью они связаны.
3. Браузеры. На управляемых устройствах соберите перечень расширений и веб-приложений. Отметьте инструменты, способные читать открытые страницы, заполнять формы, обрабатывать встречи или загружать файлы.
4. Сеть. Просмотрите журналы DNS, прокси-сервера, межсетевого экрана или защищённого веб-шлюза. Регулярные обращения к API помогают обнаружить неизвестный сервис, однако домен назначения не раскрывает содержание переданных данных.
5. Рабочие станции и среда разработки. Проверьте командные утилиты, дополнения редакторов кода, конфигурации MCP, локальные процессы, задания автоматического запуска и зависимости проектов.
6. Секреты и автоматизации. Инвентаризируйте ключи API, токены в хранилищах секретов и переменных CI/CD, веб-перехватчики и интеграции с репозиториями. У каждого секрета должны быть владелец, назначение и связанная система.

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

Шаг 2. Определите данные и полномочия агента

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

Название приложения не раскрывает реальный объём доступа. Рекомендации Google Workspace по областям OAuth поясняют, что эти области определяют вид и уровень доступных приложению данных, и предписывают выбирать наиболее узкие разрешения. Право изменять почту или читать файлы следует оценивать отдельно от заявленного назначения сервиса.

• Низкий риск: нет корпоративного входа, подключений и секретов; рабочие данные сервису не передаются.
• Средний риск: инструмент получает внутренние, но не критичные материалы, а значимые действия подтверждает человек; доступ можно ограничить отдельным рабочим пространством.
• Высокий риск: агент видит персональные данные, коммерческие секреты, исходный код или ключи либо способен менять ресурсы, выполнять команды и расширять полномочия.

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

Шаг 3. Выберите блокировку, изоляцию или допуск

Блокируйте инструмент, если у него нет рабочего владельца, запрошенные права несоразмерны задаче, условия обработки неясны или сервис уже получил секреты. Отзовите согласия OAuth и токены, отключите расширение или процесс, закройте доступ на управляемых устройствах и замените переданные ключи. Сохраните журналы, необходимые для определения затронутых учётных записей и ресурсов.

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

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

Отчёт CrowdStrike о наблюдениях за 2025 год описывает эксплуатацию легитимных генеративных сервисов более чем в 90 организациях, атаки на платформы разработки ИИ и вредоносные серверы, имитировавшие доверенные службы для перехвата чувствительных данных. Эти наблюдения показывают, почему токены, локальные среды и зависимости агента нужно проверять вместе с его доступом к почте и облачным хранилищам.

Как не потерять найденные агенты из виду

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

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

Читайте также:

• Безопасная удалённая работа: как защитить учётные записи, устройства и доступ к компании
• Найти не только по IP: что такое рынок пробива данных
• Цифровой след: как компании используют наши данные в интернете