Skip to content

Security Architecture — Zero-Trust-on-Premises (ZTP-prem)

Twelve composed defence layers, designed against an insider operator with kubectl and root credentials. Every layer is in code today or is shipping as a scaffold with a published implementation roadmap. The trust posture is the product.

This page is the canonical reference for enterprise security reviewers, sales engineers, risk officers, and auditors. The architectural foundations live in platform/ztp-prem/; the verifiable code paths are linked inline below.

Threat model

TLSStress.Art is built against the only adversary a Fortune 500 audit officer cares about: the operator with kubectl and root credentials inside the customer's own organisation. Not the script kid. Not the external attacker who first has to get past a network firewall.

The compliance officer's question is "prove a past test run was not tampered with". The threat model's question is "the maintainer who runs kubectl apply could lie about what just ran — how do you stop that?" Both questions are answered by the same twelve-layer architecture.

The twelve layers

Each layer closes one specific adversary capability. None is a checkbox; each is composed of code in the repo and (where applicable) an operator-visible card on /admin/ztp-prem.

# Layer Status Reference
01 Cloud HSM custody Runtime gate shipping; real HSM probe scheduled (Wave 9++) dashboard/src/lib/license/hsm-heartbeat.ts · pkg/ztp-prem-signctl/
02 Confidential Computing detection Shipping (per-node DaemonSet + admin card) pkg/ztp-prem-detect/
03 TPM measured boot Probe scaffold shipping; PCR signing scheduled (Wave 11-B) pkg/ztp-prem-tpm/ · TPM-MEASURED-BOOT.md
04 Sealed audit hash-chain Shipping (chain + replay verifier + admin card) dashboard/src/lib/license/sealed-audit.ts
05 K8s admission webhook Audit + enforce + break-glass + chain cross-correlation shipping pkg/ztp-prem-admission/ · k8s/ztp-prem/admission-webhook.yaml
06 Anti-debug runtime posture Distroless + readonly-rootfs + dropped caps across all Tier B containers every Tier B Dockerfile
07 Tier A/B code partition Policy YAML + CI lint shipping platform/ztp-prem/tier-policy.yaml · scripts/ztp-tier-lint.sh
08 UTXO token vault Shipping (notes-not-balance; auto-issue dev mode) dashboard/src/lib/license/utxo.ts
09 Tier B binary obfuscation CI gate shipping (garble matrix over 6 Go modules) scripts/ztp-prem-obfuscate-tier-b.sh · TIER-B-OBFUSCATION.md
10 DLP egress monitor Shipping (5 rules, host skiplist, redaction) dashboard/src/lib/dlp/
11 Behavioural anomaly detector Rule-based 4-detector shipping; ML overlay scheduled (Wave 13-B) dashboard/src/lib/ztp-prem/anomaly-detector.ts
12 Separation of duties CODEOWNERS + nightly SoD audit + policy memo .github/CODEOWNERS · SEPARATION-OF-DUTIES.md

Two layers (03 and 11) carry an honest "scheduled" follow-up. The scheduled work is named, scoped, and pointed at a specific upcoming release. The cells that ship today are running in the operator dashboard.

Three differentiators not on competitor public roadmaps

Cross-language signing contract (Patent #18)

Go (pkg/ztp-prem-signctl/canonical.go) and Node (dashboard/src/lib/license/envelope.ts) produce byte-identical canonical envelope signatures, including post-quantum primitives (ML-KEM-768 + ML-DSA-65). Both reference implementations verified to produce a 295-byte signature with the same SHA-256.

This is the cross-platform signing primitive that Vault Enterprise, Snowflake, and Cisco Smart Licensing do not have on their public roadmaps. Two independent teams could maintain Go and Node implementations against the same contract — neither can drift without the verifier breaking.

UTXO token vault

Tokens are tamper-evident notes, not a mutable balance. Each test plan execution burns a note and emits a signed receipt. There is no balance column in the schema — operator counts unspent_unexpired rows. No race condition is possible because no row is ever updated; notes are immutable once issued, and "spent" is a separate sentinel table that the chain verifies.

Side effect: a "negative balance attack" (concurrent debits racing to take a balance below zero) is structurally impossible because there is no balance to race against.

Admission ↔ sealed audit cross-correlation

Kubernetes admission decisions (Wave 8/9 ValidatingAdmissionWebhook) are lifted from the webhook's local 1000-entry ring buffer into the sealed audit hash-chain (Wave 1) on operator command (Wave 10-B button) or via cron. Pod restarts no longer erase forensic evidence; tampering attempts break the chain and are detectable on cloud-side replay verification.

Vendor products typically treat admission decisions and audit logs as separate concerns. The cross-correlation primitive is unique to TLSStress.Art.

Compliance mapping

This mapping is restrained — only the controls a SecOps reviewer would actually cite, with each row pointing to a specific layer.

Framework Control ZTP-prem layer(s)
SOC 2 II CC1.5, CC8.1 12 (CODEOWNERS + SoD audit)
SOC 2 II CC7.2 04 (sealed audit) + 11 (behavioural anomaly)
ISO/IEC 27001 A.6.1.2 12
ISO/IEC 27001 A.12.4.1, A.12.4.2 04 + 10 (DLP egress)
LGPD (Brazil) / GDPR (EU) DPIA process · GDPR Art. 46 10 + 04
PCI-DSS 4.0 7.2.5 12 (path-scoped reviewer enforcement)
NIST SP 800-53 Rev. 5 AU-10 04 + 10
NIST SP 800-53 Rev. 5 SI-4 11
NIST PQC FIPS 203 / 204 / 205 Patent #18 (ML-KEM-768 + ML-DSA-65)

The mapping intentionally omits controls that could be argued to apply if read broadly. Datasheet-grade rigor means every row stands up to a SecOps reviewer's specific question.

Patent posture

Patent claims #18 to #25 cover, in order:

  1. #18 — Cross-language license-envelope signing contract (RSA-4096-PSS-SHA-384 + ML-DSA-65, byte-identical across runtimes)
  2. #19 — UTXO token vault primitives (notes + signed receipts + sentinel-table spend tracking)
  3. #20 — Admission decision to sealed-audit-chain bridge with UID-keyed idempotency ledger
  4. #21 — Sealed audit hash-chain with WORM enforcement at storage layer + cloud-side replay reconciliation
  5. #22 — TPM-sealed boot integration with PCR0..PCR7 measurement set + license-gate cross-check
  6. #23 — DLP egress redaction policy combining host skiplist, tracking-URL override, and 5-rule baseline pattern set
  7. #24 — Tier A/B partition enforcement at CI lint + admission webhook + obfuscation pipeline simultaneously
  8. #25 — Behavioural anomaly rule floor that cannot be regressed below by an overlaid ML model

Filings on record; available under NDA for technical due-diligence.

The operator's view

The trust posture is not a separate product. The same /admin/ztp-prem page that the operator uses to launch tests is the page the auditor opens to verify the chain. Seven cards in v3.7.0:

  1. Confidential Computing status (per-node attestation readiness)
  2. Tier A/B policy (live consistency check)
  3. License envelope summary (current envelope + features + expiry)
  4. License envelope import (signed envelope upload)
  5. Sealed audit log replay verifier
  6. DLP egress monitor (top hosts + recent events + pattern hits)
  7. Admission audit (mode banner + 6 tiles + DENIED/BREAK-GLASS badges)

Three admin endpoints back the cards. Three additional endpoints land in v3.7.0: /admission-correlate · /hsm-heartbeat · /anomalies.

How to verify

Every claim on this page is anchored to source. To confirm the cited asset still exists at the cited path before any procurement review:

# Sealed audit replay verifier UI
git log --oneline -1 -- dashboard/src/components/SealedAuditReplayCard.tsx

# Patent #18 cross-language canonical encoder (Go side)
git log --oneline -1 -- pkg/ztp-prem-signctl/canonical.go

# Patent #18 cross-language canonical encoder (Node side)
git log --oneline -1 -- dashboard/src/lib/license/envelope.ts

# UTXO vault (no balance column)
git log --oneline -1 -- dashboard/src/lib/license/utxo.ts

# Admission ↔ chain bridge
git log --oneline -1 -- dashboard/src/lib/ztp-prem/admission-correlate.ts

# Twelve-layer policy source-of-truth
git log --oneline -1 -- platform/ztp-prem/tier-policy.yaml

If any path no longer exists, this page must be updated before the next release. The page is treated as part of the marketing-site-obligation contract: every release v3.7+ keeps it current with the shipping code.

Implementation roadmap (Wave-B follow-ups)

Honest about what is scheduled vs shipping:

Wave Adds Target
9++ Real PKCS#11 / AWS Cloud HSM probe + cron for heartbeat automation v3.8
10-C K8s CronJob hitting /admission-correlate every 5 min v3.8
11-B Privileged sidecar with go-tpm; PCR0..PCR7 signed into chain v4.0
11-C Dashboard TpmFleetCard reading per-node TPM annotations v3.8
12-B Tier B Dockerfiles with OBFUSCATE=true opt-in build arg v3.8
12-C Per-customer seed derivation (deployment-id-keyed) v4.0
13-B Dashboard AnomaliesCard + optional ML overlay v3.8 / v4.0
13-C Webhook/Slack/PagerDuty notification subscription v4.0
14-B Dashboard SoDCard inline; reviewer-rotation tracker v3.8
v6.0+ Confidential Computing enforcement (Tier B refuses to schedule on non-CC nodes) + TPM-PCR enforcement v6.0+

Companion materials

Talking to the reviewer

A SecOps reviewer arriving at this page should be able to answer five questions in under ten minutes:

  1. What is the threat model? — Insider operator with kubectl + root.
  2. What protects against it? — Twelve composed layers, listed above with code references.
  3. What is shipping vs scheduled? — Two layers (03, 11) carry honest "scheduled" follow-ups; the other ten ship today.
  4. How is this verified? — Sealed hash-chain replay + cosign-signed images + SBOM + the bash one-liners above.
  5. What is uniquely defensible? — Three primitives not in comparable products: Patent #18 cross-language signing, UTXO token vault, admission-chain cross-correlation.

The page is structured so each question has its own section. The reviewer reads top to bottom and exits with an actionable summary.

Last verified against shipping code: v3.7.0 (2026-05-12).