Более 2000 корпоративных AI-приложений оказались доступны из открытого интернета без нормальной защиты, а часть из них фактически отдавала админ-доступ любому, кто знает URL. Для русскоязычной IT-аудитории это неприятный, но полезный сигнал: теневой ИИ больше не сводится к копипасте в чат-боты, теперь сотрудники с помощью AI собирают рабочие сервисы, подключают их к боевым системам и публикуют наружу быстрее, чем служба ИБ успевает открыть тикет.
О находке сообщает The Hacker News со ссылкой на исследование The Shadow Builders от компании Red Access. Авторы утверждают, что изучили более 380 тысяч публично доступных веб-активов на крупных платформах для vibe-кодинга, то есть AI-сервисах, где приложение можно собрать по текстовому описанию. Из этого массива около 5000 активов выглядели корпоративными, а свыше 2000 содержали чувствительные корпоративные, операционные или персональные данные. География, по данным исследования, охватывает шесть континентов, а уязвимые экземпляры нашлись в компаниях из разных отраслей. Самая неприятная деталь: для доступа, как утверждается, не требовалась эксплуатация сложных багов. Во многих случаях хватало просто открыть опубликованный адрес.
Это и есть новый теневой ИИ, который выходит за привычную рамку «сотрудник отправил лишнее в ChatGPT». Теперь артефакт меняется: вместо одного промпта появляется готовый продукт. Маркетолог собирает трекер кампаний и цепляет к BI-системе с реальными показателями. Операционный менеджер делает форму для онбординга подрядчиков и связывает ее с тикетингом. Финансовая команда быстро клепает дашборд для совета директоров и подтягивает туда инвойсы. Все это выглядит как обычная оптимизация рутины, и именно поэтому история опаснее классического Shadow IT. Раньше команда могла тихо купить сторонний SaaS, но данные хотя бы жили внутри понятного вендора с идентификацией, логами и хоть каким-то контуром управления. Здесь же приложение собирается на лету, данные заливаются вручную или через API, интеграции идут напрямую в CRM, ERP, BI и другие системы учета, а результат нередко публикуется в открытый интернет.
Отдельный дискомфорт для ИБ в том, что большая часть привычного стека эту картину видит кусками. EDR замечает браузер, но не понимает смысл того, что пользователь собрал внутри вкладки. Для агента на ноутбуке поведение выглядит почти так же, как чтение новостей или работа в обычном веб-сервисе. DLP умеет ловить перечисленные каналы и может среагировать, если сотрудник вставляет регулируемые данные в известный AI-чат, но не видит, как vibe-приложение программно тянет данные из санкционированной BI-системы через API, то есть гоняет информацию облако-в-облако вообще в обход endpoint. CASB исторически проектировался под Shadow IT в форме внешних SaaS-сервисов, а не под бесконечное число кастомных приложений на субдоменах AI-платформы. В итоге вся эта масса может выглядеть как один «разрешенный» поставщик. Firewall и SSE, в свою очередь, видят трафик до домена платформы, но не видят бизнес-смысл конкретного приложения.
Еще один неприятный вывод касается управляемости устройств. Даже там, где современные EDR, enterprise browser или SASE-развертывания дают более глубокую телеметрию, они по определению ограничены корпоративными ноутбуками и управляемыми браузерами. Личный ноутбук сотрудника, машина подрядчика, BYOD-сценарий или просто личная вкладка в неподконтрольном браузере остаются слепой зоной. Поэтому компания может вполне честно проходить аудиты и держать «зеленую» карту по средствам защиты, пока рядом уже живут опубликованные AI-приложения с чувствительными данными. Авторы исследования именно на этом и настаивают: проблема не в том, что конкретный класс защиты вдруг стал бесполезным. Проблема в архитектурных зазорах между слоями, где сигналы есть, но не складываются в единую управляемую картину.
На этом фоне логично выглядит тезис про контроль на уровне сессии браузера. Если весь жизненный цикл такого сервиса происходит внутри веб-сессии, там же надо искать и наблюдаемость. Построение приложения, выдача OAuth-доступа к корпоративной системе, загрузка данных, подключение интеграций и кнопка Publish, которая превращает прототип в живой публичный URL, происходят в одном и том же браузерном контексте. С технической точки зрения это важное уточнение для разработчиков и архитекторов: риск возникает не только в момент доступа к данным, а в момент, когда неразработчик получает возможность быстро собрать поверх этих данных внешний интерфейс и сразу отдать его в интернет. Vibe-кодинг резко сокращает путь от идеи до продакшена, но одновременно обнуляет многие старые точки согласования.
Практический блок у Red Access, несмотря на маркетинговый интерес автора, звучит разумно и без магии. Первая мера — инвентаризация через прямой запрос к сотрудникам: не «кто нарушил политику», а «кто что уже собрал». Вторая — картирование связей: к каким корпоративным системам подключено приложение, по какой схеме идет доступ, через OAuth, API-ключ или ручную загрузку, и опубликовано ли оно наружу. Третья — создание санкционированного пути: список допустимых платформ, понятные категории данных и минимальные требования к аутентификации. Четвертая — признание того, что это не разовая кампания. Такие приложения появляются постоянно, а значит, теневой ИИ требует не квартальной проверки по чек-листу, а непрерывного обнаружения.
Для российского рынка здесь нет экзотики, только знакомый сюжет в новой обертке. Бизнес хочет скорость, сотрудники получают инструменты без порога входа, а контрольные процессы по-прежнему рассчитаны на классическую разработку, закупку SaaS или хотя бы на участие IT в архитектуре. Теперь между «сделал прототип для себя» и «вынес наружу кусок боевой системы» может пройти один рабочий день. Главный вопрос уже не в том, можно ли запретить vibe-кодинг, а в том, кто первым встроит его в нормальный контур управления: сама компания или случайный опубликованный URL, который однажды найдет не внутренний аудитор, а кто-то менее дружелюбный. Подробности исследования можно сверить в материале .