AI-агенты стали источником инцидентов для 42% организаций

По оценке специалистов, рост связан с тем, что компании стали чаще выводить AI-агентов за пределы пилотных проектов – в ИТ, инженерные команды, клиентский сервис, безопасность, закупки и внутренние операционные процессы. Данные опроса фиксируют, что 58% респондентов указывают, что обнаружение и реагирование занимает более пяти часов. Основная причина задержки – отсутствие сквозного журналирования цепочки решений агента: команда видит итоговое действие, но не видит, какой промпт, какой инструмент и какие данные привели к этому действию. Российская динамика согласуется с глобальным трендом, но пока отстает по проявлениям.

Главная сложность в том, что AI-агент отличается от обычного чат-бота или аналитического инструмента. Он использует API, создает задачи, редактирует документы, запускает скрипты, пересылает данные, подключается к CRM, SIEM, тикетным системам и репозиториям. При недостаточной настройке прав такой агент начинает действовать шире, чем предполагали владельцы процесса. Около 53% организаций сталкивались с ситуациями, когда AI-агенты превышали заданные полномочия, например, обращались к учетным записям и хранилищам, не входившим в исходную задачу.

На динамику 2026 года повлияла децентрализация внедрения. Только 5% компаний используют единую платформу для AI-агентов, тогда как 44% работают сразу с двумя-тремя платформами, а 43% – с четырьмя и более. Внутренний контроль при такой модели быстро теряет полноту: часть агентов создается бизнес-подразделениями без согласования с ИБ, часть появляется в рамках low-code-сценариев, часть подключается к SaaS-сервисам через личные или групповые токены, нередко с избыточными правами на запись. Отдельная техническая проблема состоит в том, что AI-агент с точки зрения целевых систем выглядит как обычная учетная запись, при этом ни инструменты IAM, ни процессы согласования доступа изначально не проектировались под нечеловеческие идентичности с автономным поведением. По данным исследований, организации, последовательно применяющие принцип минимально необходимого доступа к AI-агентам, фиксируют инциденты в 17% случаев, против 76% у компаний без такой практики – это самое крупное единичное снижение риска среди всех контролируемых мер. Дополнительный фактор риска – появление в 2025-2026 годах открытых протоколов взаимодействия агентов с инструментами (Model Context Protocol, MCP) и между собой (Agent-to-Agent, A2A): они ускоряют интеграцию, но создают новый слой доверительных отношений, которым по умолчанию не управляет ни одна классическая система защиты. По оценке «Информзащиты», в компаниях с численностью от 1000 сотрудников доля неинвентаризированных AI-агентов в 2026 году достигает 27%, а в организациях с активным использованием low-code и no-code платформ – до 39%. Это не всегда прямое нарушение политики, но именно такие зоны чаще становятся источником утечек, ошибочных действий и неконтролируемого обмена данными.

Разбивка по векторам атак показывает, что наиболее заметную долю занимают злоупотребления правами и выход за пределы разрешенного сценария – 31% выявленных событий. В декабре 2025 года OWASP выпустила отдельный Top 10 for Agentic Applications, ASI (Top 10 для агентных приложений), в котором классические LLM-риски переосмыслены под автономное исполнение: prompt injection (инъекция в запрос) превращается в Agent Goal Hijack (перехват цели агента), excessive agency (избыточные полномочия) – в вектор privilege escalation (эскалации привилегий), data poisoning (отравление данных) – в memory poisoning (долговременную порчу памяти агента). Структура инцидентов, фиксируемая «Информзащитой», соответствует этой классификации. На prompt injection и подмену инструкций приходится 24%, на утечки через подключенные коннекторы и корпоративные хранилища – 18%, на shadow AI-агентов без владельца и формального учета – 14%, на компрометацию токенов, API-ключей и сервисных учетных записей – 9%, на атаки через сторонние плагины и цепочки поставки – 4%.

Наиболее уязвимыми оказались финансовые организации, на которые приходится 26% зарегистрированных инцидентов с AI-агентами. В зоне повышенного риска также находятся ИТ- и телеком-компании с долей 21%, промышленность и энергетика – 17%, ритейл и e-commerce – 14%, медицинские и фармацевтические организации – 11%, логистика и транспорт – 7%, профессиональные услуги и консалтинг – 4%. Финансовый сектор лидирует из-за высокой плотности интеграций, большого числа регуляторных требований и активного использования автоматизации в антифроде, клиентской поддержке и обработке документов. В ИТ и телекоме риск усиливается из-за доступа агентов к репозиториям, CI/CD и системам управления инфраструктурой. В промышленности проблема чаще связана с подключением AI-инструментов к данным мониторинга, техдокументации и сервисным контурам.

Картину 2026 года уже сформировали несколько публично раскрытых инцидентов. В апреле 2026 года компания Vercel подтвердила компрометацию через сторонний AI-инструмент Context.ai с ущербом около $2 млн, развивавшуюся по классическому supply-chain-сценарию: от личного аккаунта сотрудника в AI-сервисе, к корпоративному Google Workspace и далее к внутренним средам. Уязвимость EchoLeak в Microsoft 365 Copilot (CVE-2025-32711) показала возможность zero-click-эксфильтрации данных через скрытую инструкцию в письме, без действий пользователя. Отдельный класс рисков иллюстрируют инциденты с агентами разработки: задокументированы случаи, когда автономный кодинговый агент за секунды удалял рабочие базы данных и резервные копии, реагируя на типовую техническую ошибку.

По рекомендациям экспертов, компаниям необходимо вести полный реестр агентов, фиксировать владельца каждого сценария, ограничивать права по принципу минимально необходимого доступа, разделять доступ к данным и действиям, контролировать использование токенов и сервисных учетных записей, а также внедрять журналирование на уровне промптов, инструментов, API-вызовов и итоговых операций. Для сценариев с доступом к персональным данным, финансовой информации, исходному коду и производственным системам нужен отдельный процесс согласования, тестирование на prompt injection и регулярная проверка фактических полномочий. Дополнительный слой защиты дают runtime-политики: ограничение списка доступных инструментов и внешних доменов, обязательное подтверждение операций с высоким риском, изоляция секретов от контекста модели, выполнение действий агента в изолированной среде (sandboxing) и заранее настроенный механизм принудительной остановки – kill switch на уровне платформы оркестрации. Отдельным направлением становится инвентаризация и управление нечеловеческими идентичностями (NHI): каждому агенту присваивается собственная учетная запись с уникальными правами, отделенная от учетных записей разработчиков и сервисных аккаунтов общего назначения. Параллельно формируется практика «надзорных агентов» (guardian agents), которые в реальном времени отслеживают поведение основных агентов и блокируют действия, выходящие за установленные политики. Практика показывает, что наибольший эффект дает связка инвентаризации, runtime-контроля, DLP, мониторинга аномального поведения и заранее описанных процедур отключения агента при выходе за допустимый контур. Без такой дисциплины автономность агентов начинает работать против бизнеса: скорость операций растет, но вместе с ней увеличивается окно, в котором ошибка агента или точная атака превращается в полноценный инцидент. «Информзащита» рекомендует встраивать AI-агентов в стандартные циклы управления уязвимостями, инцидентами и доступом с самого начала проекта, а не после первого инцидента: издержки на «догоняющий» контроль, по нашим наблюдениям, кратно превышают стоимость превентивного внедрения.