K-Guard MCP

안경선배 · 바이브코딩 선배

만드는 흐름은 끊지 않고, 출하는 대충 넘기지 않습니다.

K-Guard MCP ist ein lokal priorisierter MCP-Prüfer, der vor der Auslieferung von Vibe-Coding-Ergebnissen gemeinsam Website-, API-Exposition-, Datenverwaltungs- und Betriebsrisiken prüft. Guardian unterscheidet zwischen „kein Problem" und „noch nicht gesehen" und liefert die Bewertung auslieferbar / reparieren und ausliefern / Prüfumfang unzureichend sowie die nächsten Schritte auf Koreanisch zurück.

K-Guard ist keine Garantie, die menschliche Geschäftsentscheidungen oder rechtliche Prüfungen ersetzt. Es automatisiert die Fragen, die ein Senior-Entwickler vor der Auslieferung stellt, und fail-closed-Gates.

5-Minuten-Installation · Installations- und Designvalidierung · Nutzungsanleitung · GitHub-Veröffentlichungshinweise · Erforderliche Qualifikation · Produkt-Nordstern · Gesamte Dogfood-Bewertung · Vorbereitung für den 2026-Wettbewerb

Erste 5 Minuten: Aktuellen Quellcode auschecken

Eine Verteilung über einen öffentlichen Paketindex wird noch nicht vorausgesetzt. Bei der ersten Ausführung installieren Sie den aktuellen Quellcode aus dem Repository-Root und folgen den nächsten Schritten, die 안경선배 anzeigt.

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

auto findet installierte Grok-, Codex- und Antigravity-Installationen, führt den k-guard-MCP im Benutzerbereich zusammen und bereitet, falls ein OpenAI-tunnel-client vorhanden ist, ein lokales Profil für ChatGPT vor. --workspace . fixiert das aktuelle Projekt als private Bindung. Auch wenn der MCP danach aus einem anderen Arbeitsverzeichnis gestartet wird, prüft er dieses Projekt und lehnt Pfade außerhalb der Grenze mit high HOLD ab. Für ChatGPT doctor/run wird zusätzlich ein CONTROL_PLANE_API_KEY mit Tunnels-Read- und Use-Berechtigung in der aktuellen Shell benötigt. Da bei ChatGPT danach tunnel-client run und die Verbindung der Entwicklermodus-App ausstehen, stellt der Installer den Erfolg nicht schön dar, sondern gibt Teilverbindung · nächste Schritte erforderlich zurück. Bestehende Konfigurationen werden bewahrt, vor JSON-Änderungen wird ein Backup erstellt, und Betriebs-Evidence-Keys sowie der Workspace-Originaltext werden nur in benutzerspezifischen Dateien unter ~/.k-guard gespeichert. local-dev aktiviert nur lokale localhost-Read-only-Probes und einen kleinen festen Vertiefungspfad; externe und Sitzungs-Probes bleiben weiterhin deaktiviert. Wenn nur statische Prüfungen benötigt werden, verwenden Sie --profile workspace.

Die Standardausgabe von Installation und Diagnose besteht aus drei Schritten: Verbindungsbereitschaft → AI-Client → nächste Schritte. Für Automatisierung verwenden Sie install --json und doctor --json. Für Wettbewerbs-Jury, Release-Reproduktion und Code-Änderungen verwenden Sie den Prüf- und Reproduktionsvalidierungspfad der 5-Minuten-Installation und installieren build- und evidence-lock mit --require-hashes. Semgrep 1.174.0 und pip-audit 2.10.1 werden ebenfalls mit dem vollständigen Hash-Closure aus requirements-semgrep.lock bzw. requirements-pip-audit.lock in isolierten venvs installiert, ohne die zu prüfende Laufzeit zu verändern.

Im MCP-Client:

안경선배로 이 앱을 끝까지 봐줘. 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 ist keine Prüfung, die in 5 Sekunden schnell erledigt ist, sondern ein Werkzeug, das eine vollständige Workspace-Prüfung annimmt. Die erste Antwort ist review_in_progress, und bis continue_review abgeschlossen ist, wird keine Auslieferungsentscheidung getroffen. Auch die für die Verteilung bestimmten Textartefakte in dist, build und .next werden geprüft; wenn Kandidatenanzahl, Pfad-SHA-256 und Leseabschluss nicht übereinstimmen, wird mit high blockiert. Das Abschlussergebnis erzeugt eine review_receipt, die an die Workspace- und Source-Tree-SHA-256 gebunden ist. Wenn sich der Code ändert, kann die Auslieferungsprüfung nicht mit der alten review_id gestartet werden; check_my_app muss erneut abgeschlossen werden.

Related MCP server: Secure Code Review MCP Server

안경선배-Bewertung

Alle repräsentativen Ergebnisse bieten sowohl experience.presentation als auch den kompatiblen Alias experience.details.presentation an, wobei die Reihenfolge fest auf verdict → why → next_actions → details gesetzt ist. Guardian zeigt das App-Risiko als application_assurance und den Validierungsstatus des Prüfwerkzeugs selbst als auditor_qualification getrennt an. experience.verdict_code, experience.verdict_message und experience.summary sind kompatible Felder für bestehende Berichte.

Was wird geprüft

K-Guard kombiniert:

• Statischer Scan: Koreanische PII, zusammengesetzte PII, koreanische Organisationskennungen (사업자등록번호-Prüfsummen-Syntaxvalidierung; 법인등록번호 historische Annex-Prüfsumme oder post-2025-01-31 4+2+7 explizite Kontext-/Syntaxerkennung, keine Live-Registervalidierung), Geheimnisse

• Konfigurationsscan: CORS-/Debug-/Source-Map-/Env-Präfix-Risiken

• Senior-App-Risikoscans: direkte Request-zu-SQL-/Befehls-/Datei-/URL-/HTML-Sinks, Mass Assignment, offene Weiterleitungen, Browser-Token-Speicherung, schwache Cookies, Klartext-Passwortvergleiche und JWT-Decode-ohne-Verify

• Koreanischer Data-Governance-Scan: eindeutige/sensible Felddeklarationen, Verschlüsselungs-/Zugriffskontroll-Beweise, Zugriffsprotokollierung, Prüfung externer Verarbeiter, Aufbewahrung und Löschung

• MCP-nativer Bedrohungsscan: versteckte Anweisungen, Tool-Poisoning, Exfiltrationsabsicht und übermäßiger lokaler Zugriff über direkten Text sowie begrenzte Unicode-/Confusable-, escaped-/Prozent-/HTML-, Base64-, Split-Fragment- und dreizeilige Rolling-Normalisierung

• Strukturierte MCP-Konfigurationsprüfung: Shell-Wrapper, veränderbare Paket-Launcher, unverschlüsseltes Remote-HTTP, feste Anmeldedaten, unsichere Links/Lesefehler und fail-closed-Erkennungsgrenzen über Projekt-/Codex-/Grok-/Antigravity-Konfigurationskandidaten

• YARA-lite lokales Regelpaket: Prompt-Injection-Marker, Exfil-Befehlsmarker, koreanische Bulk-Schema-Hinweise

• Sichere dynamische Probe: localhost-HTTP-Prüfungen, ausdrücklich autorisierte externe Origin-Prüfungen, optionale begrenzte Deep-Exposure-Prüfungen sowie optionale benutzerbereitgestellte Read-only-Sitzungsheader

• Data-Flow-Risikokarte: heuristischer Graph plus Python-AST- und leichtgewichtige JS/TS-Source-zu-Sink-Taint-Analyse, einschließlich Unique-Import-Python-Helper-Parameter-zu-Sink-Zusammenfassungen und begrenzter JS/TS-Route-zu-Service-IDOR-Zusammenfassungen

• MCP-Laufzeit-Beobachter/Interceptor: JSON-/JSONL- und stream-fähige Ereignisprüfungen für versteckte Anweisungen, PII-zu-agentischem/externem Sink-Fluss sowie Batch-Block-/Redact-Durchsetzung für weitergeleitete Ereignisströme

• Semgrep-Deep-Adapter: Offline-40-Regel-Profil, exakter gescannter Zielnachweis, gepinnte 1.174.0-Identität, Source-Snapshot-Bindung und fail-closed JS/TS/Python/Java/Kotlin/Go/PHP/Ruby/C#-Findings

• Neun-Sprachen-Validierungspaket: Python/JavaScript/TypeScript/Java/Kotlin/Go/PHP/Ruby/C# 90 gepinnte verwundbare/saubere Fälle, TP/FN/FP/TN-Bewertung und exakte Zwei-Lauf-Fingerabdruck-Reproduktion

• Software-Composition-Analyse: begrenzte Python-/npm-/Go-Manifest- und Lock-Abdeckung mit pip-audit, npm audit und govulncheck; teilweiser Engine-, Lock-, Ausgabe- oder Source-Drift-Fehler blockiert die Veröffentlichung

• Streamable-HTTP-MCP-Proxy: vollständige Vermittlung von POST/GET-SSE/DELETE, prinzipiengebundener Lebenszyklus, Default-Deny-JIT-/JEA-Gewährungen, gefiltertes Tool-Inventar, begrenzte Streams und HMAC-verkettete rohfrei-Auditprotokolle

• Datenbankkontrollen: SQLGlot-AST-Allowlist, Rollen-/Datenbank-/Schema-/Tabellen-/Spalten-RBAC, EXPLAIN-vor-Lesen, SQLite-Query-only-Autorisierer, Pfad-Containment sowie Zeilen-/Zellen-/Ergebnis-/Zeitbudgets

• Read-only-Konnektoren: lokale SQLite-, Log-, JSON-/CSV-/TSV-Speicher-Stichproben ohne Rohwert-Speicherung; Konnektorlücken werden zu high-Findings

• Aufbewahrungs-/Löschprüfung: kennzeichnet fehlende Aufbewahrungs-/Löschmarker, wenn personenbezogene Datensignale vorhanden sind

• Cross-Plane-Bewertungen: korreliert koreanische PII-Findings mit LLM-/MCP-/externen-/Data-at-Rest-Sink-Beweisen

• FP/FN-Scoreboard: Fixture-Korpus-Recall und False-Positive-Rate. FPR verwendet measurable_negative_count als Nenner (saubere Negative ohne expected_absent); negative_count sind alle deklarierten Negative und targeted_absence_case_count deckt ausgewählte Regel-Absenzen ab, die nicht in den FPR-Nenner eingehen. Ein Nenner von null messbaren Negativen wird als FPR 0.0 gemeldet.

• SARIF/CI-Ausgabe: Builds bei konfigurierten Schweregraden fehlschlagen lassen

• korean_senior-Guardian-Profil: fail-closed-Vier-Domänen-Vertrag für Website-Sicherheit, API-Exposition, Datenverwaltung und Betriebsrisiko

• Primäre MCP-Tools: check_my_app, continue_review, start_review_before_ship; interne kanonische Engine: Guardian high; geführter Prompt: guided_review

• Erweiterte MCP-Tools: 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

Installationsgrenzen

Benutzer, die die vom Release-Workflow erstellte requirements-evidence.lock zusammen mit dem exakten Wheel erhalten haben, können die geprüfte Dependency-Closure ohne Repository wie unten reproduzieren. k-guard, k-guard-dashboard, k-guard-mcp, python -m k_guard_mcp.cli, python -m k_guard_mcp.server sind Befehle des installierten Wheels.

Das Release enthält auch SHA256SUMS, ein mit GitHub-OIDC signiertes SLSA-Provenance-Bundle und ein CycloneDX-SBOM-Attestation-Bundle. Online verifizieren Sie zuerst mit gh attestation verify ./k_guard_mcp-0.1.0-py3-none-any.whl -R windmillstudio/k-guard-mcp Build-Subjekt und Digest und installieren dann. Wenn nur die Checksumme stimmt, die Attestation aber nicht verifiziert ist, wird das Artefakt nicht als offizielles Release-Artefakt behandelt.

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

Auf verwalteten PCs, auf denen die Windows-Anwendungssteuerungsrichtlinie den k-guard.exe-Konsolen-Launcher von pip blockiert, verwenden Sie den Modul-Einstiegspunkt desselben Wheels. Funktions- und Bewertungsvertrag sind identisch.

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

Wenn nur das Wheel installiert wird, werden nur Laufzeitbefehle bereitgestellt. Das Release-sdist und der Repository-Checkout enthalten scripts/..., tests/fixtures/... und Validierungsvorlagen. Die Entwicklungsumgebung wird vorbereitet, indem im Repository-Root die beiden Locks mit --require-hashes installiert und dann python -m pip install --no-build-isolation --no-deps -e . ausgeführt wird. Das Evidence-Lock fixiert Versionen und zulässige SHA-256 des Release-Dependency-Closures gemeinsam; Lizenz-, Schwachstellen-, SBOM- und Fresh-Wheel-Smoke verwenden dieselbe Datei.

안경선배-Prüfraum

Um autorisierte Websites auf dem Bildschirm zu prüfen, führen Sie das lokale Dashboard aus.

k-guard-dashboard --port 8765

Öffnen Sie im Browser http://127.0.0.1:8765/. Der Bildschirm folgt der Reihenfolge 선배-Bewertung → Findings → Prüfprotokoll → Expositionskarte, und die endgültige Auslieferungsberechtigung liegt nicht beim Bildschirm, sondern ausschließlich bei start_review_before_ship des MCP. Markenbilder sind Original-Assets, die für das Projekt erstellt wurden; die Provenance wird in docs/brand-assets.md dokumentiert.

Installierte Wheel-CLI

Unter den folgenden Befehlen ist tests/fixtures/korean_fixture_corpus.json ein öffentlicher Beispiel-Corpus, der direkt aus dem Quellcode-Checkout ausgeführt werden kann. Benutzer, die nur das Wheel installiert haben, ersetzen ihn durch einen eigenen Fixture-Pfad mit demselben Schema.

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 ist kurzlebig und an genau eine Origin gebunden. Guardian zählt einen authentifizierten Vergleich erst dann als abgeschlossen, wenn auch die behauptete Identitätsantwort übereinstimmt:

{
  "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>"
  }
}

Halten Sie die Datei innerhalb des aufgerufenen Workspace oder neben dem Guardian-Manifest. Dateien außerhalb dieser Grenze, Links, abgelaufene Sitzungen, nicht übereinstimmende Origins, nicht unterstützte Header und übermäßig große Dateien schlagen fail-closed fehl. Der Digest deckt die exakten begrenzten Antwortbytes vor der UTF-8-Dekodierung ab; rohe Sitzungswerte und Antwortkörper werden nicht in Findings geschrieben.

Nur für Quellcode-Checkout gültige Validierung

Die folgenden scripts/** und pytest sind keine Benutzerbefehle, die im Wheel enthalten sind.

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

Das Coverage-Gate 90.00% der vollständigen Quellcode-Regression ist eine branch-inklusive kombinierte Coverage, die Statement- und Branch-Opportunity gemeinsam berechnet. Es bedeutet nicht, dass die Branches selbst 90 % betragen; da precision=2 und fail_under=90 verwendet werden, schlägt 89.90% fehl. Der public_source_only-Umfang der öffentlichen Repository-CI schließt separate Verteilungsbeweise und native Fälle aus, daher gelten die Schwellen 88% insgesamt und 85% für redaction.py; die beiden Werte werden nicht gegeneinander ausgetauscht.

Quellcode-Checkout-Release-Hygiene

Verwenden Sie die Release-Hygiene-Prüfung vor der CTO-Überprüfung oder der Veröffentlichungsvorbereitung:

python scripts/release_hygiene.py --json

Der Standardmodus validiert, dass ein unsauberer Release-Kandidaten-Worktree klassifiziert ist, frei von sichtbarer Laufzeit-Scratch-Ausgabe und frei von ungelösten review-pflichtigen Artefakten. Verwenden Sie --strict-clean nach dem beabsichtigten Release-Commit; der strikte Modus vergleicht außerdem jedes Byte der Paket-Build-Eingaben mit seinem Git-Index-Blob. Die getaggte Veröffentlichung erfordert zusätzlich --expected-tag v{project.version}, und genau dieser Tag muss auf den ausgecheckten HEAD-Commit auflösen. Der Release-Workflow wartet auf die wiederverwendbare Windows-/macOS-/Linux-CI-Matrix, erstellt Attestationen und veröffentlicht die Tag-Artefakte als GitHub-Release. Details finden Sie in docs/release-hygiene.md.

Die Guardian-Actions-Vorlage installiert derzeit den exakten K-Guard-Quellcode-Checkout, der vom Workflow-Commit ausgewählt wird; sie setzt kein PyPI-Paket voraus. Bevor Sie sie in ein anderes Repository kopieren, vendorieren Sie K-Guard an einem commit-gepinnten Pfad und setzen Sie K_GUARD_SOURCE_PATH. Sobald Release-Artefakte existieren, sollten Verbraucher entweder ein exaktes Wheel plus dessen veröffentlichte SHA-256 oder einen vollständigen 40-stelligen Git-Commit in einer Direktreferenz-Anforderung pinnen. Ersetzen Sie die Platzhalter nur durch einen tatsächlichen Release-Ort:

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's primary license is MIT. Apache-2.0 upstream attribution, reviewed revisions, modified-file mapping, and excluded license boundaries are recorded in THIRD_PARTY_NOTICES.md and 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 is disabled by default. Enable it only for trusted audit sessions:

K_GUARD_MCP_ENABLE_PROBE=1 python -m k_guard_mcp.server

Authenticated read-only probing through MCP also requires K_GUARD_MCP_ENABLE_SESSION_PROBE=1 and a short-lived, origin-bound local session_file. Header values are read locally and are not written to findings. A header alone never proves login: Guardian requires the optional identity_assertion to match before authenticated comparison coverage can pass.

Bounded deep active probing through MCP also requires K_GUARD_MCP_ENABLE_DEEP_ACTIVE_PROBE=1 and probe_http(..., deep_active=true). This mode checks a small fixed list of exposed env/git/backup/debug paths and still avoids login attempts, mutations, fuzzing, and exploit payloads.

Authorized external probing through MCP also requires K_GUARD_MCP_ENABLE_EXTERNAL_PROBE=1 plus either K_GUARD_MCP_EXTERNAL_ALLOWED_HOSTS=example.com,staging.example.com or a per-call external_authorized=true with an authorization_note. The report records the authorization basis with DYN_EXTERNAL_TARGET_AUTHORIZATION_AUDIT.

Installation und Verbindung sind auf die vier Clients ChatGPT, Grok, Codex und Antigravity abgestimmt; die detaillierten Schritte finden Sie in docs/quickstart-ko.md und docs/mcp-client-install.md.

Für die Vorbereitung des Wettbewerbs-Ergebnisberichts und der tatsächlichen Kompatibilitätsnachweise verwenden Sie docs/contest-2026-result-report-draft-ko.md und docs/client-interop-evidence-kit-ko.md. Als tatsächlich abgeschlossene Kompatibilität werden nur Bereiche gezählt, für die pro Client install → restart → tool list → check_my_app → reconnect-Aufzeichnungen, eine eindeutige SHA-256-Prüfsumme und eine separate Überprüfung vorliegen.

MCP calls also enforce argument and inline-text budgets by default:

• 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 calls preflight the whole manifest against the target, filtered-file, byte, and projected HTTP-request budgets. File expansion is bounded at the configured limit plus one detection entry, so an oversized tree is rejected without first enumerating the entire tree. Oversized multi-target work returns a Guardian-shaped fail-closed report; use the CLI or split the manifest for intentionally larger batches. Dynamic HTTP inspection reads at most 1 MiB per response by default and also stops at 16 MiB, 80 requests, or 30 seconds per probe run.

Safety Defaults

• JSON/Markdown/MCP outputs pass through a central redaction layer

• SARIF output also passes through the same redaction layer and stores raw-free evidence

• Dynamic probe only allows localhost, 127.0.0.1, and ::1 by default

• External dynamic probe requires explicit authorization evidence and opt-in, then remains fixed-path, read-only, same-origin, and no-redirect. Each request resolves only allowlisted public addresses and connects to the selected validated IP while preserving the original HTTP Host/TLS SNI.

• Dynamic probe does not follow redirects to non-allowlisted hosts

• Dynamic probe uses non-destructive HTTP methods only

• --deep-active is a bounded authorized check for common exposed .env, .git/config, backup/dump, and debug/runtime paths. It is not recursive crawling, password guessing, exploit payloading, or a path brute-force dictionary.

• Dynamic probe uses a timeout and caps sampled response bodies

• External secret validity checks are not performed

Severity and Confidence

Severity values are validated centrally:

• critical: credential/private-key/DB URL exposure, direct high-risk identifiers, or unauthenticated sensitive routes

• high: strongly identifying combinations, risky localhost exposure, or sensitive flow candidates

• medium: standalone contact/location/config signals and hardening findings

• low: weak heuristic signals

• info: informational observations

Confidence values are high, medium, and low.

Data Flow And Inner-Core Limits

The flow map is explicitly EXPERIMENTAL and marked as heuristic+ast-taint+js-ts-taint with line-distance+python-intra-procedural-ast+js-ts-intra-file+limited-interprocedural-taint precision. It is a developer triage aid: Python AST taint is supported, and JS/TS now has lightweight intra-file taint, limited route-to-service summaries, plus framework-aware heuristics for Next.js route handlers/server actions, Express IDOR-shaped route params, Supabase service-role/RLS boundary hints, and Firebase Admin auth-boundary hints. Full TypeScript type checking, alias-complete import resolution, middleware proof, deployed RLS/Firebase rule proof, and complete inter-procedural taint remain roadmap items. Flow findings include raw-free source/sink line hashes to make evidence reproducible without echoing sensitive values. Flow visualizations are generated as local SVG/HTML without external JavaScript or CDN dependencies. The same redaction layer protects JSON, Markdown, SVG, HTML, and MCP responses.

Runtime MCP observation ingests JSONL/JSON event exports through observe_mcp_events and can also evaluate one event at a time through observe_mcp_event(session_id=...). CLI mcp-intercept applies those block and redact decisions to a batch event stream before writing forwarded JSONL. CLI mcp-proxy -- <upstream argv> is the live enforcement path for line-delimited stdio JSON-RPC. CLI mcp-http-proxy --upstream <URL> enforces the same policy across Streamable HTTP POST, GET SSE, and DELETE session lifecycles, with official Python MCP SDK interoperability coverage. Both proxies emit the same raw-free, transaction-linked HMAC receipt chain for access deny and content allow/redact/block decisions; configured sidecar persistence happens before forwarding and fails closed. Operator-secret verification is required for tamper-resistance claims because HMAC is a shared-secret tag, not a public-key signature. Both proxies fail closed on invalid framing, correlation errors, size or timeout limits, and transport control failures. Streaming observer state has bounded idle/LRU session retention. MCP enforce_mcp_events remains report-only. Binary framing, nonstandard transports, and a universal drop-in proxy for every MCP client remain roadmap work.

Read-only connectors inspect local SQLite/log/storage files only. Remote Postgres/Supabase/Firebase/S3, backups, and actual deletion execution are roadmap items.

Feedback Drift Loop

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 files are sanitized before write and summarized locally for corpus tuning. False-negative snippets use extra conservative token masking because the detector may have missed the sensitive value. feedback-export requires --reviewed or K_GUARD_FEEDBACK_EXPORT_REVIEWED=1 so accidental automated exports fail closed. Review feedback-summary.json before sharing it outside the partner environment; do not transmit raw feedback.jsonl.

Field Benchmark

benchmark-template creates a 20/20/10 manifest:

• 20 general baseline sites or reports

• 20 vibe-coded suspected sites or reports

• 10 owned, partner-approved, or bug-bounty scoped targets

benchmark aggregates raw-free K-Guard JSON reports and, only with --run-probes, authorized manifest rows marked mode=probe. It reports high/critical target rate, strong-identifier detection rate, top rules, and manual false-positive rate by cohort. The default path is report-only so benchmark work can start from dashboard exports without touching external sites.

The same workflow is available through MCP as create_benchmark_template and field_benchmark. MCP benchmark probes require the same explicit probe opt-ins as probe_http.

Guardian Mode

guardian-template creates an authorized target manifest for continuous product guarding. A row can point to a local workspace, an HTTP origin, an MCP runtime JSONL export, or an existing raw-free K-Guard JSON report. guardian aggregates all rows into one raw-free report with per-target gates, new/resolved finding drift, top recurring rules, and fix recipes from suggest_fix.

Guardian manifests also carry raw-free business-intent and scope assertion fields: business_purpose, data_classes, user_scope, public_endpoints, scope_basis, and scope_proof_ref. K-Guard does not claim human-level business understanding or prove ownership by itself; it records whether those assertions exist and stores only hashed refs. Scope completion requires an explicit scope_proof_ref; locators and legacy authorization notes are not treated as proof. Data-release gating requires those target-level contracts and verified operator-keyed evidence bundles whose artifact hashes match the current report before treating a report as shipment evidence.

New templates set audit_profile=korean_senior. In this profile a release gate does not pass merely because it found zero blockers. It also requires a substantive workspace with at least one supported and successfully decoded production source file, flow analysis, a completed deep HTTP review, declared endpoint paths that actually return 2xx/3xx/401/403 rather than only 404, and explicit purpose/data/user/scope assertions. Guardian content-hashes each workspace immediately before and after its audit; a mismatch emits GUARDIAN_SOURCE_CHANGED_DURING_AUDIT, blocks the target, and excludes that run from substantive coverage. Use an immutable CI checkout for release authority. The report exposes review_contract.domains for site_security, api_exposure, data_management, and operational_risk; guardian_gate.passed remains false when any required domain is incomplete. Legacy manifests without audit_profile remain on the narrower standard profile and must not be presented as four-domain senior coverage.

public_endpoints is executable review scope, not decorative metadata. Guardian safely adds valid same-origin paths from that field to the fixed GET/OPTIONS probe set (maximum 50; no absolute URL, parent traversal, or templated path). This lets the API review cover app-specific read-only endpoints while keeping the probe bounded.

When an HTTP row includes session_file, Guardian runs the same bounded path set twice: once unauthenticated and once with the operator-provided read-only session. This keeps public exposure checks visible instead of replacing them with an authenticated-only view. The session must prove both an auth-wall transition and the declared identity response digest. A korean_senior gate rejects HTTP coverage when either proof is absent, when a probe produced request or control errors, or when no valid declared endpoint scope was reached.

guardian --fail-on high is the canonical pre-release gate. It is the workflow to use when K-Guard should decide whether a target app can ship under a configured threshold. Workspace-only scan --fail-on and MCP security_gate are quick checks; they do not replace Guardian's manifest, coverage-gap, drift, and multi-target execution contract.

By default, guardian writes a report and exits successfully so teams can review findings without turning it into a release blocker. Use --fail-on high when the same report should act as a CI gate; it exits with code 3 when blocking targets or new blocking findings are present. On the first run without --previous, the report is an initial_snapshot: current blockers and coverage gaps can still fail the gate, but K-Guard does not label every current finding as new drift. In gate mode, HTTP rows in the manifest must actually execute via --run-probes or they become coverage gaps instead of silent passes.

HTTP-Zeilen werden nur ausgeführt, wenn --run-probes übergeben wird. Der CLI-Pfad ist für einen vertrauenswürdigen lokalen Operator gedacht und verwendet explizite CLI-Flags/Manifest-Zeilen als Opt-in. MCP ist agentenvermittelt und strenger: guardian_audit(..., run_probes=true) erfordert K_GUARD_MCP_ENABLE_PROBE=1; Manifeste, die externe, tiefaktive oder Sitzungs-Probes anfordern, erfordern zusätzlich K_GUARD_MCP_ENABLE_EXTERNAL_PROBE=1, K_GUARD_MCP_ENABLE_DEEP_ACTIVE_PROBE=1 bzw. K_GUARD_MCP_ENABLE_SESSION_PROBE=1. Der Guardian-Modus verwendet weiterhin feste sichere GET/OPTIONS-Probes und führt keine Login-Versuche, Passwort-Raten, Mutationen, Exploit-Payloads, rekursives Crawling oder Cross-Host-Redirect-Folgen durch.

MCP-Clients sollten fail_on="high" an guardian_audit übergeben, um das kanonische Release-Gate-Urteil in guardian_gate.passed zu erhalten; Prozess-Exit-Codes bleiben eine CLI-Angelegenheit. Verwenden Sie --previous previous-guardian-report.json, um den Bericht in einen Drift-Monitor zu verwandeln. Neue blockierende Befunde werden nur dann separat aufgelistet, wenn ein vorheriger Bericht geladen ist; kombinieren Sie --previous mit --fail-on, wenn diese Befunde ein Release stoppen sollen. Wenn MCP-Kontrollprüfungen den Guardian vor der Zielausführung stoppen, geben sowohl der Berichtsmodus als auch der Gate-Modus eine Guardian-förmige Antwort mit execution_contract, summary und findings zurück; der Gate-Modus enthält zusätzlich guardian_gate.passed=false. Der Bericht enthält einen Abschnitt execution_contract, sodass übersprungene, fehlerhafte und ausgeführte Ziele an einer Stelle sichtbar sind, einschließlich Markdown- und HTML-Exporten.

MCP security_gate(path, fail_on) ist ein schnelles reines Workspace-Gate. Es gibt jetzt security_gate.passed=false bei MCP-Kontrollfehlern wie ungültigen Schwellenwerten, Argumentbudgets, Workspace-Budgetgrenzen oder Scan-Ausnahmen zurück, meldet aber absichtlich coverage_model="workspace_only". Verwenden Sie Guardian für Release-Entscheidungen, die HTTP-Ziele, MCP-Laufzeitexporte, frühere Berichte oder Coverage-Lücken-Berechnung benötigen.

Die Unterdrückungsrichtlinie ist fail-closed. suppression-template erstellt eine CSV, die jede Ausnahme an app_id, audit_profile, den aktuellen Quell-Snapshot oder Review-Evidenz-Hash, target_id, Befund-Fingerabdruck, Eigentümer, Grund und zukünftiges Ablaufdatum bindet. Eine Ausnahme kann nicht gegen eine andere App oder einen geänderten Release-Snapshot wiederverwendet werden; ungültige, veraltete oder abgelaufene Zeilen fügen einen Policy-Befund mit hoher Schwere hinzu. Unterdrückungen können weder Guardian-Coverage-Lücken noch MCP-Kontrollfehler-Regeln beseitigen. field-validation-queue exportiert jeden High/Critical-Kandidaten mit einem redigierten Fingerabdruck, Detektor-Subtyp, Artefakt-Bereich, Datei/Body/Header-Ortstyp und verfügbarem Antwort-Hash. Der strenge Anspruch von field-validation-report --profile field bleibt geschlossen, bis 12–20 eigene/Partner-Apps, 120 beschriftete Fälle, 50 Positive, 40 Negative, fünf kritische Fälle, drei Schichten, ein vorregistriertes Holdout mit mindestens 70 Fällen, 35 Positiven, 35 Negativen und 35 Kandidaten, rollengetrennte Prüfer-/Verwahrer-Signaturen und ein exakter zweiter kanonischer Guardian-Ausführungslauf alle festen Schwellenwerte bestehen. Gesamt-/Holdout-Präzision, Holdout-High/Critical-Recall und Holdout-Spezifität müssen sowohl den Punktschätzer als auch die Wilson-95%-Untergrenze bestehen; der kritische Holdout-Recall bleibt exakt 1,0. Jeder Kandidat muss an genau einen eingefrorenen Entwicklungs-/Holdout-Bereich gebunden sein. Kandidat (false_positive + benign) / (true_positive + false_positive + benign) wird als False-Discovery-Rate gemeldet; die False-Positive-Rate wird nur über saubere Fälle als FP / (FP + TN) berechnet. Das Datenfreigabe-Gate ist strenger: Jeder bekannte False Negative oder gutartige High/Critical-Kandidat blockiert die Freigabe. K_GUARD_FIELD_REVIEWER_HMAC_KEYS und K_GUARD_FIELD_CUSTODIAN_HMAC_KEY müssen sich vom Operator-Evidenzschlüssel unterscheiden; diese lokalen HMACs trennen Rollen, beweisen aber keine reale Identität oder kryptografisch unabhängige Ausführung. Legacy-validation-*-Befehle aggregieren nur Kandidatenbeschriftungen und können keinen Feld-Recall etablieren.

Der öffentliche Vertrag für die automatische Blockierungsqualifikation ist von der Feldvalidierung getrennt. release_blocker_actionability_v3 erfordert eine vorregistrierte Zählung von mindestens 100 automatischen Blockierern, 0,90 Kandidaten-Actionability und eine Wilson-95%-Untergrenze von 0,80. Es erfordert außerdem automatische Blockierer in mindestens 20 Anwendungen. Eine Anwendung gilt nur dann als vollständig umsetzbar, wenn jeder automatische Blockierer in dieser Anwendung als true_positive beschriftet ist; sowohl die Rate vollständig umsetzbarer Anwendungen als auch die Wilson-Untergrenze müssen 0,90 und 0,80 bestehen. Dieses anwendungsbezogene Sensitivitäts-Gate verhindert, dass Dutzende korrelierter Zeilen in einem Repository falsches statistisches Vertrauen erzeugen. Manuelle Prüf- und Policy-Integritäts-Sperren bleiben fail-closed, sind aber von der automatischen Blockierer-Actionability ausgeschlossen.

Der vollständige Vertrag zu Evidenzstufen, erster Baseline, Beschriftung und Wiederholungsläufen ist in docs/field-validation-v2-ko.md dokumentiert.

data-release-gate ist strenger: Es erfordert K_GUARD_EVIDENCE_HMAC_KEY, das ursprüngliche Guardian-Manifest, einen kanonischen high-Guardian-Anspruch, der an den aktuellen Bericht gebunden ist, Ziel-Evidenz- und Quell-Snapshots, separat signierte primäre und wiederholte Validierungsquellen-Guardian-Originale, die exakten Ground-Truth-/Prüfer-CSVs, die ursprüngliche Verwahrer-Vorregistrierung, koreanische Korpus-Evidenz und den tatsächlichen weitergeleiteten MCP-Interceptor-Stream. Es führt die Feldvalidierung aus diesen Originalen erneut aus, validiert die Prüfer-/Verwahrer-HMACs erneut und verlangt, dass die neu berechnete Projektion dem eingereichten Bericht entspricht. Es öffnet auch den wiederholten Guardian erneut und prüft unabhängig Inhalt, Bundle, Ausführungsattestierung, Toolchain, Manifest, Quell-/HTTP-/MCP-Eingaben und die exakte Kandidaten-Multimenge. Die Design-Partner-Validierung ist absichtlich unabhängig von der einzelnen aktuell freigegebenen App; ihre Kandidaten-App-/Ziel-/Befund-Referenzen müssen mit dem Validierungsquellen-Guardian-Bericht übereinstimmen und dürfen nicht als Release-App-Coverage auftreten. Eine wiederverwendbare GitHub-Actions-Vorlage befindet sich unter docs/templates/github-actions/guardian-release-gate.yml.

Unauthentifiziertes JSON wird nach Risiko aufgeteilt. Sensible/private Datensatzstrukturen bleiben DYN_UNAUTH_API_JSON mit hoher Schwere; JSON ohne diese Indikatoren wird zu DYN_PUBLIC_API_JSON_REVIEW mit Info-Schwere, sodass eine absichtliche öffentliche API ein Release nicht allein wegen der Rückgabe von JSON blockiert.

scripts/site_scale_calibration.py führt lokale Black-Box-HTTP-Fixtures für großes allgemeines HTML-Rauschen, mittlere öffentliche Kontaktseiten, kleines vibe-codiertes Bulk-JSON, gültige starke Identifikatoren und Bankkonto-JSON aus. Es verwendet keinen externen Netzwerkzugriff.

scripts/deep_probe_synthetic_calibration.py führt ein lokales synthetisches Loopback-Kalibrierungsharness über denselben Dashboard-scan_url(..., deep_active=True)-Pfad aus. Der Standard-Evidenzlauf verwendet 500 Loopback-Aufrufe über 24 begrenzte Szenarien; dies sind keine 500 echten Websites, keine Schwachstellenerkennung und kein Penetrationstest. Es deckt .env, .git/config, Backup-SQL, Debug-Endpunkte, Admin-/API-Exposition, OpenAPI, Source Maps, CORS, Redirects, PII-/Geheimnis-Antwortstufen und False-Positive-Kontrollen für Login-Wände, SPA-Shells und HTML-Fallbacks ab. Es enthält auch Negativkontrollen, die beweisen, dass der Erwartet-gegen-Beobachtet-Scorer injizierte fehlende und unerwartete Regeln erkennen kann. Es verwendet keinen externen Netzwerkzugriff; echte externe Tiefen-Probes erfordern weiterhin eine explizite Zielautorisierung.

scripts/inner_core_product_gate.py führt das breitere lokale synthetische Produkt-Gate für den „Inner-Core“-Audit-Anspruch aus. Es kombiniert die 500-Ziel-Loopback-Tiefenproben-Kalibrierung mit statischen Code-/Konfig-/MCP-Textprüfungen, Python-AST-Taint, MCP-Laufzeit-JSONL-Beobachtung, schreibgeschützten SQLite-/Log-/Speicher-Konnektoren, Aufbewahrungs-/Löschprüfung, Cross-Plane-PII-zu-agentischen/externen Urteilen und rohfreien Evidenzgraph-Prüfungen. Dieses Gate muss null fehlende erforderliche Regeln, null unerwartete Tiefenproben-Regeln, bestandene Negativkontrollen, nicht-leere Flussgraph-Knoten/-Kanten und keine verbotenen Roh-Marker im serialisierten Bericht aufweisen. Es ist ein Produkttiefen-Gate, kein Beweis für die Schwachstellenerkennung auf Websites Dritter.

Der CI-Workflow führt die vollständige pytest-Suite plus ein 24-Ziel-Inner-Core-Gate bei Push/Pull-Request aus, das jedes synthetische Szenario einmal abdeckt. Der geplante/manuelle Audit-Workflow führt das 500-Ziel-Inner-Core-Gate aus und lädt sein JSON-/Markdown-/HTML-Evidenzpaket hoch. Der Repository-Selbst-SARIF-Scan wird als nicht-gating-Evidenz hochgeladen, da dieses Scanner-Repository absichtlich Detektorregeln, Fixtures und Dokumentationsbeispiele enthält, die K-Guard-Befunde auslösen sollten; verwenden Sie --fail-on gegen das geprüfte Produkt, nicht gegen K-Guards eigenen fixture-lastigen Quellbaum, sofern keine projektspezifische Baseline existiert.

scripts/passive_homepage_calibration.py führt eine reine GET-/-Homepage-Kalibrierung aus einem CSV-Manifest aus. Es unterstützt --max-targets, --delay-ms, --checkpoint-jsonl und --resume für Sharded-Läufe im 10k-Maßstab. Es meldet Kohorten-, Rang-Bucket-, Ergebnis- und Hygiene-Stufen-Aggregate wie well_managed_quiet, hardening_gap, boundary_redirect und messy_or_risky_signal, sodass laute gut verwaltete Websites und unordentliche Long-Tail-Websites getrennt kalibriert werden können. Es gibt außerdem ein release_gate mit Pass-/Warn-/Fail-Prüfungen für Messertrag, High-/Critical-Rate, Strong-Identifier-Rate und Boundary-Redirect-Rate aus. Es fordert keine /admin, /api, .env, .git, OPTIONS oder rekursiven Pfade an.

scripts/build_top_domain_manifest.py erstellt dieses passive Kalibrierungsmanifest automatisch aus einer öffentlichen Top-Domain-CSV- oder ZIP-Quelle. Die Standardquelle ist Trancos neuestes Top-1m-ZIP, sodass Operatoren nicht manuell 10.000 URLs sammeln müssen. Verwenden Sie --start-rank, um Long-Tail-Unordentliche-Kandidaten-Kohorten zu erstellen, z. B. Ränge 900.001 bis 910.000. Majestic-Million-Stil-CSVs können ebenfalls mit --source-url bereitgestellt werden.

KI-only-Wettbewerbs-RC-Evidenz

Der Wettbewerbs-RC hält Entwicklungsevidenz in getrennten Spuren, anstatt eine einzige gepoolte Genauigkeitszahl zu veröffentlichen:

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

• Der koreanische Qualifikationsbericht meldet 117 Fixture-Fälle und ein eingefrorenes, von Evaluatoren erstelltes Holdout mit 68 Fällen als getrennte Spuren. Er prüft außerdem fünf Workspace-Verträge, die vier offiziellen Unique-Identifier-Konzepte, Geschäfts-/Firmennummern-Grenzen und sechs sensible-Vokabular-Oberflächen. Er veröffentlicht keine gepoolte Konfusionsmatrix und beansprucht keine blinde, menschlich begutachtete, Register-, Partner- oder Feldgenauigkeit.

• Die öffentliche Scorecard bewahrt aktuelle und historische Spuren getrennt auf. --require-integrity-pass schlägt absichtlich fehl, solange ein ausgewähltes historisches Artefakt einen Digest- oder Bindungsfehler aufweist; ein Bericht kann dennoch erzeugt werden, sodass ein unzulässiges historisches Ergebnis sichtbar bleibt, anstatt stillschweigend neu geschrieben oder verworfen zu werden.

• Das Wettbewerbs-Leistungsprofil misst exakte synthetische All-Benign-Low-Signal-Korpora auf einem offengelegten Host, einschließlich Kaltlatenz bei frischem Prozess und Warmlatenz bei persistentem Scanner, 10/50/100-MiB-Skalierung, In-Process-CPython-Thread-Konkurrenz 1/4/8, Spitzen-RSS, vollständige Kandidatenabdeckung und rohfreie Ergebnisinvarianz. Es misst keine Befund-dichte Skalierung, Prozessebenen-Parallelität, Produktions-SLO, Feldgenauigkeit, hardwarenormalisierten Vergleich oder Überlegenheit Dritter.

Aktuelle Grenzen

• Roadmap zur Produkthärtung: docs/pre-release-auditor-hardening-plan-ko.md

• PDF/DOCX/HWP-Extraktion ist noch nicht enthalten

• Dynamische Prüfungen sind nur auf localhost beschränkt, sofern sie nicht ausdrücklich auf die Whitelist gesetzt oder vom Betreiber für ein eigenes, partnergeprüftes oder im Rahmen von Bug-Bounties abgedecktes externes Ziel attestiert wurden

• Vom Benutzer bereitgestellte Sitzungs-Header werden nur an schreibgeschützte GET-Anfragen angehängt, und Header-Werte werden nicht gespeichert

• JS/TS-Taint ist konservativ und leichtgewichtig, mit Intra-Datei-Taint, begrenzten Route-zu-Service-Zusammenfassungen und framework-bewussten Heuristiken für häufige Next.js/Express/Supabase/Firebase-Grenzfehler; Python-AST-Taint ist intraprozedural

• Die Laufzeit-MCP-Beobachtung und das MCP-Tool enforce_mcp_events bleiben beratend; mcp-proxy und mcp-http-proxy führen eine tatsächliche bidirektionale Durchsetzung für zeilenbasiertes stdio-JSON-RPC und den getesteten Streamable-HTTP-Lebenszyklus durch. Binäres Framing, nicht standardkonforme Transporte und ein universeller Drop-in-Proxy für jeden Client bleiben außerhalb der durchgesetzten Grenze

• Remote-DB/Speicher/Backups und die tatsächliche Ausführung von Löschungen sind noch nicht verifiziert

• Koreanische PII-Muster sind regelbasiert und benötigen projektspezifische Fehlalarm-Abstimmung

• Koreanische Unternehmensregistrierungsnummern verwenden eine Prüfsummen-Syntaxvalidierung an synthetischen bzw. anbietererstellten Fixtures. Historische Unternehmensregistrierungsnummern (ausgestellt vor dem 31.01.2025) können die alte Anlage mit alternierender 1,2-Gewichtungsprüfsumme verwenden. Seit dem 31.01.2025 bestehen aktuelle Unternehmensnummern aus 4 Register- + 2 Typ- + 7 Serienziffern ohne Prüfsumme, sodass die Erkennung nur eine explizite Feldkontext-/Syntaxerkennung ist. Nichts davon ist PII natürlicher Personen, Live-Registervalidierung oder unabhängige Feldvalidierung. Nur kontextbezogene aktuelle Werte sind unverifizierte Syntax-/Kontexterkennung. Datenschutzorientierte Mehrdeutigkeit: Eine plausible koreanische RRN/FRN gewinnt gegenüber einer Unternehmens- oder Geschäftsbezeichnung, einem Header oder einem geteilten JSON-Schlüssel und wird niemals als Organisations-ID klassifiziert oder redigiert.

• Der vom Evaluator erstellte 68-Fälle-Holdout für koreanische sensible/Organisationsdaten (evidence/holdout/korean-sensitive-org-v1.cjson) ist eine Post-Implementierungs-Inspektion synthetischer Orakel, keine blinde Feldgenauigkeits- oder Registervalidierungsstudie. Ein Fall besteht, wenn jede must_all-Regel vorhanden ist, jede must_any-Gruppe mindestens eine passende Regel hat und keine forbidden-Regel erscheint (Any-Rule-Recall pro Fall). Nach diesem Durchgang erreicht das eingefrorene Manifest 68/68 mit Recall 1,0, Spezifität 1,0 und exakter Zwei-Lauf-Wiederholung. Das ist keine Behauptung über Live-Feldgenauigkeit.