1 сентября 2026 года The New Stack выпустил колонку с неприятным, но точным тезисом: теневой ИТ больше не прячется в забытых SaaS-подписках, теперь он разворачивается прямо в корпоративном облаке. Для русскоязычной IT-аудитории это звучит особенно знакомо: один инженер, AI-агент, полдня работы, и у компании уже есть внутренний сервис, который никто не согласовывал, но который уже ходит в продовые данные.
Как пишет The New Stack, раньше сценарий был сравнительно понятным. Кто-то в маркетинге или другой бизнес-команде подключал сторонний сервис к Google Workspace, а первым сигналом для безопасности становился несанкционированный OAuth grant. Это раздражало, но хотя бы хорошо ловилось: по SSO-аномалиям, сетевому трафику, отчетам по расходам или журналам доступа. В новой версии проблемы ничего подобного может не быть. Приложение собирается с помощью AI-агента, инфраструктура поднимается в облачном аккаунте самой компании, а выглядит все абсолютно легитимно: сотрудник настоящий, доступы настоящие, инструменты разрешенные.
Автор материала, Энди Гомбар, Staff Detection & Response Engineer в Webflow, формулирует сдвиг довольно жестко: мы переходим от SaaS sprawl к code sprawl. И в этой формулировке нет журналистского драматизма ради драматизма. Если раньше теневой ИТ в основном жил снаружи корпоративного контура, то теперь он живет внутри. Такой сервис может получить IAM-роль, доступ к внутренним API, продовым таблицам, облачным ресурсам и секретам. Он не выглядит как что-то чужое или явно подозрительное. Это не случайный внешний сервис, который можно быстро отключить. Это код, который уже работает у вас в инфраструктуре и делает ровно то, ради чего его и запустили.
Самый показательный момент в колонке связан не с техникой, а с мотивацией. Гомбар отдельно подчеркивает: в отличие от классического shadow IT, здесь чаще нет намерения обойти правила. Инженер не пытается спрятаться от безопасности или ускорить закупку мимо IT-отдела. Он просто хочет быстро решить локальную задачу команды. AI-агент снимает трение, пишет код, генерирует программы для Pulumi, поднимает инфраструктуру и доводит идею до рабочего состояния быстрее, чем успевает среагировать любой процесс ревью. Проблема в том, что часть этого трения раньше была не бюрократией, а встроенной защитой. Пока человек вручную собирал сервис, оформлял доступы и ждал согласования, в процесс хотя бы успевали вмешаться те, кто думает про поверхность атаки, сетевые правила и избыточные привилегии.
Гомбар описывает и вполне реалистичный инцидентный сценарий. Инженер делает небольшой внутренний инструмент для автоматизации рутинной задачи, просит AI-агента заняться инфраструктурой, агент создает ресурсы в AWS-аккаунте команды, открывает нужные порты и выкатывает приложение. Команда довольна: все работает, ручной процесс исчез, KPI не пострадали. Никакого тикета не появляется, потому что для автора сервиса формально не было повода его заводить. Через шесть недель CSPM находит публичный endpoint с чрезмерно привилегированной IAM-ролью. На этом этапе речь уже не про учебный пример из презентации, а про нормальный operational risk: если такую точку кто-то заметит извне, сценарий с lateral movement перестает быть теорией. Намерения были хорошими, а радиус поражения получился вполне взрослый.
Для разработчиков и платформенных команд здесь неприятна именно разница между старой и новой моделью обнаружения. Инструменты, заточенные под SaaS-хаос, не очень помогают против AI-собранных внутренних сервисов. OAuth-логи ничего не покажут, сетевой след будет выглядеть штатно, сотрудник не скрывался и не использовал запрещенный стек. Иначе говоря, теневой ИТ перестает быть историей про «чужой сервис в обход политики» и становится историей про «свой сервис без нормальной инженерной рамки». Отсюда и главный вывод: проблему нельзя решить одним запретом. Если разработчик за час может получить рабочий сервис из текстового запроса, то процесс, который требует три формы, два согласования и неделю ожидания, просто проиграет по умолчанию.
Рецепт у автора не магический, зато практичный. Цель не в том, чтобы затормозить инженеров, а в том, чтобы безопасный путь оказался самым простым. Для этого нужны базовые платформенные ограничения, которые делают корректную конфигурацию вариантом по умолчанию; процессные контроли, чтобы человек с security-контекстом видел изменения до продакшена; и слой детекта на случай, если что-то все же проскочило. Гомбар отдельно пишет, что awareness тоже работает как превентивная мера: если на онбординге объяснить, какие проверки обязательны и почему они вообще существуют, часть проблем исчезнет еще до деплоя. При этом он не предлагает собирать отдельную армию AppSec-инженеров. Его модель скорее про распределенную ответственность: низкорисковые инструменты может смотреть инженер с базовым security-контекстом, а все, что касается облачной инфраструктуры, прямого доступа к данным или нетривиальной эскалации IAM, должно уходить на формальный security review.
Для российского рынка и вообще для любой команды, где любят скорость и автономию, вывод довольно неприятный: AI не просто ускоряет разработку, он отменяет прежние естественные тормоза. Поэтому спор уже не о том, разрешать ли vibe coding внутри компании, а о том, успеют ли внутренние правила, шаблоны инфраструктуры и контрольные точки адаптироваться быстрее, чем очередной «маленький полезный сервис» дорастет до полноценной дыры в проде. В этом смысле новый теневой ИТ опасен не тем, что он тайный, а тем, что он выглядит нормой до самого момента, когда безопасность приходит с вопросом, почему этот endpoint вообще открыт миру.