Разбираем web-pentest skill в Hermes Agent – встроенный навык, который превращает AI-агента в пентестера с методологией «No Exploit, No Report». Прошли весь kill chain на трёх реальных веб-приложениях, потратили 23,5 млн токенов и собрали выводы о том, где у такого подхода реальная ценность, а где – предел.

Мы в Ideco занимаемся сетевой безопасностью, и нам интересно не только то, как агенты атакуют сети, но и то, как они меняют сам процесс пентеста. Поэтому мы взяли open-source агента Hermes Agent, подключили к нему web-pentest skill и прогнали через него три реальных веб-приложения. В статье – архитектура навыка, разбор пяти фаз, защитные ограничения (guardrails) и попытка понять где у такого подхода предел и какая работа остается людям.

AI-пентест 2026: от обёрток над ChatGPT к автономным агентам

За полтора года после выхода GPT-4 рынок offensive-инструментов на базе LLM вырос с единиц до нескольких десятков. Исследовательская команда Hadrian к марту 2026 насчитала 70 open-source инструментов AI-пентеста; до релиза GPT-4 в апреле 2023 их было меньше пяти. Это автономные end-to-end агенты, генераторы эксплойтов, фреймворки для LLM red-teaming и CTF-агенты.

Подтянулся и коммерческий сегмент. xBow первым из машин возглавил глобальный leaderboard HackerOne и закрыл больше 200 zero-day без ложных срабатываний; в марте 2026 компания подняла раунд, превысивший оценку в 1 млрд долларов. NodeZero от Horizon3.ai первым полностью прошёл бенчмарк Game of Active Directory за 14 минут – задачу, на которой спотыкались GPT-4o, Gemini 2.5 Pro и Claude Sonnet 3.7.

Важный сдвиг: эти системы перестали выдавать статичные результаты сканера и начали действовать так, как работает живой пентестер – строить гипотезу, проверять её эксплойтом и отбрасывать недоказанное. Именно в этом контексте интересен Hermes Agent. Это не очередной специализированный security-сканер. Это агент, для которого пентест – одна из множества способностей, упакованная в отдельный навык.

Чем «skill в general-purpose agent» отличается от standalone-инструмента

Большинство известных AI-пентестеров – специализированные продукты: Shannon, PentestGPT, NodeZero, xBow. Они заточены под одну задачу и под неё же оптимизированы.

Hermes Agent устроен иначе. Это self-hosted, model-agnostic автономный агент от Nous Research с лицензией MIT. Его ключевая особенность – встроенный learning loop: агент сам создаёт навыки из опыта, дорабатывает их в процессе работы, ищет по своим прошлым диалогам и постепенно достраивает модель пользователя. Навык (skill) здесь – это markdown-документ с YAML frontmatter, описывающий runbook под конкретную задачу.

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

Для контекста: Hermes Agent вышел 25 февраля 2026 года в версии v0.1.0, за полтора месяца дошёл до v0.8.0, а версия v0.5.0 была целиком посвящена security hardening – больше 200 PR: command approval, sandboxing, защита credentials, патчи SSRF и path traversal. На июнь 2026 проекту около трёх месяцев. Предложение добавить web-pentest skill оформлено в GitHub issue #400 от 3 марта 2026.

Проблема: между сканером и ассистентом

У классического пентеста две болевые точки, и AI пока закрывает их по отдельности.

• Сканеры дают шум. Автоматические сканеры уязвимостей хорошо находят кандидатов, но плохо отличают реальную проблему от теоретической. На выходе – список из сотен «потенциальных» находок, которые инженер вручную перепроверяет. Большая часть оказывается ложными срабатываниями.

• Чат-ассистенты не исполняют. ChatGPT, Claude и подобные дают грамотные рекомендации: «проверьте параметр на SQLi», «добавьте CSP». Но они не самостоятельно не подтвердят эксплуатируемость. Между советом и доказательством – ручная работа. С ними даже более рутинная, чем раньше.

Разрыв очевиден: нужен агент, который сам проходит весь kill chain – от разведки до подтверждённого эксплойта – и репортит только то, что доказано изменением поведения приложения. Именно эту задачу решает связка Hermes Agent + web-pentest skill, опираясь на философию Shannon.

Что такое Shannon и причём тут «No Exploit, No Report»

Shannon – автономный white-box пентестер от KeygraphHQ, написанный на TypeScript поверх Claude Agent SDK. Он набрал 96,15% на бенчмарке XBOW – 100 из 104 эксплойтов в hint-free режиме. Его философия – «No Exploit, No Report»: если гипотезу не удалось превратить в работающий PoC, находка отбрасывается как ложноположительная. В отчёт попадают только доказанные, эксплуатируемые уязвимости.

Web-pentest skill в Hermes Agent берёт эту методологию и адаптирует под OWASP Testing Guide. Дальше – как именно.

Анатомия web-pentest skill: пять фаз

Навык реализует пентест как структурированный конвейер из пяти фаз (нулевая – подготовительная). Логику удобно держать перед глазами:

Разберём по порядку.

Phase 0. Engagement Setup – авторизационный рубеж

Самая важная фаза с точки зрения легальности. Перед любым действием агент требует вербального подтверждения scope примерно такого вида: «Confirm: (a) target URL is [X], (b) you own or have written authorization to test it». Любой ответ, кроме явного authorized, означает STOP. Подтверждение фиксируется в файле engagement/authorization.md, scope – в scope.txt.

Ручное подтверждение действий – одновременно юридический и технический рубеж: агент физически не переходит к задачам без записанного подтверждения. В наших прогонах подтверждение проходило через чат (ответ «authorized»), и факт авторизации фиксировался в материалах.

Phase 1. Live Recon – строго read-only

Разведка без изменения состояния цели. Здесь работают привычные инструменты:

• nmap в режиме -T3 – заметим, не -T4/-T5: навык намеренно держит «вежливый» темп, чтобы не создавать нагрузку и не выглядеть как DoS (а также не попадать из-за этого под возможные блокировки);

• whatweb и анализ HTTP-заголовков – фингерпринтинг стека;

• браузерный краулинг, разбор robots.txt и sitemap.

В одном из наших кейсов уже на этой фазе агент по заголовкам и cookie восстановил весь стек: nginx как reverse proxy, React SPA на FastAPI-бэкенде, развёрнутый в облаке на Kubernetes с Ingress-NGINX – и тут же по robots.txt и DNS вытащил список поддоменов, включая отдельный портал на Bitrix CMS под Apache. За такую «ниточку» часто можно вытянуть хороший «клубок» уязвимых сервисов и shadow-IT. Особенно в эпоху вайбкодинга.

Phase 2. Vulnerability Analysis – параллельные sub-агенты

Самая нетривиальная с архитектурной точки зрения фаза. Вместо последовательного перебора навык использует delegate_task и раздаёт классы уязвимостей независимым sub-агентам, которые работают одновременно: отдельный агент на SQLi, отдельный на XSS, на SSRF, на AuthZ, на IDOR. Это существенно сокращает время пентеста (в среднем в нашем случае он и так занял 1,5 часа на каждый сервис).

Это та же идея, что и у топовых коммерческих платформ. У xBow архитектура построена на тысячах короткоживущих параллельных агентов, каждый из которых решает узкую задачу со свежим контекстом, а координирует их глобальный менеджер поверхности атаки. Hermes делает то же самое в миниатюре, средствами своего скилла. Параллелизм здесь –оптимизация не только ради скорости, а способ дать каждому классу уязвимостей чистый контекст и не «размазывать» внимание модели.

Phase 3. Exploitation – доказательство вместо предположения

Здесь срабатывает «No Exploit, No Report». Агент не репортит гипотезу – он её доказывает. Ключевые приёмы:

• Witness payloads – безопасные маркеры вместо разрушительных. Для XSS, например, <svg/onload=console.log("HERMES-PENTEST-XSS")> вместо alert(1), чтобы не мешать другим пользователям в общих средах;

• Эскалация L1→L4 – от «кандидата» (L1) к «частично подтверждено» (L2), «подтверждено» (L3) и «критично» (L4). В отчёт идут только L3 и L4;

• Sleep probe и callback host – для слепых классов вроде time-based SQLi и SSRF;

• Оценка по CVSS 3.1 для каждой подтверждённой находки.

Перед тем как записать кандидата в false_positive, агент обязан пройти все техники из references/bypass-techniques.md – так называемый bypass exhaustion. Это защита от ленивого вывода «не сработало» после одной попытки.

На практике дисциплина «доказательства» проявилась наглядно. В кейсе с порталом на Bitrix агент нашёл reflected-вход для XSS – поиск отражал ввод, – но честно классифицировал его как L2 partial: HTML-сущности кодировались, исполняемого контекста не нашлось. В отчёт он не попал. Зато туда попала находка, которую агент довёл до доказательства: эндпоинт входа в админ-панель при некорректном запросе отдавал полный PHP stack trace с внутренними путями, конфигурацией БД и структурой namespace – это уже воспроизводимый факт, а не догадка.

Phase 4. Reporting – структурированный отчёт

Финал – отчёт по шаблону templates/pentest-report.md: Executive Summary, scope, перечень находок с severity и CVSS, доказательства (request/response, команды воспроизведения), рекомендации и шаги верификации после фикса. Структура совпадает с тем, что выдают коммерческие инструменты, и сразу ложится в рабочий процесс команды защиты (и ее AI-агентов).

Практика: три реальных веб-приложения, 23,5 млн токенов

Чтобы понять навык не по документации, а по делу, мы прогнали через него три реальных веб-приложения разной природы:

1. React SPA на FastAPI в облаке на Kubernetes – с набором обнаруженных поддоменов, включая портал на Bitrix CMS и сайт документации;

2. Webmail-сервис на Roundcube (PHP 8.4) за nginx, с почтовым стеком Postfix/Dovecot;

3. Публичный DNS-сервис – связка Next.js-сайта и личного кабинета на Django REST + jQuery.

Все три теста суммарно обошлись в 23,5 млн токенов (и 347 запросов) через модель Owl Alpha на OpenRouter (в настоящее время доступна бесплатно). Цифра показательна: пентест на агенте – это не «один запрос к LLM», а длинная цепочка recon → анализ → эксплуатация → отчёт с десятками инструментальных вызовов и параллельными sub-агентами.

Как это выглядит в работе

Сценарий каждого прогона повторял пять фаз. Покажем характерные моменты.

• Authorization gate. До любых активных действий – подтверждение scope и фиксация в authorization.md. Без authorized агент не двигался дальше.

• Recon. Агент сам поднимал карту цели. На webmail-сервисе он по nmap и баннерам восстановил всю схему: nginx как reverse proxy, за ним Roundcube 1.6.12 на PHP 8.4.17 (FPM), внешние IMAP/SMTP, отдельный порт административного интерфейса. На DNS-сервисе – разделение на публичный Next.js-сайт и кабинет на Django, с полной картой API-эндпоинтов аутентификации.

• Анализ и эксплуатация. Дальше параллельные sub-агенты отрабатывали классы уязвимостей. И вот что важно: на всех трёх целях ядро инъекционных атак не прошло. SQL-инъекции упирались в подготовленные выражения и ORM, XSS – в корректное экранирование, SSRF – в валидацию. Агент это зафиксировал четко, без ложных алертов.

Реально подтверждённые проблемы оказались в другой плоскости – конфигурация и раскрытие информации:

Отчёт. На каждую цель – структурированный документ с Executive Summary, таблицей находок, CVSS-векторами, командами воспроизведения и рекомендациями. Ниже – фрагмент доказательной части из реального отчёта (раскрытие stack trace):

Это и есть «No Exploit, No Report» на практике: воспроизводимый запрос с конкретным ответом, а не строчка «возможно раскрытие информации».

Главный вывод по результатам

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

Guardrails и этика: где проходят границы

Offensive-возможности в руках автономного агента – это риск, и навык это учитывает. Несколько встроенных ограничителей.

• Запрет cloud metadata. Жёсткий блок обращений к 169.254.169.254 и подобным endpoint'ам метаданных облака – чтобы агент не утянул IAM-токены при тестировании SSRF.

• Rate limit. Темп запросов сдерживается (порядка 200 мс между ними), nmap идёт на -T3. Тестирование не должно превращаться в стресс-тест.

• Редакция credentials. Любые секреты в выводе усекаются до последних символов – чтобы отчёт и логи не стали утечкой.

• Bypass exhaustion. Прежде чем закрыть кандидата как false-positive, агент обязан перебрать все техники обхода.

Отдельно стоит проговорить два специфических риска.

• Aux-client leakage. Уникальный для архитектуры Hermes момент: данные engagement могут утечь через путь компрессии контекста в auxiliary client. Навык прямо предупреждает об этом. Для security-sensitive тестов это значит: внимательно относитесь к тому, какие вспомогательные модели и сервисы подключены к агенту.

• Безопасность самого агента. Тут стоит вспомнить контекст: v0.5.0 Hermes Agent был выпущен как security-hardening релиз с command approval, sandboxing и защитой credentials. Нужно понимать, что автономный агент с доступом к offensive-инструментам сам по себе – часть поверхности атаки. Запускать такой инструмент стоит в контейнере, с сетевой изоляцией и минимальными правами. И точно не на рабочем компьютере с коммерческими данными и личными аккаунтами.

Мы в Ideco смотрим на это как на проявление более общего тренда: приложения перестают быть статичными и детерменированными, а трафик всё чаще генерируют не люди, а агенты – и свои, и чужие. Безопасность, которая рассчитана только на «вчерашние» паттерны, такой трафик не увидит.

Ограничения навыка: честно о пределах

Agent Web-pentest skill – не серебряная пуля. Где он заканчивается:

• Только веб. Навык про веб-приложения и API. Никакого (пока!) Metasploit, Active Directory, lateral movement или binary reverse engineering. Для сравнения: тот же NodeZero специализируется на сетях и AD, а Excalibur на базе PentestGPT компрометировал 4 из 5 хостов в AD-окружении – это другая лига задач, которую web-pentest skill не покрывает.

• Качество зависит от модели. Навык model-agnostic, но результат сильно определяется моделью под капотом. Слабая модель будет хуже строить гипотезы и чаще сдаваться на bypass. Мы специально провели тест не на фронтир-моделях, а на бесплатной Owl Alpha – которая оказалась весьма годной для этой задачи.

• Нет промышленной интеграции. Ни Burp Suite, ни связки с SIEM, ни тикет-трекинга из коробки. Это инструмент исследователя, а не готовый enterprise-pipeline. Впрочем, выглядит что его не сложно запрограммировать.

• Ограничение по времени и доступу. В наших прогонах часть поверхности осталась непротестированной без валидных учётных данных (например, аутентифицированные функции webmail и внутренние API). Агент это явно отметил в разделе ограничений каждого отчёта.

Вывод

Web-pentest skill в Hermes Agent – пока не замена живому пентестеру. Его реальная ценность в двух вещах: автономная pre-engagement-разведка и отчётность с доказательствами вместо шума ложных срабатываний. На хорошо настроенных приложениях он не вскрывает «всё подряд», а системно вычищает конфигурационные и информационные проблемы – и делает это с воспроизводимыми PoC.

Интереснее сам прецедент. Offensive-возможности переезжают из специализированных инструментов в general-purpose агентов как ещё один навык. Это значит, что число акторов, способных запустить автономный пентест, будет расти – и далеко не все из них дружелюбны.

Для нас, как для разработчика NGFW, вывод прямой. Когда часть трафика – и атакующего, и защищающего – генерируют автономные агенты, средства защиты периметра обязаны учитывать agentic-трафик: его темп, паттерны параллельных sub-агентов, характерные witness-payloads. Это и есть та угроза завтрашнего дня, к которой защита должна быть готова сегодня. Мы в Ideco исходим из того, что безопасность не должна успевать устаревать – и агентный пентест ровно про это.