Теневой ИИ в компании ищут в рабочих доступах, а не только в браузере сотрудника

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

Локальная LLM оставляет документы внутри компании только при закрытом пути обработки.

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

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

Риск передачи исходного кода агенту оценивают по маршруту файлов, запросов и журналов.

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

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

Например, помощнику для чтения задачи нужен доступ к её тексту. Токен, которым можно удалить проекты или изменить рабочую базу, для этого избыточен. OWASP относит лишние функции, права и автономию к риску Excessive Agency.

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

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

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

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

Маскирование в журнале полезно, но не даёт гарантии: документация GitHub Actions прямо предупреждает об этом. Важно, чтобы утилита не печатала секрет, а процесс без необходимости его не получал.

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

Проверяйте область действия каждой защиты. В документации Claude Code на 7 октября 2026 изоляция команд описана отдельно от файловых инструментов, MCP-серверов и хуков, служебных скриптов агента. Значит, надпись «песочница включена» ещё не отвечает, чем ограничен весь запуск.

Запись «не читай секреты» помогает объяснить задачу, но не забирает право чтения. Правила для ИИ-агентов нужны вместе с техническими ограничениями: разрешение проверяет система, которая исполняет действие.

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

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

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

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

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

Корпоративный ChatGPT Enterprise оценивают по рабочим задачам и правилам доступа к данным.

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

Если разработку некому вести внутри, на /services мы предлагаем выполнение очереди задач с приёмкой. Репозиторий и доступы согласовываются до работы. Это дверь в разработку под управлением инженера; клиентского кейса аудита теневого ИИ у нас нет.

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

2. Проверяйте окружение и вывод команд, даже если в репозитории нет секретов.

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

4. Повторяйте затронутые проверки после изменения инструмента, токена или способа запуска.