ИИ-агенты в корпоративной сети: как взять под контроль скрытое внедрение технологий

Для команд, которые привыкли считать ROI от автоматизации и тайм-ту-маркет, это означает простую вещь: вопрос «нужен ли нам ИИ-агент» закрыт — он либо уже внедрён, либо внедряется прямо сейчас, зачастую мимо IT-отдела. Осталось решить другое: как перевести его из категории shadow AI в управляемый процесс, где понятны и сценарии использования, и уровень допустимого риска.

Что говорит телеметрия

BI.ZONE отмечает, что по признакам присутствия в инфраструктуре чаще всего встречаются Cursor (24%), Codex (24%), Copilot (17%) и Claude Code (8%). Но если смотреть не на «установлено ли», а на «реально ли работает», картина переворачивается: в топ-5 активных агентов входят Codex (54%), Claude Code (13%), Cursor (12%), Zed (9%) и OpenCode (9%). Именно это расхождение — самое ценное наблюдение для руководителя: наличие инструмента на рабочей станции ещё не означает, что команда его освоила, а значит, и риски от него никто толком не просчитал.

Сценарий, который уже произошёл

В одном из расследований BI.ZONE SOC аналитики увидели, как пользователь применял ИИ-агента для запуска задач на чужих машинах — агент самостоятельно разворачивал наступательные утилиты и выполнял команды в целевых системах от имени сотрудника. Для службы безопасности это меняет привычную логику расследования: нужно отделить действия самого человека от того, что агент инициировал автономно, иначе картина инцидента просто не сходится. Похожий риск несёт и shadow AI — плагины и агентские компоненты, которые сотрудник поставил себе сам, не поставив в известность ни IT, ни кибербез. По сути это новый класс корпоративных инструментов: они сами принимают решения, сами ходят во внешние сервисы и сами забирают доступ к репозиториям, облачным платформам и внутренним документам.

Где споткнуться и что отслеживать

Прежде чем выдавать агенту права, имеет смысл пройтись по сценарию, который мы обычно используем в похожих внедрениях. Сначала — инвентаризация: какие ИИ-инструменты и связанные с ними компоненты реально работают в вашем периметре, а не просто числятся в реестре установленного софта; здесь помогает телеметрия EDR, как это делает BI.ZONE SOC, плюс описания типовых мисконфигураций на портале киберразведки. Затем — матрица доступов: кому и к какому репозиторию, облаку или API агент действительно нужен, а где можно ограничиться read-only. Дальше — разделение процессов: какие действия инициирует сотрудник, какие запускает агент, и где проходит граница, за которой автономность превращается в слепую зону для безопасников. И, наконец, тот же подход, что и при подборе беговых кроссовок под вес тела: инструмент должен соответствовать задаче и нагрузке, а не наоборот — иначе и эффективность процесса падает, и риск растёт.

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