Агент безопасности

Доступность. Раздел «Безопасность» — on-prem enterprise-функция,
доступная по лицензии на модуль security. Грант fuzz или testing
также может открыть вкладку «Сканеры». Для остальных шести вкладок
нужно место Security; они доступны в серверной установке.

Раздел «Безопасность» — это зонтичный модуль Mockarty для offensive
security-тестирования. Он объединяет fuzzing-движок (вкладка
«Сканеры») с AI-red-team-агентом на пяти pentest-персонах,
очередью согласований для шагов эксплуатации с участием
человека, каталогом отчётов с экспортом в SARIF / VEX / HTML /
PDF / Allure и курируемой базой знаний, на которую опирается
агент.

Быстрый старт: от лицензии до первого сканирования

После активации лицензии с флагом security пользователь проходит
такой путь:

1. Появляется сайдбар. Зайдите в UI, найдите запись
   «Безопасность» (иконка щита) в левом сайдбаре. Если её нет —
   у вашего аккаунта нет грантов security (см. раздел «Права»).
2. Выберите вкладку для начала. По умолчанию открывается
   «Сканеры» (классический API-фаззер). Для AI-флоу — «AI-агент».
3. Соберите профиль сканирования (вкладка «AI-агент»):
   • Укажите одну или несколько целей (по одной на строку — форма
     отправит до 25 целей одним bulk-запросом).
   • Выберите персоны (web / API / infra / mobile / cloud).
   • Интенсивность: passive (только разведка), safe-active
     (по умолчанию — стандартные пейлоады), intrusive (активная
     эксплуатация, каждый шаг ставится на паузу до подтверждения)
     или destructive (может изменить данные — требуется явное
     письменное разрешение).
   • Бюджет в USD (по умолчанию $5). Оркестратор корректно
     остановится при достижении.
   • Нажмите «Запустить сканирование».
4. Наблюдайте за прогрессом в Runs Tray (плавающая панель) —
   security-сканы появляются с иконкой щита и прогресс-баром. Клик
   по карточке — переход к отчёту. Вкладка «Отчёты» обновляется
   автоматически каждые 5 секунд.
5. Подтверждайте intrusive-шаги во вкладке «Согласования» по мере
   запросов диспетчера. Каждая строка содержит цель, сканер и поле
   причины — ваше решение фиксируется в audit log.
6. Читайте отчёт во вкладке «Отчёты»: откройте строку, чтобы
   увидеть доказательства по каждой аномалии, CVE/CWE-ссылки,
   reproducer-curl и remediation-рекомендации. Экспорт через кнопки
   в тулбаре (SARIF / VEX / HTML / PDF / Allure).
7. Объедините несколько сканирований в один отчёт для
   стейкхолдеров: отметьте чекбоксами 2 и больше отчётов, нажмите
   «Объединить в один отчёт» в sticky-toolbar, подтвердите название.
   Аномалии дедуплицируются по fingerprint.

Быстрый старт: сканирование через чат AI-агента

Если настроен LLM-профиль (Админ → Agent Settings → LLM):

1. Откройте чат (пузырь справа внизу).
2. Скажите: просканируй наш сайт https://example.com или
   найди уязвимости в нашем staging-API.
3. Оркестратор передаёт red_team_lead, который задаёт уточняющие
   вопросы ПЕРЕД запуском:
   • «Какие именно URL / хосты тестируем?»
   • «Подтвердите, что у вас есть письменное разрешение тестировать
     эти цели.»
   • «Какая интенсивность? (passive / safe-active / intrusive /
     destructive — по умолчанию safe-active)»
   • «Есть что-то, что точно НЕ нужно трогать?»
   • «Цель за auth-стеной? Если да — есть тестовые креды?»
4. Отвечайте в свободной форме. Агент повторяет параметры и просит
   финального подтверждения («Запускаю?»). Ответьте да / go.
5. Скан запускается. Агент задаёт approval-вопросы в чате для
   intrusive-шагов — ответьте approve / reject с причиной.
6. Итоговый отчёт приходит в чат с ID отчёта; клик открывает полное
   представление.

Варианты развёртывания

Mockarty поддерживает три варианта security-стека:

• Single-node (по умолчанию): admin-процесс хостит engine,
  сканеры, диспетчер и approvals-очередь. Дополнительных контейнеров
  не нужно. Для разработки — запустите бинарник; для прод — helm chart с
  single-node values.
• Cluster (многонодовый): scheduler / KB-feedback-ingestion
  запускаются только на лидере через PostgreSQL leader-election;
  approval-строки + отчёты в shared PG, чтобы любой нод обслуживал
  UI; cross-node SSE доставляет finding-события в браузер оператора
  независимо от того, какой нод запустил сканер.
• + Раннеры безопасности (опциональные Kali-контейнеры): когда нужно
  делегировать AI-агенту внешние инструменты (сканирование портов,
  глубокий SQL-injection, аудит SMB / SSH / RDP, CIS-бенчмарк Kubernetes,
  статический анализ мобильных приложений), поднимите Kali-раннеры
  командой docker compose --profile security up -d. Они opt-in и
  поставляются только как Docker-образы. Полная настройка — в разделах
  «Два раннера» и «Развёртывание раннера» ниже. Без раннера встроенные
  сканеры всё равно покрывают web / API / cloud-control-plane / contract /
  GraphQL / gRPC / WebSocket.

Сканирование целей внутри своей сети

По умолчанию Security Agent ходит только на публичные адреса.
Цель, которая резолвится в loopback (127.0.0.1, ::1) или в приватный
диапазон (10.x, 172.16–31.x, 192.168.x, IPv6 ULA), отклоняется
дважды: при приёме сканирования (в отчёте будет причина «host is on the
always-deny list») и в момент установления соединения — поэтому хост,
у которого DNS-ответ меняется между этими двумя моментами, тоже не
будет просканирован.

Чтобы проверять собственный внутренний контур, запустите Mockarty так:

ALLOW_PROXY_TO_PRIVATE_IPS=true ./mockarty

С поднятым флагом внутренние хосты сканируются ровно так же, как
публичные. Cloud-metadata (169.254.169.254, fd00:ec2::254,
100.100.100.200) и link-local адреса заблокированы в любом случае —
ни один профиль сканирования не направит сканер на endpoint с
учётными данными инстанса.

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

Права

• security — это seat-pool фича. Workspace покупает
  N мест Security; админ выдаёт их конкретным операторам в
  Админ → Пользователи → пользователь → Фичи → Security. Логика
  идентична chaos / tcm / api-tester.
• Вкладка «Сканеры» (фаззинг) доступна с грантом testing,
  fuzz или security. Остальные вкладки
  (AI-агент, Отчёты, Согласования, Стоимость, База знаний, LLM-профили агентов) требуют
  security.
• Роли admin / support видят раздел Безопасность в режиме
  только чтение. Запуск скана, согласование, управление
  LLM-профилями всё ещё требуют явный security seat — авторские
  операции жгут seat, операции триажа / просмотра — нет.
• Kali red-team-runner авторизует per-user на стороне admin’а: задание
  от пользователя без активного Security seat’а отклоняется до того,
  как раннер его увидит.

LLM-профили

AI-агент и LLM-классификатор используют LLM-профиль per namespace. Без
профиля оркестратор переходит в heuristic-only режим (сканеры всё ещё
запускаются, но их аномалии не верифицируются ИИ). Настройка в
Админ → LLM-профили → Создать.

Поддерживаемые провайдеры (с pre-fill в форме создания):

Рекомендации для российского рынка:

• DeepSeek API — основной облачный LLM для sub-agent задач.
  Регистрация на platform.deepseek.com/api_keys, ключ копируется в
  форму, base URL уже подставлен.
• Self-hosted Qwen 2.5 — основной on-prem LLM. Разверните Qwen 2.5
  72B / 32B Coder за vLLM gateway’ом (или sglang / Ollama), укажите
  адрес гейтвея в профиле. Шесть Qwen-моделей предзаполнены в dropdown
  (от qwen2.5-72b-instruct до 7b, плюс qwen2.5-coder-32b-instruct и
  reasoning-модель QwQ-32B-Preview).
• YandexGPT — создайте Service Account в Yandex Cloud, выпустите
  Api-Key и вставьте его в поле API-ключа. YandexGPT также требует
  Folder ID: добавьте его в Parameters как x-folder-id. Выберите
  модель из списка (yandexgpt/latest для Pro, yandexgpt-lite/latest
  или yandexgpt-32k/latest); Mockarty сам построит URI
  gpt://<folder>/<model>.
• GigaChat (Сбер) — API-ключ это Авторизационные данные
  (Base64(client_id:client_secret)) с developers.sber.ru/gigachat.
  Mockarty обменивает их на короткоживущий токен и обновляет его
  автоматически. Укажите scope доступа в Parameters как X-GigaChat-Scope:
  GIGACHAT_API_CORP (pay-as-you-go) или GIGACHAT_API_B2B (предоплата)
  для организаций, GIGACHAT_API_PERS для физлиц. Серверы GigaChat
  используют сертификаты НУЦ Минцифры (Russian Trusted Root CA): на хосте,
  который уже доверяет этому корню, всё работает сразу; иначе укажите
  X-GigaChat-CA-Cert (в Parameters) на PEM-бандл Минцифры либо установите
  X-GigaChat-Insecure-TLS в true — только для dev/оценки.

Когда провайдер не возвращает счётчик токенов в ответе (некоторые
квантованные сборки Ollama, free-tier OpenRouter, vLLM без per-request
usage), cost-tracker подставляет оценку. Оценённые строки помечаются,
чтобы их можно было отличить от строк с точным расходом.

Где находится

• Сайдбар. «Безопасность» (иконка щита). Заменяет отдельную запись
  «Фаззинг»; старый маршрут /ui/fuzzing сохранён как
  обратно-совместимая закладка и открывает ту же вкладку «Сканеры».
• URL. /ui/security открывает вкладку «Сканеры» по умолчанию.
  Добавьте ?tab=ai-agent|reports|approvals|cost|kb|llm-profiles для прямой ссылки.
• API-префикс. Все эндпоинты Агента безопасности находятся под
  /api/v1/security/. Доступ к ним определяет лицензионный модуль
  security; старое имя security_agent также принимается как алиас.

Вкладки

1. Сканеры

Содержит интерфейс API-фаззинга без изменений. Все прежние функции
доступны: CRUD конфигов, загрузка OpenAPI, стратегии пейлоадов (SQLi,
XSS, SSRF, XXE, SSTI, mass assignment, ошибки CORS, заголовки
безопасности, батареи OWASP Top 10), вью запусков / аномалий /
карантина. Каталог активных проверок включает также две продвинутые
web-pentester проверки, которые AI-оркестратор может запустить по
запросу:

• HTTP request smuggling (scan_http_smuggling, CWE-444). Отправляет
  пробы CL.TE / TE.CL / TE.TE с намеренно неоднозначными комбинациями
  заголовков Content-Length + Transfer-Encoding. Помечает цель как
  high, когда ответ содержит оба заголовка (фронтенд и бэкенд
  расходятся в границах запроса), и как critical, когда в теле
  ответа просачивается строка чужого HTTP-ответа.
• Insecure deserialization (scan_insecure_deserialization,
  CWE-502). Подсовывает канонические magic-bytes Python pickle / Java
  serialized / PHP serialized через три точки внедрения (тело, параметр
  запроса, кастомный заголовок) и помечает цель как critical, когда
  в ответе появляется сигнатура ошибки десериализатора
  (pickle.UnpicklingError, java.io.InvalidClassException,
  ObjectInputStream, unserialize(), __PHP_Incomplete_Class,
  phar://). Сканер намеренно НЕ шлёт weaponised-gadget chain —
  достаточно подтвердить, что сервер вообще доводит недоверенные байты
  до своего нативного десериализатора.
• Time-based blind injection (scan_blind_injection, CWE-89 / 78
  / 943). Снимает baseline-время ответа тремя пробами, берёт медиану,
  затем внедряет sleep-пейлоады для SQL (MySQL SLEEP(3), MSSQL
  WAITFOR DELAY '0:0:3', PostgreSQL pg_sleep(3)), NoSQL
  ({"$where":"sleep(3000)"}) и OS-command (; sleep 3 #)
  семейств. Помечает цель как high, когда ответ под sleep-пейлоадом
  стабильно медленнее базового. Intrusive — каждая проба
  держит worker на цели ~3 с. CWE выбирается по семейству пейлоада
  (SQL → CWE-89, command → CWE-78, NoSQL → CWE-943), чтобы триаж
  попадал в нужный playbook.
• Stack trace leak (scan_stack_trace_leak, CWE-209). Шлёт
  пейлоады, которые с большой вероятностью валят наивный обработчик —
  NULL-байт в теле, переполненное целое, малформенный JSON / XML,
  type-confusion в query — и матчит ответ против language-specific
  паттернов (Java / Spring, Python, PHP, .NET, Node, Ruby, Go).
  Создаёт по одной аномалии medium на каждый distinct язык, чтобы
  полиглот-фреймворк, текущий несколькими стеками, дал отдельные
  remediation-контексты. Интенсивность safe-active.
• Утечка файловых путей (scan_path_disclosure, CWE-209).
  Отличается от утечки стек-трейсов: многие приложения отдают
  абсолютные пути (/var/www/html/uploads/..., C:\inetpub\wwwroot\...,
  /Users/...) в обычном JSON-ответе об ошибке без какого-либо
  стек-трейса. Зондирует каждый query-параметр payload’ами-«ловушками»
  (NUL-байт, битый UTF-8, длинная строка, traversal-последовательности)
  и поднимает аномалию при появлении одного из 16 известных префиксов
  пути (POSIX, Windows, macOS, Docker /app/src/). Severity
  поднимается до medium при ошибке сервера и высокой уверенности;
  на эндпоинтах, легитимно отдающих пути, сканер настроен молчать,
  чтобы держать precision высокой.
• Anomaly diff (scan_anomaly_diff, CWE-707). Универсальная
  baseline-mutate-compare сеть. Снимает базовый профиль ответа цели на
  исходных параметрах, затем мутирует каждый query-параметр батареей
  универсальных payload-классов (NUL-байт, длинная строка, Unicode
  RTL-override, битый UTF-8, малформенный JSON, отрицательное / огромное
  число, «голая» SQL-кавычка, CRLF-injection, format-string). Поднимает
  аномалию при заметном отклонении от базового профиля. Дополняет все
  остальные сканеры — ловит аномалии, которые не описываются известным
  CWE-классом (разовая ошибка сервера, утечка отладочной страницы,
  неожиданный редирект).
• Утечка PII (scan_pii_leak, CWE-359). Пассивный сканер — один
  запрос, проверка тела ответа на curated PII-паттерны. Покрывает US
  SSN, кредитные карты с валидацией Luhn (префиксы Visa / MC / Amex /
  Discover), IBAN, US + международные телефоны и российскую
  регулируемую триаду: ИНН (10 / 12 цифр), СНИЛС
  (NNN-NNN-NNN NN), паспорт (NNNN NNNNNN). Критично для 152-ФЗ и
  GDPR — единичная утечка паспорта = инцидент, подлежащий
  уведомлению регулятора. Email срабатывает только при ≥ 3 совпадениях,
  чтобы исключить false-positive на контактных формах. В аномалиях
  лежат редактированные образцы (первые 2 + последние 2 символа),
  чтобы хранилище findings само не стало вектором распространения PII.

Все семь сканеров встроены и работают на admin-ноде — раннер не нужен.
Intrusive проверки (smuggling, deserialization, blind injection)
блокируются на ручное подтверждение оператора перед каждым вызовом
(см. вкладку «Согласования»); safe-active и пассивные пробы
(стек-трейсы, утечка путей, anomaly diff, утечка PII) работают
автономно. Полный справочник — в руководстве
Фаззинг API; это тот же движок, просто перенесённый
под зонтик «Безопасность», чтобы весь offensive-инструментарий жил в
одном месте.

2. AI-агент

Задаёт профиль сканирования, который оркестратор передаёт
pentest-персонам. Профиль содержит:

• Цель — базовый URL или namespace Mockarty, чьи зарегистрированные
  эндпоинты становятся поверхностью атаки.
• Пресет профиля — baseline (пассивный recon, без аутентификации),
  authenticated (вы сами указываете учётные данные) или full
  (активная эксплуатация; может вызвать срабатывание WAF — запускайте
  только против своей цели).

Кнопка Запустить сканирование запускает скан и сразу добавляет
новую запись во вкладку «Отчёты». Скан выполняется в фоне —
переключитесь на вкладку «Отчёты», чтобы в реальном времени видеть,
как аномалии появляются по мере завершения работы каждой персоны.

3. Отчёты

GET /api/v1/security/reports?namespace=<ns> заполняет
пагинированный список исторических сканов. Каждая строка показывает:

• ID отчёта — открывает детальный вид с доказательствами по каждой
  аномалии (транскрипты request/response, ссылки CWE/CVE, recipe
  эксплуатации).
• Цель сканирования.
• Статус — pending, running, complete, cancelled, failed.
• Количество аномалий — суммарно по всем severity.
• Время старта.

Доступные форматы экспорта для отчёта:

• GET /api/v1/security/reports/{id}/export?format=sarif —
  SARIF 2.1.0 (GitHub Code Scanning, Sonar, плагины IDE).

• format=vex — OpenVEX 0.2.0 (метаданные раскрытия уязвимостей).

• format=html / format=pdf — человекочитаемые отчёты.

• format=allure — Allure 2 launch JSON: одна аномалия = один Allure
  test case. Кладётся в тот же Allure-приёмник, который уже
  питают Test Plans и TCM, поэтому функциональные результаты,
  contract-проверки и security-аномалии видны на одном дашборде.
  Сопоставление:

  Severity Mockarty	Allure status	Allure severity label
  critical	failed	blocker
  high	failed	critical
  medium	broken	normal
  low	skipped	minor
  info	skipped	trivial

  Найденная уязвимость всегда трактуется как упавший тест — в
  Allure нет статуса «passed» для существующей уязвимости. CVE-ID
  превращается в ссылку типа issue на NVD; CVE / CWE / OWASP /
  KEV / CVSS уходят в параметры; evidence и reproducer curl
  прикладываются как вложения text/plain и text/x-shellscript.
  Поток можно отправлять в существующий Allure-приёмник рядом с
  функциональными и contract-launch’ами.

Отменить запущенный скан:
POST /api/v1/security/reports/{id}/cancel.
Отмена запрашивает остановку сканирования, но не означает, что завершающая
обработка уже закончилась. При штатном завершении Mockarty также ждёт окончания
обработки ранее отменённых локальных сканирований в пределах времени остановки.

4. Согласования

Некоторые сканеры требуют явного согласования перед запуском —
обычно это шаги активной эксплуатации, разрушительные пейлоады или
действия против хостов вне области. Вкладка «Согласования» вызывает
GET /api/v1/security/approvals?namespace=<ns> и показывает каждый
ожидающий запрос: тип, цель, инициатор, время.

В каждой строке есть кнопки Подтвердить и Отклонить. Любая
из них отправляет
POST /api/v1/security/approvals/{id}/decide с соответствующим
телом {"decision":"approved"|"rejected"}. Оркестратор продолжает
скан, как только решение приходит.

Решение по всему прогону сразу. Строки группируются по прогону;
Одобрить все / Отклонить все отправляют один запрос
POST /api/v1/security/reports/{id}/approvals/decide вместо вызова на
каждый гейт.

Аппруверы по умолчанию и маршрутизация. В пространстве можно назначить
аппруверов по умолчанию (вкладка Approvals → поле Аппруверы по умолчанию,
сохраняется через PUT /api/v1/security/approval-settings). Новые pause-гейты
маршрутизируются этим ревьюерам — отображаются как Назначено в строке, и
каждому приходит уведомление (колокольчик + его каналы). Принять решение по
гейту может только участник пространства (роли аудитора достаточно —
проверка отделена от запуска скана).

Опциональное авто-истечение. Задайте MOCKARTY_SECURITY_APPROVAL_TTL_MINUTES
(env, до запуска; по умолчанию выключено), чтобы гейт, по которому никто не
принял решение в течение TTL, авто-истекал (трактуется как отклонение) и не
держал отчёт в awaiting_approval вечно. Очистка — leader-only в кластере.

Опциональный кворум N-из-M. Для разделения обязанностей можно потребовать
более одного отдельного аппрувера перед освобождением гейта. Задайте (env, до
запуска; по умолчанию 1 = одно одобрение) MOCKARTY_SECURITY_APPROVAL_QUORUM_DESTRUCTIVE
и/или MOCKARTY_SECURITY_APPROVAL_QUORUM_INTRUSIVE. При кворуме 2 первое
одобрение записывает голос, строка остаётся pending (ответ содержит
{approvals, required}); второй ОТЛИЧНЫЙ аппрувер освобождает гейт. Одно
отклонение убивает гейт сразу, независимо от кворума. Такие гейты решаются
по одному — Одобрить все их пропускает (один актор не наберёт N-из-M).

Пред-авторизация прогона (пресет автономии). При запуске скана селектор
Approval autonomy может заранее одобрить требующие подтверждения сканеры
до выбранного потолка интенсивности — интрузивный прогон идёт без паузы на
каждом действии, а destructive-хвост всё равно гейтится. По умолчанию —
Гейтить каждое действие.

5. База знаний

Агент безопасности опирается на курируемую офлайн-базу знаний. Корпус
индексируется локально при старте и перечитывается по расписанию (раз в шесть
часов), а также по кнопке «Переиндексировать сейчас» — во время
сканирования внешние сетевые вызовы не выполняются, поэтому агент
одинаково хорошо работает и в полностью изолированных (air-gapped)
развёртываниях.

Проиндексированные источники:

Поставка офлайн-корпуса (air-gapped). Задайте MOCKARTY_SECURITY_KB_FEEDS_DIR
(каталог) и положите туда файлы фидов до запуска — агент индексирует каждый
присутствующий файл на старте: nvd.json, kev.json, attack.json (ATT&CK
STIX), atlas.json (ATLAS STIX), cwe.xml, capec.xml. OWASP Top 10 встроен
(файл не нужен). Если переменная не задана, агент работает только на
custom-документах пространства и ручном обновлении — маленькую установку по
умолчанию это не нагружает.

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

Собственные документы. На вкладке «База знаний» workspace может загружать
свои документы (спецификации продукта, модели угроз, внутренние плейбуки) — агент
сверяется с ними перед планированием сканирования. Удаление документа — решение,
которое workspace сохраняет: документ не возвращается в корпус после перезапуска
или переиндексации, и фид не может добавить его заново, даже с изменённым
содержимым. Список «Удалённые документы» показывает, кто и почему удалил;
«Восстановить» возвращает документ и индексирует его снова. Те же операции
доступны по API: POST /api/v1/security/kb/docs (загрузка),
DELETE /api/v1/security/kb/docs/{id} (удаление, опционально reason),
GET /api/v1/security/kb/docs/suppressed и POST /api/v1/security/kb/docs/{id}/restore.

В многоузловом кластере каждый узел держит собственный поисковый индекс корпуса,
но загрузка, удаление или восстановление вступают в силу на всех узлах сразу:
обслуживший узел сообщает остальным, а они читают документ из общей базы. Узел,
ненадолго потерявший связь с кластером, при переподключении перечитывает весь
корпус. Источники-фиды и переиндексацию настраивает администратор платформы через
/api/v1/security/kb.

6. Стоимость

Вкладка «Стоимость» показывает расходы на сканирования и график по дням или часам. Проверьте её перед запуском следующего сканирования, чтобы оценить затраты.

7. LLM-профили агентов

Во вкладке «LLM-профили агентов» выбирают подключение к модели для агента безопасности. Провайдеры и порядок настройки описаны в разделе LLM-профили выше.

Разрешения и лицензирование

• Видимость в сайдбаре — грант fuzz, testing или security
  может открыть вкладку «Сканеры». Для остальных шести вкладок нужно
  персональное место security. В старых настройках этот модуль может
  называться security_agent.
• Доступ к вкладкам — «AI-агент», «Отчёты», «Согласования»,
  «Стоимость», «База знаний» и «LLM-профили агентов» требуют место Security.
  API проверяет права отдельно от отображения вкладок.
• Исторические данные — если enterprise-грант истёк, чтение
  существующих отчётов сохраняется (write-операции запрещены). Это
  соответствует общеплатформенному правилу сохранения исторических
  данных.

Встроенные сканеры инъекций

Встроенные сканеры включают по одному на класс атаки.
Четыре сканера ниже закрывают семейства инъекций, которые не покрывает
обычный SQLi / command-injection / XXE / SSTI: они не требуют внешнего
runner’а и запускаются на тире интенсивности intrusive, поэтому по
умолчанию pause-gate’ятся в каждой персоне.

Каждый сканер опрашивает все URL query-параметры цели и останавливается
на первом подтверждённом совпадении. Severity поднимается до critical,
если ответ — 5xx (утёкшее unhandled-исключение), иначе остаётся high.
Каждый finding фиксирует параметр, использованный payload, статус ответа
и совпавший фрагмент, плюс готовый к вставке curl -i-reproducer.

Подключение внешних агентов

Агент безопасности из коробки содержит набор встроенных сканеров,
которые admin-нода запускает сама (HTTP-зонды, проверки заголовков,
пассивные анализаторы). Для инструментов
с тяжёлым runtime — nmap, sqlmap, hydra и других из набора
Kali — Mockarty использует отдельный бинарь runner
(mockarty-redteam-runner), который запускается на отдельном хосте и
принимает задачи по A2A.

Два раннера

Mockarty поставляет два образа раннеров, оба на базе Kali. Запускайте те
уровни, которые вам нужны:

• mockarty/redteam-runner (порт 8500) — разведка и сканирование:
  сканы сетевых портов, глубокая проверка SQL-инъекций, аудит SSH / SMB,
  CIS-бенчмарк Kubernetes, статический анализ мобильных приложений, подбор
  паролей. Этот уровень нужен большинству команд.
• mockarty/exploit-runner (порт 8501) — уровень эксплуатации:
  превращает подтверждённую слабость в доказательство (например, выгружает
  данные через SQL-инъекцию или подделывает слабый токен). Каждое действие
  здесь по умолчанию проходит через подтверждение (см. Approvals).
  Запускайте его, только когда хотите, чтобы агент продемонстрировал
  воздействие, а не просто сообщил о проблеме.

Оба раннера сами регистрируются у admin-ноды при старте и появляются в
Admin → Remote Agents. Без раннера встроенные сканеры всё равно
покрывают web / API / cloud-control-plane / contract / GraphQL / gRPC /
WebSocket.

Развёртывание раннера

Нужны два значения — их задают в .env (Compose) или в secret чарта (Helm):

• API-токен — выпустите его в UI админ-ноды в Настройки → API-токены.
  Он идентифицирует раннер перед admin-нодой.
• Регистрационный секрет — любая достаточно случайная строка, которую
  вы придумываете сами. Используйте одно и то же значение для всех
  раннеров вашего флота. Он защищает связь между admin-нодой и раннерами. В
  UI он не вводится — живёт только в окружении раннера.

Docker Compose (рекомендуется) — раннеры под профилем security:

# .env
SECURITY_RUNNER_API_TOKEN=mk_...            # из Настройки → API-токены
SECURITY_RUNNER_SECRET=<придумайте-надёжный-секрет>
SECURITY_RUNNER_NAMESPACE=production

docker compose --profile security up -d

Поднимутся оба раннера; они авторегистрируются и через несколько секунд
появятся в Admin → Remote Agents.

Kubernetes (Helm) — включите redteamRunner (а для уровня эксплуатации —
exploitRunner) в чарте и передайте те же два значения через secret чарта.

Подключение за NAT или в CI (pull-режим)

По умолчанию admin пушит задачи раннеру — для этого раннер должен быть
доступен по своему callback-URL. Когда admin не может достучаться до раннера
(раннер за NAT или это эфемерный CI-воркер без стабильного адреса),
переключите раннер в pull-режим, где он сам запрашивает работу у admin:

• redteam-runner: добавьте --pull-mode
• exploit-runner: добавьте --pull

В pull-режиме callback-URL не обязателен. Для CI-задач, которые поднимают
раннер, отрабатывают одну порцию работы и гасятся, ограничьте время жизни
раннера через --max-tasks=N, --once (ровно одна задача), --drain (не принимать новых) и/или --drain-after-idle=2m; раннер сам
снимется с регистрации и завершится чисто, не оставляя «призраков» в списке
активных раннеров.

Пока сканер работает, раннер продлевает именно ту аренду задачи, которую
получил. Если аренда истекла или задача была выдана заново, запоздалые
heartbeat и результат старой попытки отклоняются и не могут перезаписать итог
текущего сканирования.

Защита соединения

• Держите раннеры в доверенной сети и используйте HTTPS для URL admin и
  callback-URL раннера в продакшене, чтобы регистрационный секрет не
  передавался в открытом виде.
• Выберите надёжный случайный секрет и храните его в менеджере секретов
  (Compose .env, Kubernetes Secret или vault), а не в системе контроля
  версий.
• Ротация — поменяйте значение и перезапустите раннер.
• Каждый раннер обслуживает один workspace (--namespace); admin отклоняет
  задачи между пространствами имён.

Управление раннерами

Откройте Admin → Remote Agents, чтобы увидеть все зарегистрированные
раннеры, их статус (активен / истёк) и навыки, которые они объявляют. Оттуда
можно временно отключить раннер (admin перестанет слать ему работу),
снова включить его или удалить. Раннер, переставший отвечать,
автоматически помечается как истёкший и пропускается, пока не переподключится
— ручная очистка не нужна.

Сканеры раннеров и параметры эксплуатации

Список сканеров в конструкторе профилей показывает обе половины каталога:
сканирующие модули самого admin-узла и навыки, которые объявляет
зарегистрированный раннер. Строки раннера помечены значком раннер и
работают только пока он онлайн. Правила у них те же, что у встроенных
сканирующих модулей: потолок интенсивности профиля отсекает всё, что выше, а
intrusive- или destructive-навык приостанавливает скан в разделе
«Одобрения», если вы не предодобрили этот тир автономным пресетом.

Навыку эксплуатации нужны ещё и параметры — module для Metasploit, тот самый
param, по которому должен отработать дамп sqlmap. Заполняются они из двух
источников:

• executorOptions в профиле скана, по ключу сканера (например
  {"exploit_msf": {"module": "exploit/unix/ftp/vsftpd_234_backdoor", "payload": "cmd/unix/interact"}});
• автономный цикл — он выводит их из уже найденных находок: находка SQL-инъекции
  даёт параметр, находка с CVE даёт модуль, если Mockarty знает его для этой CVE.

Значение, заданное вами, всегда важнее выведенного: ваш lhost — это решение,
а выведенный параметр — лишь значение по умолчанию.

Артефакты доказательств (opt-in). Поле evidence у находки ограничено
несколькими килобайтами, а дамп, транскрипт или скриншот, доказывающий результат
эксплуатации, в него не влезает. При MOCKARTY_SECURITY_ARTIFACTS=on раннер
загружает эти байты, находка несёт ссылку, HTML-отчёт на неё ссылается, а скачивание
идёт через маршрут отчёта — с проверкой пространства имён и аутентификацией.
По умолчанию ВЫКЛЮЧЕНО осознанно: артефакт при находке эксплуатации часто
представляет собой сырой дамп учётных данных, поэтому включение — это осознанное
решение хранить такой материал в blob-хранилище платформы (по умолчанию файловая
система, S3-совместимое через обычные настройки blob, с теми же правилами хранения
и доступа, что у прочих вложений). При выключенном артефакте раннер продолжает
отправлять текстовые доказательства и записывает причину отсутствия артефакта.
Человек открывает артефакт из HTML-отчёта; агент читает те же байты инструментом
security_get_finding_artifact — доказательство достижимо и из UI, и из
автономного прогона.

Шаги, которым нужны учётные данные (боковое перемещение, добор кредов, проверка
повышения привилегий), ссылаются на добытые креды через непрозрачный handle, а не
несут их в себе: материал держит брокер внутри процесса exploit-runner, поэтому он
не попадает ни в задание, ни в отчёт, ни в выгрузки, ни в резервную копию. Два
следствия, которые стоит учитывать: handle не переживает перезапуск этого раннера
и у него есть срок жизни. В обоих случаях шаг завершается явной находкой
«credential unusable», а не попыткой аутентификации ни с чем — потерянный handle
видно, а не тихо. Карточка одобрения
показывает точные параметры, то есть вы одобряете команду, а не категорию.
Mockarty никогда не выдумывает адрес атакующего: модуль, которому он нужен,
называется без него, и исполнитель откажется работать вместо того, чтобы
стучаться на хост, который никто не выбирал.

Проведение engagement’а с эксплуатацией

Всё, что нужно тиру эксплуатации, доступно из конструктора профилей: выставьте
Тир интенсивности → Destructive, отметьте нужные эксплойт-навыки в allow-list
сканеров (они помечены значком runner и требуют онлайн exploit-runner), а
параметры инструментов положите в «Параметры инструментов (JSON)» — например
module и payload для Metasploit или параметр для sqlmap. Оставьте автономию
одобрений на «Гейтить каждое действие» — тогда каждый destructive-шаг
приостанавливается на ваше подтверждение с показом точных параметров; либо
выберите «Полная автономия», чтобы предодобрить этот тир на весь прогон.

Автономные, необслуживаемые пути намеренно останавливаются ниже него: deep-security
проход миссии пропускает все destructive-навыки, а скан, запущенный агентом, не
может сам себе выдать destructive-тир — то есть инструмент, меняющий данные, никогда
не запускается без именованного решения человека. Когда прогону нужно дойти до тира
эксплуатации, его запускает человек.

Прохождение по UI

В разделе «Безопасность» три задачецентричные вкладки плюс уже
существующие «Сканеры» и «База знаний»:

1. Сайдбар → Безопасность. Открывает раздел.
2. Конструктор профиля сканирования. Заполните цель (базовый URL
   или namespace), выберите персону, сузьте allow-list сканеров,
   выберите уровень интенсивности, при желании задайте cost budget
   и нажмите Запустить сканирование. Форма отправляет
   POST /api/v1/security/scans и перебрасывает на детальный вид
   нового отчёта.
3. Отчёты. Кликните по строке отчёта, чтобы открыть детальный
   вид. Страница в реальном времени опрашивает статус, показывает
   аномалии по мере поступления, рисует граф цепочки атак и
   предоставляет четыре формата экспорта (SARIF / VEX / HTML / PDF).
4. Согласования. Просмотрите все pause-gate решения, которые
   оркестратор пометил как требующие участия человека — обычно это
   intrusive- или destructive-режимы сканеров. Подтвердите или
   отклоните; скан продолжится сразу после прихода решения.

Справочник конфигурации раннера

Оба раннера принимают одинаковые флаги подключения; у каждого флага есть и
эквивалент в виде переменной окружения MOCKARTY_* (удобно для Compose /
Helm, которые передают конфигурацию через env). Основные настройки:

Отличия redteam и exploit:

• Флаг pull-режима: redteam-runner использует --pull-mode, exploit-runner —
  --pull.
• У exploit-runner /healthz по умолчанию на :8501 (‡), а его переменные
  окружения allow-list / меток — с префиксом EXPLOIT (†):
  MOCKARTY_EXPLOIT_ALLOWED_TOOLS и MOCKARTY_EXPLOIT_LABELS.
• --runner-name (MOCKARTY_RUNNER_NAME) применим только к redteam-runner;
  exploit-runner регистрируется под именем своего контейнера.

Каналы уведомлений

Каждая аномалия, сохранённая в отчёт, дополнительно сверяется с порогом severity
(по умолчанию high). Если порог достигнут — аномалия отправляется в
ту же фабрику уведомлений, которую используют Test Plans,
performance-тесты и fuzzing: Slack / Telegram / email / webhook /
Discord / Teams / Mattermost.

Маршрутизация происходит через стандартный UI Channel Bindings; никакой
отдельной конфигурации для безопасности не требуется.

1. Откройте Админ → Каналы уведомлений и создайте транспорт,
   через который хотите получать аномалии (Telegram-бот, Slack webhook,
   корпоративный SMTP, generic webhook URL и т. д.).
2. В том же UI создайте Channel Binding на этот канал с типом
   события security.finding.recorded. Binding можно ограничить
   namespace’ом — так prod-аномалии попадут в дежурный чат, а staging
   — в более тихий.
3. Запустите скан. Каждая аномалия severity high или critical
   отправляет одно событие в binding. Шаблон канала по умолчанию
   рендерит заголовок, severity, цель, ключ сканера и deep-link на
   страницу отчёта. Шаблон можно переопределить per (event, channel,
   language) в Уведомления и каналы → Шаблоны сообщений.

Низкие severity (info, low, medium) намеренно не отправляются —
оператор видит их в таблице аномалий отчёта, но не получает пинг в
Slack/Telegram. Это согласуется с общей политикой шума Mockarty:
уведомление только тогда, когда нужен человеческий триаж.

Если канал недоступен (transport упал, rate-limit, открыт circuit
breaker) — сбой логируется, а аномалия остаётся в отчёте; доставка
канала — best-effort и никогда не блокирует скан.

MCP-инструменты

Когда лицензия security_agent активна, MCP-сервер admin-ноды
публикует перечисленные ниже инструменты Агента безопасности для
аутентифицированных MCP-клиентов (AI-чаты, sub-агенты, скриптовые
автоматизации). Имена инструментов стабильны и гейтятся тем же
feature-флагом, что UI и REST.

• security_list_agents — список зарегистрированных A2A-runner’ов
  в namespace’е вызывающего. По строке на агента: id, name,
  status, capabilities, lastHeartbeatAt, callbackUrl. Без
  обязательных аргументов (namespace берётся из закреплённого за
  вызывающим).
• security_list_scanners — список встроенных сканеров.
  Каждая строка содержит key, persona, intensity —
  по ним можно выбрать сканер до запуска скана.
• security_start_scan — запустить полный профиль скана.
  Обязательные аргументы: title (метка) и profile (JSON-объект
  ScanProfile — scopeDescription, intensity, targets, плюс
  опциональные cost / rate caps). Возвращает созданную строку
  report; сам скан выполняется в фоне.
• security_get_report — получить один отчёт по reportId.
  Возвращает статус, profile, счётчики стоимости, метки времени
  startedAt / completedAt.
• security_list_findings — все finding’и привязанные к отчёту.
  Обязательно: reportId. По строке: severity, CVE / CWE / OWASP
  идентификаторы (если применимо), evidence, reproducer-curl и
  предложенный remediation.
• security_get_finding_artifact — получить артефакт-доказательство,
  привязанный к finding’у (полный дамп, транскрипт инструмента или вывод
  скана, который поле evidence лишь пересказывает). Обязательно: reportId
  и findingId. Возвращает {ref, filename, size, encoding, content, truncated} — текст inline как utf-8, бинарь как base64, большие
  артефакты обрезаются с truncated:true (size — полная длина в байтах).
  404 — у finding’а нет сохранённого артефакта, 503 — на этом узле хранение
  артефактов не включено. Это агентский путь к тем же байтам, которые
  человек скачивает из отчёта.
• security_export_report — рендер отчёта в portable-формате.
  Обязательно: reportId и format (sarif | vex | html |
  pdf | allure). Возвращает сырые байты с Content-Type от
  сервера. allure — Allure 2 launch JSON, чтобы аномалии попали в
  тот же Allure-приёмник, что и Test Plans / TCM.
• security_decide_approval — одобрить или отклонить
  pause-gated шаг, который оркестратор вывел на human review.
  Обязательно: approvalId и decision (approve | reject).
  Опциональный reason сохраняется в строке approval для аудита.
• security_triage_finding — пометить одну аномалию как
  confirmed / false_positive / duplicate / wont_fix /
  resolved (или вернуть к auto). Обязательно: findingId и
  status. Опциональный note несёт причину оператора в audit
  trail. Используйте после security_list_findings, чтобы закрыть
  заведомо ложное срабатывание или перевести аномалию в
  «исправлено» после фикса. REST-эквиваленты —
  POST /api/v1/security/findings/{id}/triage и
  POST /api/v1/security/findings/triage-bulk (тело
  {ids, status, note?} для массового варианта).

Набор дополняют инструменты для автоматизации и отчётности:

• security_list_reports — список недавних отчётов в namespace (id,
  название, статус, число аномалий), чтобы найти отчёт перед запросом.
• security_bulk_scans — запустить несколько сканирований одним
  вызовом (по одному на цель) — удобно для обхода списка хостов из скрипта.
• security_cancel_report — остановить идущее сканирование.
• security_merge_reports — объединить несколько отчётов в один сводный.
• security_dedupe_findings — схлопнуть дубликаты аномалий в отчёте.
• security_kb_search — поиск по Базе знаний подтверждённых аномалий
  (см. вкладку «База знаний»). Каждый результат называет свой корпус
  (corpus, для этой базы знаний — security_kb), а необязательный
  аргумент corpus сужает поиск до одного корпуса: security_kb,
  product_context (документы, описывающие продукт) или experience
  (что выяснили прошлые прогоны). Любое другое значение отклоняется
  с перечислением известных.
• security_save_template / security_load_template — сохранить
  профиль сканирования как шаблон и загрузить его при запуске нового скана.

Каждый инструмент проходит через ту же per-namespace авторизацию + аудит,
что и REST-эндпоинты, поэтому MCP-клиент не может читать отчёт другого
workspace’а даже зная ID.

Prometheus-метрики

Агент безопасности и реестр A2A-пиров публикуют Prometheus-коллекторы
на стандартном эндпоинте /metrics. Каждая метрика несёт
общеплатформенные const-labels node_id, environment и version,
поэтому агрегации по multi-node-кластеру работают «из коробки».

Счётчики

Гистограммы

Гейджи

Гейджи обновляются каждые 15 секунд leader-only фоновой задачей,
которая читает реестр + очередь pending approvals.

Типовые запросы Grafana

Findings в минуту по severity:

sum by (severity) (rate(mockarty_security_finding_recorded_total[5m])) * 60

p95 длительности прогона по статусу:

histogram_quantile(0.95, sum by (le, status) (rate(mockarty_security_scan_duration_seconds_bucket[10m])))

Доля неуспешных удалённых диспатчей за последние 30 минут:

sum(rate(mockarty_security_dispatch_latency_seconds_count{outcome!="success"}[30m]))
/
sum(rate(mockarty_security_dispatch_latency_seconds_count[30m]))

Длина очереди approval’ов по namespace (алёрт при стабильно > 5):

max by (namespace) (mockarty_security_pending_approvals)

Срабатывания cost-cap в час (любое ненулевое значение — повод
разобраться: либо ёмкость подкручена не туда, либо автоматизация
ломает агента):

sum by (namespace, scope) (rate(mockarty_security_cost_limit_reached_total[1h])) * 3600

CI/CD: запуск сканов из скриптов

CLI и SDK раскрывают только operator-friendly surface — запустить
скан, опросить статус, получить findings, скачать SARIF/HTML/PDF,
посмотреть scanner-каталог, отменить запуск. Админ-операции (LLM-
профили, включение агентов, шаблоны сканеров) живут в админ-UI.

CLI (mockarty-cli)

mockarty-cli security list-scanners --namespace prod
mockarty-cli security start-scan --namespace prod \
    --target https://api.example.com \
    --persona web_pentester --intensity passive
# → "Scan started: 8f3a... (status=running)"
mockarty-cli security get-report 8f3a...
mockarty-cli security list-findings 8f3a... --severity high
mockarty-cli security export 8f3a... --format sarif -o scan.sarif.json
mockarty-cli security list-agents --namespace prod
mockarty-cli security cancel 8f3a...

Go SDK

client := mockarty.NewClient(os.Getenv("MOCKARTY_URL"),
    mockarty.WithAPIKey(os.Getenv("MOCKARTY_API_KEY")))
rep, _ := client.Security().StartScan(ctx, mockarty.StartScanRequest{
    Title: "ci-nightly", Namespace: "prod",
    Profile: mockarty.SecurityScanProfile{
        Intensity:        "passive",
        ScopeDescription: "https://api.example.com",
        Targets: []mockarty.SecurityTarget{{URL: "https://api.example.com"}},
    },
})
sarif, _ := client.Security().ExportReport(ctx, rep.ID, "sarif")
_ = os.WriteFile("scan.sarif.json", sarif, 0o644)

Полный пример: sdk/go-sdk/examples/security_scan/main.go.

Python SDK

from mockarty import MockartyClient

with MockartyClient(namespace="prod") as c:
    rep = c.security.start_scan(
        namespace="prod", target="https://api.example.com",
        persona="web_pentester", intensity="passive")
    # ... опрос c.security.get_report(rep["id"]) пока не терминал
    sarif = c.security.export_report(rep["id"], format="sarif")
    open("scan.sarif.json", "wb").write(sarif)

Полный пример: sdk/py-sdk/examples/security_scan.py.

Java SDK

try (MockartyClient c = MockartyClient.builder()
        .baseUrl(System.getenv("MOCKARTY_BASE_URL"))
        .apiKey(System.getenv("MOCKARTY_API_KEY"))
        .namespace("prod").build()) {
    Map<String, Object> rep = c.security().startScan(
        "prod", "https://api.example.com",
        "web_pentester", "passive", "ci-nightly");
    byte[] sarif = c.security().exportReport((String) rep.get("id"), "sarif");
    Files.write(Path.of("scan.sarif.json"), sarif);
}

Полный пример: sdk/java-sdk/examples/src/main/java/ru/mockarty/examples/SecurityScanExample.java.

Что нового в v1.1

Live-прогресс по каждому сканеру

Панель отчёта теперь показывает два прогресс-бара во время сканирования:

• Прогресс плана — счётчик оркестратора «сканер N из M», помеченный
  текущей персоной («Персона: api_pentester»).
• Прогресс сканера — внутренний счётчик активного сканера
  («scan_sqli — payload 1247 / 5000»). Длинные сканеры сообщают свой
  прогресс в реальном времени; бар заполняется по мере обхода списка
  нагрузок и сбрасывается, когда стартует следующий сканер.

Оба бара обновляются через SSE (/api/v1/events?subscribe=security_progress)
без поллинга. Если SSE-соединение прерывается — автоматически
включается резервный 3-секундный опрос; небольшая надпись сообщает
оператору, что бар обновится на следующем тике.

CVE-алерты (CISA KEV / повышение CVSS)

Leader-only шедуллер обходит прошлые аномалии namespace’а на каждом
тике (по умолчанию 1 час) и отслеживает у каждой уникальной CVE два
перехода в базе знаний:

• Добавление в CISA KEV — KEV=false → true. Появляется
  синтетическая аномалия уровня Critical с заголовком «{CVE} added to
  CISA KEV catalogue».
• Рост CVSS-оценки ≥ 1.0 — KB переоценила CVE вверх. Появляется
  синтетическая аномалия уровня High с дельтой балла.

Каждый переход срабатывает ровно один раз для пары
(namespace, cveID) — повторные дубли на последующих тиках
подавляются автоматически. Алерты идут через те же per-namespace
каналы (Telegram / Slack / email / webhook), что и обычные аномалии;
Scanner помечается как cve_alert, чтобы правила канала могли
фильтровать их.

«Найти похожие прошлые аномалии» в модалке

При открытии аномалии появилась кнопка Найти похожие прошлые
аномалии. По клику делается запрос GET /api/v1/security/kb/similar
с тройкой (title, scanner, cwe), и top-N результатов отображаются
inline. Чекбокс переключает: включать ли past-findings из текущего
namespace, или ограничиться только curated-каталогом (NVD / CWE /
OWASP).

Сравнение с предыдущим сканом (baseline diff)

В тулбаре отчёта появилась кнопка Сравнить с предыдущим. Берёт
самый свежий терминальный отчёт в том же namespace, отличный от
текущего, и POST’ит /api/v1/security/reports/diff, показывая в
модалке: Новые аномалии / Исправлено (исчезло) / Без изменений / Без
цели. Сопоставление — по стабильному отпечатку идентичности аномалии
(сканер, цель и класс уязвимости), поэтому мелкие переформулировки от
запуска к запуску не ломают diff.

Панель задач агентов

Задачи агентов открываются бейджем очереди в шапке — отдельной страницы для них
нет. Панель собирает задачи AI-агентов (security, code-review, TCM-drafter, …) в один список с
фильтром по статусу, отменой запущенных задач и открытием транскрипта. Страница
«Задачи» (/ui/tasks) показывает ту же активность рядом с задачами трекера, а сканы,
запущенные из чата, несут agentTaskId, так что вкладка «Отчёты» и панель задач
показывают одну и ту же работу с двух сторон.

Кнопка «Переиндексировать сейчас» в KB

Кнопка Переиндексировать сейчас (admin-gated) перечитывает файлы фидов
оператора (MOCKARTY_SECURITY_KB_FEEDS_DIR) и обновляет индекс на месте, не
дожидаясь планового тика. Повторные клики безопасны: документ с неизменным
содержимым пропускается, изменённый заменяет предыдущую версию, поэтому каталог
не разрастается. Если каталог фидов не задан, действие сообщает, что
перечитывать с диска нечего.

Выберите, что сканировать

В Конструкторе сканов выберите хотя бы одну персону. Отметьте отдельные
сканеры, если хотите сузить проверку; пустой список сканеров запускает все
сканеры выбранных персон. В автоматизированном профиле
тот же выбор задают поля allowedPersonas и allowedScanners.

Следите за расходами

На вкладке Стоимость показан график затрат в USD по дням или часам. Наведите
курсор на столбец, чтобы увидеть число запусков.

Попросите агента безопасности

Откройте чат или нажмите Попробовать в чате в Конструкторе сканов. Например:

• «Просканируй https://staging.api.acme.com». Перед более активной проверкой
  агент уточнит разрешение на тестирование, интенсивность и исключения.
• «Покажи активные проверки» или «Останови проверку api.acme.com».
• «Запусти базовую проверку для этих 10 хостов». Один запрос может запустить
  до 25 проверок.

Если для следующего шага требуется одобрение, запрос появится в чате.

Связанные руководства

• Фаззинг API — движок, на котором работает вкладка
  «Сканеры».
• База знаний (RAG) — тот же RAG-слой,
  переиспользуемый в Агенте безопасности.
• Безопасность и соответствие —
  общеплатформенные контролы (аудит, шифрование PII, KeyStore, SIEM
  export).
• Модель угроз (STRIDE) — собственная модель
  угроз Mockarty; Агент безопасности намеренно сканирует пользовательские
  цели, а не сам инстанс Mockarty.