Trust
The promises are structural.
The things it won't do, it can't do.
Deleting your files isn't forbidden — the operation doesn't exist. There is no delete on the surface your Host can reach, so there is nothing to bypass and no permission to skip. Revealing your keys to your AI isn't restricted — there is no code path. Your Host uses a credential by asking a broker to act with it; the bytes never enter its reach.
A guarantee is only structural if removing it means rebuilding. That is the bar we hold, and it is why these read as absences rather than rules.
Verified continuously, not asserted once
The platform runs roughly sixty tripwires against its own production, every ten minutes, from the position of an outside caller. Each one tests the effect of a promise the platform depends on — tenant isolation, egress walls, the billing doctrine, certificate chains — and a green-to-red transition pages us. They run against production, forever, instead of once at build time. When we fix something the platform depends on, we add a tripwire for it. Fixed once, asserted forever.
Some of what is asserted, continuously
- No token is ever billedIf an inference or embedding charge ever landed on a wallet, this tripwire goes red permanently. The only meter is borrowed machine time.
- A Host cannot reach another tenantIsolation from platform internals and from other tenants is asserted from inside an actual pod — independent of any network policy.
- There is no anonymous identityA connection without a client certificate cannot make a call. Identity is the certificate; a forged id is refused.
- Permissions are proven, never claimedA permission slip is a signature over its terms. Alter one term and it stops verifying. Revocation is checked offline, and a stale revocation view fails closed.
- The operation surface is a fixed listAn unknown operation is refused at the gateway and on your machines. There is no arbitrary-execution path to harden, because there is no arbitrary execution.
- Provenance is issued, never self-declaredThird-party code cannot be signed as first-party. The signing authorities are disjoint, and the tripwire goes red if they ever overlap.
How the machine is built
Your machine is a dedicated container with its own PostgreSQL, filesystem, hostname, and certificate identity. It runs as a non-root user on a read-only root filesystem, with every Linux capability dropped and a custom seccomp profile. It has no inbound ports: it dials out to one governed gateway over mutual TLS, so there is nothing to scan, on it or on the machines you join to it.
Code never runs in that container. When your Host hands a task to a coding agent, the agent runs in a separate, disposable pod on your machine's side of the line: its own user, its own workspace, non-root, read-only filesystem, seccomp, only the credential the task needs, and an internet exit that is logged for you. When the run ends the pod is destroyed. What survives is the branch.
The agents you talk to are refused code execution outright. Every dispatched agent starts with zero capabilities; your Host grants what the task needs, per task, and the grant ends with the task. Credentials are used through a broker, so an agent sees results and never the bytes. Revealing a key to yourself takes your second factor.
PII: a lane on your own machine, off by default
Outbound model requests can pass through a PII sterilization lane that lives on your own bastion — personal data scrubbed, metadata stripped, the queue in-memory and fail-closed. It is advertised by your bastion, not imposed by us, and it is off until you turn it on. If the lane is unhealthy, the request doesn't go; nothing fails open into a dirtier path.
This isn't an audit, and we won't call it one. These are our own checks, running against our own production, and we'll tell you exactly what they cover.