# GaugeWright Workbench — Security Overview

*For IT and security teams evaluating GaugeWright as a vendor. Written to be
verified, not sold; the formal model lives in the product's
[architecture document](architecture.html) and `specs/`.*

**Status legend** — **Available**: in the shipped product today · **Built**:
implemented and tested in code, not yet operationally available · **Planned**:
committed, not yet built.

## What it is

A desktop workbench for building and running AI agents (the "method") against
private data (the "context") under an enforced boundary. **It orchestrates
locally; the agent's reasoning is performed by a third-party LLM provider you
configure.** Hosted, relayed, and attested deployment modes are roadmap.

## Where your data goes

| Stage | What happens | Status |
|---|---|---|
| **Inference** | The agent's reasoning calls the LLM provider you configure (e.g. OpenAI, Anthropic, Azure OpenAI). **Your prompts and the in-scope context are sent to that provider over the network.** You authenticate the provider; its retention/training terms are the provider's, not ours. No local-only inference today. | Available |
| **At rest** | Content is addressed by handle, not stored inline. Envelope encryption (AES-256-GCM, data key wrapped by a KMS key) is implemented and verified live against Azure Key Vault for server/hosted deployments. Confirm the at-rest posture for your specific mode. | Built (server) |
| **In transit** | Cross-machine traffic uses certificate-pinned TLS; the rendezvous relay routes only opaque encrypted bytes and cannot read payload. Cross-party messages are signed and verified before admission. | Available |

**The one fact to take away:** local orchestration is not local inference.
GaugeWright does not remove your LLM provider from the trust boundary. If data
may not leave for a third-party model, you need a provider you've contracted
(bring-your-own account) or the future confidential-inference mode, which is not
yet available.

## Isolation & access control

- **Authority / scope model.** Every fact names a responsible authority and the
  scope it touches; no authority writes outside its scope. Projects and tenants
  are isolated by scope, not row-level filters. — *Available*
- **Handles don't grant access.** Holding a reference conveys no read; payload
  access requires a separate, explicit basis evaluated at the boundary. Checks
  are **fail-closed** — uncertainty denies. — *Available*
- **Method is read-only at runtime, kernel-enforced.** A running agent cannot
  rewrite its own prompt, policy, or tools. Enforced by an OS sandbox
  (bubblewrap on Linux, Seatbelt on macOS); every write path, including a shell,
  is blocked at the kernel. **Windows: enforcement pending — runs fail-closed
  (refused) until the backend ships.** — *Available (Linux/macOS)*

## Identity & access management

OIDC and SAML sign-in, SCIM provisioning/de-provisioning, coarse role-based
access (owner/admin/member/viewer/billing), and org-level MFA enforcement are
**built and tested** (OIDC verified per-commit against Keycloak). Live interop
with specific IdP vendors (Okta, Entra, Google) and deploy-time wiring are
**planned**. The shipped desktop product today is local and needs no account.
— *Built*

## Audit & integrity

- Every durable fact is an **append-only, immutable event**, totally ordered
  within its scope; corrections are new events, never edits. State is the
  deterministic replay of events.
- Audit entries carry actor / action / target references only (no payload) and
  export to your SIEM via a customer-configured webhook.
- **Honest limit:** append-only is enforced *semantically*, not yet with
  cryptographic tamper-evidence or non-repudiation. Cross-party log trust today
  rests on the operator, not a signature chain. — *append-only Available;
  tamper-evidence Planned*

## Confidential / attested compute

Designed and partially built. The AMD SEV-SNP attestation **quote verifier** is
implemented and tested against real hardware vectors (validates the
ARK→ASK→VCEK chain and report signature). Live confidential-VM hosting, the KMS
Secure-Key-Release wiring, and confidential *inference* (removing the model
provider from the trust boundary) are **not yet operational**. — *Verifier
Built; live attestation & confidential inference Planned*

## Software assurance

The protection model's invariants are **machine-checked** as formal models
(Quint), each paired with an adversarial "teeth" test that confirms the check
fails when the protection is removed (fail-open, skip-auth, method-write-leak,
…). The core reducers are pure and property-tested against those models. No
independent third-party penetration test has been performed yet. — *Formal
verification Available; pen test Planned*

## Compliance & certifications

**None available to cite today.** SOC 2 Type II, a Data Processing Agreement
with a published subprocessor list, and an independent penetration test are
committed and prioritized but not yet delivered. Subprocessors will include your
configured LLM provider(s) and, for hosted/attested modes, Microsoft Azure.
— *Planned*

## Current stage

What you can deploy today is the **local desktop workbench** — single-party,
local orchestration, remote inference. The hosted, relayed, attested, and
enterprise-identity capabilities above range from code-complete-and-tested to
design-only, but are **not operationally available** and carry no live
certification yet. The security *model* is verified; operational *readiness* for
a regulated mid-market deployment is still in progress.

---

*Security contact:* jack@gaugewright.com · Source & formal specs:
github.com/jamesjscully/un-tie · Reviewed against spec rev 2026-06.