Пентест с агентным ИИ: методология, риски и выбор подрядчика

Условный сценарий. Небольшая финтех-команда за месяц до релиза мобильного банка получает предложение от поставщика: «автономный ИИ-пентест» личного кабинета и API, без выделенных специалистов, с отчётом через двое суток. Команда соглашается на пробный запуск на тестовом стенде. Агент работает быстро: перебирает эндпоинты, находит пару отражённых XSS, пишет аккуратные описания. А на второй день в журнале обнаруживаются запросы к домену платёжного партнёра. Выясняется, что одно из отладочных сообщений стенда содержало адрес партнёрского API, и агент счёл его частью цели. Никакой злонамеренности: модель просто прочитала ответ приложения шире, чем позволяло разрешение.

Этот пример выдуман, но в нём собраны вопросы, которые заказчику стоит задать до покупки. Что именно агент считает целью и кто это проверяет? Что будет, если ответ тестируемой системы подтолкнёт его не туда? Какие находки подтвердил человек, а какие модель просто правдоподобно описала? И главное — заменяет ли такой инструмент классическую оценку, расширяет её или только ускоряет отдельные этапы?

Ниже разбираем пентест с агентным ИИ с позиции устоявшейся методологии, а не маркетинговых обещаний: как соотносить автономный пентест с NIST SP 800-115, OWASP WSTG и ASVS, какие риски несёт сам агент как программная система, какие меры безопасности требовать на демонстрации и как поэтапно расширять автономность, не теряя подотчётности.

Что на самом деле означает пентест с агентным ИИ

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

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

В этой статье рамки сознательно ограничены веб-приложениями и API, доступными по HTTP. Для этих поверхностей существуют конкретные версионированные тест-кейсы и требования, позволяющие сопоставлять работу агента с каталогом проверок. Сетевой пентест, проверки облачной плоскости управления, физическая безопасность и социальная инженерия требуют отдельного разговора. И важная оговорка: ничто в тексте не даёт права тестировать чужие системы. Любое описанное действие предполагает документированную авторизацию всех сторон, уполномоченных разрешить работы в затрагиваемых активах и среде.

Методология не меняется: NIST SP 800-115, WSTG и ASVS как мерило

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

NIST SP 800-115, технический руководящий документ по тестированию и оценке информационной безопасности, опубликован в сентябре 2008 года и заменил SP 800-42. Он помогает организациям планировать и проводить технические проверки, анализировать результаты и вырабатывать меры по снижению рисков. Формально документ выделяет три фазы оценки: планирование, выполнение и пост-выполнение, где анализируются находки и готовятся рекомендации. Цикл устранения и повторной проверки, о котором пойдёт речь ниже, — практическое продолжение этой модели, а не отдельная фаза стандарта.

Особенно ценно для разговора об агентах то, что NIST описывает конкретные технические приёмы вместе с их преимуществами и ограничениями. Агент — просто новый способ выполнять эти приёмы, и его ограничения нужно документировать так же честно, как ограничения сканера уязвимостей. Ещё одна оговорка документа: он не является полной программой тестирования, а даёт обзор ключевых элементов. Платформа, которая автоматизирует выполнение, не отменяет потребности в программе. Определение рамок, правила проведения работ, согласования, валидация находок и контроль устранения остаются за организацией.

OWASP Web Security Testing Guide — флагманский документационный проект OWASP и один из основных практических ресурсов по тестированию безопасности веб-приложений. В этой статье WSTG 4.2 используется как выбранный пример; при закупке нужно уточнять версию, которую поставщик действительно применяет. Главное для заказчика: WSTG содержит каталог тест-кейсов, поэтому покрытие агента можно сопоставлять с ним по пунктам, а не верить общей фразе «проверяем всё по OWASP».

OWASP Application Security Verification Standard версии 5.0.0 задаёт основу для проверки технических мер защиты и стремится выровнять разброс в глубине и строгости проверок на рынке. У ASVS есть деталь, которая делает его почти идеальным языком для агентов: идентификаторы требований с указанием версии, например v5.0.0-1.2.5, и опубликованные списки требований в CSV и JSON. Машиночитаемый стандарт агент может использовать как цель, а отчёт — как стабильную ссылку, понятную и людям, и системам отслеживания дефектов.

Что агент видит в веб-приложении: сессии, роли и политики браузера

Качество любого динамического теста ограничено тем, что инструмент способен наблюдать. Справочник MDN описывает HTTP как протокол без сохранения состояния в модели «клиент — сервер». Это значит лишь, что сам протокол не связывает запросы между собой. Состояние в приложениях существует постоянно: через cookie, серверные сессии, токены в заголовках. Именно с этим состоянием агент и должен уметь работать.

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

Вторая область — политики браузера: CORS, Content Security Policy, Cross-Origin Resource Policy, атрибуты cookie. Инструмент должен понимать, что та или иная политика означает для реальной эксплуатации, а не просто фиксировать отсутствие заголовка. При этом не каждый эндпоинт обязан требовать аутентификацию: публичная страница тарифов или открытый справочный API — нормальная часть продукта. Хороший агент, как и хороший специалист, отличает намеренно публичный ресурс от случайно открытого.

Отсюда практический критерий: просите показать на пилоте работу с аутентифицированными сессиями в нескольких ролях и проверку горизонтального и вертикального доступа между ними. Результаты такого сценария дают проверяемое сравнение инструментов в условиях пилота.

Покрытие рисков: OWASP Top 10, CWE Top 25 и классы, где нужны доказательства

OWASP Top 10 в редакции 2025 года — документ осведомлённости, отражающий широкий консенсус о наиболее критичных рисках веб-приложений. Он хорошо подходит как общий словарь для находок агента, но списком проверок не является. Если поставщик пишет «покрываем OWASP Top 10», правильный ответный вопрос — какими конкретно тест-кейсами WSTG или требованиями ASVS это покрытие подтверждается.

MITRE CWE Top 25 за 2025 год выделяет наиболее серьёзные и распространённые слабости ПО, стоящие за опубликованными уязвимостями. По оценке MITRE, такие слабости часто легко найти и эксплуатировать, а их последствия — захват системы, кража данных или нарушение работы приложения. Сопутствующий перечень CWE Top 10 KEV Weaknesses ранжирует слабости, которые реально эксплуатируются, по каталогу известных эксплуатируемых уязвимостей CISA.

Для агентного тестирования эти списки полезны как инструмент приоритизации. Если агент работает ограниченное время, логично требовать явных доказательств покрытия для классов, которые привлекают атакующих: внедрения команд ОС, межсайтового скриптинга, обхода каталогов. Те же классы фигурируют в оповещениях программы CISA Secure by Design, адресованных производителям ПО. Отсутствие находки по такому классу должно сопровождаться свидетельством того, что проверка действительно выполнялась, а не просто тишиной в отчёте.

Агент-тестировщик сам является агентной системой

Этот вопрос нужно проверять отдельно от маркетингового описания продукта. ИИ-агент, который атакует ваше приложение, сам является LLM-приложением с инструментами, памятью и правами. А значит, на него распространяются те же классы рисков, которые он должен искать в чужих продуктах. В редакции OWASP Top 10 для LLM-приложений 2026 года, опубликованной в августе 2026-го, к этой ситуации напрямую относятся как минимум два пункта: LLM01 «Промпт-инъекция» и LLM03 «Избыточная агентность».

Ответы цели — недоверенный ввод

Агент читает HTTP-ответы, HTML, сообщения об ошибках, содержимое загруженных файлов — всё, что вернула тестируемая система. Для модели это такой же контекст, как инструкции оператора. Отладочное сообщение со ссылкой на внешний сервис, комментарий в HTML, текст в карточке товара, оставленный другим пользователем, могут подтолкнуть агента к действию за пределами разрешения, как в примере из начала статьи. Злой умысел для этого не нужен: достаточно того, что модель восприняла текст как подсказку.

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

Делегирование идентичности и память между проектами

Агенту выдают тестовые учётные записи, токены API, иногда доступ к среде разработки. Это делегирование идентичности, и к нему нужны те же вопросы, что к сервисной учётной записи: какие права, на какой срок, где хранятся секреты, кто может их увидеть. Отдельный вопрос — память. Если агент накапливает контекст между запусками, нужно понимать, изолирована ли память по клиентам и проектам и не окажутся ли фрагменты ваших ответов или учётных данных в контексте чужого теста. Тот же вопрос относится к использованию данных заказчика для дообучения моделей.

Обход согласований и каскадные действия

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

Автономия или помощь агента: где проходят компромиссы

Потенциальные преимущества агентов стоит воспринимать как гипотезы, которые нужно подтвердить на пилоте. Агент, возможно, способен единообразно повторять тест-кейсы, работать между ручными проверками и без усталости проходить большие каталоги вроде WSTG и ASVS. Такие преимущества правдоподобны для широких повторяющихся проверок — например, множества однотипных приложений или частых релизов, — но их размер и стоимость нужно измерять на пилоте.

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

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

Консервативный исходный режим этой статьи — агент выполняет, а человек проверяет и утверждает; конкретная организация выбирает режим по риску и данным своего пилота. Данные пилота могут впоследствии обосновать больше самостоятельности только для конкретных классов, чьи чувствительность данных, назначение, эффективные права, объём, обратимость и наблюдаемое поведение соответствуют исполняемой политике.

Если вы сейчас выбираете между классическим пентестом и проверкой с участием агентов, полезно сначала договориться о рамках, средах и ожидаемых доказательствах, а уже потом об инструменте. Эти вопросы можно разобрать с командой Pentest.red: страница согласования рамок пентеста помогает собрать исходные данные — цели, роли, ограничения и окна тестирования.

Меры безопасности, которые нужно увидеть вживую

Сначала разрешение. Каждый запуск агента должен опираться на письменно зафиксированные рамки: целевые хосты, среды, учётные записи, временные окна и запрещённые действия. Это прямое продолжение фазы планирования из NIST SP 800-115. Принципиальный момент — инструмент должен обеспечивать соблюдение рамок технически, а не только на уровне политики или инструкции в промпте.

Минимальный набор механизмов стоит увидеть на живой демонстрации, а не в документации: письменное описание не доказывает, что механизм работает в эксплуатации. Нужны жёсткие списки разрешённых целей и сред; ограничение частоты запросов и контроль нагрузки; аварийный выключатель, который оператор может задействовать в любой момент; разделение проверок только на чтение и тестов, изменяющих состояние; одобрение человеком перед потенциально разрушительным шагом. Наконец, нужны достаточные коррелированные журналы решений агента, вызовов инструментов и сетевых действий. Промпты и HTTP-данные минимизируют и маскируют, доступ ограничивают, задают срок хранения и защищают целостность. Журналы помогают воспроизвести находку и сопоставляются с записями прокси или сетевого контроля; один журнал сам по себе не доказывает отсутствие действий за рамками.

Сама ИИ-платформа — система, которую тоже нужно защищать. В ней хранятся учётные данные тестовых аккаунтов, находки, фрагменты ответов приложения, иногда персональные данные. Программа CISA Secure by Design ссылается на руководства по безопасной разработке ИИ-систем, а её принципы предполагают, что базовые механизмы — многофакторная аутентификация, SSO и журналирование — доступны клиенту без доплаты. Разумно предъявлять те же ожидания к платформе тестирования.

Результаты стоит связать с NIST Cybersecurity Framework 2.0, чтобы находки попадали в управление рисками организации, а не оседали в отдельном хранилище. Профили CSF 2.0 и информативные ссылки помогают соотнести конкретную уязвимость с более широкими целями. Использовать ИИ-инструмент как вспомогательную технику и непрерывно оценивать его результаты — практическое правило этой статьи, а не вывод из CSF. Для агентного тестирования его реализуют через пилот, валидацию человеком и повторную оценку после изменений.

Как меняется работа команды безопасности

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

Для применимых веб- и API-контролей отчёты должны ссылаться на версионированные требования ASVS и тест-кейсы WSTG; подходящие технические слабости сопоставляют с CWE. Для остальных находок фиксируют иной критерий или неприменимость. Одних идентификаторов недостаточно для дедупликации: сравнивают также актив, путь, версию, предусловия и первопричину. ASVS указывают с версией, поскольку его идентификаторы могут меняться между редакциями.

Встраивать агентов в конвейер релизов имеет смысл, если они тестируют непродуктивные или явно согласованные среды. Проверки, которые запускаются при изменениях, хорошо дополняют периодический пентест — этот подход мы подробнее описывали в материале о пентесте по триггеру изменений. Тестирование в продуктиве должно проходить тот же путь управления изменениями и согласований, что и любой ручной пентест.

Наконец, результаты должны возвращаться к разработчикам. MITRE позиционирует CWE Top 25 как инструмент устранения целых классов дефектов, а подход Secure by Design возлагает ответственность на производителя. Если находки агента раз за разом повторяются в одном классе слабостей, это сигнал устранять первопричину — в шаблоне, библиотеке, общем компоненте, — а не закрывать ошибки по одной. Повторный прогон после исправления — естественная сильная сторона агентов, но и здесь нужно доказательство, а не отметка «исправлено»; как его получить, разобрано в статье о проверке устранения уязвимостей после пентеста.

Как выбирать поставщика: вопросы и приёмочные проверки

Руководство CISA Secure by Demand адресовано заказчикам ПО на переговорах с поставщиками и реселлерами; совместное руководство австралийского ACSC и CISA по выбору безопасных и проверяемых технологий также написано для закупающих организаций. Общая идея обоих документов применима и к ИИ-пентесту: требуйте проверяемых доказательств, а не заверений.

Вопросы к поставщику стоит формулировать так, чтобы ответом была демонстрация. Какие применимые к веб-приложениям и API тест-кейсы WSTG и требования ASVS 5.0.0 покрывает продукт и как это показать? Кто утверждает находку перед включением в отчёт — квалифицированный специалист или модель? Какие технические механизмы обеспечивают рамки, ограничение частоты и аварийную остановку? Что журналируется, как данные минимизируются и маскируются, где хранятся, кто имеет доступ, каков срок хранения и используются ли данные клиента для обучения моделей?

Не менее важны вопросы о глубине и переносимости. Как агент работает с аутентифицированными сессиями в нескольких ролях? Как подходящие технические слабости сопоставляются с CWE, а применимые веб- и API-находки — с OWASP Top 10 2025 и версионированными идентификаторами ASVS? Есть ли MFA, SSO и журналирование без доплаты? Готов ли поставщик провести ограниченный по времени пилот на санкционированной цели и передать достаточные воспроизводимые и обезличенные доказательства?

Любую заявленную долю обнаружения, кратное ускорение или ярлык «полностью автономный» считайте гипотезой для пилота. Если поставщик не может по запросу воспроизвести находку с доказательствами, она не должна засчитываться. Предпочтительны договоры, где за итоговый отчёт отвечает квалифицированный специалист, а находки можно выгрузить в открытых форматах, чтобы результаты оставались переносимыми между поставщиками. Как сравнивать подрядчиков в целом, без привязки к ИИ, — в нашем сравнении поставщиков пентеста.

Поэтапное внедрение: автономия по мере накопления доказательств

Консервативная стратегия этой статьи — привязать уровень автономности к доказательствам пилота. Следующий этап начинается только тогда, когда предыдущий дал достаточно подтверждений, и самостоятельность агента расширяется не по всем классам сразу, а по тем, где он доказал предсказуемое поведение.

1. Разрешение и рамкиПисьменное разрешение, цели, среды, правила работ и критерии успеха, сопоставленные с тест-кейсами WSTG и требованиями ASVS.
2. Параллельный пилотАгент проверяет ту же санкционированную цель, что и экспертная оценка; сравниваются находки, ложные срабатывания и пропущенные классы.
3. Валидация человекомКаждая находка подтверждается специалистом; минимизированные коррелированные журналы и записи сетевого контроля проверяются на выход за рамки и цепочки изменяющих состояние действий.
4. Уровень автономностиУчитывают данные, назначение, права, объём и обратимость; даже чтение и неразрушающие проверки могут требовать шлюза.
5. Эксплуатация и переоценкаПосле обновления модели или продукта пилотные проверки повторяются: прежние результаты не переносятся на новую версию автоматически.

Параллельный пилот — ключевой этап. Сравнение с проверенной оценкой той же цели показывает, что агент добавил в условиях этого пилота: новые классы находок, иную частоту запусков или более быстрое оформление. Вывод ограничен целевой системой, версиями модели и продукта, доступом, методикой и участвующей командой. Если пилот показывает, что агент расширяет покрытие или частоту без неприемлемого риска, его разумно внедрять вместе с периодическим тестированием под руководством экспертов. Если он не может продемонстрировать контроль рамок и воспроизводимые доказательства, внедрять его не стоит, какой бы привлекательной ни была цена.

Переоценка после обновлений — не формальность. Поведение агента зависит от модели, промптов и обвязки инструментов; смена любой из этих частей может изменить то, как он интерпретирует ответы цели. Поэтому повторять пилотные проверки после таких изменений — практическое правило этой статьи; оно не приписывается NIST или CSF.

Итог: агент как исполнитель, методология как мерило

Пентест с агентным ИИ лучше всего понимать как новый уровень исполнения устоявшейся методологии. NIST SP 800-115, OWASP WSTG и ASVS уже описывают, как выглядит качественное тестирование, а OWASP Top 10 и CWE Top 25 помогают расставить приоритеты. Вопрос для заказчика не в том, «умный» ли агент, а в том, отвечает ли он этим ожиданиям безопасно и проверяемо — и защищён ли он сам от того, что прочитает в ответах вашей системы.

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

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