haechi 1.3.2 → 1.3.3

package/docs/current/operations-runbook.ko.md

@@ -21,6 +21,17 @@ docker compose up -d        # 참조 스택 빌드 + 실행
 docker compose logs -f haechi
 ```
 
+**사전 빌드 이미지(GHCR).** 각 `v<semver>` 릴리스는 cosign 서명된 이미지를 `ghcr.io/<owner>/haechi`에 발행하며(태그 `<major>.<minor>.<patch>`, `<major>.<minor>`, `<major>`, `latest`), 실행 전에 검증하십시오 — 서명과 provenance가 이미지를 이 repo의 release workflow에 묶습니다:
+
+```bash
+cosign verify ghcr.io/<owner>/haechi:1.3.3 \
+  --certificate-identity-regexp '^https://github.com/<owner>/haechi/' \
+  --certificate-oidc-issuer https://token.actions.githubusercontent.com
+gh attestation verify oci://ghcr.io/<owner>/haechi:1.3.3 --repo <owner>/haechi
+```
+
+이미지는 `proxy.trustForwardedProto: true`를 구워 넣으므로(TLS를 종단하는 리버스 프록시 뒤에서 `0.0.0.0`에 바인딩 — 아래 참조), Haechi는 보호되는 모든 요청에 `X-Forwarded-Proto: https`를 요구합니다. Haechi가 직접 TLS를 종단하게 하려면 `proxy.tls`가 설정된 본인의 설정을 마운트하십시오.
+
 **TLS + 인증으로 앞단을 보호하십시오.** Haechi는 자체 TLS가 없습니다. 포트는 TLS를 종단하고 인증하는 리버스 프록시(nginx / Caddy / Traefik / API 게이트웨이)에만 공개하고, 원시 Haechi 포트를 공개 인터페이스에 절대 노출하지 마십시오. compose 예제는 바로 이 이유로 호스트 loopback(`127.0.0.1:11016`)에만 공개합니다.
 
 **Loopback 너머 바인딩.** 컨테이너 내부에서는 매핑된 포트가 도달 가능하도록 Haechi가 `0.0.0.0`에 바인딩해야 하며, 이는 `--allow-remote-bind`를 요구합니다(참조 `CMD`가 전달합니다). 호스트에서는 기본 loopback 바인딩을 선호하고 리버스 프록시를 통해 Haechi에 접근하십시오. [Loopback 너머 바인딩](./configuration.ko.md)을 참고하십시오.

package/docs/current/operations-runbook.md

@@ -30,6 +30,23 @@ docker compose up -d        # build + run the reference stack
 docker compose logs -f haechi
 ```
 
+**Pre-built image (GHCR).** Each `v<semver>` release publishes a cosign-signed
+image to `ghcr.io/<owner>/haechi` (tags `<major>.<minor>.<patch>`, `<major>.<minor>`,
+`<major>`, `latest`). Verify it before running — the signature and provenance bind
+the image to this repo's release workflow:
+
+```bash
+cosign verify ghcr.io/<owner>/haechi:1.3.3 \
+  --certificate-identity-regexp '^https://github.com/<owner>/haechi/' \
+  --certificate-oidc-issuer https://token.actions.githubusercontent.com
+gh attestation verify oci://ghcr.io/<owner>/haechi:1.3.3 --repo <owner>/haechi
+```
+
+The image bakes `proxy.trustForwardedProto: true` (it binds `0.0.0.0` behind a
+TLS-terminating reverse proxy — see below), so Haechi requires `X-Forwarded-Proto:
+https` on every protected request; mount your own config with `proxy.tls` set
+instead if you want Haechi to terminate TLS itself.
+
 **Front it with TLS + auth.** Haechi has no TLS of its own. Publish its port only
 to a TLS-terminating, authenticating reverse proxy (nginx / Caddy / Traefik / an
 API gateway); never expose the raw Haechi port on a public interface. The compose

package/docs/current/release-process.ko.md

@@ -68,6 +68,7 @@ npm audit signatures
 |---|---|---|---|
 | `.github/workflows/ci.yml` | — | 모든 push/PR | test, release preflight, SBOM artifact |
 | `.github/workflows/npm-publish.yml` | `haechi` | `v<semver>` | npm provenance publish + 체크섬/증명 release 자산 |
+| `.github/workflows/container-publish.yml` | `ghcr.io/<owner>/haechi` 이미지 | `v<semver>` | 루트 Dockerfile 빌드, GHCR로 push, digest 기준 keyless cosign 서명 + sigstore build-provenance 증명 |
 | `.github/workflows/crypto-kms-publish.yml` | `haechi-crypto-kms` | `crypto-kms-v<semver>` | satellite publish, 동일한 서명 아티팩트 경로 |
 | `.github/workflows/auth-jwt-publish.yml` | `haechi-auth-jwt` | `auth-jwt-v<semver>` | satellite publish, 동일한 서명 아티팩트 경로 |
 | `.github/workflows/dashboard-publish.yml` | `haechi-dashboard` | `dashboard-v<semver>` | satellite publish, 동일한 서명 아티팩트 경로 |

package/docs/current/release-process.md

@@ -68,6 +68,7 @@ npm audit signatures
 |---|---|---|---|
 | `.github/workflows/ci.yml` | — | any push/PR | Tests, release preflight, SBOM artifact |
 | `.github/workflows/npm-publish.yml` | `haechi` | `v<semver>` | npm provenance publish + checksummed/attested release assets |
+| `.github/workflows/container-publish.yml` | `ghcr.io/<owner>/haechi` image | `v<semver>` | Build the root Dockerfile, push to GHCR, keyless cosign sign by digest + sigstore build-provenance attestation |
 | `.github/workflows/crypto-kms-publish.yml` | `haechi-crypto-kms` | `crypto-kms-v<semver>` | satellite publish, same signed-artifacts path |
 | `.github/workflows/auth-jwt-publish.yml` | `haechi-auth-jwt` | `auth-jwt-v<semver>` | satellite publish, same signed-artifacts path |
 | `.github/workflows/dashboard-publish.yml` | `haechi-dashboard` | `dashboard-v<semver>` | satellite publish, same signed-artifacts path |

package/docs/current/reliability-hardening-track.ko.md

@@ -1,6 +1,6 @@
 # 신뢰성 하드닝 트랙 (Reliability Hardening Track)
 
-- 상태: 계획 (2026-06-12 확정; 1.1.1 코어에 대한 5-렌즈 읽기 전용 감사에 근거)
+- 상태: 출시 완료 — WS1–WS6 전부 core 1.2.0으로 전달·컷됨(릴리스 게이트 G7 Pass). 이 문서는 계획/감사 기록으로 보존합니다. (2026-06-12 확정; 1.1.1 코어에 대한 5-렌즈 읽기 전용 감사에 근거.)
 - 대상 라인: 1.1.2(patch) → 1.2.0(minor); 신규 제품 표면 없음
 - 목적: Haechi를 **상용 솔루션 수준의 신뢰성**으로 끌어올립니다 — 운영 AI 보안 게이트웨이에 기대되는 신뢰·운영성·탐지 품질의 밀도입니다. 이것은 품질 목표이지 상용화 계획이 아닙니다. 모든 항목은 **이미 존재하는 것을 조이거나, 측정하거나, 문서화**하며, 신규 기능을 추가하지 않습니다.
 

package/docs/current/reliability-hardening-track.md

@@ -1,6 +1,6 @@
 # Reliability Hardening Track
 
-- Status: Plan (pinned 2026-06-12; grounded in a 5-lens read-only audit of the 1.1.1 core)
+- Status: Shipped — WS1–WS6 all delivered and cut in core 1.2.0 (release gate G7 Pass). This doc is retained as the planning/audit record. (Pinned 2026-06-12; grounded in a 5-lens read-only audit of the 1.1.1 core.)
 - Target line: 1.1.2 (patch) → 1.2.0 (minor); no new product surface
 - Purpose: raise Haechi to **commercial-solution-level reliability** — the trust, operability, and detection-quality density a production AI-security gateway is expected to have. This is a quality objective, not a commercialization plan. Every item **tightens, measures, or documents what already exists**; none adds a new feature.
 

package/docs/current/risk-register-release-gate.ko.md

@@ -14,9 +14,9 @@ Haechi는 `1.x` stable 라인을 출시했습니다. developer preview 게이트
 | 구분 | 판단 | 이유 |
 |---|---|---|
 | GitHub public | 허용 | 보안 한계, threat model, shared responsibility가 문서화됨 |
-| GitHub release/tag | 허용 (`v1.3.2` 릴리스됨) | `v1.3.2` CR2 보완 컷이 태깅·릴리스됨; §5.7 및 §5.8(`CR2-001..008`) 항목이 모두 Resolved이고 G9/G10은 Pass |
-| npm stable | `haechi@1.3.2` publish됨 | CR2 보완이 `haechi@1.3.2` attested OIDC publish(2026-06-16)로 발행됨; 이전 `1.3.1`은 CR2 수정 이전 동작을 담고 있음 |
-| production use | 운영자 게이트; `1.3.2`로 업그레이드 | 운영자 네트워크 통제, 인가/인증, key custody가 있을 때만 지원; `haechi@1.3.1` 운영자는 민감한 제3자 업스트림 트래픽을 프록시로 라우팅하기 전에 CR2 수정(특히 `CR2-001` 프록시 upstream-cancel과 `CR2-002` token-vault audit hygiene)을 반영하도록 `1.3.2`로 업그레이드해야 함 |
+| GitHub release/tag | 허용 (`v1.3.3` 릴리스됨) | `v1.3.3`이 현재 릴리스(CR2 컷 `1.3.2` 위의 선제적 하드닝 패치); §5.7 및 §5.8(`CR2-001..008`) 항목은 모두 Resolved 유지, G9/G10은 Pass |
+| npm stable | `haechi@1.3.3` publish됨 | `1.3.3`은 CR2-보완된 `1.3.2` 기준 위에 response-direction marker-skip 강화 + cosign 서명 GHCR 컨테이너 이미지를 더한 attested OIDC publish |
+| production use | 운영자 게이트; `1.3.3`로 업그레이드 | 운영자 네트워크 통제, 인가/인증, key custody가 있을 때만 지원; 운영자는 민감한 제3자 업스트림 트래픽을 프록시로 라우팅하기 전에 최신 `haechi@1.3.3`(1.3.2의 CR2 수정 + marker-skip 하드닝 포함)을 실행해야 함 |
 
 ## 2. 릴리스 게이트
 

package/docs/current/risk-register-release-gate.md

@@ -14,9 +14,9 @@ Haechi has shipped its `1.x` stable line. The developer-preview gate (G2, `haech
 | Category | Judgment | Rationale |
 |---|---|---|
 | GitHub public | Allowed | Security limitations, threat model, and shared responsibility are documented |
-| GitHub release/tag | Allowed (`v1.3.2` released) | The `v1.3.2` CR2 remediation cut is tagged and released; all §5.7 and §5.8 (`CR2-001..008`) findings are Resolved and G9/G10 are Pass |
-| npm stable | `haechi@1.3.2` published | The CR2 remediation shipped in the `haechi@1.3.2` attested OIDC publish (2026-06-16); the prior `1.3.1` carries the pre-CR2-fix behavior |
-| Production use | Operator-gated; upgrade to `1.3.2` | Supported only with operator network controls, authz/authn, and key custody; operators on `haechi@1.3.1` should upgrade to `1.3.2` to pick up the CR2 fixes (notably the `CR2-001` proxy upstream-cancel and `CR2-002` token-vault audit hygiene) before routing sensitive third-party upstream traffic through the proxy |
+| GitHub release/tag | Allowed (`v1.3.3` released) | `v1.3.3` is the current release (a proactive-hardening patch over the CR2 cut `1.3.2`); all §5.7 and §5.8 (`CR2-001..008`) findings remain Resolved and G9/G10 are Pass |
+| npm stable | `haechi@1.3.3` published | `1.3.3` is an attested OIDC publish adding the response-direction marker-skip tightening + a cosign-signed GHCR container image, over the CR2-remediated `1.3.2` baseline |
+| Production use | Operator-gated; upgrade to `1.3.3` | Supported only with operator network controls, authz/authn, and key custody; operators should run the latest `haechi@1.3.3` (it carries the CR2 fixes from `1.3.2` plus the marker-skip hardening) before routing sensitive third-party upstream traffic through the proxy |
 
 ## 2. Release Gates
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "haechi",
-  "version": "1.3.2",
+  "version": "1.3.3",
   "description": "Self-hosted AI context enforcement across LLM, MCP, vLLM, Ollama, and agent traffic — a stable, zero-dependency security gateway.",
   "license": "Apache-2.0",
   "type": "module",

package/packages/filter/index.mjs

@@ -540,12 +540,15 @@ function scanEntry(entry, rules, context = {}) {
   // own token. This is response-only on purpose: a REQUEST that contains a
   // marker-shaped string is NOT Haechi output (Haechi hasn't transformed it yet),
   // so it is scanned normally — otherwise an attacker could wrap a real secret in
-  // a fake `[TOKEN:…]` to evade request-side detection.
+  // a fake `[TOKEN:…]` to evade request-side detection. On the RESPONSE side the
+  // same wrap-a-secret risk is closed by haechiMarkerSpans recording a span only
+  // when the inner content matches a GENUINE emitted format — a fake marker
+  // wrapping a real secret stays in the scan and is detected/blocked.
   // Markers are pure ASCII and NFKC-stable, so their spans are computed on the
   // ORIGINAL value exactly as before — they line up with the same-length
   // normalized scan (Case 2 below) and are irrelevant to the whole-leaf scan
   // (Case 3).
-  const markerSpans = context?.direction === "response" ? haechiMarkerSpans(entry.value) : [];
+  const markerSpans = context?.direction === "response" ? haechiMarkerSpans(entry.value, rules, context) : [];
 
   // WS2d — Unicode evasion via NFKC normalization. A client can defeat every
   // regex rule by sending PII/secrets in a Unicode form that folds to ASCII
@@ -824,12 +827,157 @@ function isPositionStableNfkc(value, normalized) {
   return rebuilt === normalized;
 }
 
-// Spans of Haechi's own transform markers in a string, so detection can skip
-// them: `[TOKEN:…]`, `[HAECHI_ENC:…]`, `[REDACTED:…]`.
-function haechiMarkerSpans(text) {
+// Spans of Haechi's own transform markers in a string, so RESPONSE-direction
+// detection can skip them: `[TOKEN:…]`, `[HAECHI_ENC:…]`, `[REDACTED:…]`. A
+// tokenized round-trip echoed by the model would otherwise be re-flagged as a
+// secret (Haechi blocking its own output).
+//
+// CR-???: a span is recorded ONLY when its inner content matches a GENUINE
+// format actually emitted by core's transform (packages/core/index.mjs
+// replacementFor). Without this check the marker frame `[(?:TOKEN|…):[^\]]*]`
+// would skip ANY inner content, so a hostile model could exfiltrate a real
+// secret by wrapping it in a FAKE marker — `[TOKEN:sk-ant-api03-<secret>]`,
+// `[HAECHI_ENC:<secret>]`, `[REDACTED:<secret>]` — and that span would be
+// dropped from the scan. A marker-SHAPED string whose inner content is not
+// genuine is left in the scan, so the wrapped secret is detected/blocked.
+// Genuine inner formats:
+//   [REDACTED:<type>]            <type> is a detection type name (lowercase
+//                                identifier: [a-z][a-z0-9_]*).
+//   [TOKEN:<vaultTokenId>]       vault id shape `tok_<type>_<hexhash>`
+//                                (matches token-vault VAULT_TOKEN_SHAPE).
+//   [TOKEN:<type>:<shortHash>]   non-vault deterministic token: type name + hex.
+//   [HAECHI_ENC:<base64url>]     base64url that decodes to a VALID envelope
+//                                JSON object (cryptoProvider.encrypt envelope:
+//                                has `kid`+`aadHash`). A real secret string will
+//                                not base64url-decode to such an object.
+// Markers are pure ASCII / NFKC-stable and spans are computed on the ORIGINAL
+// entry.value, so offset integrity is unchanged.
+
+// Detection-type name shape (the `detection.type` written by core into REDACTED
+// and the type segment of a non-vault TOKEN). Built-in rule types and custom
+// rule types are lowercase identifiers; a real secret (hyphens, uppercase,
+// length) does not match, so a wrapped secret stays in the scan.
+const MARKER_TYPE_NAME = /^[a-z][a-z0-9_]*$/;
+// Vault token id shape — mirrors token-vault VAULT_TOKEN_SHAPE
+// (`tok_<type>_<hexhash>`, random: 16 hex, deterministic: 32 hex). Kept in sync
+// with packages/token-vault/index.mjs (not exported from there).
+const MARKER_VAULT_TOKEN = /^tok_[a-z0-9_]+_[a-f0-9]{16,}$/;
+// Non-vault deterministic token: `<type>:<hex>` (core shortHash → 12 hex; allow
+// any reasonable hex run so the check does not over-fit a single length).
+const MARKER_NONVAULT_TOKEN = /^[a-z][a-z0-9_]*:[a-f0-9]{8,}$/;
+// base64url alphabet only (core emits base64url with no padding).
+const MARKER_BASE64URL = /^[A-Za-z0-9_-]+$/;
+
+function isGenuineTokenInner(inner) {
+  return MARKER_VAULT_TOKEN.test(inner) || MARKER_NONVAULT_TOKEN.test(inner);
+}
+
+function isGenuineRedactedInner(inner) {
+  return MARKER_TYPE_NAME.test(inner);
+}
+
+// True only when `inner` base64url-decodes to a valid UTF-8 JSON object that
+// carries the encrypt-envelope signature (`kid` + `aadHash` — the contract keys
+// asserted by assertCryptoProviderConformance, present in the local AES-GCM
+// envelope and any conformant external provider). Any decode/parse failure or a
+// non-envelope shape → NOT a genuine marker (so a wrapped secret is scanned).
+function isGenuineEncInner(inner) {
+  if (!MARKER_BASE64URL.test(inner)) {
+    return false;
+  }
+  try {
+    const bytes = Buffer.from(inner, "base64url");
+    // Reject inputs that do not round-trip through base64url (e.g. an invalid
+    // tail that Buffer silently truncates): a genuine marker always round-trips.
+    if (bytes.toString("base64url") !== inner) {
+      return false;
+    }
+    if (!isUtf8(bytes)) {
+      return false;
+    }
+    const parsed = JSON.parse(bytes.toString("utf8"));
+    return (
+      parsed !== null &&
+      typeof parsed === "object" &&
+      !Array.isArray(parsed) &&
+      typeof parsed.kid === "string" &&
+      typeof parsed.aadHash === "string"
+    );
+  } catch {
+    return false;
+  }
+}
+
+// Belt-and-suspenders for the genuine-marker shapes: even a correctly-SHAPED
+// TOKEN/REDACTED inner must not itself carry a detectable secret. The lowercase-
+// identifier classes (MARKER_TYPE_NAME, the type segments of the token shapes)
+// overlap the body of real lowercase-bodied secrets (notably GitHub `gh[pousr]_`
+// tokens), so a hostile model could smuggle such a secret as the `<type>` segment
+// of an otherwise genuine-shaped marker. Re-scan the inner with the SAME rules and
+// refuse to treat it as genuine if anything detectable is inside — this un-skips a
+// marker exactly when skipping it would hide a leak.
+function textHasDetection(text, rules, context) {
+  for (const rule of rules) {
+    if (rule.direction && rule.direction !== context?.direction) {
+      continue;
+    }
+    const regex = new RegExp(rule.pattern, rule.flags.includes("g") ? rule.flags : `${rule.flags}g`);
+    for (const match of text.matchAll(regex)) {
+      if (!rule.validate || rule.validate(match[0])) {
+        return true;
+      }
+    }
+  }
+  return false;
+}
+
+// The attacker-controllable segment(s) of a genuine-shaped marker inner — i.e. the
+// `<type>` position(s) a hostile model could smuggle a secret into. For TOKEN we
+// peel off the structural framing (`tok_<type>_<hex>` → `<type>`, `<type>:<hex>` →
+// `<type>`) and scan the segment IN ISOLATION as well as the whole inner: a `\b`-
+// anchored rule (e.g. GitHub `\bghp_…`) misses a token glued to the `tok_` prefix
+// (no word boundary after `_`), but matches the segment scanned on its own.
+function markerSecretSurfaces(kind, inner) {
+  const surfaces = [inner];
+  if (kind === "TOKEN") {
+    const vault = /^tok_(.+)_[a-f0-9]{16,}$/.exec(inner);
+    if (vault) {
+      surfaces.push(vault[1]);
+    }
+    const nonVault = /^(.+):[a-f0-9]{8,}$/.exec(inner);
+    if (nonVault) {
+      surfaces.push(nonVault[1]);
+    }
+  }
+  return surfaces;
+}
+
+function innerContainsDetection(kind, inner, rules, context) {
+  return markerSecretSurfaces(kind, inner).some((surface) => textHasDetection(surface, rules, context));
+}
+
+function haechiMarkerSpans(text, rules = [], context = {}) {
   const spans = [];
-  for (const m of text.matchAll(/\[(?:TOKEN|HAECHI_ENC|REDACTED):[^\]]*\]/g)) {
-    spans.push([m.index, m.index + m[0].length]);
+  for (const m of text.matchAll(/\[(TOKEN|HAECHI_ENC|REDACTED):([^\]]*)\]/g)) {
+    const kind = m[1];
+    const inner = m[2];
+    let genuine = false;
+    if (kind === "TOKEN") {
+      genuine = isGenuineTokenInner(inner);
+    } else if (kind === "REDACTED") {
+      genuine = isGenuineRedactedInner(inner);
+    } else {
+      genuine = isGenuineEncInner(inner);
+    }
+    // HAECHI_ENC is exempt from the inner re-scan: its inner is an opaque base64url
+    // envelope validated by decode above (a raw secret cannot forge a valid
+    // envelope, and the envelope's base64url body is not a detectable leaf).
+    if (genuine && kind !== "HAECHI_ENC" && innerContainsDetection(kind, inner, rules, context)) {
+      genuine = false;
+    }
+    if (genuine) {
+      spans.push([m.index, m.index + m[0].length]);
+    }
   }
   return spans;
 }