AI-агенты стали источником инцидентов для 42% организаций
Изображение: recraft
Эксперты компании «Информзащита» выявили тенденцию роста инцидентов безопасности, связанных с использованием AI-агентов в корпоративной среде: в 2026 году с такими событиями столкнулись 42% организаций против 31% годом ранее. По оценке специалистов, рост связан с тем, что компании стали чаще выводить 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-эксфильтрации данных через скрытую инструкцию в письме, без действий пользователя. Отдельный класс рисков иллюстрируют инциденты с агентами разработки: задокументированы случаи, когда автономный кодинговый агент за секунды удалял рабочие базы данных и резервные копии, реагируя на типовую техническую ошибку.
«Компания может видеть выполнение задачи, но не видеть всю цепочку решений, которая к ней привела. В 2026 году мы ожидаем, что число инцидентов будет расти прежде всего там, где агенты внедряются быстрее, чем появляются владельцы, журналы действий и правила остановки», – комментирует Анатолий Песковский, директор Департамента наступательной безопасности компании «Информзащита».
По рекомендациям экспертов, компаниям необходимо вести полный реестр агентов, фиксировать владельца каждого сценария, ограничивать права по принципу минимально необходимого доступа, разделять доступ к данным и действиям, контролировать использование токенов и сервисных учетных записей, а также внедрять журналирование на уровне промптов, инструментов, API-вызовов и итоговых операций. Для сценариев с доступом к персональным данным, финансовой информации, исходному коду и производственным системам нужен отдельный процесс согласования, тестирование на prompt injection и регулярная проверка фактических полномочий. Дополнительный слой защиты дают runtime-политики: ограничение списка доступных инструментов и внешних доменов, обязательное подтверждение операций с высоким риском, изоляция секретов от контекста модели, выполнение действий агента в изолированной среде (sandboxing) и заранее настроенный механизм принудительной остановки – kill switch на уровне платформы оркестрации. Отдельным направлением становится инвентаризация и управление нечеловеческими идентичностями (NHI): каждому агенту присваивается собственная учетная запись с уникальными правами, отделенная от учетных записей разработчиков и сервисных аккаунтов общего назначения. Параллельно формируется практика «надзорных агентов» (guardian agents), которые в реальном времени отслеживают поведение основных агентов и блокируют действия, выходящие за установленные политики. Практика показывает, что наибольший эффект дает связка инвентаризации, runtime-контроля, DLP, мониторинга аномального поведения и заранее описанных процедур отключения агента при выходе за допустимый контур. Без такой дисциплины автономность агентов начинает работать против бизнеса: скорость операций растет, но вместе с ней увеличивается окно, в котором ошибка агента или точная атака превращается в полноценный инцидент. «Информзащита» рекомендует встраивать AI-агентов в стандартные циклы управления уязвимостями, инцидентами и доступом с самого начала проекта, а не после первого инцидента: издержки на «догоняющий» контроль, по нашим наблюдениям, кратно превышают стоимость превентивного внедрения.
