AI-компоненты выходят в интернет быстрее, чем компании успевают их учесть
AI-сервисы стали достаточно простыми, чтобы их запускали не только ИТ-отделы. Команда маркетинга может собрать автоматизацию в n8n, разработчик — развернуть интерфейс для локальной модели, а основатель стартапа — опубликовать прототип, созданный с помощью AI-инструментов. Через несколько дней такой проект уже работает, получает доступ к данным и воспринимается как часть бизнеса.
Проблема начинается, когда компания не знает, где именно он находится, кто им управляет и что произойдёт после компрометации.
По данным исследования Censys, опубликованного 14 октября 2026 года, за девять месяцев число интернет-доступных систем, связанных с AI, выросло на 63% — почти до 268 тысяч. В эту оценку вошли не только чат-боты и серверы языковых моделей, но также платформы автоматизации, интерфейсы, шлюзы и компоненты, связывающие модели с корпоративными приложениями.
Самым распространённым продуктом среди обнаруженных систем оказался n8n: исследование выявило почти 114 тысяч таких хостов. Ещё около 54 тысяч пришлось на OpenClaw. В число часто встречающихся компонентов также вошёл Open WebUI — интерфейс для работы с AI-моделями.
Эти цифры показывают масштаб доступной инфраструктуры, но сами по себе не доказывают, что все найденные системы уязвимы или уже подвергались атакам. Важен другой вывод: значительная часть AI-поверхности сосредоточена вокруг нескольких популярных инструментов, а значит, ошибки их настройки могут повторяться в тысячах компаний.
Почему панель автоматизации опаснее забытого веб-сервиса
Открытый веб-сервис может содержать устаревшую форму, тестовую страницу или административную панель. AI-компонент часто представляет собой не просто страницу, а узел в цепочке действий.
Например, рабочий процесс в n8n может:
- читать входящие письма и документы;
- обращаться к CRM и внутренним базам;
- запускать скрипты по расписанию;
- отправлять сообщения клиентам или сотрудникам;
- создавать сделки и изменять записи;
- передавать данные внешней языковой модели;
- работать с ключами API и сервисными аккаунтами.
Если административный интерфейс такой системы доступен из общего интернета, атакующий получает потенциальный путь не к одной функции, а ко всей цепочке автоматизации. Риск зависит от настроек, версии продукта, качества аутентификации и выданных прав, поэтому нельзя утверждать, что любой открытый экземпляр автоматически скомпрометирован. Но сама архитектура делает последствия ошибки существенно серьёзнее.
В исследовательских материалах упоминаются уязвимости OpenClaw, позволявшие выполнять произвольный код на хост-машине, и проблемы n8n, связанные с чтением файлов. Наличие подобных уязвимостей не означает, что ими воспользовались против каждого пользователя. Оно показывает, почему публикация административных интерфейсов без дополнительных ограничений — плохая практика.
Быстрый прототип превращается в shadow IT
Новая инфраструктурная проблема возникает на пересечении двух процессов.
Первый — распространение AI-разработки. Сотрудники и небольшие команды создают приложения быстрее, чем раньше, часто без полноценного цикла проектирования, ревью и сопровождения.
Второй — подключение этих приложений к реальным данным и внешним сервисам. Прототип перестаёт быть экспериментом, когда получает доступ к почте, CRM, хранилищу документов или платёжному API.
Исследование 200 публично доступных приложений, созданных преимущественно с помощью AI-инструментов, обнаружило хотя бы одну уязвимость в 91% случаев. В 65,77% выявленных проблем оценка была critical или high. Чаще всего встречались ошибки контроля доступа, инъекции и проблемы аутентификации.
Эти показатели нельзя переносить на весь рынок: выборка была связана с двумя конкретными инструментами, а часть проблем выявлялась автоматизированным аудитом с последующей проверкой специалистами. Однако результат хорошо иллюстрирует механизм: AI снижает стоимость создания приложения, но не отменяет необходимость проверять его безопасность.
В итоге компания может получить десятки компонентов, которые никто официально не заносил в реестр. Один был создан для демонстрации клиенту, другой — для внутренней рассылки, третий — для обработки документов. Через полгода все они продолжают работать, имеют доступ к данным и не закреплены за конкретным владельцем.
С чего начать аудит
Полноценная защита требует участия ИТ и специалистов по безопасности, но базовую инвентаризацию можно начать с управленческого вопроса: какие системы способны читать наши данные или выполнять действия от имени компании?
1. Найти публичные компоненты
Составьте список внешних IP-адресов, облачных аккаунтов, поддоменов и серверов. Отдельно проверьте панели n8n, Open WebUI, серверы моделей, прокси, плагины и внутренние приложения, опубликованные для тестирования.
Важно искать не только то, что зарегистрировано в официальном каталоге ИТ. Информацию могут дать журналы DNS, облачные консоли, корпоративные VPN, системы управления устройствами и отделы, которые запускали эксперименты с AI.
2. Составить карту полномочий
Для каждого компонента зафиксируйте владельца, назначение, подключённые данные, API и сервисные аккаунты. Отметьте, какие операции выполняются автоматически, а какие требуют подтверждения человека.
Особое внимание стоит уделить ключам с широкими правами. Если автоматизация может читать всю CRM или отправлять сообщения без проверки, её нужно рассматривать как полноценную бизнес-систему, а не как удобный скрипт.
3. Закрыть административные интерфейсы
Панель управления не должна быть доступна из общего интернета без необходимости. Для таких интерфейсов нужны VPN или identity-aware proxy, многофакторная аутентификация, сетевые ограничения и отдельные учётные записи для администрирования.
4. Ввести контроль изменений
Перед публикацией AI-приложения проверяйте зависимости, секреты, авторизацию и права доступа. После запуска нужны журналы действий, регулярное обновление компонентов и понятный способ быстро остановить автоматизацию.
Вывод
AI-инфраструктура стала отдельным корпоративным периметром. Она включает не только модели, но и панели автоматизации, интерфейсы, шлюзы, прототипы и соединения с бизнес-системами.
Главная ошибка — считать эксперимент временным только потому, что его собрали быстро. Если приложение доступно из интернета и имеет доступ к данным, оно уже является частью инфраструктуры. Компании, которые начнут учитывать такие компоненты сейчас, получат не запрет на эксперименты, а управляемый способ развивать их без потери контроля.
