WAF v1 compliance definition-of-done (PCI 6.4.2: audit logging, redaction, rule-change trail, health signal, monitor mode, starter pack)

## Context

Security/compliance review of the WAF proposal (Aron, 2026-07-02; design doc: Confluence SD "Harper WAF — Design Proposal"; component PR: #517). Verdict: the enforcement engineering is strong, but a WAF that regulated customers can buy has three legs — **enforce, prove, operate** — and v1 currently only stands up the first. PCI DSS 4.0 Req 6.4.2 (mandatory since 2025-03) requires the automated solution to be *actively running, generating audit logs, and configured to block or alert for immediate investigation* — that makes several "productize-later" items part of what "WAF" means, not polish.

## v1 definition-of-done (moved up from "productize")

- [ ] **Blocked/logged-request audit logging** ships with the component: structured records (timestamp, source IP, rule id, action, request summary) durable enough for assessment evidence, with a path to alerting. Without this a customer cannot pass a PCI assessment using our WAF.
- [ ] **Log content redaction policy** before any logging ships: WAF logs capture paths, query strings, and headers → tokens, PII, potentially PANs. PCI forbids logging PAN; GDPR expects minimization. Define masking rules now — retrofitting redaction into a shipped log format is miserable.
- [ ] **Rule-change audit trail**: who changed which rule, when, before/after values (SOC 2 change management; PCI Req 10). Cheap while rule management is four registered operations. *Investigate first:* Harper table-level audit on `system.hdb_waf_rules` may provide most of this natively (`read_audit_log` records operations with originating user) — if so this is enablement + documentation, not new machinery.
- [ ] **Enforcement health signal**: "actively running" is literal requirement language. Fail-open on subscription/compile failure is the chosen default — it must be documented, ideally configurable, and observable (a health/status surface proving the WAF is enforcing, e.g. rules loaded + last-recompile timestamp + subscription liveness).
- [ ] **Global monitor mode** (detection-only): per-rule `log` action gets most of the way; name it as an explicit mode — every customer expects a tuning period, every QSA asks.
- [ ] **Default starter rule pack**: an empty rule table "detects and prevents" nothing (6.4.2). Ship OWASP-Top-10-injection-floor coverage on path/query. Note this also pressures the `requestBody` phase priority — most real injection arrives in POST bodies, and the label "WAF" carries assessor expectations; be careful with the word in customer-facing material until coverage matches.

## Open-question resolutions (from the same review)

- Block responses: per-rule `blockStatus` + fixed minimal body for v1; **no custom bodies** (info-leak / template-injection surface for zero compliance benefit).
- Log rules alongside a block: **log them** — enforcement can short-circuit, telemetry must not (being fixed in #517 directly).
- Non-SU denial as 400 op-not-found: acceptable, no core change.
- Rate limiting: documented per-worker approximation is fine.

## Plan-for-later (decisions now must not preclude)

- [ ] RBAC below super_user for rule management (separation of duties; today one compromised super_user on any node controls traffic fleet-wide via replication). Don't freeze the rule schema/authz in a way that blocks it.
- [ ] Compliance reporting: rule-set export, config attestation, blocked-traffic summaries (customers must show auditors the control exists and operates; Studio UI is planned, reporting isn't).

Symphony-side counterparts: HarperFast/symphony#11 (hot-swappable protection config — also a prerequisite for the WAF→Symphony blocklist feed), #12 (JA4), #13 (deployment security docs).

---
Filed by KrAIs (Claude) on Kris's behalf, digesting Aron's review.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Begin with component PR #517 and the Harper design proposal; inspect how the WAF currently handles rule actions, logging, and the system.hdb_waf_rules table. Use the checklist as the acceptance boundary: auditability and redaction, health visibility, monitor mode, and a starter rule pack must be addressed without closing the listed later RBAC and reporting options.

Written by the indexing model from the issue text.