65,4% агентных чат-ботов в компаниях вообще ни разу не использовались после создания, но их учетные данные и доступы продолжают жить своей жизнью. Именно поэтому теневой ИИ теперь выглядит не как старая история про утечки в публичные чат-боты, а как новая версия классической проблемы с access control: в инфраструктуре уже работают агенты, которым кто-то когда-то выдал слишком много прав.
Об этом сообщает The Hacker News: главный риск сместился с вопроса «что сотрудник вставил в ИИ-инструмент» на вопрос «какие ИИ-агенты вообще запущены в компании, к чему они подключены и что им разрешено делать». Для русскоязычных команд это звучит болезненно знакомо. Если разработчик или продуктовая команда за вечер собирает агента, который ходит в GitHub, Slack, CRM и облако, проблема начинается не в момент промпта, а в момент выдачи токена, OAuth-доступа или сервисной учетной записи.
Логика первой волны защиты была довольно прямолинейной. Сотрудники копировали чувствительные данные в публичные AI-сервисы, а безопасники отвечали политиками использования, блокировкой доменов и DLP-правилами. На этапе, когда ИИ был в основном «умным текстовым окном», это работало. Но агентный ИИ быстро вышел из роли пассивного помощника. Теперь это не просто интерфейс, куда что-то вставляют, а исполняющий механизм, который умеет вызывать API, читать записи, менять конфигурации, запускать пайплайны и дергать downstream-процессы без отдельного ручного подтверждения на каждом шаге.
В этом и состоит принципиальная разница между старым shadow IT и тем, что авторы называют shadow AI. Несанкционированный SaaS обычно был местом, куда данные утекали или где они хранились вне контроля компании. Агент же сам становится действующим лицом. В статье приводят показательный набор интеграций: кастомный ИИ-агент может быть подключен к Salesforce, Snowflake, GitHub, Gong и Slack одновременно. В таком виде это уже не просто риск раскрытия данных. Такой агент способен читать, записывать и удалять данные, менять настройки в проде, открывать тикеты, триггерить автоматизации и продолжать все это делать месяцами, даже если создатель давно перешел в другую команду или уволился.
Отдельная неприятность в том, что существующие средства контроля в компаниях проектировались под людей и предсказуемые сценарии. IAM-политики, DLP и сетевой мониторинг предполагают понятные роли, детерминированное поведение и фиксированные точки доступа. Агентный ИИ ломает эту модель. Если агенту поручили разрулить неудачный деплой, он может последовательно прочитать логи, сходить в систему мониторинга, поправить инфраструктурную конфигурацию, открыть инцидент и уведомить инженеров. Все это с одними и теми же унаследованными правами. Чтобы не тормозить процесс, разработчики часто дают доступ «с запасом». Потом этот запас становится постоянным, а команды безопасности теряют видимость не только по перечню агентов, но и по фактическим действиям, которые выполняют эти нечеловеческие идентичности.
Именно здесь The Hacker News ссылается на исследование Token Security и Cloud Security Alliance. Авторы предлагают довольно приземленный чек-лист из шести вопросов, который выглядит полезнее большинства абстрактных рамок про AI governance. Где вообще создаются и ставятся агенты: в санкционированных AI-платформах, браузерных расширениях, SaaS-функциях, локальных девтулзах или внутренних приложениях? Кто владелец агента и кто имеет право им пользоваться? К каким системам и сервисам он подключен? Какие идентичности и секреты он использует: API-ключи, сервисные аккаунты, OAuth-токены, облачные IAM-роли? Что агент должен делать по замыслу и что он уже реально делал? И, наконец, остается ли он активным. Последний пункт особенно важен, потому что те самые 65,4% неиспользуемых агентных чат-ботов с живыми доступами выглядят как идеальная точка для тихого накопления риска.
Для разработчиков тут неприятная правда в том, что агент почти неизбежно наследует архитектурные грехи окружающей системы. Если в компании и без ИИ было принято раздавать сервисным аккаунтам права «на всякий случай», с агентами это масштабируется мгновенно. Для ИТ-директоров и безопасников вывод еще жестче: блокировка публичных AI-доменов больше не решает задачу. Когда агент уже получил креды к корпоративным системам, периметр давно пройден. Значит, нужно не запрещать ИИ как класс, а строить инвентаризацию агентов, назначать владельцев, ограничивать права по минимуму и автоматизировать отзыв доступов у неактивных сущностей. Иначе бизнес будет получать обещанную продуктивность, а ИБ — новый слой непрозрачных сервисных идентичностей, которые никто толком не администрирует.
Для рынка это еще и симптом более широкого сдвига. ИИ в компаниях все чаще внедряется не как отдельный продукт, а как функция внутри знакомых платформ, IDE, облачных панелей и корпоративных SaaS. Из-за этого теневой ИИ прячется не на виду: не в экзотическом стартап-сервисе, а в обычной кнопке automation, расширении для браузера или внутреннем скрипте, который «временно» собрали под задачу отдела. Чем быстрее организации переходят от разговоров про генерацию текста к реальным агентам с правом действия, тем ближе ИИ-безопасность становится к старому доброму identity security. Вопрос уже не в том, утекают ли данные в чат-бот. Вопрос в том, сколько автономных исполнителей с избыточными правами уже работают внутри вашей инфраструктуры и кто вообще помнит, зачем им эти права выдавали. Подробнее об исходном материале можно прочитать в .