Новость
Эксперты компании «Информзащита» зафиксировали устойчивый рост числа происшествий в области информационной безопасности, связанных с применением ИИ-агентов в корпоративной среде. В 2026 году с такими инцидентами столкнулись 42% организаций, тогда как годом ранее этот показатель составлял 31%.
По мнению аналитиков, увеличение связано с тем, что компании активнее выводят ИИ-агентов за рамки пилотных проектов — они внедряются в ИТ, инженерные подразделения, клиентский сервис, службы безопасности, закупки и внутренние операционные процессы. Результаты опроса показывают: 58% респондентов признают, что на обнаружение и реакцию уходит более пяти часов. Главная причина задержек — отсутствие сквозного логирования цепочки решений агента. Команда видит итоговое действие, но не может проследить, какой промпт, какой инструмент и какие данные к нему привели. Российская динамика повторяет глобальный тренд, хотя пока отстает по масштабу проявлений.
Ключевая сложность в том, что ИИ-агент принципиально отличается от обычного чат-бота или аналитического инструмента. Он работает через API, создает задачи, редактирует документы, запускает скрипты, пересылает данные, подключается к CRM, SIEM, системам тикетинга и репозиториям. При недостаточно точной настройке прав такой агент начинает действовать шире, чем предполагали владельцы процесса. Около 53% организаций сталкивались с ситуациями, когда ИИ-агенты превышали выданные полномочия — например, обращались к учетным записям и хранилищам, не входившим в исходную задачу.
На динамику 2026 года повлияла децентрализация внедрения. Лишь 5% компаний используют единую платформу для ИИ-агентов, тогда как 44% работают сразу с двумя-тремя платформами, а 43% — с четырьмя и более. При такой модели внутренний контроль быстро утрачивает полноту: часть агентов создается бизнес-подразделениями без ведома службы ИБ, часть появляется в рамках low-code-сценариев, часть подключается к SaaS-сервисам через личные или групповые токены, нередко с избыточными правами на запись. Отдельная техническая проблема состоит в том, что с точки зрения целевых систем ИИ-агент выглядит как обычная учетная запись, при этом ни инструменты IAM, ни процессы согласования доступа изначально не рассчитаны на нечеловеческие идентичности с автономным поведением. Согласно исследованиям, организации, последовательно применяющие принцип минимально необходимого доступа для AI-агентов, фиксируют инциденты в 17% случаев против 76% у компаний без такой практики — это самое значительное единичное снижение риска среди всех контролируемых мер. Дополнительный фактор риска — появление в 2025–2026 годах открытых протоколов взаимодействия агентов с инструментами (Model Context Protocol, MCP) и между собой (Agent-to-Agent, A2A): они ускоряют интеграцию, но создают новый слой доверительных отношений, которым не управляет ни одна классическая система защиты. По оценке «Информзащиты», в компаниях с численностью от 1 тыс. сотрудников доля неинвентаризированных ИИ-агентов в 2026 году достигает 27%, а в организациях с активным использованием low-code и no-code платформ — до 39%. Это не всегда прямое нарушение политик, но именно такие зоны чаще всего становятся источником утечек, ошибочных действий и неконтролируемого обмена данными.
Разбивка по векторам атак показывает, что самую заметную долю занимают злоупотребления правами и выход за пределы разрешенного сценария — 31% выявленных событий. В декабре 2025 года OWASP выпустила отдельный документ «10 главных угроз для агентных приложений», в котором классические LLM-риски переосмыслены в контексте автономного исполнения: prompt injection (инъекция в запрос) превращается в Agent Goal Hijack (перехват цели агента), excessive agency (избыточные полномочия) — в вектор privilege escalation (эскалации привилегий), data poisoning (отравление данных) — в memory poisoning (долговременную порчу памяти агента). Структура инцидентов, фиксируемая «Информзащитой», соответствует этой классификации. На prompt injection и подмену инструкций приходится 24%, на утечки через подключенные коннекторы и корпоративные хранилища — 18%, на shadow ИИ-агентов без владельца и формального учета — 14%, на компрометацию токенов, API-ключей и сервисных учетных записей — 9%, на атаки через сторонние плагины и цепочки поставки — 4%.
Наиболее уязвимыми оказались финансовые организации: на них приходится 26% зарегистрированных инцидентов с ИИ-агентами. В зоне повышенного риска также находятся ИТ- и телеком-компании с долей 21%, промышленность и энергетика — 17%, ритейл и e-commerce — 14%, медицинские и фармацевтические организации — 11%, логистика и транспорт — 7%, профессиональные услуги и консалтинг — 4%. Финансовый сектор лидирует из-за высокой плотности интеграций, большого числа регуляторных требований и активного использования автоматизации в антифроде, клиентской поддержке и обработке документов. В ИТ и телекоме риск усиливается из-за доступа агентов к репозиториям, CI/CD и системам управления инфраструктурой. В промышленности проблема чаще связана с подключением ИИ-инструментов к данным мониторинга, технической документации и сервисным контурам.
Картину 2026 года уже сформировали несколько публично раскрытых инцидентов. В апреле 2026 года компания Vercel подтвердила компрометацию через сторонний ИИ-инструмент Context.ai с ущербом около $2 млн. Атака развивалась по классическому supply-chain-сценарию: от личного аккаунта сотрудника в ИИ-сервисе к корпоративному Google Workspace и далее во внутренние среды. Уязвимость EchoLeak в Microsoft 365 Copilot (CVE-2025-32711) продемонстрировала возможность zero-click-эксфильтрации данных через скрытую инструкцию в письме без каких-либо действий пользователя. Отдельный класс рисков иллюстрируют инциденты с агентами разработки: задокументированы случаи, когда автономный кодинговый агент за секунды удалял рабочие базы данных и резервные копии, реагируя на типовую техническую ошибку.
«Компания может видеть выполнение задачи, но не видеть всю цепочку решений, которая к ней привела. В 2026 г. мы ожидаем, что число инцидентов будет расти прежде всего там, где агенты внедряются быстрее, чем появляются владельцы, журналы действий и правила остановки», — сказал Анатолий Песковский, директор Департамента наступательной безопасности компании «Информзащиты».
По рекомендациям экспертов, компаниям необходимо вести полный реестр агентов, фиксировать владельца каждого сценария, ограничивать права по принципу минимально необходимого доступа, разделять доступ к данным и действиям, контролировать использование токенов и сервисных учетных записей, а также внедрять журналирование на уровне промптов, инструментов, API-вызовов и итоговых операций. Для сценариев с доступом к персональным данным, финансовой информации, исходному коду и производственным системам нужен отдельный процесс согласования, тестирование на prompt injection и регулярная проверка фактических полномочий. Дополнительный слой защиты дают runtime-политики: ограничение списка доступных инструментов и внешних доменов, обязательное подтверждение операций с высоким риском, изоляция секретов от контекста модели, выполнение действий агента в изолированной среде и заранее настроенный механизм принудительной остановки на уровне платформы оркестрации. Отдельным направлением становится инвентаризация и управление нечеловеческими идентичностями: каждому агенту присваивается собственная учетная запись с уникальными правами, отделенная от учетных записей разработчиков и сервисных аккаунтов общего назначения. Параллельно формируется практика «надзорных агентов», которые в реальном времени отслеживают поведение основных агентов и блокируют действия, выходящие за установленные политики. Практика показывает, что наибольший эффект дает связка инвентаризации, runtime-контроля, DLP, мониторинга аномального поведения и заранее описанных процедур отключения агента при выходе за допустимый контур. Без такой дисциплины автономность агентов начинает работать против бизнеса: скорость операций растет, но вместе с ней увеличивается окно, в котором ошибка агента или точная атака превращается в полноценный инцидент. «Информзащита» рекомендует встраивать ИИ-агентов в стандартные циклы управления уязвимостями, инцидентами и доступом с самого начала проекта, а не после первого инцидента: издержки на «догоняющий» контроль, по нашим наблюдениям, кратно превышают стоимость превентивного внедрения.