ADR 0026 — ZTP-prem 12-camadas insider-operator posture (umbrella)¶
- Status: Accepted (formalized 2026-05-12 with v3.7.0 — 12/12 camadas shipping)
- Date: 2026-05-11 (locked), 2026-05-12 (formalized)
- Deciders: TLSStress.Art project
- Targets: v3.7.0 (camadas 1, 5, 6, 8 shipping); v6.0+ (camada 3 mandatory Confidential Computing)
- Source memo:
project_ztp_prem_posture_locked_2026_05_11.md - Patent claim family: claims #18..#25 (cross-language signing, Tier A/B partition, sealed audit chain, admission webhook, TPM measured-boot, DLP egress, behavioural anomaly, UTXO token vault)
- Sibling ADRs: 0027 (signing), 0028 (Tier A/B), 0029 (sealed audit), 0030 (admission), 0031 (TPM/CC), 0032 (DLP + anomaly), 0033 (LICENSE.Art UTXO)
Context¶
TLSStress.Art targets Fortune-500 customers running the bench on-premises in regulated DCs. The threat model is not the external attacker — it is the insider operator with full root shell access to the bench (a sysadmin pulled into a deployment, an auditor's escort, a malicious internal contractor). Without a posture against that adversary, the dashboard's promise that the bench is "lab-only, no external data egress, no licence bypass" is unverifiable.
Five orthogonal threats to defeat:
- Operator extracts licence keys and clones the bench
- Operator modifies code (binary swap, init-container side-loader)
- Operator forges audit history (delete-then-replay, evidence laundering)
- Operator exfiltrates data (lab traffic, customer URL lists, PCAPs)
- Operator runs out-of-policy workloads (cryptominer, rogue pod, side-channel attack)
A single mitigation defeats none of these. Defense in depth is mandatory, but the layers need to be named and audited individually — otherwise customers cannot certify what they operate.
Decision¶
Adopt the ZTP-prem 12-camada model as the canonical Zero-Trust-on-Premises posture. Every layer has (a) a named owner ADR or module README, (b) a Tier A/B classification, and (c) a shipping or planned implementation gate.
| # | Camada | What it defends | ADR / Module | v3.7.0 status |
|---|---|---|---|---|
| 1 | Cloud HSM key custody | Operator never holds raw ISK keys | ADR 0027 · pkg/ztp-prem-signctl/ |
✅ Shipping |
| 2 | Confidential Computing detection | Surface CC readiness per node | ADR 0031 · pkg/ztp-prem-detect/ |
✅ Shipping (probe) |
| 3 | TPM 2.0 measured-boot probe | Detect kernel + bootloader integrity surface | ADR 0031 · pkg/ztp-prem-tpm/ |
🟡 Scaffold (v6.0+ enforces PCR signing) |
| 4 | Tier A/B code partition | Customer-replaceable A; moat-closed B | ADR 0028 · platform/ztp-prem/tier-policy.yaml |
✅ Shipping (CI gate) |
| 5 | K8s ValidatingAdmissionWebhook | Every Pod admission classified + audited | ADR 0030 · pkg/ztp-prem-admission/ |
✅ Shipping (audit + enforce + break-glass) |
| 6 | Sealed audit hash-chain (WORM) | Tamper-evident, append-only audit history | ADR 0029 · dashboard/src/lib/ztp-prem/sealed-audit/ |
✅ Shipping (Wave 10 + 10-B) |
| 7 | Cross-correlation chain bridge | Admission decisions linked to sealed audit | ADR 0029 · dashboard/src/lib/ztp-prem/admission-correlate.ts |
✅ Shipping (Wave 10-B) |
| 8 | UTXO token vault | Notes-not-balance licence model | ADR 0033 · dashboard/src/lib/license/ |
✅ Shipping (Wave 8) |
| 9 | MÓDULO LICENSE.Art envelope | Signed licence envelope w/ counter-signed Cloud HSM | ADR 0027, 0033 · cross-language byte-identical (Go ↔ Node) | ✅ Shipping (Wave 8+1) |
| 10 | Sealed-key release scaffold | Wave 11-B will release sealed keys against PCR quote | ADR 0031 | 🟡 Planned v6.0+ |
| 11 | DLP egress monitor | Tracked-fetch wrapper + 5 baseline rules | ADR 0032 · dashboard/src/lib/ztp-prem/dlp/ |
✅ Shipping (Wave 13) |
| 12 | Behavioural anomaly detector | Rule-based 4-detector for insider patterns | ADR 0032 · dashboard/src/lib/ztp-prem/anomaly/ |
✅ Shipping (Wave 14) |
Open vs closed: camadas 1, 4, 8, 9 are the moat (Tier B,
patent-claimed, garble-obfuscated). Camadas 2, 3, 5, 6, 7, 10, 11,
12 are Tier A (open, customer-auditable). The split is itself
an audit artifact and is reproducible from platform/ztp-prem/tier-policy.yaml.
Marketing alignment: the 12-camada model is the centerpiece slide of the Investor Deck and the second-page callout of the Customer Datasheet. Every release note bumps mention the camada that delivered or the camada that hardened.
Consequences¶
Pros - Single named posture lets customers run a compliance audit against a checklist instead of a Wiki dive - Tier A/B partition lets us ship open-source community trust while keeping the moat - 12 named layers map cleanly to NIST 800-207 / SP 800-204A / FedRAMP High control families - Patents #18..#25 are anchored in shipping code, not in slideware
Cons - Every new feature now has to declare a camada (or none) — small ongoing cost - v6.0+ migration to mandatory Confidential Computing will break legacy NGFW DC deploys without CC-capable hosts (intentional)
Reversibility: low. The 12-camada count + Tier A/B partition are baked into the marketing identity, the investor deck, and the patent applications. The implementation of any one camada can be replaced, but the count and the partition cannot.
Related¶
- SECURITY_ZTP_PREM.md — full posture
platform/ztp-prem/tier-policy.yaml— code-side source of truthplatform/ztp-prem/CLOUD-HSM-KEY-CUSTODY.md— camada 1 key custody designplatform/ztp-prem/TIER-B-OBFUSCATION.md— garble policy- All sibling ADRs 0027..0033
Last verified against shipping code: v3.7.0 (2026-05-12).