Confidentiality you can measure.

Three steps, and the third is the one nobody else offers. Site and App are the same machine with different surfaces; Storage and Agent attach to it later.

Git or a folder, plus a compose file. No new packaging format, no rewrite. The workload is a measured composition, so attestation names exactly what ran.

Every deployment lives on name.secret.express, or bring your own domain. TLS terminates inside the confidential machine — the certificate is requested, held and used within the attested environment, never at an edge proxy.

This is not new work. dstack-gateway already does it: ACME dns-01 in-process, CAA records pinning issuance to its own account, content-addressed domains. The paper names every other dstack component and decides each one. The gateway is not among them — the word appears three times, meaning network-gateway workloads and retail billing gateways, never the component that terminates TLS. And if TLS terminates anywhere outside the machine, plaintext exists somewhere the tenant never attested.

A link. The person who opens it did not deploy the workload, has no account, and installs nothing. That constraint is the entire product.

Rebuild from source and compare the measurement yourself. If the guest image is dstack's published one, the reference to compare against is upstream — no registry we control sits in that path.

These are dated SecretVM registry figures, not Zone’s registry. Zone is greenfield on dstack. Its prototype evaluates supplied policy files; ledger admission and custody remain unimplemented.

Source: SecretVM KMS registry read, §3. The get_all_hw_registers encrypted query returned:

The registry read demonstrates enumerable measurement pairs. It does not by itself establish when governance admitted each pair, or authorize a Zone workload. See prototype coverage and limits.

These are not four products. They are one machine with four surfaces, plus storage that attaches to none of them, one of them, or many. Site and App need a machine and a name. Storage adds a bucket. Agent needs everything.

Which is why the narrative order and the build order are inverses. Marketing can lead with the agent long before the agent exists.

An agent with its own computer — a real Linux session, not a sandbox behind an API. Message it and it works. Watch the screen without touching. Take over and you are at the same desk; leave, and chat is driving again.

Nothing is sent without a human, by default. Three replies drafted, none delivered. That default is the trust model — it should be explicit and configurable, not incidental.

It answers the objection every agent platform faces — what happens when it gets something wrong — not with guardrails, but with a seat you can take.

S3-compatible, on records.secret.express. Sealed means keys only to who you grant. Open means anyone can see what's inside. Grant a machine, not a user — the grant target has a measurement, which is what makes it different from an access list, and checkable.

A bucket attaches to one computer, many, or none. It is the answer to files being stuck inside the thing that made them.

Secret.Zone runs on dstack — the same guest stack Phala Cloud sells as a managed product. "We run dstack too" is not a pitch, and pretending otherwise wastes everyone's time.

Here is the honest comparison. Three rows carry the argument. Two are worse.

And the counter-argument, before a buyer makes it: for most workloads none of the three differentiators matters, and Phala is available now at a known price. The buyer who cares is the one for whom the operator is part of the threat model — regulated data, adversarial jurisdictions, agents handling money.

That is a narrower market than "confidential compute." It is worth aiming at deliberately rather than arriving at by accident.

This mockup is for argument, not applause. Everything below is our proposal rather than the paper's, and each is somewhere we would rather be corrected than agreed with.