Sealed execution
The core guarantee — your input is decrypted only inside an environment no one outside it can observe.
Sealed execution is the heart of the studio. A unit of work — a build — consists of an encrypted input you submit and a finished output returned to you. Between submission and return, the work is processed inside an environment that is opaque to everyone outside it.
The four guarantees
For any build with input x and output y, a sealed execution environment guarantees:
- Input confidentiality.
xis decrypted only inside the environment and is never accessible to any outside party. - Non-retention. Neither
xnor any intermediate state survives the build. When the environment terminates, the data is gone. - Output integrity.
yis returned only to the holder of the originating wallet key. - No training surface. Because
xis never persisted, it cannot enter any training corpus — ever.
How the seal works
The environment runs on confidential-compute hardware and produces a cryptographic attestation that it is configured correctly and unmodified. If attestation fails, your encrypted input is never routed there. The guarantee is verifiable, not promised.
The attestation is checked before your encrypted input is routed anywhere. You don't have to take anyone's word for it.
Why this is different
Conventional tools can read everything you submit and rely on a policy not to. ArxCode cannot read what it processes — there is no administrative session to inspect, no log to leak, and no retained corpus to train on. The difference is structural: a promise replaced by a property.
Next
- Follow a build end to end in Lifecycle of a build.
- See what the studio does and does not defend against in the Threat model.