"Your data stays inside your perimeter" is usually a contract clause. Here it's a system property: the design constraint the whole product is built to hold, enforced by architecture, and where data does cross a boundary, the crossing is explicit, permitted, and labelled.
We operate the control plane and are architecturally unable to read the data plane. That separation is what makes "we run the plumbing, we never see your data" literally true, and it contractually binds our subcontractors as well as us.
Telemetry carries control-plane fields only. What leaves your deployment for our operations is health, versions, and metering, never content. The same constraint is written into every subcontractor relationship: vendor access is contractually scoped to the control and operations plane, never to prompts, documents, or weights.
The surface where models are deployed, access is set, egress is enforced, and your audit trail lives runs self-hosted, behind your firewall, inside your trust boundary. Placing it there was one of the first design decisions in the product, and much of the architecture exists to keep it true.
Platform and model updates are pulled from a mirror inside your perimeter and applied by a control loop we gate. Automated, but initiated inside the boundary. No vendor, including us, pushes changes in from outside.
The control plane is the source of truth for access control; it holds the secrets, tokens, and certificates, and it owns the audit log. Custody of keys and audit trail is never subcontracted, to anyone.
Every additional party with in-perimeter control-plane access is one more entity your CISO must trust and audit. Our operating model is built to keep that list as short as it can be.
There is exactly one way the system changes: versioned, signed configuration, reconciled by a proven GitOps engine.
Every enforcement control (budget refusal, egress blocking, drift reversion, tamper recovery) is validated by injected-fault tests: deliberately broken, shown to fail visibly, and shown to recover cleanly, before we claim it works.
The same honesty runs through the console: numbers carry their provenance, estimates are labelled, and a quantity the system can't measure renders as a labelled absence.
Honesty as a UX principle →An application backed by a third-party model says so plainly: "this application's prompts leave your perimeter to this provider, under your key." The console scores each app's sovereignty as configured.
Under controlled egress, only explicitly permitted outbound calls exist: user-invoked web search, docs lookups, whitelisted APIs, third-party model traffic under your key. Each one logged.
Identity, application, model, decision, timestamp, and token counts are recorded for every call, and message content is excluded by construction. An audit your compliance officer can sign and your employees can live with.
Identity federates from your provider over OIDC, so access follows the joiner-mover-leaver process you already run. Remove a person once and the console shows every app and model their access no longer reaches: offboarding you can demonstrate to an auditor.
The isolation ladder goes all the way to a full air gap: no connectivity, for classified and contractually air-gapped environments. Each rung's tradeoffs are stated up front, so you hold exactly the line your mandate requires.
The isolation ladder →We built this product to survive a hostile security review. If your team wants to go deep on the boundary, the audit, or the enforcement model, that's the conversation we most enjoy.