K-Guard MCP

Старший коллега по очкам · Старший коллега по вайбкодингу

Поток создания не прерываем, но выпуск не пропускаем кое-как.

K-Guard MCP — это локально-ориентированный MCP-аудитор, который перед выпуском результатов вайбкодинга проверяет вместе с вами сайт, экспозицию API, управление данными и операционные риски. Guardian различает «проблем нет» и «ещё не видел», возвращая вердикт можно выпускать / исправить и выпускать / недостаточно объёма проверки и следующие действия на корейском языке.

K-Guard не является гарантийным документом, заменяющим человеческие бизнес-решения или юридическую проверку. Он автоматизирует вопросы, которые старший разработчик задаёт перед выпуском, и fail-closed шлюзы.

Установка за 5 минут · Установка и проверка дизайна · Руководство по использованию · Инструкция по публикации на GitHub · Обязательная квалификация · Северная звезда продукта · Полная оценка dogfood · Подготовка к конкурсу 2026

Первые 5 минут: текущий исходный код

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

python -m pip install .
k-guard install --client auto --profile local-dev --workspace .
k-guard doctor --client auto

auto находит установленные Grok, Codex, Antigravity, объединяет MCP k-guard в пользовательскую область, а если есть OpenAI tunnel-client, подготавливает локальный профиль для ChatGPT. --workspace . фиксирует текущий проект как private binding. После этого, даже если MCP запускается из другого рабочего каталога, он проверяет этот проект, а пути за пределами границы отклоняет как high HOLD. Для ChatGPT doctor/run также требуется CONTROL_PLANE_API_KEY с правами Tunnels Read + Use в текущей оболочке. Поскольку после этого для ChatGPT остаются tunnel-client run и подключение приложения в режиме разработчика, установщик не приукрашивает успех и возвращает частичное подключение · требуются следующие шаги. Существующие настройки сохраняются, перед изменением JSON создаётся резервная копия, а ключи доказательств оператора и исходный текст workspace сохраняются только в пользовательских файлах ~/.k-guard. local-dev включает только localhost read-only probe и небольшой фиксированный углублённый путь, внешние и сессионные probe остаются выключенными. Если нужна только статическая проверка, используйте --profile workspace.

Базовый вывод установки и диагностики состоит из трёх этапов: готовность подключения → AI-клиент → следующие действия. Для автоматизации используйте install --json, doctor --json. Для воспроизводимости судейства конкурса и релиза, а также для исправления кода используйте путь проверки судейства и воспроизводимости из установки за 5 минут, устанавливая build и evidence lock с --require-hashes. Semgrep 1.174.0 и pip-audit 2.10.1 также устанавливаются с полным hash closure из requirements-semgrep.lock и requirements-pip-audit.lock соответственно в изолированный venv, не изменяя проверяемую среду выполнения.

В MCP-клиенте:

안경선배로 이 앱을 끝까지 봐줘. check_my_app으로 전체 검수를 시작하고,
continue_review를 state=completed 또는 failed가 될 때까지 반복해줘.
완료 전에는 통과라고 말하지 마. 코드를 고쳤다면 check_my_app을 다시 완료해줘.
출하 전에는 실제 사업 목적과 범위를 확인한 뒤 최신 review_id로
start_review_before_ship을 실행하고 다시 continue_review로 Guardian 완료까지 기다려줘.
experience.presentation 순서대로 판정, 이유, 다음 행동 3개만 먼저 말해줘.

check_my_app — это не проверка, которая кое-как завершается за 5 секунд, а инструмент приёма полной аудиторской проверки всего workspace. Первый ответ — review_in_progress, и до завершения continue_review вердикт о выпуске не выносится. Проверяются также текстовые артефакты для развёртывания в dist, build, .next; если количество кандидатов, SHA-256 путей и завершение чтения не совпадают, блокируется как high. По завершении выдаётся review_receipt, привязанный к SHA-256 workspace и дерева исходников. Если код изменился, начать проверку выпуска со старым review_id нельзя — нужно заново завершить check_my_app.

Related MCP server: Secure Code Review MCP Server

Вердикт старшего коллеги по очкам

Все основные результаты предоставляют совместимый с experience.presentation алиас experience.details.presentation, порядок фиксирован: verdict → why → next_actions → details. Guardian показывает риск приложения отдельно как application_assurance, а статус валидации самого инструмента аудита — как auditor_qualification. experience.verdict_code, experience.verdict_message, experience.summary — это поля, совместимые с существующими отчётами.

Что проверяется

K-Guard объединяет:

• Статическое сканирование: корейские PII, составные PII, корейские идентификаторы организаций (синтаксическая проверка контрольной суммы 사업자등록번호; распознавание 법인등록번호 по историческому приложению контрольной суммы или по явному контексту/синтаксису 4+2+7 после 2025-01-31, без проверки в живом реестре), секреты

• Сканирование конфигурации: риски CORS/debug/source map/env prefix

• Сканирование рисков уровня старшего разработчика: прямые request-to-SQL/command/file/URL/HTML sink'и, массовое присваивание, open redirect, хранение токенов в браузере, слабые cookie, сравнение паролей в открытом виде, JWT decode без verify

• Сканирование корейского управления данными: объявления уникальных/чувствительных полей, доказательства шифрования и контроля доступа, журналирование доступа, проверка внешних обработчиков, сроки хранения и удаление

• MCP-нативное сканирование угроз: скрытые инструкции, отравление инструментов, намерение эксфильтрации и чрезмерно широкий локальный доступ по прямому тексту плюс ограниченные Unicode/confusable, escaped/percent/HTML, Base64, split-fragment и трёхстрочная скользящая нормализация

• Структурированная проверка MCP-конфигурации: shell-обёртки, изменяемые загрузчики пакетов, обычный удалённый HTTP, фиксированные учётные данные, небезопасные ссылки/ошибки чтения и fail-closed границы обнаружения по кандидатам конфигурации project/Codex/Grok/Antigravity

• Локальный набор правил YARA-lite: маркеры prompt-injection, маркеры команд эксфильтрации, намёки на массовые корейские схемы

• Безопасный динамический probe: проверки localhost HTTP, явно авторизованные проверки внешних источников, опциональные ограниченные проверки глубокой экспозиции, а также опциональные предоставленные пользователем read-only заголовки сессий

• Карта рисков потоков данных: эвристический граф плюс Python AST и облегчённый JS/TS анализ taint source -> sink, включая сводки параметр-в-sink для уникальных импортов Python-хелперов и ограниченные сводки IDOR route-to-service для JS/TS

• Наблюдатель/перехватчик MCP runtime: проверки событий JSON/JSONL и stream-ready на скрытые инструкции, потоки PII в агентные/внешние sink'и, а также пакетное блокирование/редактирование для пересылаемых потоков событий

• Глубокий адаптер Semgrep: офлайн-профиль из 40 правил, точное доказательство сканируемой цели, фиксированная идентичность 1.174.0, привязка к снимку исходников и fail-closed находки для JS/TS/Python/Java/Kotlin/Go/PHP/Ruby/C#

• Пакет валидации на девяти языках: Python/JavaScript/TypeScript/Java/Kotlin/Go/PHP/Ruby/C# 90 закреплённых уязвимых/чистых случаев, оценка TP/FN/FP/TN и точное воспроизведение отпечатка за два запуска

• Анализ состава программного обеспечения: ограниченное покрытие манифестов и lock-файлов Python/npm/Go с pip-audit, npm audit и govulncheck; частичный сбой движка, lock, вывода или дрейфа исходников блокирует выпуск

• Streamable HTTP MCP proxy: полное посредничество POST/GET SSE/DELETE, жизненный цикл, привязанный к субъекту, default-deny JIT/JEA гранты, фильтрованный инвентарь инструментов, ограниченные потоки и HMAC-цепочные журналы аудита без сырых данных

• Контроль базы данных: SQLGlot AST allowlist, RBAC по роли/базе/схеме/таблице/колонке, EXPLAIN-перед-чтением, SQLite query-only авторизатор, ограничение путей и бюджеты строк/ячеек/результатов/времени

• Read-only коннекторы: локальный SQLite, журналы, сэмплирование хранилища JSON/CSV/TSV без хранения сырых значений; пробелы коннекторов становятся high-находками

• Проверка хранения/удаления: отмечает отсутствие маркеров хранения/удаления при наличии сигналов персональных данных

• Межуровневые вердикты: коррелирует находки корейских PII с доказательствами sink'ов LLM/MCP/внешних/данных в покое

• Табло FP/FN: полнота recall по корпусу фикстур и доля ложных срабатываний. FPR использует measurable_negative_count как знаменатель (чистые негативы без expected_absent); negative_count — все объявленные негативы, а targeted_absence_case_count покрывает отсутствия по выбранным правилам, которые не входят в знаменатель FPR. Нулевой измеримый негативный знаменатель сообщается как FPR 0.0.

• Вывод SARIF/CI: сбой сборки при настроенных уровнях серьёзности

• Профиль Guardian korean_senior: fail-closed четырёхдоменный контракт для безопасности сайта, экспозиции API, управления данными и операционного риска

• Основные MCP-инструменты: check_my_app, continue_review, start_review_before_ship; внутренний канонический движок: Guardian high; управляемый промпт: guided_review

• Расширенные MCP-инструменты: scan_workspace, deep_analyzer_audit, validate_multilang_pack, software_composition_audit, validate_policy_controls, validate_streamable_http_runtime, scan_text, scan_diff, scan_mcp_config, probe_http, build_flow_map, observe_mcp_events, enforce_mcp_events, observe_mcp_event, score_fixture_corpus, data_release_gate, create_field_campaign_template, field_campaign_status, create_guardian_manifest_template, guardian_audit, explain_rule, suggest_fix, security_gate

Границы установки

Пользователь, получивший requirements-evidence.lock, распространяемый вместе с точным wheel, созданным release workflow, может воспроизвести проверенное closure зависимостей без репозитория, как показано ниже. k-guard, k-guard-dashboard, k-guard-mcp, python -m k_guard_mcp.cli, python -m k_guard_mcp.server — это команды установленного wheel.

Релиз также включает SHA256SUMS, SLSA provenance bundle, подписанный GitHub OIDC, и CycloneDX SBOM attestation bundle. В онлайне проверьте субъекта сборки и digest с помощью gh attestation verify ./k_guard_mcp-0.1.0-py3-none-any.whl -R windmillstudio/k-guard-mcp, затем устанавливайте. Если checksum совпадает, но attestation не проверен, артефакт не считается официальным релизным.

python -m pip install --require-hashes -r ./requirements-evidence.lock
python -m pip install --no-deps ./k_guard_mcp-0.1.0-py3-none-any.whl
k-guard --help
k-guard install --client auto --profile local-dev --workspace .
k-guard doctor --client auto

На управляемых ПК с Windows, где политика контроля приложений блокирует консольный загрузчик k-guard.exe от pip, используйте точку входа модуля того же wheel. Контракт функций и вердиктов идентичен.

python -m k_guard_mcp.cli --help
python -m k_guard_mcp.cli install --client auto --profile local-dev --workspace .
python -m k_guard_mcp.cli doctor --client auto

Установка только wheel предоставляет только команды времени выполнения. Релизный sdist и checkout репозитория включают scripts/..., tests/fixtures/... и шаблоны валидации. Среда разработки подготавливается из корня репозитория установкой двух lock-файлов с --require-hashes, затем python -m pip install --no-build-isolation --no-deps -e .. Evidence lock фиксирует вместе версии релизного closure зависимостей и допустимые SHA-256; лицензии, уязвимости, SBOM и fresh-wheel smoke используют тот же файл.

Комната проверки старшего коллеги по очкам

Чтобы просмотреть авторизованный сайт на экране, запустите локальную панель управления.

k-guard-dashboard --port 8765

Откройте в браузере http://127.0.0.1:8765/. Экран идёт в порядке вердикт старшего → находки → журнал проверки → карта экспозиции, и окончательное право выпуска принадлежит не экрану, а только start_review_before_ship в MCP. Брендовые изображения — это оригинальные активы, созданные для проекта, их происхождение фиксируется в docs/brand-assets.md.

CLI установленного wheel

Среди команд ниже tests/fixtures/korean_fixture_corpus.json — это публичный пример корпуса, который можно запустить прямо из checkout исходников. Пользователь, установивший только wheel, заменяет его на путь собственного фикстура той же схемы.

python -m k_guard_mcp.cli scan .
python -m k_guard_mcp.cli scan . --json report.json --markdown report.md
python -m k_guard_mcp.cli scan . --sarif k-guard.sarif --fail-on high
python -m k_guard_mcp.cli probe http://localhost:3000
python -m k_guard_mcp.cli probe http://localhost:3000 --deep-active
python -m k_guard_mcp.cli probe http://localhost:3000 --session-file session.headers.json --json
python -m k_guard_mcp.cli probe https://staging.example.com --allow-external --authorization-note "owned staging domain" --json
python -m k_guard_mcp.cli flow . --svg flow.svg --html flow.html
python -m k_guard_mcp.cli observe-mcp --events mcp-events.jsonl --json
python -m k_guard_mcp.cli mcp-proxy --report mcp-proxy-report.json --response-timeout 30 -- python -m your_upstream_mcp_server
python -m k_guard_mcp.cli mcp-http-proxy --upstream http://127.0.0.1:9000/mcp --port 8765 --report mcp-http-proxy.json --receipt-log mcp-http-proxy.receipts.jsonl
python -m k_guard_mcp.cli deep-analyze . --output deep-analyzer.json
python -m k_guard_mcp.cli language-validate --output language-validation.json
python -m k_guard_mcp.cli sca . --output sca.json
python -m k_guard_mcp.cli control-validate --output control-validation.json
python -m k_guard_mcp.cli runtime-validate --output runtime-validation.json
python -m k_guard_mcp.cli access-policy-template --output access-policy.json
python -m k_guard_mcp.cli agent-grant --policy access-policy.json --output agent.jwt --app-id APP --session-id SESSION --purpose RELEASE_REVIEW --subject AGENT --role release-reviewer --method tools/list --method tools/call --tool check_my_app --tool start_review_before_ship
python -m k_guard_mcp.cli score-corpus --corpus tests/fixtures/korean_fixture_corpus.json --output fixture-metrics.json --json
python -m k_guard_mcp.cli benchmark-template --output benchmarks/field-benchmark-template.csv
python -m k_guard_mcp.cli benchmark --manifest benchmarks/field-benchmark-template.csv --output field-benchmark.json --markdown field-benchmark.md --html field-benchmark.html
python -m k_guard_mcp.cli guardian-template --output benchmarks/guardian-targets.csv
python -m k_guard_mcp.cli suppression-template --output .k-guard/suppressions.csv
python -m k_guard_mcp.cli field-campaign-template --output benchmarks/field-app-roster.csv
python -m k_guard_mcp.cli field-campaign-status --roster benchmarks/field-app-roster.csv --output field-campaign-status.json
python -m k_guard_mcp.cli field-validation-template --ground-truth-output benchmarks/field-ground-truth.csv --review-output benchmarks/field-review.csv
python -m k_guard_mcp.cli field-validation-sign --ground-truth benchmarks/field-ground-truth.csv
python -m k_guard_mcp.cli field-validation-preregister --roster benchmarks/field-app-roster.csv --ground-truth benchmarks/field-ground-truth.csv --custodian-id split-custodian-a --output benchmarks/field-preregistration.json
python -m k_guard_mcp.cli guardian --manifest benchmarks/guardian-targets.csv --output guardian-report.json --markdown guardian-report.md --html guardian-report.html
python -m k_guard_mcp.cli guardian --manifest benchmarks/guardian-targets.csv --suppressions .k-guard/suppressions.csv --fail-on high --run-probes --run-sca --language-validation-report language-validation.json --mcp-http-proxy-report runtime-validation.json --control-validation-report control-validation.json --field-validation-report field-validation.json --output guardian-gate.json
python -m k_guard_mcp.cli field-validation-queue --guardian-report guardian-gate.json --output benchmarks/field-review.csv
python -m k_guard_mcp.cli field-validation-sign --review benchmarks/field-review.csv
python -m k_guard_mcp.cli field-validation-report --guardian-report guardian-gate.json --repeat-guardian-report guardian-gate-repeat.json --roster benchmarks/field-app-roster.csv --ground-truth benchmarks/field-ground-truth.csv --review benchmarks/field-review.csv --preregistration benchmarks/field-preregistration.json --profile field --output field-validation.json
python -m k_guard_mcp.cli mcp-intercept --events mcp-events.jsonl --forwarded-output forwarded.jsonl --report intercept-report.json --app-id YOUR_APP_ID --session-id RELEASE_SESSION_ID --guardian-report guardian-gate.json --fail-on-block
python -m k_guard_mcp.cli data-release-gate --guardian-report guardian-gate.json --guardian-manifest .k-guard/guardian-targets.csv --validation-source-guardian-report validation-source-guardian.json --validation-repeat-guardian-report validation-source-guardian-repeat.json --validation-report field-validation.json --validation-review benchmarks/field-review.csv --validation-ground-truth benchmarks/field-ground-truth.csv --validation-preregistration benchmarks/field-preregistration.json --validation-roster benchmarks/field-app-roster.csv --korean-fixture-corpus tests/fixtures/korean_fixture_corpus.json --korean-corpus-report fixture-metrics.json --mcp-intercept-report intercept-report.json --mcp-forwarded-output forwarded.jsonl --output data-release-gate.json

session.headers.json недолговечен и привязан к одному точному источнику. Guardian считает аутентифицированное сравнение завершённым только тогда, когда ответ с заявленной личностью также совпадает:

{
  "origin": "http://localhost:3000",
  "expires_at": "2026-07-14T12:30:00+09:00",
  "headers": {"Cookie": "session=<local-test-session>"},
  "identity_assertion": {
    "path": "/api/me",
    "expected_status": 200,
    "expected_body_sha256": "<64 lowercase hex characters>"
  }
}

Держите файл внутри вызываемого workspace или рядом с манифестом Guardian. Файлы за пределами этой границы, ссылки, истёкшие сессии, несовпадающие источники, неподдерживаемые заголовки и файлы слишком большого размера завершаются сбоем (fail closed). Digest покрывает точные ограниченные байты ответа до декодирования UTF-8; сырые значения сессий и тела ответов не записываются в находки.

Валидация только для checkout исходников

Приведённые ниже scripts/** и pytest — это не пользовательские команды, входящие в wheel.

python -m pytest -q
python scripts/site_scale_calibration.py
python scripts/deep_probe_synthetic_calibration.py --targets 500 --output tmp/deep-probe-synthetic-500.json --markdown tmp/deep-probe-synthetic-500.md --html tmp/deep-probe-synthetic-500.html
python scripts/inner_core_product_gate.py --targets 500 --output tmp/inner-core-product-gate-500.json --markdown tmp/inner-core-product-gate-500.md --html tmp/inner-core-product-gate-500.html
python scripts/mcp_evasion_calibration.py --output evidence/regression/mcp-evasion-normalization.json
python examples/contest-demo/v1/demo.py run
python scripts/contest_readiness.py --output contest-readiness-report.json --markdown contest-readiness-report.md
python scripts/build_top_domain_manifest.py --output datasets/tranco-passive-homepage-10k.csv --limit 10000
python scripts/passive_homepage_calibration.py --targets datasets/tranco-passive-homepage-10k.csv --output reports/passive-homepage-10k-summary.json --checkpoint-jsonl reports/passive-homepage-10k-checkpoint.jsonl --max-targets 10000 --delay-ms 500

Порог Coverage 90.00% для полной регрессии исходников — это combined coverage с включением ветвей, вычисляемый вместе по возможностям statement и branch. Это не означает, что сами ветви покрыты на 90%; используются precision=2 и fail_under=90, поэтому 89.90% — это провал. Область public_source_only CI публичного репозитория исключает отдельные доказательства развёртывания и нативные случаи, поэтому применяются пороги 88% в целом и 85% для redaction.py; эти два числа не взаимозаменяемы.

Гигиена релиза из checkout исходников

Используйте проверку гигиены релиза перед рассмотрением CTO или подготовкой публикации:

python scripts/release_hygiene.py --json

Режим по умолчанию проверяет, что грязное рабочее дерево релизного кандидата классифицировано, свободно от видимых временных артефактов выполнения и свободно от нерешённых артефактов, требующих рассмотрения. Используйте --strict-clean после предполагаемого релизного коммита; строгий режим также сравнивает каждый байт входных данных сборки пакета с его blob в Git index. Тегированная публикация дополнительно требует --expected-tag v{project.version}, и этот точный тег должен разрешаться в проверенный коммит HEAD. Release workflow ожидает переиспользуемую матрицу CI Windows/macOS/Linux, создаёт attestations и публикует тегированные артефакты как GitHub Release. Подробности в docs/release-hygiene.md.

Шаблон Guardian Actions в настоящее время устанавливает точный checkout исходников K-Guard, выбранный коммитом workflow; он не предполагает пакет PyPI. Перед копированием в другой репозиторий разместите K-Guard по пути, закреплённому за коммитом, и задайте K_GUARD_SOURCE_PATH. После появления релизных артефактов потребители должны закреплять либо точный wheel с опубликованным SHA-256, либо полный 40-символьный Git-коммит в требовании прямой ссылки. Заменяйте плейсхолдеры только на фактическое место релиза:

k-guard-mcp @ https://<artifact-host>/<exact-wheel>.whl#sha256=<published-sha256>
k-guard-mcp @ git+https://<repository-url>.git@<40-character-commit>

Основная лицензия K-Guard — MIT. Атрибуция вышестоящего проекта Apache-2.0, проверенные ревизии, сопоставление изменённых файлов и границы исключённых лицензий задокументированы в THIRD_PARTY_NOTICES.md и docs/upstream-adoption.md.

MCP

python -m pip install --require-hashes -r requirements-build.lock
python -m pip install --require-hashes -r requirements-evidence.lock
python -m pip install --no-build-isolation --no-deps .
k-guard-mcp

MCP probe_http отключён по умолчанию. Включайте его только для доверенных аудиторских сессий:

K_GUARD_MCP_ENABLE_PROBE=1 python -m k_guard_mcp.server

Аутентифицированное чтение через MCP также требует K_GUARD_MCP_ENABLE_SESSION_PROBE=1 и кратковременного локального session_file, привязанного к источнику. Значения заголовков читаются локально и не записываются в находки. Сам по себе заголовок никогда не доказывает вход в систему: Guardian требует, чтобы необязательный identity_assertion совпал, прежде чем аутентифицированное сравнительное покрытие сможет пройти.

Ограниченное глубокое активное зондирование через MCP также требует K_GUARD_MCP_ENABLE_DEEP_ACTIVE_PROBE=1 и probe_http(..., deep_active=true). Этот режим проверяет небольшой фиксированный список открытых путей env/git/backup/debug и по-прежнему избегает попыток входа, мутаций, фаззинга и эксплойт-пейлоадов.

Авторизованное внешнее зондирование через MCP также требует K_GUARD_MCP_ENABLE_EXTERNAL_PROBE=1 плюс либо K_GUARD_MCP_EXTERNAL_ALLOWED_HOSTS=example.com,staging.example.com, либо external_authorized=true с authorization_note при каждом вызове. Отчёт фиксирует основание авторизации с помощью DYN_EXTERNAL_TARGET_AUTHORIZATION_AUDIT.

Установка и подключение настроены для четырёх клиентов: ChatGPT, Grok, Codex, Antigravity. Подробные процедуры приведены в docs/quickstart-ko.md и docs/mcp-client-install.md.

При подготовке отчёта о результатах конкурса и фактических доказательств совместимости используйте docs/contest-2026-result-report-draft-ko.md и docs/client-interop-evidence-kit-ko.md. Фактическая завершённая совместимость учитывается только для тех объёмов, где есть запись install → restart → tool list → check_my_app → reconnect для каждого клиента, уникальный SHA-256 и отдельная проверка.

Вызовы MCP также по умолчанию применяют лимиты на аргументы и встроенный текст:

• K_GUARD_MCP_MAX_FILES=1000

• K_GUARD_MCP_MAX_MB=10

• K_GUARD_MCP_MAX_TEXT_MB=1

• K_GUARD_MCP_MAX_ARG_CHARS=4096

• K_GUARD_MCP_GUARDIAN_MAX_TARGETS=100

• K_GUARD_MCP_GUARDIAN_MAX_REQUESTS=200

Вызовы Guardian MCP предварительно проверяют весь манифест на соответствие бюджетам целевых объектов, отфильтрованных файлов, байтов и прогнозируемых HTTP-запросов. Расширение файлов ограничено настроенным лимитом плюс одна запись обнаружения, поэтому слишком большое дерево отклоняется без предварительного перечисления всего дерева. Чрезмерно большая работа с несколькими целями возвращает отчёт Guardian с закрытым отказом; для намеренно больших пакетов используйте CLI или разделите манифест. Динамическая HTTP-проверка по умолчанию читает не более 1 МиБ на ответ, а также останавливается на 16 МиБ, 80 запросах или 30 секундах на один прогон зонда.

Безопасность по умолчанию

• Выводы JSON/Markdown/MCP проходят через централизованный слой редактирования

• Вывод SARIF также проходит через тот же слой редактирования и хранит доказательства без сырых данных

• Динамический зонд по умолчанию разрешает только localhost, 127.0.0.1 и ::1

• Внешний динамический зонд требует явных доказательств авторизации и согласия, затем остаётся с фиксированными путями, только для чтения, с тем же источником и без перенаправлений. Каждый запрос разрешает только разрешённые публичные адреса и подключается к выбранному проверенному IP, сохраняя исходный HTTP Host/TLS SNI.

• Динамический зонд не следует перенаправлениям на неразрешённые хосты

• Динамический зонд использует только неразрушающие HTTP-методы

• --deep-active — это ограниченная авторизованная проверка распространённых открытых путей .env, .git/config, резервных копий/дампов и отладочных/рантайм-путей. Это не рекурсивное сканирование, не подбор паролей, не эксплойт-пейлоады и не словарный перебор путей.

• Динамический зонд использует таймаут и ограничивает выборку тел ответов

• Проверка внешних секретов на действительность не выполняется

Серьёзность и уверенность

Значения серьёзности проверяются централизованно:

• critical: раскрытие учётных данных/приватных ключей/строк подключения к БД, прямые высокорисковые идентификаторы или неаутентифицированные чувствительные маршруты

• high: сильно идентифицирующие комбинации, рискованное локальное раскрытие или кандидаты на чувствительные потоки

• medium: отдельные сигналы контактов/местоположения/конфигурации и находки по усилению защиты

• low: слабые эвристические сигналы

• info: информационные наблюдения

Значения уверенности: high, medium и low.

Поток данных и ограничения внутреннего ядра

Карта потока явно помечена как ЭКСПЕРИМЕНТАЛЬНАЯ и обозначена как heuristic+ast-taint+js-ts-taint с точностью line-distance+python-intra-procedural-ast+js-ts-intra-file+limited-interprocedural-taint. Это инструмент для триажа разработчика: поддерживается Python AST-taint, а JS/TS теперь имеет лёгкий внутрифайловый taint, ограниченные сводки маршрут-к-сервису, а также эвристики с учётом фреймворков для обработчиков маршрутов/серверных действий Next.js, IDOR-образных параметров маршрутов Express, подсказок границ Supabase service-role/RLS и подсказок границ аутентификации Firebase Admin. Полная проверка типов TypeScript, разрешение импорта с учётом алиасов, доказательство middleware, доказательство развёрнутых правил RLS/Firebase и полный межпроцедурный taint остаются пунктами дорожной карты. Находки потока включают хэши строк источника/приёмника без сырых данных, чтобы сделать доказательства воспроизводимыми без раскрытия чувствительных значений. Визуализации потока генерируются как локальные SVG/HTML без внешних JavaScript или CDN-зависимостей. Тот же слой редактирования защищает JSON, Markdown, SVG, HTML и ответы MCP.

Наблюдение MCP в рантайме принимает экспорт событий JSONL/JSON через observe_mcp_events и может также оценивать одно событие за раз через observe_mcp_event(session_id=...). CLI mcp-intercept применяет решения block и redact к пакетному потоку событий перед записью пересылаемого JSONL. CLI mcp-proxy -- <upstream argv> — это путь принудительного применения в реальном времени для построчного stdio JSON-RPC. CLI mcp-http-proxy --upstream <URL> применяет ту же политику к жизненным циклам сессий Streamable HTTP POST, GET SSE и DELETE, с официальной поддержкой совместимости Python MCP SDK. Оба прокси излучают одну и ту же цепочку квитанций HMAC без сырых данных, связанную с транзакциями, для решений об отказе в доступе и разрешении/редактировании/блокировании контента; настроенная сохранность в сайдкаре происходит перед пересылкой и завершается отказом. Проверка секрета оператора требуется для заявлений об устойчивости к вмешательству, потому что HMAC — это тег с общим секретом, а не подпись с открытым ключом. Оба прокси завершаются отказом при неверной структуре кадров, ошибках корреляции, превышении размера или таймаута, а также при сбоях управления транспортом. Состояние потокового наблюдателя имеет ограниченное удержание сессий idle/LRU. MCP enforce_mcp_events остаётся только для отчётов. Бинарная структура кадров, нестандартные транспорты и универсальный прокси для всех MCP-клиентов остаются работой на будущее.

Коннекторы только для чтения проверяют только локальные файлы SQLite/логов/хранилищ. Удалённые Postgres/Supabase/Firebase/S3, резервные копии и фактическое выполнение удаления — пункты дорожной карты.

Цикл обратной связи по дрейфу

k-guard feedback --type fn --rule PII_PHONE --text "missed sample" --output feedback.jsonl
k-guard feedback-export --input feedback.jsonl --output feedback-summary.json --reviewed

Файлы обратной связи очищаются перед записью и обобщаются локально для настройки корпуса. Фрагменты ложноотрицательных результатов используют дополнительное консервативное маскирование токенов, потому что детектор мог пропустить чувствительное значение. feedback-export требует --reviewed или K_GUARD_FEEDBACK_EXPORT_REVIEWED=1, чтобы случайные автоматические экспорты завершались отказом. Просмотрите feedback-summary.json перед передачей за пределы партнёрской среды; не передавайте сырой feedback.jsonl.

Полевой бенчмарк

benchmark-template создаёт манифест 20/20/10:

• 20 общих базовых сайтов или отчётов

• 20 подозрительных сайтов или отчётов, созданных с помощью vibe-coding

• 10 собственных, одобренных партнёром или находящихся в рамках bug-bounty целей

benchmark агрегирует отчёты K-Guard JSON без сырых данных и, только с --run-probes, авторизованные строки манифеста с пометкой mode=probe. Он сообщает долю целей с высоким/критическим уровнем, долю обнаружения сильных идентификаторов, основные правила и долю ложных срабатываний вручную по когортам. По умолчанию путь — только отчёт, поэтому работу над бенчмарком можно начать с экспорта дашборда, не касаясь внешних сайтов.

Тот же рабочий процесс доступен через MCP как create_benchmark_template и field_benchmark. Зонды бенчмарка MCP требуют тех же явных согласий на зондирование, что и probe_http.

Режим Guardian

guardian-template создаёт авторизованный манифест целей для непрерывной защиты продукта. Строка может указывать на локальное рабочее пространство, HTTP-источник, экспорт JSONL рантайма MCP или существующий отчёт K-Guard JSON без сырых данных. guardian агрегирует все строки в один отчёт без сырых данных с воротами для каждой цели, дрейфом новых/решённых находок, основными повторяющимися правилами и рецептами исправлений из suggest_fix.

Манифесты Guardian также содержат поля бизнес-намерений и объёма без сырых данных: business_purpose, data_classes, user_scope, public_endpoints, scope_basis и scope_proof_ref. K-Guard не претендует на понимание бизнеса на уровне человека и не доказывает владение сам по себе; он записывает, существуют ли эти утверждения, и хранит только хэшированные ссылки. Завершение объёма требует явного scope_proof_ref; локаторы и устаревшие заметки об авторизации не считаются доказательством. Ворота выпуска данных требуют этих контрактов на уровне целей и проверенных пакетов доказательств, подписанных оператором, чьи хэши артефактов совпадают с текущим отчётом, прежде чем считать отчёт доказательством отгрузки.

Новые шаблоны устанавливают audit_profile=korean_senior. В этом профиле ворота выпуска не проходят только потому, что не найдено блокирующих проблем. Также требуется содержательное рабочее пространство с хотя бы одним поддерживаемым и успешно декодированным производственным исходным файлом, анализ потока, завершённый глубокий HTTP-обзор, объявленные пути конечных точек, которые фактически возвращают 2xx/3xx/401/403, а не только 404, и явные утверждения о назначении/данных/пользователях/объёме. Guardian вычисляет хэш содержимого каждого рабочего пространства непосредственно до и после аудита; несовпадение вызывает GUARDIAN_SOURCE_CHANGED_DURING_AUDIT, блокирует цель и исключает этот запуск из содержательного покрытия. Используйте неизменяемый CI-чекаут для авторитета выпуска. Отчёт раскрывает review_contract.domains для site_security, api_exposure, data_management и operational_risk; guardian_gate.passed остаётся ложным, когда любая требуемая область неполна. Устаревшие манифесты без audit_profile остаются на более узком профиле standard и не должны представляться как четырёхдоменное старшее покрытие.

public_endpoints — это исполняемый объём проверки, а не декоративные метаданные. Guardian безопасно добавляет допустимые пути с тем же источником из этого поля в фиксированный набор зондов GET/OPTIONS (максимум 50; без абсолютных URL, обхода родительских каталогов или шаблонных путей). Это позволяет проверке API охватывать специфичные для приложения конечные точки только для чтения, сохраняя зонд ограниченным.

Когда HTTP-строка включает session_file, Guardian выполняет тот же ограниченный набор путей дважды: один раз без аутентификации и один раз с предоставленной оператором сессией только для чтения. Это сохраняет проверки публичного раскрытия видимыми, а не заменяет их представлением только с аутентификацией. Сессия должна доказать как переход через аутентификационный барьер, так и дайджест ответа объявленной личности. Ворота korean_senior отклоняют HTTP-покрытие, если отсутствует любое из доказательств, если зонд вызвал ошибки запроса или управления, или если не был достигнут допустимый объявленный объём конечных точек.

guardian --fail-on high — это канонические ворота перед выпуском. Это рабочий процесс для случаев, когда K-Guard должен решить, может ли целевое приложение быть выпущено при заданном пороге. Только рабочее пространство scan --fail-on и MCP security_gate — это быстрые проверки; они не заменяют контракт Guardian на манифест, пробелы покрытия, дрейф и выполнение с несколькими целями.

По умолчанию guardian записывает отчёт и завершается успешно, чтобы команды могли просмотреть находки, не превращая его в блокировку выпуска. Используйте --fail-on high, когда тот же отчёт должен действовать как CI-ворота; он завершается с кодом 3, когда присутствуют блокирующие цели или новые блокирующие находки. При первом запуске без --previous отчёт является initial_snapshot: текущие блокировки и пробелы покрытия всё ещё могут провалить ворота, но K-Guard не помечает каждую текущую находку как новый дрейф. В режиме ворот HTTP-строки в манифесте должны фактически выполняться через --run-probes, иначе они становятся пробелами покрытия, а не молчаливыми проходами.

HTTP-строки не выполняются, если не передан --run-probes. Путь CLI предназначен для доверенного локального оператора и использует явные флаги CLI/строки манифеста как механизм opt-in. MCP опосредован агентом и строже: guardian_audit(..., run_probes=true) требует K_GUARD_MCP_ENABLE_PROBE=1; манифесты, запрашивающие внешние, глубоко-активные или сессионные пробы, дополнительно требуют K_GUARD_MCP_ENABLE_EXTERNAL_PROBE=1, K_GUARD_MCP_ENABLE_DEEP_ACTIVE_PROBE=1 или K_GUARD_MCP_ENABLE_SESSION_PROBE=1 соответственно. Режим Guardian по-прежнему использует фиксированные безопасные GET/OPTIONS-пробы и не выполняет попытки входа, подбор паролей, мутации, эксплойт-пейлоады, рекурсивное сканирование или переходы по редиректам на другие хосты.

MCP-клиенты должны передавать fail_on="high" в guardian_audit для канонического вердикта release-gate в guardian_gate.passed; коды выхода процесса остаются заботой CLI. Используйте --previous previous-guardian-report.json, чтобы превратить отчёт в монитор дрейфа. Новые блокирующие находки перечисляются отдельно только при загрузке предыдущего отчёта; комбинируйте --previous с --fail-on, когда эти находки должны остановить релиз. Если MCP-контрольные проверки останавливают guardian до выполнения цели, и режим отчёта, и режим gate возвращают ответ в форме guardian с execution_contract, summary и findings; режим gate дополнительно включает guardian_gate.passed=false. Отчёт включает секцию execution_contract, чтобы пропущенные, ошибочные и выполненные цели были видны в одном месте, включая экспорт в Markdown и HTML.

MCP security_gate(path, fail_on) — это быстрый gate только для рабочего пространства. Теперь он возвращает security_gate.passed=false при сбоях MCP-контроля, таких как недопустимые пороги, бюджеты аргументов, лимиты бюджета рабочего пространства или исключения при сканировании, но намеренно сообщает coverage_model="workspace_only". Используйте Guardian для решений о релизе, которым нужны HTTP-цели, MCP-экспорт времени выполнения, предыдущие отчёты или учёт пробелов покрытия.

Политика подавления — fail-closed. suppression-template создаёт CSV, который привязывает каждый отказ от проверки к app_id, audit_profile, текущему снимку исходников или хэшу review-evidence, target_id, отпечатку находки, владельцу, причине и будущему сроку истечения. Отказ от проверки не может быть воспроизведён для другого приложения или изменённого снимка релиза; недопустимые, устаревшие или истёкшие строки добавляют policy-находку высокой серьёзности. Подавления не могут очистить пробелы покрытия Guardian или правила сбоев MCP-контроля. field-validation-queue экспортирует каждого кандидата high/critical с редактированным отпечатком, подтипом детектора, областью артефакта, типом расположения файла/тела/заголовка и доступным хэшем ответа. Строгое утверждение field-validation-report --profile field остаётся закрытым, пока 12–20 собственных/партнёрских приложений, 120 размеченных случаев, 50 положительных, 40 отрицательных, пять critical-случаев, три страты, предварительно зарегистрированный holdout как минимум с 70 случаями, 35 положительными, 35 отрицательными и 35 кандидатами, разделённые по ролям подписи рецензента/хранителя и точный второй канонический прогон Guardian не пройдут все фиксированные пороги. Общая/holdout точность, holdout high/critical полнота и holdout специфичность должны пройти как точечную оценку, так и нижнюю границу Wilson 95%; critical holdout полнота остаётся ровно 1.0. Каждый кандидат должен быть привязан ровно к одной замороженной области разработки/holdout. (false_positive + benign) / (true_positive + false_positive + benign) кандидата сообщается как доля ложных обнаружений; доля ложных положительных результатов рассчитывается только по чистым случаям как FP / (FP + TN). Порог выпуска данных строже: любое известное ложноотрицательное или доброкачественное high/critical-кандидат блокирует выпуск. K_GUARD_FIELD_REVIEWER_HMAC_KEYS и K_GUARD_FIELD_CUSTODIAN_HMAC_KEY должны отличаться от ключа операторских доказательств; эти локальные HMAC разделяют роли, но не доказывают реальную идентичность или криптографически независимое выполнение. Устаревшие команды validation-* агрегируют только метки кандидатов и не могут установить полевую полноту.

Публичный контракт квалификации автоматических блокировок отделён от полевой валидации. release_blocker_actionability_v3 требует предварительно зарегистрированную перепись как минимум 100 автоматических блокировок, 0.90 действенности кандидатов и нижнюю границу Wilson 95% 0.80. Он также требует автоматические блокировки как минимум в 20 приложениях. Приложение считается полностью действенным только тогда, когда каждая автоматическая блокировка в этом приложении помечена true_positive; и доля полностью действенных приложений, и нижняя граница Wilson должны пройти 0.90 и 0.80. Этот порог чувствительности на уровне приложений предотвращает создание ложной статистической уверенности десятками коррелированных строк в одном репозитории. Ручные проверки и удержания целостности политики остаются fail-closed, но исключены из действенности автоматических блокировок.

Полный контракт уровней доказательств, первого базового уровня, разметки и повторных прогонов задокументирован в docs/field-validation-v2-ko.md.

data-release-gate строже: он требует K_GUARD_EVIDENCE_HMAC_KEY, оригинальный манифест Guardian, каноническое утверждение Guardian уровня high, привязанное к текущему отчёту, снимки доказательств целей и исходников, отдельно подписанные первичные и повторные оригиналы Guardian валидационных исходников, точные CSV ground-truth/рецензента, оригинальную предварительную регистрацию хранителя, доказательства на корейском корпусе и фактический пересылаемый поток MCP-перехватчика. Он повторно запускает полевую валидацию из этих оригиналов, повторно проверяет HMAC рецензента/хранителя и требует, чтобы пересчитанная проекция равнялась представленному отчёту. Он также повторно открывает повторный Guardian и независимо проверяет контент, пакет, аттестацию выполнения, инструментарий, манифест, входные данные source/HTTP/MCP и точный мультинабор кандидатов. Валидация дизайн-партнёра намеренно независима от единственного приложения, которое в настоящее время выпускается; ссылки на приложение/цель/находку кандидата должны соответствовать отчёту Guardian валидационных исходников, а не маскироваться под покрытие выпускаемого приложения. Многоразовый шаблон GitHub Actions находится в docs/templates/github-actions/guardian-release-gate.yml.

Неаутентифицированный JSON разделяется по риску. Структура чувствительных/приватных записей остаётся DYN_UNAUTH_API_JSON с высокой серьёзностью; JSON без этих индикаторов становится DYN_PUBLIC_API_JSON_REVIEW с информационной серьёзностью, чтобы намеренный публичный API не блокировал выпуск только за возврат JSON.

scripts/site_scale_calibration.py запускает локальные black-box HTTP-фикстуры для большого общего HTML-шума, средних публичных контактных страниц, малого bulk-JSON в стиле vibe-coding, валидных сильных идентификаторов и JSON банковских счетов. Он не использует внешний сетевой доступ.

scripts/deep_probe_synthetic_calibration.py запускает локальный синтетический loopback-калибровочный стенд через тот же путь dashboard scan_url(..., deep_active=True). Прогон доказательств по умолчанию использует 500 loopback-вызовов в 24 ограниченных сценариях; это не 500 реальных веб-сайтов, не обнаружение уязвимостей и не пентестинг. Он покрывает .env, .git/config, резервные SQL, отладочные конечные точки, экспозицию admin/API, OpenAPI, source maps, CORS, редиректы, уровни ответов PII/секретов и контроли ложных срабатываний для login-стен, SPA-оболочек и HTML-фолбэков. Он также включает отрицательные контроли, доказывающие, что скорер «ожидаемое против наблюдаемого» может обнаруживать внедрённые отсутствующие и неожиданные правила. Он не использует внешний сетевой доступ; реальные внешние глубокие пробы по-прежнему требуют явной авторизации цели.

scripts/inner_core_product_gate.py запускает более широкий локальный синтетический продуктовый gate для утверждения аудита «inner-core». Он объединяет 500-целевую loopback-калибровку глубоких проб со статическими проверками кода/конфигурации/MCP-текста, Python AST-taint, наблюдением MCP-рантайма JSONL, коннекторами SQLite/журналов/хранилищ только для чтения, проверкой хранения/удаления, вердиктами PII-к-агентному/внешнему на разных уровнях и проверками графа доказательств без сырых данных. Этот gate должен иметь ноль отсутствующих обязательных правил, ноль неожиданных правил глубоких проб, проходящие отрицательные контроли, непустые узлы/рёбра графа потока и отсутствие запрещённых сырых маркеров в сериализованном отчёте. Это gate глубины продукта, а не доказательство обнаружения уязвимостей сторонних сайтов.

CI-рабочий процесс запускает полный набор pytest плюс 24-целевой inner-core gate при push/pull request, который покрывает каждый синтетический сценарий один раз. Планируемый/ручной аудит-рабочий процесс запускает 500-целевой inner-core gate и загружает пакет доказательств JSON/Markdown/HTML. Само-SARIF-сканирование репозитория загружается как неблокирующее доказательство, потому что этот репозиторий сканера намеренно содержит правила детекторов, фикстуры и примеры документации, которые должны вызывать находки K-Guard; используйте --fail-on против аудируемого продукта, а не против собственного дерева исходников K-Guard с обилием фикстур, если не существует проектного базового уровня.

scripts/passive_homepage_calibration.py запускает калибровку только главной страницы GET / из CSV-манифеста. Он поддерживает --max-targets, --delay-ms, --checkpoint-jsonl и --resume для шардированных прогонов масштаба 10k. Он сообщает агрегаты когорты, рангового сегмента, исхода и уровня гигиены, такие как well_managed_quiet, hardening_gap, boundary_redirect и messy_or_risky_signal, чтобы шумные хорошо управляемые сайты и беспорядочные длиннохвостые сайты можно было калибровать отдельно. Он также выдаёт release_gate с проверками pass/warn/fail для выхода измерений, доли high/critical, доли сильных идентификаторов и доли boundary-редиректов. Он не запрашивает /admin, /api, .env, .git, OPTIONS или рекурсивные пути.

scripts/build_top_domain_manifest.py автоматически создаёт этот пассивный калибровочный манифест из публичного CSV или ZIP-источника топ-доменов. Источник по умолчанию — последний top-1m ZIP Tranco, поэтому операторам не нужно вручную собирать 10 000 URL. Используйте --start-rank для создания когорт длиннохвостых беспорядочных кандидатов, например ранги с 900 001 по 910 000. CSV в стиле Majestic Million также можно указать с помощью --source-url.

Доказательства RC для конкурса только с ИИ

Конкурсный RC хранит доказательства разработки в отдельных дорожках вместо публикации одного объединённого показателя точности:

python scripts/qualify_korean_privacy_ai_only.py --output evidence/qualification/korean-privacy-ai-only-v1.json
python scripts/ai_public_benchmark_scorecard.py --output evidence/qualification/ai-public-benchmark-scorecard-v1.json
python scripts/benchmark.py --profile contest --output benchmark-report.json

• Корейский квалификационный отчёт сообщает 117 фикстур-случаев и замороженный holdout из 68 случаев, написанный оценщиком, как отдельные дорожки. Он также проверяет пять контрактов рабочего пространства, четыре официальных концепции уникальных идентификаторов, границы бизнес/корпоративных номеров и шесть поверхностей чувствительной лексики. Он не публикует объединённую матрицу ошибок и не заявляет о слепой, подтверждённой человеком, реестровой, партнёрской или полевой точности.

• Публичная карта показателей сохраняет текущие и исторические дорожки отдельно. --require-integrity-pass намеренно завершается ошибкой, пока любой выбранный исторический артефакт имеет несоответствие дайджеста или привязки; отчёт всё равно может быть сгенерирован, чтобы недопустимый исторический результат оставался видимым, а не молча переписывался или удалялся.

• Профиль производительности конкурса измеряет точные синтетические all-benign низкосигнальные корпуса на одном раскрытом хосте, включая холодную задержку свежего процесса и тёплую задержку постоянного сканера, масштабирование 10/50/100 МиБ, конкурентность потоков CPython в процессе 1/4/8, пиковый RSS, полное покрытие кандидатов и инвариантность результатов без сырых данных. Он не измеряет масштабирование с плотностью находок, параллелизм на уровне процессов, производственный SLO, полевую точность, сравнение с нормализацией по оборудованию или превосходство третьих сторон.

Текущие ограничения

• Дорожная карта усиления продукта: docs/pre-release-auditor-hardening-plan-ko.md

• Извлечение PDF/DOCX/HWP пока не включено

• Динамические проверки выполняются только на localhost, если только они явно не внесены в белый список или не подтверждены оператором для собственной, одобренной партнёром или охваченной программой bug-bounty внешней цели

• Предоставленные пользователем заголовки сеанса прикрепляются только к запросам GET, доступным только для чтения, и значения заголовков не сохраняются

• Taint-анализ JS/TS является консервативным и лёгким, с внутрифайловым taint-анализом, ограниченными сводками маршрут-к-сервису и эвристиками с учётом фреймворков для распространённых ошибок на границах Next.js/Express/Supabase/Firebase; taint-анализ AST Python является внутрипроцедурным

• Наблюдение за MCP во время выполнения и инструмент MCP enforce_mcp_events остаются рекомендательными; mcp-proxy и mcp-http-proxy выполняют фактическое двунаправленное принуждение для построчного stdio JSON-RPC и протестированного жизненного цикла Streamable HTTP. Двоичная кадровая структура, нестандартные транспорты и универсальный прокси-заменитель для каждого клиента остаются за пределами принудительной границы

• Удалённые БД/хранилища/резервные копии и фактическое выполнение удаления пока не проверяются

• Корейские PII-шаблоны основаны на правилах и требуют настройки ложных срабатываний для конкретного проекта

• Корейские регистрационные номера предприятий используют проверку синтаксиса контрольной суммы на синтетических/созданных вендором фикстурах. Исторические корпоративные регистрационные номера (выданные до 2025-01-31) могут использовать старую контрольную сумму Приложения с чередующимися весами 1,2. С 2025-01-31 текущие корпоративные номера состоят из 4 цифр реестра + 2 цифр типа + 7 серийных цифр без контрольной суммы, поэтому обнаружение — это только явное распознавание контекста поля/синтаксиса. Ничто из этого не является PII физического лица, проверкой живого реестра или независимой проверкой поля. Текущие значения только по контексту — это непроверенное распознавание синтаксиса/контекста. Неоднозначность в пользу конфиденциальности: правдоподобный корейский RRN/FRN имеет приоритет над корпоративной или деловой меткой, заголовком или разделённым JSON-ключом и никогда не классифицируется и не редактируется как идентификатор организации.

• Созданный оценщиком набор из 68 корейских чувствительных/организационных случаев (evidence/holdout/korean-sensitive-org-v1.cjson) — это проверка синтетических оракулов после внедрения, а не слепое исследование точности полей или проверки реестра. Случай проходит, когда присутствует каждое правило must_all, каждая группа must_any имеет хотя бы одно соответствующее правило и не появляется ни одно правило forbidden (показ recall по любому правилу для каждого случая). После этого прохода замороженный манифест набирает 68/68 с recall 1.0, специфичностью 1.0 и точным повторением двух прогонов. Это не заявление о точности полей в реальном времени.