How GaugeWright protects method and data.
Confidentiality isn't a feature here — it's the product. This is where we show our work: the boundary model, the invariants it enforces, and the documents your security team will ask for.
Security overview
Data flow, isolation, identity, audit, attestation, and compliance — distilled for a quick vendor review.
Architecture & security
Enterprise reference: system context, data-flow diagrams with trust boundaries, the invariant→control crosswalk, threat model, and honest status throughout.
The short version
A method-owner's agent and a context-owner's data meet only inside a controlled boundary. The boundary mediates what the agent can read, call, and export. Data is addressed by handle and revealed only under an explicit rule; the method runs read-only at the client and is never exported. Nothing crosses without admission, and the system fails closed. Every run is recorded as an append-only event you can audit and reverse.
The source lives on GitHub.
FAQ
The questions a security team asks first.
Does my method or data ever leave my machine?
Two answers. For inference, yes: the agent's reasoning is performed by the third-party LLM provider you configure, so your prompts and the in-scope context are sent to that provider over the network — there is no local-only inference today. For everything else, only if you opt in: orchestration and storage are local, and federation (moving anything to another party or to our infrastructure) is an explicit action where nothing crosses without the source permitting it to leave and the target admitting it. See the security overview for the full data flow.
How is confidentiality enforced — not just promised?
Structurally. Resources are addressed by handle, and a handle grants no access; reading a payload requires a separate, explicit basis evaluated at the boundary. Method reads and context reads are each explicit, execution has no ambient authority beyond what it was admitted, and every basis check fails closed. The guarantee is the emergent result of these invariants, not a setting you can misconfigure.
What can I audit?
Everything durable. Every fact is an append-only, immutable event; current state is the deterministic replay of those events. Corrections are new events, never edits, so history is a complete, reversible record. (Cryptographic tamper-evidence for cross-party disputes is a planned addition — see the brief.)
What stops a deployed agent from leaking the method or escalating?
A working deployment runs the method read-only. The definition surface is writable only from an edit session, enforced by an OS sandbox that makes it a read-only root — every write path, including a shell, is blocked at the kernel. A running agent cannot rewrite its own prompt or loosen its own policy.
What's free, and what's paid?
Local, single-party use is free. Paid tiers cover cases where a third party relies on our infrastructure — relayed multi-party work and attested sealed runs. Pricing is a take-rate model: experts set their own engagement price and we take a cut. The relay, attested-compute, and hosted tiers are on the roadmap.
What's shipped today versus on the roadmap?
Shipped: the local workbench (build, run, review) and the multi-authority steering architecture, with the protection invariants machine-checked. Roadmap: packaging and cross-party deployment, the relay and attested-compute runtimes, public hosting / the embeddable agent, and accounts/billing. The architecture doc labels every deployment mode with its honest status.
Where's the source?
On GitHub. The authoritative invariants live in specs/principles.md, and the protection properties are checked against formal models with deliberate "teeth" tests that fail when a protection is removed.