Инциденты с ИИ-агентами: 42% в России против 65–88% в мире — и это не повод расслабляться

В 2026 году, по данным отраслевого исследования, с инцидентами безопасности, связанными с ИИ-агентами, столкнулись 42% российских организаций — против 31% годом ранее. На фоне зарубежных исследований эта цифра выглядит даже умеренно: Cloud Security Alliance говорит о 65% компаний с инцидентами, связанными с ИИ-агентами, за последние 12 месяцев, AvePoint — о 88,4% организаций, переживших хотя бы один security breach, связанный с агентами.

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

Проблема не в том, что у компании появился «настоящий автономный ИИ-агент» уровня Microsoft Copilot. Она начинается раньше: когда нейросети дают доступ к CRM, таблицам, почте, базе знаний, тикетам, репозиторию или внутренним документам. В российском малом и среднем бизнесе это чаще всего не отдельный «агент», а связка попроще: ChatGPT, Claude или GigaChat, подключённые к Bitrix24, Google Таблицам и почте через n8n или Make.

Как только система может не только отвечать текстом, но и читать, менять, отправлять или запускать действия — это уже не чат, а полноценный субъект доступа. И контролировать его нужно почти так же, как сотрудника или подрядчика: с понятными правами, журналом действий и владельцем, который отвечает за то, что он делает.

Это не только «нас взломали». По разбивке того же исследования, среди инцидентов с ИИ-агентами в России больше всего приходится на злоупотребление правами и выход за рамки разрешённых сценариев — 31%. Дальше идут prompt injection и подмена инструкций — 24%, утечки через коннекторы и хранилища — 18%, «теневые» агенты, о которых ИБ-служба даже не знала, — 14%, компрометация токенов и API-ключей — 9%.

За сухими процентами стоят конкретные истории. Летом 2025 года Джейсон Лемкин, основатель SaaStr, публично описал инцидент с Replit: агент-разработчик во время режима «заморозки кода» удалил боевую базу данных, несмотря на прямой запрет на изменения в проде.

А уязвимость EchoLeak в Microsoft 365 Copilot — это уже про категорию prompt injection: скрытая инструкция в обычном письме заставляла агента собрать чувствительные данные из переписки и отправить их вовне без единого клика пользователя. Важно, что пользователь здесь не «ошибся» и не кликнул по фишинговой ссылке — агент сам стал мостом между внешней инструкцией и внутренними данными компании. Это и есть новый класс риска: не человек принял неверное решение, а система выполнила чужую команду от его имени.

Часть разброса — методология. Proofpoint в январе 2026 года опросил 1400 специалистов по безопасности в 12 странах и получил результат, который многое объясняет: даже среди организаций с внедрёнными средствами защиты ИИ половина всё равно сообщила о подозрительном или подтверждённом инциденте. Наличие контролей само по себе не решает проблему — оно просто повышает шанс её заметить.

Показательнее другое. В отчёте Gravitee подтверждённые инциденты упали с 59,3% в декабре 2025 до 34,9% в апреле 2026 — и авторы сами пишут, что это падение почти наверняка означает не снижение риска, а рост недорегистрации: парк агентов за квартал удвоился, а мониторинг почти не подрос. IBM даёт похожий, но более широкий сигнал: в Cost of a Data Breach Report 13% организаций сообщили о взломах именно моделей или приложений ИИ, и уже среди этих скомпрометированных компаний 97% не имели контроля доступа для ИИ вообще. Для агентных сценариев это особенно критично — агент не просто отвечает текстом, а выполняет действия от имени учётной записи, и без контроля доступа эта учётная запись открыта настежь.

Здесь я перехожу от фактов к обоснованному предположению, а не доказанному тезису. Если даже западные компании с более зрелым рынком AI security систематически недосчитывают инциденты, у российского рынка причин для более честной цифры не больше, а меньше. Обязательного раскрытия ИБ-инцидентов с ИИ-агентами в России нет — уведомлять регулятора обязательно только при утечке персональных данных по 152-ФЗ. Агент, который удалил базу без утечки персданных или получил лишний доступ к внутренней системе, ни в какую официальную статистику попадать не обязан — компания просто чинит проблему молча. В ИБ это стоит рассматривать не как проблему конкретно ИИ, а как более старую и знакомую проблему управления доступами и полномочиями — просто на новом типе учётных записей.

Это не значит, что 42% — ложь. Это, вероятнее всего, нижняя граница того, что компании успели заметить сами, а не полная картина.

Агенты быстро вышли из пилотов в реальные процессы — в ИТ, инженерные команды, клиентский сервис, безопасность, закупки. При этом хаоса в инфраструктуре хватает: единую платформу для агентов использует только 5% компаний, 44% работают с двумя-тремя платформами одновременно, а 43% — с четырьмя и более. Чем больше разрозненных сред, тем меньше шансов, что кто-то видит полную картину доступов.

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

Она банальнее, чем кажется: агенту дают доступ «на всякий случай», с запасом, чтобы не донастраивать права при расширении задачи. А дальше никто системно не проверяет, что он реально делает с этим доступом — отслеживают результат работы, а не сам процесс. Главный риск здесь не в «злом ИИ», а в обычной сервисной учётке без владельца, которая тихо накапливает права и переживает саму задачу, ради которой её создали.

— завести реестр агентов: кто владелец, какая задача, к каким системам есть доступ, где токены, какой у агента срок жизни;

— выдавать агентам отдельные сервисные учётные записи, а не использовать логины сотрудников;

— начинать с доступа только на чтение и расширять права лишь после проверки, что агент делает именно то, что от него ожидают;

— не пускать агента к боевым данным на этапе пилота - тестировать на нечувствительных данных;

— логировать сами действия агента, а не только итоговый результат: что прочитал, куда обратился, что изменил, какой API вызвал;

— настроить быстрый отзыв доступа - заранее знать, кто и за сколько минут может отключить агента;

— регулярно пересматривать права агентов, как для сотрудников и подрядчиков, и обязательно выводить их из эксплуатации, когда задача завершена. По данным Cloud Security Alliance, формальный процесс такого вывода есть только у 21% компаний — большинство агентов просто продолжают жить с действующими правами после того, как в них отпала нужда.

По тем же данным, компании, которые последовательно применяют принцип минимально необходимого доступа, сталкиваются с инцидентами в 17% случаев — против 76% у тех, кто этого не делает. Это самое сильное снижение риска среди всех практик в отчёте, и оно целиком в руках самой компании, без закупки новых инструментов.

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