Почему риски безопасности ИИ-агентов растут из-за отсутствия контроля

Риски безопасности ИИ-агентов и утечки данных в корпоративных системах: проблема контроля, а не моделей

Компании сталкиваются не с «вредными моделями», а с потерей контроля над ИИ-агентами. На это указывают и отраслевые отчёты, включая Cloud Security Alliance: ключевая уязвимость — управление, а не алгоритмы. Несанкционированные боты, разрозненные платформы и слабые правила создают разрыв между внедрением и контролем.

Это управленческий и архитектурный сбой. Если не задать границы и роли, инциденты будут повторяться и бить по данным и операциям.

Масштаб уже измерим. Более половины компаний фиксируют выход агентов за пределы полномочий. Почти половина сталкивалась с инцидентами. При этом только треть имеет формальную политику управления ИИ, а ответственных назначают единицы. Сотрудники приносят десятки сторонних инструментов, а компании работают сразу в нескольких системах.

Это не теория. Это ежедневная практика, которая повышает риск утечек и удлиняет время обнаружения. В зоне ответственности — CISO, AppSec, ИТ‑архитекторы и руководители, отвечающие за доступы и логи. Дальше разберём, где именно ломается контроль и какие сигналы уже можно увидеть.

Где ломается контроль при внедрении ИИ

Внедрение ИИ-агентов часто воспринимают как задачу технологий. Модели тестируют, платформы дают API, а риски связывают с редкими атаками или «плохими» моделями. Кажется, что поставщики и песочницы закрывают проблему.

На практике риски безопасности ИИ-агентов и утечки данных в корпоративных системах возникают из-за отсутствия контроля. 53% компаний видят выход агентов за пределы полномочий. 47% фиксируют ИБ‑инциденты. Только 31% имеют формальную политику. Лишь 15% назначают владельцев агентов. В 54% организаций сотрудники используют от 1 до 100 несанкционированных агентов. Параллельно компании работают сразу на нескольких платформах.

Это создаёт операционные разрывы. Инциденты дольше остаются незамеченными, потому что логи и права разбросаны. Среднее время обнаружения — около шести часов. Для CISO и AppSec это постоянная нагрузка на управление доступами и мониторинг. Дальше — где именно возникает сбой и как он приводит к утечкам.

Как возникают утечки при работе ИИ-агентов

Как это работает

ИИ-агенты действуют внутри инфраструктуры, но границы часто не заданы. 95% компаний используют несколько платформ: 44% — 2–3, ещё 43% — четыре и более. Одновременно сотрудники подключают сторонние инструменты. В 54% организаций это от 1 до 100 агентов на человека.

Возникает смешанная среда. Одни агенты имеют доступ к внутренним данным, другие — вне контроля. Логи и права разделены между системами.

Агенты выполняют задачи и формируют запросы. В этих запросах часто есть чувствительные данные. Если IAM не адаптирован под агентов, они получают лишние права. Обычная интеграция превращается в канал утечки.

Отдельный риск — конкретные векторы атак. Prompt‑инъекции подменяют инструкции и заставляют агента раскрывать данные. Data exfiltration через prompts происходит, когда в запрос попадают секреты и уходят во внешние сервисы. ИИ‑сгенерированный код добавляет уязвимости: они нетипичны, поэтому их сложнее поймать сканерами.

Почему это происходит

Первая причина — нет правил. Только 31% компаний описали управление ИИ, а владельцы есть у 15%. Вопрос «кто отвечает» остаётся открытым.

Вторая — фрагментация. При работе с несколькими платформами телеметрия дробится. Следы инцидента теряются между системами.

Третья — сами инструменты меняют характер угроз. ИИ может находить использовать уязвимости, как показали примеры вроде Claude Mythos Preview. При этом сгенерированный код создаёт новые типы ошибок.

Комбинация проста: нет политики + разрозненная инфраструктура + избыточные права = рост инцидентов. Это подтверждают данные: 53% и 47%.

К чему это приводит

Инциденты становятся системными. Они не единичны, а повторяются.

Время обнаружения растёт. При разбросанных логах даже шесть часов — не предел.

AppSec‑риски усиливаются. Передача проверки «на разработчиков» не работает: новые паттерны уязвимостей ускользают.

Растут затраты. Подписки и токены увеличивают расходы. Спрос на специалистов не падает.

И главное — нет владельца. Поэтому инциденты долго живут и медленно закрываются. «Несанкционированные ИИ-агенты... становятся причиной инцидентов, которые трудно обнаружить и долго исправлять».

Что из этого следует

Риск создаёт не модель, а связка факторов: платформы, права и отсутствие правил. Снижать риск нужно через контроль: явные роли, централизованные логи и корректный IAM.

Дальше — как это проявляется в реальных сценариях.

Типовые сценарии сбоев контроля

Интеграция чата поддержки

Команда запускает чат‑агента в изолированной среде. Руководитель уверен: доступов к базе нет.

Сотрудник ускоряет ответы и даёт боту доступ к выгрузке транзакций через общий API‑ключ. Права для агента не ограничены, ключи не разделены.

Через неделю в логах появляется аномалия. Данные ушли наружу, но источник скрыт из‑за смешения платформ.

Что помогло бы: scoped API keys и раздельные токены для каждого агента, плюс аудит логов доступа.

Разработка и внешние помощники

Команда соблюдает корпоративные правила и список сервисов. Риск кажется закрытым.

Разработчик вставляет код секретами во внешний инструмент. Агент генерирует уязвимый паттерн, который попадает в репозиторий.

Через недели сканер видит странную активность в проде. Логи разбросаны, цепочку сложно собрать.

Что помогло бы: строгая IAM‑политика для секретов, запрет на вывод секретов в prompts и централизованные audit logs.

Маркетинг и CRM

Маркетолог подключает агента к CRM ради скорости.

Бот формирует запрос и случайно экспортирует базу клиентов во внешнее хранилище. Токен без ограничений, владельца нет.

Утечку замечают по отчёту партнёра. Время обнаружения увеличено из‑за разрозненных логов.

Что помогло бы: ограничение прав токена (least privilege), владелец процесса и централизованный сбор логов.

Во всех случаях проблема одна — нет чётких границ и контроля.

Почему управление снижает риск быстрее всего

Главный источник риска — управление, а не модель. Когда нет владельца и единых правил, права размываются, а логи теряются.

Это напрямую бьёт по операционным метрикам. Увеличивается время обнаружения и восстановления. Инциденты дольше живут, значит растут затраты и нагрузка на AppSec.

Песочницы и формальные процедуры не спасают, если сотрудники обходят их ради скорости. При нескольких платформах контроль распадается.

Практический вывод: снижать риск нужно через управляемость. Нужны явные владельцы, единые политики доступа и централизованные логи. Тогда мелкие автоматизации перестают быть «невидимыми» и не превращаются в инциденты.

Следующий шаг — закрепить это на уровне архитектуры.

Компании переоценивают роль моделей и недооценивают управление. В итоге контроль размывается: агенты получают лишние права, логи дробятся, ответственность не закреплена. Так формируется среда, где утечки возникают как побочный эффект нормальной работы.

Рабочее решение — сделать контроль системным. Нужны формальные политики, назначенный владелец, единый подход к IAM и централизованная телеметрия. Когда ИИ‑слой разворачивается внутри инфраструктуры и объединяет документы, RAG‑чаты и логи, контроль становится проверяемым.

Это разрывает цепочку «много платформ → разрознённые права → незамеченные инциденты». Сокращается время обнаружения, упрощается расследование и снижаются скрытые расходы.

Практический вывод: снижать риски безопасности ИИ-агентов и утечки данных в корпоративных системах нужно через архитектуру и управление. Это не ограничивает ИИ — это делает его безопасным инструментом.

Подход, где ИИ работает поверх данных внутри инфраструктуры (как в платформах класса АСПЕКТ), помогает удержать контроль: данные не покидают контур, а процессы остаются наблюдаемыми.

Частые вопросы по безопасности ИИ-агентов