# GaugeWright Workbench — Control Crosswalk (CAIQ-style)

*A control-by-control responses sheet for vendor security assessments, organized
by the CSA Cloud Controls Matrix (CCM) domains and answerable against SOC 2,
ISO 27001, and NIST. Companion to the [architecture document](architecture.html)
and [security overview](brief.html).*

**Status:** **Available** (shipped today) · **Built** (implemented + tested, not
operationally deployed) · **Planned** (committed, not built) · **No** (not
implemented today). Every row points to evidence in the architecture doc or the
product repository (`github.com/jamesjscully/un-tie`).

> **Read this first.** The product shipped today is a **single-party desktop
> workbench** with **remote LLM inference** (your prompts and in-scope context
> are sent to the LLM provider you configure). Many enterprise/hosted controls
> below are therefore *Built* or *Planned*, not *Available*. Answers are honest
> about that distinction.

| # | Domain | Control question | Response | Status | Evidence |
|---|---|---|---|---|---|
| GRC-01 | Governance | Is there a documented security/architecture model? | Yes — an enterprise architecture & security doc, a formal invariant set, and append-only ADRs. | Available | Architecture doc; `specs/principles.md`, `specs/decisions/` |
| GRC-02 | Governance | Are there third-party certifications (SOC 2 / ISO 27001)? | No certification today. SOC 2 Type II is the highest-priority committed item; ISO 27001 not yet on the roadmap. | Planned | Arch §12 |
| A&A-01 | Audit & Assurance | Is the security model independently verified? | Protection invariants are machine-checked (42 Quint models + adversarial teeth tests) in CI. No third-party pen test or audit yet. | Available / Planned | Arch §13; `specs/models/*.qnt` |
| A&A-02 | Audit & Assurance | Can a customer obtain audit evidence? | Formal models, CI results, and live-verification harnesses are public in the repo. SOC 2 report: planned. | Available / Planned | repo CI; Arch §13 |
| IAM-01 | Identity & Access | Is SSO (OIDC/SAML) supported? | OIDC and SAML verifiers are built and tested (OIDC verified per-commit vs Keycloak; SAML via hardened sidecar with single-use replay defense). Live IdP-vendor interop is planned. | Built | Arch §6 |
| IAM-02 | Identity & Access | Is automated provisioning (SCIM) supported? | Inbound SCIM provisioning/de-provisioning endpoint is built; outbound sync planned. | Built | Arch §6 |
| IAM-03 | Identity & Access | Is RBAC enforced with least privilege? | Role assignments + an ABAC evaluator; execution has no ambient authority (acts only on admitted work, `INV-11`). Admin console planned. | Built | Arch §5–6 |
| IAM-04 | Identity & Access | Is MFA enforced? | Not implemented in the product today; org-level enforcement is roadmap. | No | Arch §6 |
| IAM-05 | Identity & Access | Are access decisions fail-closed? | Yes — uncertainty/absence of a basis denies (`INV-20`), machine-checked (`fail-closed.qnt`). | Available | Arch §5 |
| DSP-01 | Data Security & Privacy | How is customer data classified and stored? | Records / append-only events / content (by handle) / projections; stored in local SQLite + a git-backed content store. | Available | Arch §4; `ADR 0007` |
| DSP-02 | Data Security & Privacy | Does customer data leave the customer environment? | Yes, to the LLM provider: prompts + in-scope context are sent for inference in plaintext today. Otherwise local; federation is opt-in. | Available (disclosed) | Arch §2,§4 |
| DSP-03 | Data Security & Privacy | Is data isolated between tenants/projects? | By authority/scope; no authority writes outside its scope (`INV-1`); handles convey no access (`INV-10`). Hosted multi-tenant operations are planned. | Available (model) / Planned (hosted) | Arch §2,§5 |
| DSP-04 | Data Security & Privacy | Is there a data-retention & deletion capability? | Revocation (future-only, `INV-18`) and content erasure (tombstone, modeled + reducer). Bulk/admin erasure UI planned. | Available | Arch §4; `ADR 0008` |
| DSP-05 | Data Security & Privacy | Is there a DPA and subprocessor list? | Planned (legal artifact). With BYO-credentials, the LLM provider is the customer's own subprocessor. | Planned | Arch §12 |
| CEK-01 | Cryptography & Keys | Is data encrypted at rest? | AES-256-GCM (AEAD via `ring`); envelope encryption with a KMS-wrapped data key, verified live against Azure Key Vault for server deployments. | Built | Arch §8 |
| CEK-02 | Cryptography & Keys | Is data encrypted in transit? | Cross-machine traffic uses certificate-pinned TLS; the relay routes only opaque bytes; cross-party messages are signed (P-256 ECDSA) and verified. | Available | Arch §8 |
| CEK-03 | Cryptography & Keys | How are keys managed? | Envelope DEK/KEK; KEK in Azure Key Vault via a `KeyWrap` seam. Live KMS deployment needs a customer/operator service principal. | Built | Arch §8 |
| CEK-04 | Cryptography & Keys | Is confidential computing / attestation available? | AMD SEV-SNP quote verifier is built and tested against real Milan vectors (ARK→ASK→VCEK + P-384 signature + measurement allow-list). Live confidential-VM hosting and confidential inference are planned. | Built / Planned | Arch §3,§8 |
| LOG-01 | Logging & Monitoring | Is there an audit log of security-relevant actions? | Per-actor append-only `{actor, action, target}` audit log (references only, never payload), position-ordered and filterable. | Available | Arch §9 |
| LOG-02 | Logging & Monitoring | Can logs be exported to our SIEM? | Yes — `HttpAuditSink` POSTs entries as JSON to a customer-configured collector (Splunk/Datadog/webhook) with auth headers, over rustls. | Available | Arch §9 |
| LOG-03 | Logging & Monitoring | Are logs tamper-evident? | Append-only is enforced semantically (immutable event log); cryptographic tamper-evidence / non-repudiation is not yet shipped. | Planned | Arch §9 |
| LOG-04 | Logging & Monitoring | Is there production monitoring/alerting? | Not implemented today (no production observability in tree). | No | Arch §9 |
| SEF-01 | Incident Management | Is there an incident-response plan / breach notification? | Not implemented today; no IR runbooks in tree. To be established before a hosted offering. | No | Arch §9 |
| BCR-01 | Business Continuity | Is there an SLA / DR / backup posture? | Single-machine desktop today (customer controls backups). Hosted SLA + status page are planned. | Planned | Arch §3,§9 |
| CCC-01 | Change Control | How are changes controlled and verified? | Trunk-based with a green-bar CI gate on every change (fmt, clippy-deny, full test suite, model checks, coverage gate). Method-definition changes are edit-authored and audited (`INV-24`). | Available | Arch §11; `CLAUDE.md` |
| TVM-01 | Threat & Vuln Mgmt | Is there dependency CVE scanning? | Not implemented (`Cargo.lock` is pinned; no `cargo audit`/Dependabot in CI yet). | No | Arch §11 |
| TVM-02 | Threat & Vuln Mgmt | Is there SAST / secret scanning? | `cargo clippy -D warnings` runs per-PR; dedicated SAST and secret scanning are not implemented. | Partial / No | Arch §11 |
| TVM-03 | Threat & Vuln Mgmt | Is there a documented threat model? | Yes — STRIDE for the platform, OWASP LLM Top 10 (2025) + MITRE ATLAS for the AI surface, with mitigations and status. | Available | Arch §7 |
| STA-01 | Supply Chain | Is there an SBOM? | Not implemented (CycloneDX/SPDX not yet produced). | No | Arch §11 |
| STA-02 | Supply Chain | Is build provenance attested (SLSA)? | A reproducible build + image measurement digest pipeline is built; formal SLSA provenance attestation is not implemented. | Built / No | Arch §11 |
| STA-03 | Supply Chain | Are released binaries signed/notarized? | Not implemented — desktop builds are currently unsigned. | No | Arch §11; download page |
| AIS-01 | Application Security | How is the LLM agent prevented from over-reach? | No ambient authority (`INV-11`); kernel OS-sandbox bounds tool/file/network; method definition is read-only at runtime (`INV-24`); per-project network isolation is opt-in (egress open by default, no per-host allowlist yet). | Available (Linux/macOS) | Arch §7 |
| AI-01 | AI Governance | Is AI risk governed (NIST AI RMF)? | Mapped to Govern/Map/Measure/Manage: authority-bounded use, documented data-to-model flow, machine-checked protection, gated output release. No model bias/eval program. | Built / Partial | Arch §10 |
| AI-02 | AI Governance | Is the model-provider data flow documented? | Yes — prompts + in-scope context reach the configured LLM provider in plaintext today; the provider is named in the trust boundary. Confidential inference is planned. | Available (disclosed) | Arch §2,§4,§10 |
| IPY-01 | Interoperability | Can a customer export/leave with their data? | Data is event-sourced and locally stored; content is addressable. Formal export tooling/portability UI is planned. | Partial / Planned | Arch §4 |

---

*Security contact:* jack@gaugewright.com · Reviewed against spec rev 2026-06.
This sheet states current truth honestly, including gaps; a "Planned" answer with
intent is preferred to a gap papered over.