Skip to content

Roadmap & status

GaugeWright is built in shippable increments. This page is the single source of truth for what you can use today and what is coming — every other page defers here, so a capability described anywhere on the site carries the same status badge it has on this table.

The one truth to read first

GaugeDesk orchestrates locally, but it does not run the model locally. The agent uses the third-party LLM provider you configure, so your prompts and the in-scope context are sent to that provider over the network, in plaintext, today. What this means for who can and cannot see plaintext is spelled out in Where your data goes.

Network egress: filtered where enforceable, else open-by-default (disclosed)

A non-isolated chat runs under filtered egress (CORE-5, ADR 0079) — the sandbox may reach only the model endpoints, enforced by a host-filtering CONNECT proxy — on hosts that can enforce it (a rootless netns route through slirp4netns/pasta). Where that enforcement is not available, a non-isolated chat keeps the accepted open-by-default posture (unfiltered egress with a disclosed lower ceiling — the 2026-06-17 product decision): the model is reachable out of the box, but the agent can reach any host. An operator can opt into full network isolation per project (network_isolated), which denies network entirely. Honest status of enforcement: the proxy and the whole policy path are built and tested. The last-mile netns routing that makes the proxy the sandbox's sole outbound path (slirp4netns/pasta + an nft default-drop) is designed but not yet verified on a routing-capable host (FILTERED_ROUTING_VERIFIED = false). Until it is verified, the engine does not request Filtered (which the harness fails closed to isolation), so the default stays the disclosed open-by-default posture and model access is never silently broken. Filtering upgrades the default automatically once a host can enforce it. GAUGEWRIGHT_ALLOW_UNFILTERED_EGRESS=1 remains a conscious, logged opt-in to unfiltered egress regardless. The egress chokepoint and taint/consent gating are always on regardless.

What the statuses mean

These four badges are used identically across the whole docs site. If any other page ever disagrees with this table, this table wins.

  • Available — in the product you can download and use today (the local desktop workbench).
  • Built — implemented and tested in the codebase, but not yet operationally deployed (typically waiting on hosting infrastructure or go-live wiring). Not a usable end-user feature yet.
  • Planned — committed and designed, not yet built.
  • Not implemented — absent today.

Reading the split badges (for example, \"Built · live Planned\")

Some rows carry two badges because the code and the deployment have different statuses. The first badge is the code state — core Built, verifier Built, adapter Built all mean the component is implemented and tested in the codebase. The second, live Planned, means that even though the code exists, the capability is not operationally deployed for end-users — it is waiting on the hosting infrastructure to go live. A row with live Planned is not usable today, no matter what its code badge says.

Available means today. Built does not

If a page describes a Built feature, it is describing the design and the code behind it, not something you can switch on. The only mode you can use end-to-end today is the local desktop workbench.

Today's ceiling: method secrecy from the context owner is not achievable

The only Available placement is the local desktop workbench — an unattested placement where the host is the context owner. At this placement, per the boundary ceiling, method secrecy from the context owner is not achievable — only obfuscation, through isolating the run from the host network. The model endpoint and the host are both in the trust set. Raising the method ceiling to host-blind requires an attested placement, which is Built in code but not operationally live.

At a glance

Capability Status
Local desktop workbench (build · run · review) Available
Multi-authority federation (collaborate across machines) Built live Planned
Append-only audit log + SIEM export Available
Kernel-enforced method isolation (Linux/macOS) Available
Windows method-isolation sandbox Planned
Encryption at rest — local envelope encryption (AES-256-GCM) Available
Encryption at rest — KMS-backed (server deployments) Built
Cross-party packaging & deployment Built live Planned
Attested compute (confidential VM, host-blind — provider stays in TCB) verifier Built live Planned
Enterprise identity (OIDC / SAML / SCIM / RBAC) Built live Planned
Capability-gated GaugeDesk Administration Environment Built production deployment Planned
Output review & release lifecycle Built
Hosted multi-tenant platform Planned
Public hosting / embedded agents core Built live Planned
Require-MFA org policy (factor challenge delegated to the IdP) Built
Confidential inference (provider out of trust boundary) Planned
SOC 2 Type II · DPA · penetration test Planned

The Deployment modes page reads this same table from the angle of where the agent runs and who's involved. The Glossary carries the same badge on each term.

Two encryption-at-rest claims, kept apart

Local envelope encryption (AES-256-GCM, a random per-instance data key) is Available in the desktop workbench today. Separately, a KMS-backed adapter — the data key wrapped by a cloud KMS key, so nothing usable sits at rest and key access is KMS-gated — is Built: the adapter is implemented and verified live against a real Key Vault, but it is not operationally deployed at server scale (server hosting is the infra gap). Built ≠ switched on.

What \"attested\" does and does not remove

Attested compute (confidential VM) raises the method ceiling to host-blind: who operates the host no longer decides who sees plaintext. It does not remove your model provider from the trust boundary. Even with attestation Built, the residual trust set is {the attested GaugeWright code, the model provider} — the prompt still reaches the provider in plaintext. Only confidential inference (Planned) takes the provider out of the boundary. See Where your data goes.

Enterprise identity is Built in code, not yet operationally live

The enterprise-identity row reads Built because the OIDC and SAML SSO adapters, SCIM 2.0 provisioning, fixed-role RBAC, and the org-level enforce-SSO toggle are implemented and tested in the codebase (verified live against real IdPs) — but they cannot be switched on end-to-end without the hosted control plane, which is the infra gap. Built is the code, not a usable end-user feature.

Public hosting and embed

The browser-embeddable agent surface (a consultant embedding their agent in their own website for end-users) is being shipped as a clearly-scoped MVP first, then widened. Per-piece status below reflects what is built and tested in code versus what is operationally live. None of it is usable end-to-end today: the managed host that serves a live per-visitor session is infrastructure that does not run in the local scaffold, so the whole surface stays Planned for end-users until that host ships.

The entire embedded-agent surface is not operationally available today

No item in either table below is end-to-end usable today. Every row is either a Built component (implemented and tested in code, awaiting the managed host) or Planned. The per-row badges describe code-readiness, not a feature you can switch on.

Embed capability Status
Anonymous chat (ephemeral, identity-less, discarded on teardown) core Built live Planned
Managed-auth signed-in chat (audience through email / magic-link / social) adapter Built live Planned
My-chats — your own durable chats (drawer + standalone element) data layer Built live Planned
Chat panel + <gw-session> provider + embed.js bundle Built publish Planned
"Powered by" branding mark Planned
Consultant Deploy Config · Embed/Preview · basic Monitor Planned
Embed capability Status
Embedded output panel (read + download your own artifacts) Planned
Embedded files panel (browse your own worktree) Planned
BYO-OIDC sign-in + silent token pass-through adapter Built live Planned
Anonymous → authenticated claim flow (one-time claim token) Planned (decided, build deferred)
White-label — paid removal of the powered-by mark Planned
Attested host as a selectable deployment ceiling Planned
Server-side secret API key (backend proxying) Planned

What \"core Built\" covers here

The audience-identity seam, the durable-chat data layer, the scoped remote session, and the web-component elements (<gw-session> / <gw-chat>) are implemented and tested in the codebase. They cannot run end-to-end without the managed host that serves live per-visitor sessions, so the surface stays Planned for end-users. The end-user side is For embedded end-users. The consultant side is Package & deploy.

How the guarantees are backed

Not every status caveat is the same kind of promise. The docs keep two kinds apart so claims stay defensible:

  • Structural, machine-checked guarantees. Built into how the system works and paired with an adversarial test that fails if the protection is removed. These are the boundary properties on How GaugeDesk protects your work: a handle is not access. Method and context reads are both explicit. A run has no ambient authority. Everything is fail-closed. History is append-only. Available
  • Policy / operational properties. Things that depend on configuration, process, or a third party — your LLM provider's retention terms, certifications, monitoring, build signing. These are not invariants and are stated as such.

The Security & trust page splits the two bucket-by-bucket for reviewers (with the optional INV-* deep links).

Per-OS caveat on the sandbox

The kernel-enforced sandbox that stops a work chat from rewriting its own method is Available on Linux and macOS. Windows method-isolation is Planned — until it ships, run untrusted methods on Linux/macOS.

Known limitations & gaps (today)

Stated here in the docs, not only on the external trust site:

  • Inference is remote and inside the trust boundary. Prompts and in-scope context go to the third-party provider you configure. Its retention and training terms are the provider's, not GaugeWright's. Confidential inference (removing the provider from the boundary) is Planned. See Where your data goes.
  • Only the local desktop workbench is usable today. Cross-party deployment, attested compute, enterprise identity, and hosted/embed are Built or Planned — not operationally live.
  • No third-party certifications yet. SOC 2 Type II, DPA, and a penetration test are Planned.
  • GaugeDesk does not implement a second MFA factor challenge. The org-level require-SSO / require-MFA policy is Built (the enforce_sso and require_mfa org-security toggles landed 2026-06-18, tracker SEC-1 / ID-5). The MFA factor itself is delegated to your IdP under the enforce-SSO flag — GaugeWright declares the policy it honors, the IdP enforces the factor. The last-owner break-glass guard means enforce-SSO can never lock the org out.
  • Supply-chain & ops gaps. No SBOM / dependency scanning, no production monitoring, and unsigned builds today. These are tracked on the Security & trust page and its linked architecture documentation.

Where to go next