Исследователи фиксируют снижение доверия к полной ИИ-автоматизации пентестов до 9%

Эксперты компании «Информзащита» выявили рост спроса на гибридную модель проверки ИИ-систем: в 2026 году только 9% организаций готовы полностью доверить пентесты ИИ-автоматизации. Годом ранее такой подход поддерживали 29% респондентов. За двенадцать месяцев доля сторонников полного автономного тестирования сократилась на 20 процентных пунктов, тогда как число компаний, предпочитающих использовать автоматические средства для некритичных активов, а критичные системы проверять вручную, выросло на 22 процентных пункта – до 47%.

Автоматические средства быстро находят известные ошибки конфигурации, проблемы с внешней поверхностью атаки, повторяемые недостатки в API и нарушения базовых политик безопасности. Однако ИИ-приложение редко ограничивается типовой веб-логикой. Поведение LLM зависит от системных инструкций, контекста диалога, версии модели, подключенных источников данных, прав пользователя, списка доступных агенту инструментов и ограничений, заданных в оркестраторе. Уязвимость может проявиться только при определенной последовательности действий, которую невозможно получить одиночным тестовым запросом.

Разбивка по векторам уже зафиксированных ИИ-инцидентов подтверждает, что риск не ограничивается ошибками одной модели. В 44% случаев причиной становился shadow AI – использование сотрудниками несанкционированных внешних инструментов с передачей чувствительных данных. По 41% пришлось на отравление данных и моделей, а также на небезопасную обработку ответов LLM. Уязвимости в цепочке поставок были названы в 35% инцидентов, prompt injection – в 34%, ошибки LLM и слабости векторных баз и эмбеддингов – в 32% каждый. Далее следуют чрезмерные полномочия агентов и утечки системных промптов – по 24%, дезинформация – 20%, неограниченное потребление ресурсов – 15%. Автоматизированные средства полезны для регулярного контроля многих из этих направлений, но не способны самостоятельно подтвердить безопасность сложной связки между моделью, данными и бизнес-процессом.

В исследовании 78% команд сообщили, что сталкивались с пропуском критичных уязвимостей автоматизированными средствами. Для ИИ-сервисов это особенно чувствительно: ошибка может находиться не в самом запросе к модели, а в том, как она интерпретирует данные из RAG-базы, вызывает внешние API, получает доступ к внутреннему контуру или действует от имени сотрудника. Механическая проверка не всегда способна увидеть связь между отдельными элементами такой архитектуры и оценить последствия их сочетания.

Наиболее показательный пример – prompt injection. В изолированной среде модель может корректно отклонять вредоносные инструкции, но изменить поведение после обработки специально подготовленного документа, сообщения из внешней системы или фрагмента истории диалога. Аналогично проявляются риски избыточной агентности: модель получает доступ к почте, CRM, файловому хранилищу или корпоративному API, а ошибка в разграничении прав позволяет выполнить действие, которое не должно быть доступно в данном контексте. Для проверки таких сценариев нужно моделировать действия атакующего, тестировать обход защитных ограничений, анализировать бизнес-логику и оценивать фактический объем полномочий AI-агента.

Эти сценарии хорошо ложатся на классы рисков OWASP Top 10 for LLM Applications: prompt injection, data/model poisoning, improper output handling, supply-chain weaknesses, excessive agency, system prompt leakage, vector and embedding weaknesses и unbounded consumption. Автоматизация может обнаружить часть таких проблем, но не подтверждает безопасность всей цепочки от источника данных до бизнес-действия, которое модель выполняет после обработки запроса.

Разбивка инцидентов по векторам атак подтверждает, что проблема не сводится к одному классу уязвимостей. В 44% случаев причиной становился shadow AI – использование сотрудниками несанкционированных внешних AI-сервисов и передача им чувствительных данных. По 41% инцидентов пришлось на отравление данных и моделей, а также на некорректную обработку ответов LLM. Уязвимости цепочки поставок фигурировали в 35% случаев, prompt injection – в 34%, ошибки LLM и слабости векторных баз и эмбеддингов – в 32%. Избыточные полномочия агентов и утечки системных промптов отмечались в 24% инцидентов, дезинформация – в 20%, неограниченное потребление ресурсов – в 15%. Автоматизация может обнаружить часть этих проблем, но не способна самостоятельно подтвердить безопасность всей цепочки от источника данных до бизнес-действия, которое модель выполняет после обработки запроса.

Отраслевой разрез исследования не ранжирует сферы по уровню доверия к полной автоматизации и не дает статистики инцидентов для каждой вертикали. Однако состав выборки показывает, где вопрос особенно актуален: разработка ПО представлена 27% респондентов, здравоохранение – 21%, финансовые и страховые организации – 14%, информационные сервисы – 10%, другие отрасли – 27%. В разработке ПО ИИ-инструменты часто подключают к репозиториям, средам разработки и CI/CD-конвейерам, поэтому ошибка в правах агента может затронуть исходный код или цепочку поставки. В здравоохранении основной риск связан с обработкой медицинских данных и интеграциями с профильными системами. Для финансового сектора критичны операции с платежной информацией, персональными данными и сервисами, которые участвуют в принятии решений по клиентам. Информационные сервисы чаще работают с внешними запросами, большими массивами контента и поисковыми системами, что повышает значимость контроля источников данных и RAG-контуров. Указанные проценты отражают структуру выборки, а не уровень уязвимости отраслей.

Сложность проверки усугубляется тем, что найденные проблемы не всегда быстро устраняются. В 2026 году ИИ- и LLM-приложения показали самую низкую долю закрытых высокорисковых уязвимостей среди всех типов пентестов – 38,4%. Годом ранее показатель составлял 21,1%, однако даже после роста он остается существенно ниже, чем у веб-приложений с 73,7% и API с 77,3%. При этом 77% организаций уже регулярно проводят оценки безопасности и пентесты ИИ-продуктов, а 59% используют red teaming или adversarial testing с фокусом на LLM. Проверок становится больше, но возможности команд по устранению сложных находок растут медленнее.