Как провести инвентаризацию Shadow AI в компании?

Некоторое время назад я набрасывал контент для карточек по тому, как бороться с Shadow AI с помощью продуктов Positive Technologies. Ну а формат карточек таков, что там можно прописать достаточно небольшой объем текста, что позволяет наметить некие общие шаги, но не дает погрузиться в детали. Например, достаточно легко дать совет: «Настройте на NGFW или пограничном маршрутизаторе контроль доступа к следующим доменам:

• api.openai.com
• api.anthropic.com
• api.deepseek.com
• api.groq.com
• openrouter.ai
• replicate.com
• huggingface.co
• together.ai
• cohere.ai
• api.mistral.ai
• chat.openai.com
• claude.ai
• gemini.google.com
• perplexity.ai
• poe.com».

А дальше ты начинаешь настраивать эти правила и вдруг понимаешь, что у тебя ИИ может вызываться внутри обычных сервисов – Notion, MS Office, VS Code, плагины браузера и т.п. И как тут быть? Как провести инвентаризацию ИИ-сервисов, то есть выполнить первый шаг в деле контроля Shadow AI? Поэтому я бы искал не только ИИ-приложение (то же LM Studio или ChatGPT Classic можно поймать с помощью EDR), а признаки активации ИИ-функции внутри обычного приложения. И можно выделить, как мне кажется, несколько уровней (спойлер – их семь), которые надо учитывать при мониторинге Shadow AI.

Доступ к ИИ-инфраструктуре от обычных приложений

Это самый очевидный способ, когда у ИИ-функции есть отдельная сетевая инфраструктура.Хороший пример – GitHub Copilot внутри VS Code. GitHub документирует отдельные узлы, среди которых:

• *.githubcopilot.com
• *.business.githubcopilot.com
• *.enterprise.githubcopilot.com
• *.individual.githubcopilot.com
• copilot-proxy.githubusercontent.com
• origin-tracker.githubusercontent.com
• copilot-telemetry.githubusercontent.com

Причем GitHub прямо предлагает предприятиям интересный механизм: разрешить *.business.githubcopilot.com/*.enterprise.githubcopilot.com и блокировать *.individual.githubcopilot.com. То есть можно отличать корпоративно разрешенный Copilot от личного и либо просто блокировать трафик на NGFW или ACL маршрутизатора, либо создать корреляционное правило в SIEM

"приложение + *.individual.githubcopilot.com + пользователь ivanov = Shadow AI"

Когда контроль по доменам не работает

Microsoft 365 Copilot – прекрасный контрпример кейса с Github. Copilot глубоко встроен в Microsoft 365 и использует общую инфраструктуру Microsoft. В частности, Microsoft указывает *.cloud.microsoft и *.office.com, WSS и множество стандартных узлов Microsoft 365. Более того, Microsoft прямо не рекомендует пытаться управлять Copilot Chat выборочной блокировкой доменов и IP: можно сломать обычные функции Microsoft 365.

Чем глубже ИИ интегрируется в легитимное приложение, тем хуже работает традиционная сетевая инвентаризация.

Логи SaaS могут быть важнее МСЭ

Для встроенного вглубь приложения ИИ надежнее получать события непосредственно от SaaS. Например, для Microsoft 365 надо смотреть не только proxy/NGFW, а логи Microsoft 365 audit / usage, а там уже вытаскивать по конкретному пользователю работу с нужным функционалом, например, Copilot Chat / Copilot feature, в нужном приложении в нужное время.

У Microsoft есть отдельный лог по использованию Copilot Chat. То есть SIEM должен поглощать ИИ-телеметрию самих SaaS-платформ, а не пытаться реконструировать все из TCP-соединений.

Аналогичная история с Notion – обычный Notion и Notion AI используют одну экосистему доменов. Notion AI живет непосредственно внутри workspace и способен работать с его содержимым; AI Connectors дополнительно позволяют обращаться к данным подключенных приложений, а Agent в некоторых случаях способен даже совершать действия. Официальный список Notion включает notion.com, app.notion.com, api.notion.com, notionusercontent.com и другие общие узлы, и понять по ним, применяется ли ИИ или нет, нельзя. Для каждого используемого workspace нужны данные audit / admin telemetry / entitlement / configuration, если конкретный тариф и API это позволяют.

Это важный нюанс. У многих SaaS-провайдеров доступ к расширенной телеметрии и логам стоит дополнительных денег и в базовые тарифы обычно не входит.

В 2019-м году я написал статью про мониторинг безопасности облаков (часть 1 и 2) и рассмотрел там все эти нюансы.

Расширения – один из лучших объектов для инвентаризации Shadow AI

Вот здесь я бы копал особенно активно; особенно если у вас установлены EDR на рабочих местах. Например, для VS Code надо смотреть в папках:

~/.vscode/extensions/
%USERPROFILE%\.vscode\extensions\

и искать установленные extension ID. Не только GitHub Copilot, но и вообще категории Copilot, Claude, Codeium/Windsurf, Continue, Cline, Roo Code, Gemini, Amazon Q, Tabnine и т.п.

Список упомянутых расширений неполный – оцените то, что может использоваться у вас – постоянно появляется что-то новое. Также учитывайте и свою ОС, в которой пути хранения упоминаемых в заметке конфигов могут быть своими.

То есть агент EDR/MDM/asset-management постоянно проверяет установленное на ПК или смартфоне программное обеспечение и сравнивает полученный в реальном времени список с корпоративным белым списком разрешенного ПО.

Тут впору задуматься о AI Software Bill of Materials рабочего места, который не только содержит список того, какие программы стоят на компьютере, но и какие расширения, ИИ-функции, модели, внешние сервисы и т.п. Но это пока из области фантастики – у нас еще не все EDR-то используют.

Инвентаризация браузеров

Поднимаясь по пирамиде телеметрии (от сети к приложениям, от приложений к их расширениям), можно задуматься о том, что собирать не просто название расширений и плагинов браузера навроде Super Productivity Assistant, а следующие данные:

• extension ID
• version
• publisher
• permissions
• host_permissions
• content_scripts
• externally_connectable
• nativeMessaging

А по каждому расширению еще и список «интересных» привилегий:

• <all_urls>
• activeTab
• tabs
• scripting
• clipboardRead
• clipboardWrite
• downloads
• webRequest
• nativeMessaging

Централизованно получать сведения об установленных расширениях можно у корпоративно управляемых Chrome/Edge. У Chrome Enterprise, например, есть Chrome Management API и Chrome Browser Cloud Management; у Edge – политики и управление через Microsoft Intune/Edge management. У корпоративной версии Яндекс.Браузера тоже есть свой функционал по контролю установленных расширений.

Если браузер не управляется централизованно, это можно делать средствами EDR/MDM/скриптами инвентаризации. Например, Chromium-браузеры хранят данные по расширениям в пользовательском профиле. Можно собирать Extensions/Preferences или Secure Preferences и разбирать manifest.json каждого расширения, в котором стоит анализировать, например, вот такие параметры:

{

  "permissions": [],

  "host_permissions": [],

  "content_scripts": [],

  "externally_connectable": {}

}

Можно еще и свое расширение навайбкодить написать для корпоративно управляемых браузеров.

Помните, что доступ к ИИ-сервису может произойти и без участия пользователя. Например, пользователь зашел в веб-почту, а в браузере работал ИИ-плагин, который автоматически считал почту и отправил ее в ИИ-сервис. Пользователь вроде и не виноват, но Shadow AI налицо.

IDE нужно контролировать не только по расширениям

Сейчас тот же разработчик способен использовать ИИ в том же VS Code как минимум четырьмя способами – GitHub Copilot, другое расширение ИИ, MCP и собственный Python/Node-клиент с доступом к LLM API. Поэтому для рабочего места разработчика я бы собирал еще:

• расширения VS Code
• конфигурацию MCP
• settings.json
• .env
• пакеты Python
• пакеты npm
• инструменты CLI
• сетевые назначения.

Например, появление:

"mcpServers": {

    ...

}

в конфигурационных файлах – уже очень интересное событие, которое может говорить о наличии Shadow AI (если указанный MCP-сервер не был в списке разрешенных). А вот такая связка «новый MCP-сервер + доступ к файловой системе + доступ к репозиторию Git + доступ к внешней LLM» уже вероятно говорит о Shadow AI; особенно если никакого нового ИИ-приложения пользователь вообще не устанавливал и не попал в поле зрения через телеметрию EDR.

Notion, например, официально поддерживает MCP, через который Claude, ChatGPT, Cursor и другие ИИ-клиенты могут читать и записывать страницы Notion. У Notion Agent тоже могут подключаться внешние MCP-серверы. Получается замечательная цепочка: «Cursor + MCP + Notion + корпоративные документы». Каждый компонент сам по себе разрешен. А вся цепочка может оказаться Shadow AI.

Доступ к MCP-серверам, кстати, можно отслеживать решениями класса NTA/NDR.

Разрешенный сервис, но через личный аккаунт

Есть еще сценарий, который сетевые средства практически не решают – сотрудник использует разрешенный в компании ИИ-сервис, но через личный ИИ-аккаунт. Например, GitHub Copilot Personal, Notion personal workspace, личная учетка в Google Gemini или личный ИИ-плагин. Поэтому неплохо бы еще сопоставлять и идентификационную информацию: «Приложение + ИИ-функция + Identity + Лицензия + Тенант». Например, «VS Code + Copilot + user@gmail.com» может быть признаком Shadow AI, а та же цепочка: «VS Code + Copilot Enterprise + ivanov@company.com + корпоративный тенант» говорит о контролируемом компанией ИИ.

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

Чтобы отделить использование личного от корпоративного ИИ-сервиса в браузере помогут SSO, профили браузера, ограничения тенанта, логи IdP/CASB/SaaS и возможности конкретного сервиса.

А что с теневыми ИИ-агентами?

Это как раз самая неприятная категория Shadow AI, потому что у самописного агента может не быть ни ollama.exe, ни характерного расширения, ни отдельного GUI, ни даже слова ИИ где-либо в названии. Поэтому искать нужно не «агента», а совокупность признаков агентного поведения. Например, сскать LLM/API-вызовы из неожиданного процесса (особенно если процесс раньше с LLM не общался).

Но список доменов должен включать не только производителей моделей, но и AI gateways/routers/proxies. Плюс организация может иметь собственный gateway.

Во-вторых, можно искать AI SDK и агентские фреймворки, На ПК можно провести инвентаризацию Python/Node/Java-пакетов и зависимости проектов. Например, openai, anthropic, google-genai, langchain,langgraph, llama-index, crewai, autogen, semantic-kernel, mcp.

Но здесь важно не делать ошибку: langchain установлен ≠ агент работает. Это сигнал, но еще не инцидент.

Еще можно искать API-ключи и конфигурацию ИИ-агентов. Например, OPENAI_API_KEY, ANTHROPIC_API_KEY, GOOGLE_API_KEY, AZURE_OPENAI_ENDPOINT или OPENROUTER_API_KEY в:

• .env
• .env.local
• config.yaml
• settings.json
• docker-compose.yml
• Kubernetes Secret
• CI/CD variables

Кстати, большая ошибка – искать ИИ-агентов только на ноутбуках. Их могут развернуть в Docker или в Kubernetes, или на внешней VPS, которые тоже должны попасть в поле внимания для инвентаризации.

Наконец, MCP делает самописных агентов одновременно мощнее и заметнее. Поэтому можно искать конфигурации с mcpServers и уже потом оценивать, что это за MCP, кто к нему подключается, куда, с какими правами и к каким ресурсам.

Вообще, еще много всяких признаков работы агентов можно придумать. Например, необычные доступы и их комбинации (агент же запускается именно для выполнения действий) или повторяемая поведенческая петля «модель → действие» или GitHub/GitLab/Jenkins и другие CI/CD-решения или различные «нечеловеческие» учетные записи (сервисные учетки, OAuth-приложения, machine/workload-учетки), которые появились недавно, обращаются сразу к нескольким системам, работают круглосуточно, совершают нетипичные API-вызовыи параллельно взаимодействуют с LLM.

Резюмируя

Если все это подсобрать вместе, то у нас получается, что современный Shadow AI может вообще не иметь собственного процесса, порта или домена, которые можно было бы легко выявить с помощью EDR, NGFW или сканера безопасности. Он может быть функцией внутри разрешенного SaaS, расширением разрешенного браузера, плагином IDE или агентом, собранным из пяти разрешенных компонентов. Поэтому у нас получается 7 уровней контроля, которые должны применяться сообща с целью инвентаризации Shadow AI в компании:

То, что не ловится на одном уровне, можно ловить на другом, третьем и т.д. По сути речь идет о корреляционных цепочках для SIEM. Например:

Chrome + новый extension ID + <all_urls> + соединение с неизвестным AI API = Shadow AI extension

Code.exe + новое AI extension + *.individual.githubcopilot.com = Personal Copilot на корпоративном ПК

Word + корпоративный Microsoft 365 + Copilot entitlement отсутствует + Copilot usage event = аномалия / нарушение политики

VS Code + новый MCP server + файловая система + Git + Notion + внешняя LLM = несанкционированный ИИ-агент

Подводя итог, можно сказать, что реальная задача инвентаризации Shadow AI выглядит не как: «Где у нас установлен ИИ?» а как: «Где в нашей инфраструктуре возникла способность передавать данные ИИ-модели или позволять модели читать данные, принимать решения и выполнять действия?» И это уже более всесторонняя задача, чем просто настроить правила на NGFW или телеметрию на EDR. Хотя с них, безусловно, надо начинать. А дальше вас ждет много интересных открытий… не только о том, как работает ИИ (что полезно знать), но и о том, как работает ваша компания, давно уже вышедшая за рамки применения обычного офисного ПО.