Shadow AI и ИИ-агенты: как закрыть облачный контур риска

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

Так появляется Shadow AI. Это использование моделей, приложений и функций ИИ без одобрения, контроля или участия организации. Риск растёт, когда к модели подключается ИИ-агент.

Обычный чат-бот отвечает на запрос. Агент сохраняет контекст, обращается к SaaS и API, использует токены и выполняет действия. Поэтому новый облачный контур включает не только данные, но и право действовать от имени сотрудника.

🔍 Shadow AI начинается с незаметного облачного доступа

Shadow AI не всегда выглядит как отдельный чат. Сотрудник может открыть личную учётную запись в генеративном сервисе. Он может установить расширение браузера или включить функцию ИИ внутри уже знакомой SaaS-платформы.

К этой же группе относятся внешние API внутри внутренних приложений. Сюда входят помощники для кода, переводчики и инструменты для работы с текстом. Локальная модель на рабочем ноутбуке тоже создаёт контур риска.

Сотрудник обычно решает рабочую задачу. Он ускоряет анализ или исправляет код. Но ИТ-команда не видит, какие данные покидают организацию, где их обрабатывают и кто получает доступ.

Shadow AI отличается от легитимного применения ИИ. Корпоративный сервис проходит согласование, получает владельца и правила работы с данными. Теневой инструмент появляется без такой проверки.

Проблема имеет заметный масштаб. Анализ 22,4 млн корпоративных запросов к ИИ выявляет 665 разных генеративных инструментов. При этом официальные подписки на ИИ имеют только 40% компаний в указанном исследовании.

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

Что сделать сейчас: составьте короткое правило. Любой ИИ, который обрабатывает корпоративные данные, получает владельца и проходит проверку.

⚠️ Почему ИИ-агент опаснее обычного чат-бота

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

Для работы агент получает учётную запись или токен. Токен — это секрет, который подтверждает право доступа. Если право слишком широкое, агент получает больше возможностей, чем нужно задаче.

Агент может читать корпоративные документы через коннектор. Он может обращаться к календарю, системе задач или репозиторию. Чем больше подключений, тем шире последствия ошибки.

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

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

Риски становятся автоматическими. Человек может не проверять каждый шаг. Система выполняет операцию быстро и повторяет ошибку на большом числе объектов.

Практический вывод прост. Агент нужно считать отдельным участником облачной среды. Для него нужны собственная личность, свои права и собственные журналы.

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

📊 Масштаб риска измеряется не только числом сервисов

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

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

Финансовый эффект тоже измерим. По приведённым оценкам, Shadow AI добавляет 670 тысяч долларов к средней стоимости утечки. Риск со стороны сотрудников из-за неосторожного применения ИИ оценивается в 10,3 млн долларов в год.

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

Запрет не решает проблему. Почти половина сотрудников продолжает использовать личные ИИ-аккаунты после запрета. Значит, контроль должен учитывать реальное поведение людей.

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

Такая модель снижает стимул пользоваться личным аккаунтом. Она также помогает объяснить требования без давления и лишней бюрократии.

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

🗺️ Карта облачного контура показывает скрытые связи

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

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

Следующий слой — API-ключи и сервисные учётные записи. Они часто работают без постоянного участия человека. Такой доступ нельзя смешивать с личной учётной записью сотрудника.

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

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

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

Минимальный состав карты

• учётные записи пользователей и агентов;
• каталоги SaaS и встроенные функции ИИ;
• корпоративные хранилища и репозитории;
• API-ключи, токены и сервисные записи;
• плагины, коннекторы и внешние модели;
• журналы входа, согласий и действий.

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

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

🛠️ Как выявить теневой доступ без запрета всей работы

Первый источник сигналов — журналы входа. Ищите новые приложения, личные аккаунты и необычные обращения к ИИ-сервисам.

Второй источник — журнал OAuth-согласий. OAuth позволяет приложению получить разрешение на доступ к данным. Согласие пользователя не заменяет проверку организации.

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

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

Следующий шаг — проверка передачи данных. Определите, какие запросы содержат код, персональные данные, секреты или сведения о клиентах.

Затем сопоставьте права с задачей. Агент для поиска документа не должен изменять репозиторий. Помощнику для текста не нужен доступ к финансовой системе.

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

1. Соберите журналы входа и OAuth-согласий.
2. Составьте список приложений и доменов.
3. Проверьте передаваемые типы данных.
4. Сравните права с рабочими задачами.
5. Удалите неиспользуемые токены.
6. Назначьте владельца каждому подключению.

Проверка должна повторяться. Новая интеграция меняет карту доступа. Разовая инвентаризация быстро теряет актуальность.

Что сделать сейчас: начните с OAuth. Найдите все согласия за последний период и поставьте на проверку приложения без владельца.

🔐 Модель доступа должна учитывать личность агента

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

Давайте агенту только минимально необходимые права. Такой подход ограничивает ущерб при ошибке или компрометации токена.

Разделяйте чтение и изменение. Право просматривать документы не должно открывать удаление или публикацию. Критические действия выделяйте в отдельную операцию.

Ограничивайте срок жизни токена. Постоянный секрет создаёт длительный риск. Короткий срок требует обновления и уменьшает окно возможного злоупотребления.

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

Разделяйте данные по чувствительности. Агент может работать с общими материалами, но не получать доступ к персональным данным без отдельного основания.

Используйте принцип нулевого доверия. Каждое обращение проверяется заново. Сам факт нахождения агента внутри корпоративной сети не даёт ему права на всё.

Эта матрица помогает быстро увидеть избыточные права. Если поле нельзя объяснить рабочей задачей, доступ нужно пересмотреть.

Что сделать сейчас: отделите одного агента от общей учётной записи. Оставьте ему только чтение и проверьте записи в журнале.

🛡️ Данные требуют отдельного слоя защиты

До подключения ИИ разделите информацию по классам. Выделите секреты, персональные данные, код, внутренние документы и открытые материалы.

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

Запретите передачу секретов в запросах. К секретам относятся ключи, пароли и токены. Агент не должен получать их из документов или переменных среды без отдельного контроля.

Используйте маскирование. Оно заменяет чувствительные значения безопасными метками. Модель получает структуру задачи, но не видит исходные реквизиты.

Добавьте фильтрацию запросов и ответов. Проверка запроса ищет запрещённые данные до отправки. Проверка ответа ловит раскрытие сведений после обработки.

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

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

Нужно контролировать и ответы. Агент может сформировать файл, сообщение или изменение в системе. Перед публикацией результат должен пройти проверку.

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

🎯 Инструкции внутри данных становятся частью угрозы

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

Так возникает подмена инструкций в обрабатываемых данных. Агент принимает внешний текст за рабочее указание. Затем он раскрывает сведения или запускает лишнюю операцию.

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

Разделяйте инструкции и данные. Агент должен понимать, какие поля являются командами, а какие только содержимым для анализа.

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

Добавьте подтверждение перед критической операцией. Человек проверяет цель, объект и итоговое действие. Одного краткого сообщения о намерении недостаточно.

Журналируйте входные данные и решения агента с учётом правил приватности. Запись помогает понять, откуда появилась команда и какие права использовал агент.

Проверяйте результат на несоответствие задаче. Если помощник для поиска внезапно пытается изменить файл, процесс должен остановиться.

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

🌍 Supply chain показывает, как агент становится целью атаки

Инцидент с пакетом Nx показывает особый риск. Вредоносные версии пакета оставались доступными в npm около четырёх часов. Пакет устанавливают примерно 6 млн раз в неделю.

Атакующие использовали внедрение команды через непроверенный заголовок запроса на изменение. Это дало выполнение команды в рабочем процессе. Затем злоумышленники получили токен с правом записи.

После этого они добавили вредоносную ветку и рабочий процесс. Через процесс публикации они вывели токен npm. Вредоносный код собирал локальные файлы, переменные среды и учётные данные.

Особенность инцидента связана с локальными ИИ-инструментами. Вредоносный код пытался вызвать установленные CLI Claude, Gemini и Amazon Q.

Эти инструменты получили команду сформировать файл с секретами. Затем код отправлял содержимое файла в репозиторий злоумышленника.

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

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

Для агента действуют те же ограничения. Он не должен видеть секреты сборки без необходимости. Его команды нужно отделять от действий вредоносного кода.

Что сделать сейчас: проверьте рабочие станции разработчиков. Найдите ИИ-инструменты, доступ к переменным среды и токены публикации.

✅ План управления Shadow AI на практике

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

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

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

Поставьте новые интеграции на согласование. Проверяйте OAuth-права, срок токена, поставщика и передачу данных. Отдельно проверяйте встроенные функции ИИ в уже используемых SaaS.

Включите многоуровневое выявление. Смотрите на сеть, SaaS, конечные устройства, браузер и идентичности. Один источник не показывает весь контур.

Ведите журналы действий агентов. Фиксируйте запрос, использованный инструмент, объект, результат и решение о публикации. Эти данные нужны для расследования ошибки.

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

Обучайте сотрудников на коротких примерах. Покажите риск личных аккаунтов, секретов и внешних расширений. Объясните, почему одобренный сервис безопаснее полного запрета.

1. Определите владельца Shadow AI.
2. Составьте карту SaaS, агентов и токенов.
3. Разделите данные по чувствительности.
4. Создайте каталог разрешённых инструментов.
5. Ограничьте права и срок токенов.
6. Включите фильтрацию запросов и ответов.
7. Добавьте подтверждение критических действий.
8. Проводите повторную ревизию доступа.

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

Что сделать сейчас: выберите один процесс с ИИ-агентом. Пройдите по этому списку и зафиксируйте первый пробел контроля.

🔮 Безопасный агент начинается с прозрачности

ИИ-агенты не исчезают после запрета. Запрет может вытолкнуть работу в личные аккаунты и не одобренные приложения. Поэтому организация должна управлять реальным использованием.

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

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

Критические операции остаются за человеком. Система может подготовить результат, но публикация или изменение требует проверки. Это снижает цену автоматической ошибки.

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

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

Такой подход не мешает внедрению ИИ. Он задаёт границы для экспериментов и переводит полезные сценарии в управляемый корпоративный процесс.

Что сделать сейчас: проведите ревизию одного агента по пяти вопросам: кто владелец, какие данные он видит, какие права получает, что он делает и где записываются действия.

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

• Как защитить облачные контейнеры от вредных образов и атак на цепочку поставки
• Безопасность облачных платформ при интеграции внешних AI-моделей: риски и защита
• Shadow IT: инфраструктура, которой нет в реестре — риски и методы обнаружения
• Безопасный AI-код в продакшене: секреты и зависимости под контролем
• Защита корпоративных LLM от утечки данных: риски и методы защиты

📖 Термины

IAM (Identity and Access Management) · OAuth · Shadow IT (теневая ИТ-инфраструктура) · Zero Trust · Безопасность ИИ

🔗 Источники

• Shadow AI explained: risks, costs, and enterprise governance(2026-08-21 ✓)
• What Is Shadow AI? Definition, Risks, and Security Strategies(2026-08-21 ✓)
• Летальное трио агентской разработки: как ИИ-агенты открывают доступ к инфраструктуре и что с этим делать(2026-08-21 ✓)