haechi 1.0.0 → 1.1.0

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

@@ -27,6 +27,7 @@
 | G3 | npm stable | P1 production reference, stream-aware enforcement, API stability hardened | Blocked |
 | G4 | 0.9.0 observability + interactive-auth satellite cut | P1-SEC-026 / P1-OPS-009 mitigated and P2-CRYPTO-001 accepted; `haechi-dashboard` + `haechi-auth-oidc` + `haechi-crypto-kms@0.2.0` tests green; satellite tarballs zero-dep; core bumped to 0.9.0 (only an additive FORBIDDEN_KEYS audit hardening) | Pass |
 | G5 | 1.0.0 stable API contract + signed-plugin sandbox | P1-SEC-024 / P1-SEC-025 mitigated, P2-API-001 / P2-OPS-006 resolved; the API freeze + deprecation policy + `tests/api-contract.test.mjs` green; the Ed25519 signed-plugin contract + `assertAuthProviderConformance` + the worker-isolated `authProvider` sandbox tests green; PR0 satellite peer-ranges widened to `>=0.8.0 <2.0.0` and the `check-satellite-peer-ranges.mjs` preflight gate green; core stays zero runtime dependency; core bumped to 1.0.0 | Pass |
+| G6 | 1.1.0 plugin capability enforcement (`process-isolated`) | P1-SEC-027 / P1-SEC-028 mitigated; the `process-isolated` runtime (child under `--permission`, zero grants, `data:`-URL load, stdio-ignored, JSON-string IPC) + the fail-closed `--allow-net` feature detection (`netEnforcement:"require-permission"`) + the core `haechi/ssrf` guard + host-mediated key material + the spawn-storm circuit breaker; the fs/net/stdio red-team + SSRF + config tests green (the behavioral suite runs on a `--allow-net` Node and skips fail-closed otherwise); the API freeze stays green (additive `./ssrf` export + additive config keys); core stays zero runtime dependency; core bumped to 1.1.0 (additive + opt-in minor) | Pass |
 
 ## 3. P0 Distribution-Blocking Risk Status
 
@@ -114,11 +115,18 @@ These IDs are scoped to the 1.0.0 stable cut (the API freeze + the Ed25519 signe
 
 | ID | Risk | Status | Resolution evidence |
 |---|---|---|---|
-| P1-SEC-024 | Dynamic plugin execution / sandbox trust model: a signed `authProvider` plugin loaded into the worker sandbox could abuse the host (`fs`/`net`/`process.env`) or exfiltrate the credential it receives. **Supersedes P1-SEC-004's manifest-only stance** — 1.0 deliberately lifts it, enabling dynamic loading narrowly under new controls | Mitigated | `packages/plugin/sandbox.mjs` `createSandboxedAuthProvider` (PR #49): `node:worker_threads` memory/crash isolation, in-memory verified spawn (no path re-resolution / TOCTOU), data-minimized JSON-string wire (only the credential slice crosses; the host builds the keyed-HMAC identity), null-proto claims sanitizer, single-occupancy + correlation-id concurrency, required `timeoutMs` terminate + `resourceLimits`/`maxPendingCalls`/`maxMessageBytes`, kill-switch (`plugins.enabled:false`), and the full gate re-run on every respawn. Lifecycle audit (`plugin.load.*`/`authenticate.deny`/`worker.terminated`) + extended `FORBIDDEN_KEYS`; the audit identity is projected to the frozen 5 keys `{id,type,subjectHash,issuerHash,provider}`. Tests: the §7.4 fail-closed + isolation matrix, the `auth.provider:"plugin"` `normalizeConfig` fail-closed tests, and the `createRuntime` + proxy auth end-to-end. **Residual:** `node:worker_threads` is memory/crash isolation + data-minimization, NOT a capability sandbox — a malicious signed plugin's `fs`/`net`/`process.env` is not blocked and it CAN exfiltrate the credential it receives; gated only by the signing/vetting trust model. True enforcement (child-process + Node permission model) is 1.x; the worker sandbox is unproven against a real hostile plugin (a 1.x red-team) |
+| P1-SEC-024 | Dynamic plugin execution / sandbox trust model: a signed `authProvider` plugin loaded into the worker sandbox could abuse the host (`fs`/`net`/`process.env`) or exfiltrate the credential it receives. **Supersedes P1-SEC-004's manifest-only stance** — 1.0 deliberately lifts it, enabling dynamic loading narrowly under new controls | Mitigated | `packages/plugin/sandbox.mjs` `createSandboxedAuthProvider` (PR #49): `node:worker_threads` memory/crash isolation, in-memory verified spawn (no path re-resolution / TOCTOU), data-minimized JSON-string wire (only the credential slice crosses; the host builds the keyed-HMAC identity), null-proto claims sanitizer, single-occupancy + correlation-id concurrency, required `timeoutMs` terminate + `resourceLimits`/`maxPendingCalls`/`maxMessageBytes`, kill-switch (`plugins.enabled:false`), and the full gate re-run on every respawn. Lifecycle audit (`plugin.load.*`/`authenticate.deny`/`worker.terminated`) + extended `FORBIDDEN_KEYS`; the audit identity is projected to the frozen 5 keys `{id,type,subjectHash,issuerHash,provider}`. Tests: the §7.4 fail-closed + isolation matrix, the `auth.provider:"plugin"` `normalizeConfig` fail-closed tests, and the `createRuntime` + proxy auth end-to-end. **Residual:** `node:worker_threads` is memory/crash isolation + data-minimization, NOT a capability sandbox — a malicious signed plugin's `fs`/`net`/`process.env` is not blocked and it CAN exfiltrate the credential it receives; gated only by the signing/vetting trust model. True enforcement (child-process + Node permission model) is **delivered in 1.1 for the opt-in `process-isolated` runtime** (P1-SEC-027, §5.5) on a `--allow-net` Node; the `worker_threads` (1.0) mode is unchanged and keeps this residual |
 | P1-SEC-025 | Plugin signing / trust-anchor / revocation lifecycle: signer-key confusion/downgrade/rollback, a swapped (TOCTOU) entry, or a revoked/expired signer loading code | Mitigated | `packages/plugin/signing.mjs` `verifySignedPlugin` (PR #48): Ed25519 (asymmetric, `node:crypto`) signature over `canonicalize({pluginId, kind, version, capabilities, coreVersionRange, entrySha256, notBefore, notAfter})` — binding `entrySha256` (anti-swap), **trust-anchor-only** key resolution (refuse before verify if `signerKeyId` ∉ allowlist; algorithm pinned to Ed25519; signer set is separate from the AES rotation key file), pin + per-`pluginId` version-floor (anti-rollback/malicious-update) + `revokedSignerKeyIds`/`revokedEntrySha256` denylists + `notBefore`/`notAfter` window, all fail-closed at load and re-verified on every respawn. `assertAuthProviderConformance` (`haechi/auth`, the auth analog of `assertCryptoProviderConformance`) is a correctness gate with per-load randomized vectors; the host re-validates PII-safety per call. Tests: the §7.3 per-reason refusal matrix (each emits `plugin.load.refused{reason}`), the conformance negative tests, and the `FORBIDDEN_KEYS`-extension `sanitizeAudit` test. **Residual:** the operator must curate trust anchors/pins; a live revocation feed / CRL is 1.x (revocation takes effect at next load; the kill-switch force-drops a live plugin) |
 | P2-API-001 (1.0) | Stable-contract freeze + deprecation policy: an unstable public API / audit-schema drift that breaks consumers without a major bump or a migration path | Resolved | `docs/current/api-stability.md`(+ko) (PR #47): the IN/OUT surface table, strict semver from 1.0, the deprecation policy (≥1-minor retention + `HAECHI_DEPRECATION_*` runtime-warning contract + the disclosed-vulnerability in-minor security exception), the frozen audit event schema including nested sub-schemas + an additive `schemaVersion`, and the config-schema freeze unit (key presence/shape frozen; safer defaults still allowed). `tests/api-contract.test.mjs` is the freeze guard: it pins the per-subpath exports + a full audit event (non-null `identity` + a `detections[]` entry) + the config key set + `schemaVersion`; an additive field passes, a removed/renamed field (top-level OR nested) fails, and `verifyAuditChain` still verifies a frozen-schema fixture with a synthetic additive field. **Residual:** a major bump can break by design (documented migration); the disclosed-vulnerability security exception permits a sanctioned in-minor break with an advisory + migration path |
 | P2-OPS-006 (1.0) | Satellite peer-range / major-tracking gate: bumping core to 1.0.0 makes every satellite's `>=0.8.0 <1.0.0` peer unsatisfiable (ERESOLVE), breaking satellite installs | Resolved | PR0 (#46) widened all four satellites' `haechi` peer range to `>=0.8.0 <2.0.0` (versions auth-jwt 0.2.1, crypto-kms 0.2.1, dashboard 0.1.2, auth-oidc 0.1.2; auth-oidc's `haechi-auth-jwt` likewise to `<2.0.0`) and regenerated the lockfile (the workspace-lockfile gotcha). `scripts/check-satellite-peer-ranges.mjs` is a `release:preflight` gate that asserts `semver.satisfies(coreVersionToPublish, range)` for every satellite, simulating core `1.0.0`. `api-stability.md §5` documents that the satellite peer upper bound tracks the core MAJOR. **Residual:** the satellites must be republished before core 1.0.0 ships so they install against it |
 
+## 5.5 1.1.0 Plugin Capability Enforcement Risk Status
+
+| ID | Risk | Status | Resolution evidence |
+|---|---|---|---|
+| P1-SEC-027 | Plugin capability *enforcement*: the 1.0 `worker_threads` sandbox is memory/crash isolation only, so a malicious signed plugin can use `fs`/`net` and exfiltrate the credential. **Strengthens P1-SEC-024's accepted worker residual** — 1.1 adds real enforcement for a new opt-in runtime | Mitigated | `packages/plugin/process-sandbox.mjs` `createProcessIsolatedAuthProvider`/`…Sync` (PR #54): a signed `authProvider` runs in a child `node` under `--permission` with **zero grants** (no fs/child-process/worker/addons/wasi, no `--allow-net`), loaded from a `data:` URL (no fs grant → no TOCTOU/symlink surface), `stdio:['ignore','ignore','ignore','ipc']` (no stdout/stderr/fd leak channel), scrubbed env, JSON-string-only IPC + the shared null-proto sanitizer + host-side keyed-HMAC identity. **Empirically validated on Node 26**: the plugin's `fs`/`net`/`fetch`/`dns`/`child_process`/`worker` and the `process.binding('tcp_wrap')` bypass are all `ERR_ACCESS_DENIED`. Network containment is the **kernel `--allow-net` denial**, not a deletable JS harness; the default `netEnforcement:"require-permission"` **fails closed** (behavior-probed feature detection; PR #54) on a Node that cannot enforce it. A spawn-storm circuit breaker (PR #56) bounds respawns. Lifecycle audit gains host-computed/enum-only `isolation`/`grants`/`netEnforcement` (PR #56). Config: `auth.plugin.isolation:"process"` wired fail-closed (PR #56). Tests: the fs/net/stdio red-team (skipped on a Node without `--allow-net`, where the runtime fails closed instead) + the always-run fail-closed contract + the config matrix. **Residual:** a Node without `--allow-net` (fail-closed, not contained); a `networkEgress`-granted plugin; credential/key material in child memory (core-dump/swap); a V8/Node escape (a runtime control, not an OS sandbox) |
+| P1-SEC-028 | Host-mediated key material + SSRF: a custom-credential plugin needing key material could be a plugin-driven SSRF vector, and core had no SSRF guard (the satellites' copies are unreachable from core) | Mitigated | A new node:-only, zero-dependency **`haechi/ssrf`** core module (PR #55): `isBlockedAddress` (private/loopback/link-local/metadata), `guardedFetch` (https-only, post-DNS re-check, `redirect:"error"`, bounded body + timeout), `createGuardedKeyFetcher` (TTL cache + cooldown). The `process-isolated` runtime's optional `keyMaterial:{url}` is fetched by the **host** from the **operator-declared** URL through this guard and injected over the IPC — the plugin never names a URL (no plugin-driven SSRF), and the kid-refetch cooldown bounds the outbound rate; a blocked-address URL fails closed. Tests: the canonical `isBlockedAddress` vector table + a core-vs-`auth-jwt` parity guard, `guardedFetch` SSRF refusal/bounding, the cooldown fail-closed, and the runtime key-injection + no-SSRF tests. **Residual:** the satellites keep their DELIBERATE local copies (a crypto/auth package must not runtime-depend on core-ssrf; `crypto-kms/ssrf-parity.test.mjs`) — the core re-import is deferred and the drift is guarded by parity, not eliminated; the guard's DNS-rebinding window (resolve-then-connect) is accepted for an operator-declared URL |
+
 ## 6. P2 Product/Documentation Risk Status
 
 | ID | Risk | Status | Resolution evidence |

package/docs/current/threat-model.ko.md

@@ -65,7 +65,7 @@ Haechi가 보호하려는 주요 자산은 다음이다.
 | 토큰 엔드포인트 POST(및 Vault `fetch`)를 통한 broker SSRF — cloud metadata (0.9) | discovery와 request 사이에 `169.254.169.254`로 DNS-rebind되는 `token_endpoint`(또는 운영자 제공 `VAULT_ADDR`)가 instance-metadata 자격증명을 유출 | 모든 egress(discovery GET, 공유 verifier 경유 JWKS GET, token-exchange POST, end-session redirect, `haechi-crypto-kms` Vault `fetch`)가 **request 직전**(post-DNS) `lookup` 후 `isBlockedAddress` 재검사를 `redirect: "error"`·bounded body·timeout과 함께 수행. 운영자 신뢰 엔드포인트에 한함 |
 | audit/로그로의 token/secret leak (broker) (0.9) | ID/access/refresh token, `client_secret`, `code`, `state`, `nonce`, raw `sub`가 audit 로그나 client 응답에 기록됨 | broker는 모든 audit 이벤트를 자체 allowlist로 projection해 `subjectHash`/`issuerHash`/`sessionIdHash`(keyed-HMAC) + `provider`/`reasonCode`/timestamp만 방출; core `FORBIDDEN_KEYS`를 broker token/claim key까지 확장; access token은 **폐기**(저장·사용 안 함). 실질적 잔여 없음 |
 | KMS backend egress (Vault HTTP, GCP/Azure SDK) (0.9) | `haechi-crypto-kms` Vault/GCP/Azure backend가 key material이나 provider/key-path 상세를 유출하거나 의도치 않은 엔드포인트에 도달 | optional-peer + injected-client 모델과 **faithful-mock conformance**(cross-key·corrupted-blob 거부, HMAC determinism/domain-separation); Vault `fetch`는 위 satellite-local SSRF 가드 수행; 모든 backend는 provider 오류를 generic fail-closed 오류로 매핑하고 provider/key-ARN 상세를 audit에 기록하지 않음. live-backend 검증은 CI 외부 |
-| 동적 로딩된 악의적/침해된 signed plugin (1.0) | signed `authProvider` plugin이 worker sandbox에 로딩된 뒤 실행 중 host를 악용 | `canonicalize({pluginId, kind, version, capabilities, coreVersionRange, entrySha256, notBefore, notAfter})`에 대한 Ed25519 서명, **trust-anchor-only** 키 해석(`signerKeyId`가 allowlist된 anchor가 아니면 verify 이전 거부; 알고리즘은 Ed25519로 고정), pin + `pluginId`별 version-floor + revocation denylist(`revokedSignerKeyIds`/`revokedEntrySha256`) + validity-window 집행, `assertAuthProviderConformance` 정합성 게이트, `node:worker_threads` memory/crash 격리 + per-call timeout-terminate, 전체 lifecycle audit(`plugin.load.*`/`authenticate.deny`/`worker.terminated`). 전체 게이트는 매 respawn마다 재실행. **수용된 잔여:** signed plugin 자신의 `fs`/`fetch`/`process.env`는 차단되지 않으며(`networkEgress: false`는 선언일 뿐 1.0에서 집행 통제 아님) 정당하게 받은 credential을 exfiltrate할 수 있음 — 오직 signing/vetting 신뢰 모델로만 통제됨. 진짜 capability 집행(child-process + Node permission model)은 1.x 경로 |
+| 동적 로딩된 악의적/침해된 signed plugin (1.0) | signed `authProvider` plugin이 worker sandbox에 로딩된 뒤 실행 중 host를 악용 | `canonicalize({pluginId, kind, version, capabilities, coreVersionRange, entrySha256, notBefore, notAfter})`에 대한 Ed25519 서명, **trust-anchor-only** 키 해석(`signerKeyId`가 allowlist된 anchor가 아니면 verify 이전 거부; 알고리즘은 Ed25519로 고정), pin + `pluginId`별 version-floor + revocation denylist(`revokedSignerKeyIds`/`revokedEntrySha256`) + validity-window 집행, `assertAuthProviderConformance` 정합성 게이트, `node:worker_threads` memory/crash 격리 + per-call timeout-terminate, 전체 lifecycle audit(`plugin.load.*`/`authenticate.deny`/`worker.terminated`). 전체 게이트는 매 respawn마다 재실행. **수용된 잔여:** signed plugin 자신의 `fs`/`fetch`/`process.env`는 차단되지 않으며(`networkEgress: false`는 선언일 뿐 1.0에서 집행 통제 아님) 정당하게 받은 credential을 exfiltrate할 수 있음 — 오직 signing/vetting 신뢰 모델로만 통제됨. **1.1이 새 opt-in `process-isolated` 런타임에 대해 이 잔여를 닫는다**(다음 행, P1-SEC-027); `worker_threads`(1.0) 모드는 불변이며 이 수용된 잔여를 유지 |
 | plugin으로의 PII/secret leak (1.0) | request body·crypto 키·token vault·raw claim이 worker 경계를 넘어 유출 | host는 worker에 **credential slice만** 전달(`Authorization` 헤더 / bearer token — request body 절대 안 보냄, crypto 키 절대 안 보냄); wire는 MessagePort 위 평문 JSON 문자열; **null-prototype, own-key-allowlist claims sanitizer**가 `__proto__`/`constructor`/`prototype`을 제거하고 크기를 bound한 뒤 **host**가 `buildExternalIdentity`로 keyed-HMAC identity를 구성(HMAC 키는 worker에 들어가지 않음). **수용된 잔여:** auth plugin이 정당하게 검증하는 credential은 그 plugin에 보임(위 행 참조) |
 | 경계 간 object/proto smuggling (1.0) | 악의적 claims object가 host prototype을 오염시키거나 raw 값을 경계 너머로 밀반입 | JSON-string wire만 사용(structured-clone 없음, `SharedArrayBuffer`/transferables 없음 → shared-memory·object-graph 채널 없음) + `buildExternalIdentity` 이전 null-proto own-key-allowlist sanitizer. 실질적 잔여 없음 |
 | plugin entry의 swap / TOCTOU (1.0) | 서명 검사 후 실행 전에 검증된 entry 바이트가 swap됨(예: symlink 경로 재해석) | 서명이 `entrySha256`을 바인딩; loader는 entry를 **메모리로** 읽어 hash·verify하고 **메모리 내 검증된 소스에서** Worker를 spawn(`eval: true`)하며 검증 후 경로를 재해석하지 않고 symlink entry를 거부. 실질적 잔여 없음 |
@@ -73,12 +73,13 @@ Haechi가 보호하려는 주요 자산은 다음이다.
 | Plugin DoS (1.0) | 버그 있거나 악의적인 signed plugin이 hang/runaway하거나 host를 flood | call별 필수 양의 `timeoutMs`(timeout 시 host가 **worker를 terminate**하고 `null` 반환, lazily respawn), heap `resourceLimits`, `maxPendingCalls`(초과 → deny), `maxMessageBytes`(초과 → deny), single-occupancy worker(per-call terminate가 sibling을 죽일 수 없음). **잔여:** signed plugin이 timeout 내에서 할당된 CPU를 소진할 수 있음(CPU/fd/socket은 1.0에서 bound 안 됨) |
 | 감사되지 않는 code-load (1.0) | tamper-evident 기록 없이 third-party 코드를 로딩/실행 | 모든 load/deny/terminate 결정이 chained audit 이벤트 — `plugin.load.accepted`/`plugin.load.refused{reason}`/`plugin.authenticate.deny{reason}`/`plugin.worker.terminated{cause}`(ids/hashes/counts만); `FORBIDDEN_KEYS`를 확장(`claims`, `subject`, `issuer`, `credential`, `authorization`, `signature`, `entry`, 추가로 `scopes`/`labels`)해 defense-in-depth 적용, audit identity는 frozen 5 키 `{id, type, subjectHash, issuerHash, provider}`로 projection. — |
 | conformance test/prod 괴리 (1.0) | signed plugin이 고정된 conformance 테스트를 감지해 정상 행동한 뒤 운영에서 오작동 | `assertAuthProviderConformance`는 **load별 예측 불가 randomized vectors**를 사용하고, load-bearing하게 **host가 매 call마다 PII-safety를 재검증**(`buildExternalIdentity` + sanitizer가 요청별 실행)하며 load 시점에만 검증하지 않음. **잔여:** conformance-pass가 신뢰성을 함의하지 않음 — 악의적 plugin이 통과 후 오작동 가능(conformance가 아니라 signing+vetting 게이트로 통제) |
+| **`process-isolated`(1.1)** 하에서 host capability를 악용하는 악의적 signed plugin | signed `authProvider` plugin이 host 파일시스템 읽기, spawn, 네트워크 도달, 로그/fd 쓰기로 받은 credential을 exfiltrate 시도 | **커널 강제** capability 거부: plugin이 `--permission` 하의 자식 `node`에서 **부여 0**(fs/child-process/worker/addons/wasi 없음)으로, **`--allow-net` 없이** 실행되며 `data:` URL로 로드(fs 권한 없음 → TOCTOU/symlink 표면 없음). `--allow-net` Node에서 커널이 `net`/`fetch`/`dns`와 `process.binding('tcp_wrap')` 우회까지 거부; `stdio:['ignore','ignore','ignore','ipc']`가 stdout/stderr/fd 유출 채널을 차단; env 정화; IPC는 JSON-문자열 전용. 네트워크 봉쇄는 **fail-closed 기능 탐지** — 기본값 `netEnforcement:"require-permission"`은 `--allow-net`을 강제 못 하는 Node에서 생성 거부. 호스트 중개 키 자료는 호스트가 코어 SSRF 가드로 가져옴(plugin은 URL 명명 안 함). spawn-storm 서킷 브레이커가 재spawn 제한(P1-SEC-027 / P1-SEC-028). **잔여:** `--allow-net` 없는 Node(fail-closed, 미봉쇄); `networkEgress`를 정당하게 부여받은 plugin; 호스트 fetch DNS-rebinding 창; 자식 메모리의 credential + 주입된 키 자료(core-dump/swap 범위 밖); V8/Node 탈출은 모든 런타임 통제를 무력화 |
 
 ## 4. 명시적 제외
 
-0.3.2는 다음을 보장하지 않는다.
+Haechi는 다음을 보장하지 않는다.
 
-- 운영 KMS/HSM/Vault adapter 자체 제공
+- 코어 자체의 운영 KMS/HSM/Vault adapter 제공(`haechi-crypto-kms` satellite가 외부 `cryptoProvider` 계약을 통해 AWS/GCP/Azure/Vault adapter를 제공한다)
 - internet-facing gateway 인증/인가
 - `streaming.maxMatchBytes`보다 긴 cross-frame 매칭(스트림 프레임에 걸쳐 분할될 수 있음)
 - `block`이 발동되기 전에 이미 방출된 스트림 바이트의 회수
@@ -94,8 +95,13 @@ Haechi가 보호하려는 주요 자산은 다음이다.
 - refresh-token rotation / silent renewal / 장수명 broker 세션 — 0.9 세션은 absolute-TTL + idle-timeout만; `offline_access`는 제거되고 access token은 폐기 (0.9)
 - Dashboard write action(reveal, purge, policy edit) — `haechi-dashboard`는 읽기 전용으로 `POST`/`DELETE` surface 없음; mutation은 reveal governance 하의 CLI에 유지 (0.9)
 - OIDC broker의 `at_hash`/`c_hash` 검증 — broker가 access token을 사용하지 않으므로 정확히 범위 외 (0.9)
-- 악의적 signed plugin에 대한 capability *집행*(`fs`/`net`/`process.env` 차단) — Node permission model 하의 child-process 격리가 필요; 1.0 worker 격리는 memory/crash 격리 + data-minimization만 제공 (1.0)
-- signed `authProvider` plugin이 정당하게 받는 credential의 봉쇄 — de-facto network egress가 있어 exfiltrate 가능; 오직 signing/vetting 신뢰 모델로만 통제 (1.0)
+- **`worker_threads`(1.0)** 모드에서 악의적 signed plugin에 대한 capability *집행*(`fs`/`net`/`process.env` 차단) — worker 격리는 memory/crash 격리 + data-minimization만 제공. **1.1의 opt-in `process-isolated` 런타임에서 집행됨**(`--permission` 하 자식 프로세스, 부여 0, `--allow-net` Node에서 — P1-SEC-027)
+- `worker_threads`(1.0) signed plugin이 정당하게 받는 credential의 봉쇄 — de-facto network egress가 있어 exfiltrate 가능; 오직 signing/vetting 신뢰 모델로만 통제. **1.1 `process-isolated`에서 봉쇄됨**(net+stdio+fs 거부, `--allow-net` Node)
+- `--allow-net` **없는** Node에서 `process-isolated` plugin의 네트워크 봉쇄 — 런타임이 거기서 **fail closed**(생성 거부)하며 미봉쇄로 실행하지 않음; `worker_threads` 또는 `--allow-net` Node 사용 (1.1)
+- `networkEgress`를 명시적으로 부여받은 `process-isolated` plugin의 봉쇄 — net egress를 허용한 운영자는 그 채널의 exfiltration에 대해 봉쇄되지 않음 (1.1)
+- 운영자 선언 키 URL에 대한 호스트 중개 키 fetch의 DNS-rebinding 창(resolve-then-connect) — bearer satellite와 동일 입장으로 수용 (1.1)
+- 자식 프로세스 메모리에 상주하는 credential + 호스트 주입 키 자료 — core-dump/swap 노출은 범위 밖 (1.1)
+- V8/Node 샌드박스 탈출 — `--permission`은 OS 수준 샌드박스(seccomp/namespaces)가 아니라 Node 런타임 통제; 런타임 탈출은 이를 무력화 (1.1)
 - classifier/filter 및 crypto plugin 로딩 — 1.0에서 동적 로딩 가능한 plugin kind는 `authProvider`뿐; 다른 kind는 injection-only 유지 (1.0)
 - unsigned dev/loader 경로 — unsigned plugin loader는 없음; 개발은 `createRuntime(config, providers)` 주입 사용 (1.0)
 - live revocation feed / CRL — revocation은 다음 load/restart에 적용(global/per-plugin kill-switch가 live plugin을 즉시 force-drop); live CRL은 1.x (1.0)

package/docs/current/threat-model.md

@@ -65,7 +65,7 @@ The primary assets Haechi protects are:
 | Broker SSRF to cloud metadata via the token-endpoint POST (and Vault `fetch`) (0.9) | A `token_endpoint` (or operator-supplied `VAULT_ADDR`) that DNS-rebinds to `169.254.169.254` between discovery and request exfiltrates instance-metadata credentials | Every egress (discovery GET, JWKS GET via the shared verifier, token-exchange POST, end-session redirect, and the `haechi-crypto-kms` Vault `fetch`) runs a `lookup`-then-`isBlockedAddress` re-check **immediately before the request** (post-DNS), with `redirect: "error"`, a bounded response body, and a timeout. Operator-trusted endpoints only |
 | Token/secret leak into audit/logs (broker) (0.9) | An ID/access/refresh token, `client_secret`, `code`, `state`, `nonce`, or raw `sub` is written to the audit log or a client response | The broker projects every audit event through its own allowlist and emits only `subjectHash`/`issuerHash`/`sessionIdHash` (keyed-HMAC) + `provider`/`reasonCode`/timestamp; core's `FORBIDDEN_KEYS` is extended to cover the broker token/claim keys; the access token is **discarded** (never stored or used). None material |
 | KMS backend egress (Vault HTTP, GCP/Azure SDK) (0.9) | A `haechi-crypto-kms` Vault/GCP/Azure backend leaks key material or provider/key-path detail, or reaches an unintended endpoint | Optional-peer + injected-client model with **faithful-mock conformance** (cross-key + corrupted-blob rejection, HMAC determinism/domain-separation); the Vault `fetch` runs the satellite-local SSRF guard above; all backends map provider errors to a generic fail-closed error and never write provider/key-ARN detail to audit. Live-backend validation is out of CI |
-| Malicious/compromised signed plugin loaded dynamically (1.0) | A signed `authProvider` plugin is loaded into the worker sandbox and abuses the host once running | Ed25519 signature over `canonicalize({pluginId, kind, version, capabilities, coreVersionRange, entrySha256, notBefore, notAfter})`, **trust-anchor-only** key resolution (refuse before verify if `signerKeyId` is not an allowlisted anchor; algorithm pinned to Ed25519), pin + per-`pluginId` version-floor + revocation denylist (`revokedSignerKeyIds`/`revokedEntrySha256`) + validity-window enforcement, `assertAuthProviderConformance` correctness gate, `node:worker_threads` memory/crash isolation + per-call timeout-terminate, and full lifecycle audit (`plugin.load.*`/`authenticate.deny`/`worker.terminated`). The full gate re-runs on every respawn. **Accepted residual:** a signed plugin's own `fs`/`fetch`/`process.env` is NOT blocked — `networkEgress: false` is a declaration, not an enforced control in 1.0 — and the plugin CAN exfiltrate the credential it legitimately receives; this is gated only by the signing/vetting trust model. True capability enforcement (child-process + Node permission model) is the 1.x path |
+| Malicious/compromised signed plugin loaded dynamically (1.0) | A signed `authProvider` plugin is loaded into the worker sandbox and abuses the host once running | Ed25519 signature over `canonicalize({pluginId, kind, version, capabilities, coreVersionRange, entrySha256, notBefore, notAfter})`, **trust-anchor-only** key resolution (refuse before verify if `signerKeyId` is not an allowlisted anchor; algorithm pinned to Ed25519), pin + per-`pluginId` version-floor + revocation denylist (`revokedSignerKeyIds`/`revokedEntrySha256`) + validity-window enforcement, `assertAuthProviderConformance` correctness gate, `node:worker_threads` memory/crash isolation + per-call timeout-terminate, and full lifecycle audit (`plugin.load.*`/`authenticate.deny`/`worker.terminated`). The full gate re-runs on every respawn. **Accepted residual:** a signed plugin's own `fs`/`fetch`/`process.env` is NOT blocked — `networkEgress: false` is a declaration, not an enforced control in 1.0 — and the plugin CAN exfiltrate the credential it legitimately receives; this is gated only by the signing/vetting trust model. **1.1 closes this residual for the new opt-in `process-isolated` runtime** (next row, P1-SEC-027); the `worker_threads` (1.0) mode is unchanged and keeps this accepted residual |
 | PII/secret leak to a plugin (1.0) | The request body, crypto key, token vault, or a raw claim leaks across the worker boundary | The host sends the worker **only the credential slice** (the `Authorization` header / bearer token — never the request body, never the crypto key); the wire is a plain JSON string over the MessagePort; a **null-prototype, own-key-allowlist claims sanitizer** strips `__proto__`/`constructor`/`prototype` and bounds size before the **host** builds the keyed-HMAC identity via `buildExternalIdentity` (the HMAC key never enters the worker). **Accepted residual:** the credential the auth plugin legitimately validates is visible to it (see the row above) |
 | Cross-boundary object/proto smuggling (1.0) | A hostile claims object pollutes the host prototype or smuggles a raw value back across the boundary | JSON-string wire only (no structured-clone, no `SharedArrayBuffer`/transferables → no shared-memory or object-graph channel) + the null-proto own-key-allowlist sanitizer before `buildExternalIdentity`. None material |
 | Swap / TOCTOU on the plugin entry (1.0) | The verified entry bytes are swapped (e.g. a symlinked path re-resolved) after signature check but before execution | The signature binds `entrySha256`; the loader reads the entry **into memory**, hashes, verifies, and spawns the Worker **from the in-memory verified source** (`eval: true`), never re-resolving the path after verification, and refuses a symlinked entry. None material |
@@ -73,12 +73,13 @@ The primary assets Haechi protects are:
 | Plugin DoS (1.0) | A buggy or hostile signed plugin hangs, runs away, or floods the host | Required positive `timeoutMs` per call (on timeout the host **terminates the worker** and returns `null`, respawning lazily), heap `resourceLimits`, `maxPendingCalls` (excess → deny), `maxMessageBytes` (oversized → deny), single-occupancy worker (a per-call terminate can never kill a sibling). **Residual:** a signed plugin can burn its allotted CPU within the timeout (CPU/fd/socket are not bounded in 1.0) |
 | Unaudited code-load (1.0) | Loading or executing third-party code without a tamper-evident record | Every load/deny/terminate decision is a chained audit event — `plugin.load.accepted`/`plugin.load.refused{reason}`/`plugin.authenticate.deny{reason}`/`plugin.worker.terminated{cause}` (ids/hashes/counts only); `FORBIDDEN_KEYS` is extended (`claims`, `subject`, `issuer`, `credential`, `authorization`, `signature`, `entry`, plus `scopes`/`labels`) as defense-in-depth, and the audit identity is projected to the frozen 5 keys `{id, type, subjectHash, issuerHash, provider}`. — |
 | Conformance test/prod divergence (1.0) | A signed plugin detects a fixed conformance test and behaves, then misbehaves in production | `assertAuthProviderConformance` uses **unpredictable per-load randomized vectors**, and — load-bearing — the **host re-validates PII-safety on every call** (`buildExternalIdentity` + the sanitizer run per request), not just at load. **Residual:** conformance-pass does not imply trustworthiness — a malicious plugin can pass then misbehave (covered by the signing+vetting gate, not by conformance) |
+| Malicious signed plugin abusing host capabilities under **`process-isolated` (1.1)** | A signed `authProvider` plugin tries to read the host filesystem, spawn, reach the network, or write to a log/fd to exfiltrate the credential it receives | **Kernel-enforced** capability denial: the plugin runs in a child `node` under `--permission` with **zero grants** (no fs/child-process/worker/addons/wasi) and **no `--allow-net`**, loaded from a `data:` URL (no fs grant → no TOCTOU/symlink surface). On a `--allow-net` Node the kernel denies `net`/`fetch`/`dns` AND the `process.binding('tcp_wrap')` bypass; `stdio:['ignore','ignore','ignore','ipc']` closes the stdout/stderr/fd leak channel; env is scrubbed; the IPC is JSON-string-only. Network containment is **fail-closed feature-detected** — the default `netEnforcement:"require-permission"` refuses to construct on a Node that cannot enforce `--allow-net`. Host-mediated key material is fetched by the host through the core SSRF guard (the plugin never names a URL). A spawn-storm circuit breaker bounds respawns (P1-SEC-027 / P1-SEC-028). **Residual:** a Node without `--allow-net` (fail-closed, not contained); a plugin legitimately granted `networkEgress`; the host-fetch DNS-rebinding window; credential + injected key material in child memory (core-dump/swap out of scope); a V8/Node escape defeats any runtime control |
 
 ## 4. Explicit Exclusions
 
-0.3.2 does not guarantee:
+Haechi does not guarantee:
 
-- A production KMS/HSM/Vault adapter
+- A production KMS/HSM/Vault adapter in core (the `haechi-crypto-kms` satellite provides AWS/GCP/Azure/Vault adapters via the external `cryptoProvider` contract)
 - Authentication/authorization for internet-facing gateways
 - Cross-frame matches longer than `streaming.maxMatchBytes` (may still split across stream frames)
 - Retraction of stream bytes already emitted before a `block` fires
@@ -94,8 +95,13 @@ The primary assets Haechi protects are:
 - Refresh-token rotation / silent renewal / long-lived broker sessions — 0.9 sessions are absolute-TTL + idle-timeout only; `offline_access` is stripped and the access token is discarded (0.9)
 - Dashboard write actions (reveal, purge, policy edits) — `haechi-dashboard` is read-only with no `POST`/`DELETE` surface; mutation stays in the CLI under reveal governance (0.9)
 - `at_hash`/`c_hash` validation in the OIDC broker — out of scope precisely because the broker never uses the access token (0.9)
-- Capability *enforcement* against a malicious signed plugin (blocking `fs`/`net`/`process.env`) — needs child-process isolation under the Node permission model; 1.0 worker isolation is memory/crash isolation + data-minimization only (1.0)
-- Containment of the credential a signed `authProvider` plugin legitimately receives — it has de-facto network egress and can exfiltrate it; gated only by the signing/vetting trust model (1.0)
+- Capability *enforcement* against a malicious signed plugin (blocking `fs`/`net`/`process.env`) in the **`worker_threads` (1.0)** mode — worker isolation is memory/crash isolation + data-minimization only. **Enforced in 1.1 for the opt-in `process-isolated` runtime** (child process under `--permission`, zero grants, on a `--allow-net` Node — P1-SEC-027)
+- Containment of the credential a `worker_threads` (1.0) signed plugin legitimately receives — it has de-facto network egress and can exfiltrate it; gated only by the signing/vetting trust model. **Contained in 1.1 under `process-isolated`** (net+stdio+fs denial) on a `--allow-net` Node
+- Network containment of a `process-isolated` plugin on a Node **without `--allow-net`** — the runtime **fails closed** there (refuses to construct) rather than run uncontained; use `worker_threads` or a `--allow-net` Node (1.1)
+- Containment of a `process-isolated` plugin explicitly granted `networkEgress` — an operator who allows net egress is not contained against exfiltration over that channel (1.1)
+- The host-mediated key fetch's DNS-rebinding window (resolve-then-connect) on an operator-declared key URL — accepted, same stance as the bearer satellite (1.1)
+- Credential + host-injected key material resident in the child process's memory — core-dump / swap exposure is out of scope (1.1)
+- A V8 / Node sandbox escape — `--permission` is a Node runtime control, not an OS-level sandbox (seccomp/namespaces); a runtime escape defeats it (1.1)
 - Classifier/filter and crypto plugin loading — `authProvider` is the only dynamically loadable plugin kind in 1.0; other kinds stay injection-only (1.0)
 - An unsigned dev/loader path — there is no unsigned plugin loader; development uses `createRuntime(config, providers)` injection (1.0)
 - A live revocation feed / CRL — revocation takes effect at the next load/restart (a global/per-plugin kill-switch force-drops a live plugin immediately); a live CRL is 1.x (1.0)

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "haechi",
-  "version": "1.0.0",
-  "description": "Experimental developer preview for self-hosted AI context enforcement across LLM, MCP, vLLM, Ollama, and agent traffic.",
+  "version": "1.1.0",
+  "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",
   "workspaces": [
@@ -50,7 +50,8 @@
     "./runtime": "./packages/cli/runtime.mjs",
     "./token-vault": "./packages/token-vault/index.mjs",
     "./stream-filter": "./packages/stream-filter/index.mjs",
-    "./auth": "./packages/auth/index.mjs"
+    "./auth": "./packages/auth/index.mjs",
+    "./ssrf": "./packages/ssrf/index.mjs"
   },
   "files": [
     "README.md",

package/packages/cli/bin/haechi.mjs

@@ -660,7 +660,7 @@ function printHelp(topic) {
     "plugin-validate", "mcp-stdio", "mcp-wrap", "auth", "config"
   ];
   const lines = order.map((name) => `  ${name.padEnd(16)}${COMMAND_HELP[name].summary}`);
-  console.log(`Haechi — self-hosted AI context enforcement (developer preview)
+  console.log(`Haechi — self-hosted AI context enforcement
 
 Usage:
   haechi <command> [options]

package/packages/cli/runtime.mjs

@@ -10,7 +10,7 @@ import { loadVerifiedPolicyBundleFileSync } from "../policy-bundle/index.mjs";
 import { createProtocolAdapter } from "../protocol-adapters/index.mjs";
 import { applyPrivacyProfile, getPrivacyProfile } from "../privacy-profiles/index.mjs";
 import { createBearerAuthProvider } from "../auth/index.mjs";
-import { createSandboxedAuthProviderSync } from "../plugin/index.mjs";
+import { createSandboxedAuthProviderSync, createProcessIsolatedAuthProviderSync } from "../plugin/index.mjs";
 import { DEFAULT_PROXY_PORT } from "../proxy/index.mjs";
 
 // Capability keys an operator may allowlist for a plugin. Mirrors the plugin
@@ -501,14 +501,51 @@ function validatePluginAuthConfig(merged) {
     throw new Error("auth.plugin.allowCapabilities must include readsCredentials for an authProvider");
   }
 
+  // isolation: "worker" (default, 1.0 worker_threads — memory/crash isolation) or
+  // "process" (1.1 — a --permission child with real capability enforcement).
+  const isolation = plugin.isolation ?? "worker";
+  if (!["worker", "process"].includes(isolation)) {
+    throw new Error(`auth.plugin.isolation must be "worker" or "process" (got: ${JSON.stringify(plugin.isolation)})`);
+  }
+
   if (!Number.isInteger(plugin.timeoutMs) || plugin.timeoutMs <= 0) {
     throw new Error("auth.plugin.timeoutMs must be a positive integer");
   }
 
-  const limits = plugin.resourceLimits;
-  if (!limits || typeof limits !== "object" || Array.isArray(limits)
-    || !Number.isInteger(limits.maxOldGenerationSizeMb) || limits.maxOldGenerationSizeMb <= 0) {
-    throw new Error("auth.plugin.resourceLimits.maxOldGenerationSizeMb must be a positive integer");
+  if (isolation === "worker") {
+    // worker_threads resourceLimits (heap bound). Required for the worker runtime.
+    const limits = plugin.resourceLimits;
+    if (!limits || typeof limits !== "object" || Array.isArray(limits)
+      || !Number.isInteger(limits.maxOldGenerationSizeMb) || limits.maxOldGenerationSizeMb <= 0) {
+      throw new Error("auth.plugin.resourceLimits.maxOldGenerationSizeMb must be a positive integer");
+    }
+  } else {
+    // process-isolated: resourceLimits is N/A (the child is OS-bounded). Validate
+    // the network-enforcement policy and the optional host-mediated key material.
+    const netEnforcement = plugin.netEnforcement ?? "require-permission";
+    if (netEnforcement !== "require-permission") {
+      throw new Error(`auth.plugin.netEnforcement must be "require-permission" (got: ${JSON.stringify(plugin.netEnforcement)})`);
+    }
+    if (plugin.keyMaterial !== undefined && plugin.keyMaterial !== null) {
+      const km = plugin.keyMaterial;
+      if (typeof km !== "object" || Array.isArray(km) || typeof km.url !== "string" || !km.url.trim()) {
+        throw new Error("auth.plugin.keyMaterial must be an object with an operator-declared url string");
+      }
+      let keyUrl;
+      try {
+        keyUrl = new URL(km.url);
+      } catch {
+        throw new Error("auth.plugin.keyMaterial.url must be a valid URL");
+      }
+      if (keyUrl.protocol !== "https:") {
+        throw new Error("auth.plugin.keyMaterial.url must be https");
+      }
+      for (const field of ["ttlMs", "cooldownMs", "timeoutMs", "maxBytes"]) {
+        if (km[field] !== undefined && (typeof km[field] !== "number" || km[field] < 0)) {
+          throw new Error(`auth.plugin.keyMaterial.${field} must be a non-negative number`);
+        }
+      }
+    }
   }
 
   if (plugin.maxPendingCalls !== undefined
@@ -573,7 +610,7 @@ function resolveAuthProvider(config, providers, cryptoProvider, auditSink) {
   }
   if (config.auth.provider === "plugin") {
     const plugin = config.auth.plugin;
-    return createSandboxedAuthProviderSync({
+    const common = {
       manifestPath: plugin.manifestPath,
       trustAnchors: normalizeTrustAnchors(plugin.trustAnchors),
       allowCapabilities: plugin.allowCapabilities,
@@ -583,12 +620,21 @@ function resolveAuthProvider(config, providers, cryptoProvider, auditSink) {
       timeoutMs: plugin.timeoutMs,
       maxPendingCalls: plugin.maxPendingCalls,
       maxMessageBytes: plugin.maxMessageBytes,
-      resourceLimits: plugin.resourceLimits,
       coreVersion: plugin.coreVersion ?? null,
       cryptoProvider,
       auditSink,
       allowedLabelKeys: config.auth.allowedLabelKeys
-    });
+    };
+    if ((plugin.isolation ?? "worker") === "process") {
+      // 1.1 capability enforcement. Construction fails closed on a Node that
+      // cannot enforce --allow-net (netEnforcement: require-permission).
+      return createProcessIsolatedAuthProviderSync({
+        ...common,
+        netEnforcement: plugin.netEnforcement ?? "require-permission",
+        keyMaterial: plugin.keyMaterial ?? null
+      });
+    }
+    return createSandboxedAuthProviderSync({ ...common, resourceLimits: plugin.resourceLimits });
   }
   return null;
 }

package/packages/plugin/index.mjs

@@ -12,6 +12,11 @@ export {
   createSandboxedAuthProviderSync
 } from "./sandbox.mjs";
 
+export {
+  createProcessIsolatedAuthProvider,
+  createProcessIsolatedAuthProviderSync
+} from "./process-sandbox.mjs";
+
 const VALID_KINDS = new Set([
   "crypto-provider",
   "key-provider",
@@ -34,10 +39,13 @@ const CAPABILITY_KEYS = [
   "auditWrite",
   "externalSecrets"
 ];
-// manifest-only is the historical, behavior-preserving path. worker-isolated is
-// the 1.0 dynamic-loading runtime — permitted ONLY for kind authProvider and
-// only with the Ed25519 signed envelope (see validateWorkerIsolatedManifest).
-const VALID_RUNTIMES = new Set(["manifest-only", "worker-isolated"]);
+// manifest-only is the historical, behavior-preserving path. worker-isolated
+// (1.0) and process-isolated (1.1) are the dynamic-loading runtimes — both
+// permitted ONLY for kind authProvider and only with the Ed25519 signed envelope
+// (see validateSignedDynamicManifest). They share the same manifest contract; the
+// difference is the isolation mechanism (worker_threads vs a --permission child).
+const VALID_RUNTIMES = new Set(["manifest-only", "worker-isolated", "process-isolated"]);
+const SIGNED_DYNAMIC_RUNTIMES = new Set(["worker-isolated", "process-isolated"]);
 
 export async function validatePluginManifestFile(path) {
   const manifest = JSON.parse(await readFile(path, "utf8"));
@@ -65,11 +73,12 @@ export function validatePluginManifest(manifest) {
       errors.push("dynamic plugin execution is not supported; set runtime to manifest-only");
     }
 
-    if (plugin.runtime === "worker-isolated") {
-      // The 1.0 dynamic-loading path: a separate, stricter contract (signed
-      // Ed25519 envelope + a validity window + authProvider-only). Kept apart
-      // from the manifest-only checks so the historical path is untouched.
-      validateWorkerIsolatedManifest(plugin, errors);
+    if (SIGNED_DYNAMIC_RUNTIMES.has(plugin.runtime)) {
+      // The dynamic-loading path (worker-isolated 1.0 / process-isolated 1.1): a
+      // separate, stricter contract (signed Ed25519 envelope + a validity window +
+      // authProvider-only). Kept apart from the manifest-only checks so the
+      // historical path is untouched.
+      validateSignedDynamicManifest(plugin, errors);
     } else {
       // manifest-only (and any other declared-but-rejected runtime): the
       // historical, behavior-preserving contract — UNCHANGED.
@@ -103,13 +112,14 @@ export function validatePluginManifest(manifest) {
   };
 }
 
-// The worker-isolated runtime is dynamic code-loading; it is permitted ONLY for
-// kind authProvider and ONLY with the Ed25519 signed envelope fields. A
-// worker-isolated manifest that is not an authProvider, or is missing the signed
-// fields / validity window / readsCredentials, is rejected with a clear error.
-function validateWorkerIsolatedManifest(plugin, errors) {
+// The signed-dynamic runtimes (worker-isolated 1.0 / process-isolated 1.1) are
+// dynamic code-loading; both are permitted ONLY for kind authProvider and ONLY
+// with the Ed25519 signed envelope fields. A manifest that is not an authProvider,
+// or is missing the signed fields / validity window / readsCredentials, is
+// rejected with a clear error. The two runtimes share this identical contract.
+function validateSignedDynamicManifest(plugin, errors) {
   if (plugin.kind !== "authProvider") {
-    errors.push("worker-isolated runtime is only supported for kind authProvider");
+    errors.push(`${plugin.runtime} runtime is only supported for kind authProvider`);
   }
 
   // The signed-envelope fields that bind authorship and the exact entry bytes.
@@ -131,14 +141,14 @@ function validateWorkerIsolatedManifest(plugin, errors) {
   const hasNotBefore = plugin.notBefore !== undefined && plugin.notBefore !== null;
   const hasNotAfter = plugin.notAfter !== undefined && plugin.notAfter !== null;
   if (!hasNotBefore && !hasNotAfter) {
-    errors.push("worker-isolated manifest requires a validity window (notBefore and/or notAfter)");
+    errors.push(`${plugin.runtime} manifest requires a validity window (notBefore and/or notAfter)`);
   }
 
   if (!plugin.capabilities || typeof plugin.capabilities !== "object" || Array.isArray(plugin.capabilities)) {
     errors.push("missing capabilities");
   } else if (plugin.capabilities.readsCredentials !== true) {
     // An authProvider sees the bearer token, so it MUST declare readsCredentials.
-    errors.push("worker-isolated authProvider must declare capabilities.readsCredentials = true");
+    errors.push(`${plugin.runtime} authProvider must declare capabilities.readsCredentials = true`);
   }
 }