Secret³ · Secret.Zone · mockup v2 · 2026-09-07, revised 2026-09-12 and 2026-09-14
Deploy a site, an app, an agent or a bucket to a confidential computer. Get a name. Hand anyone a link that proves what is running — with no account and no install.
This mockup is for argument, not applause. It is a proposal for Ian and Lisa to consider in the Foundation’s roadmap process. The screens show illustrative names, measurements and outcomes, not live verification results. Site/App comes first; Storage and Agent are later proposals. A limited pilot would retain its explicitly reduced trust contract.
The argument · The evidence behind it · Four surfaces · The agent · Storage · Against Phala Cloud · What we made up
Seven sections. The first is the argument; the middle four illustrate it; the last two are where we would most like to be corrected.
V1 · the substrate everything else rests on
The proposed first developer journey: deploy, operate and share checkable evidence. Phala already offers public verification; Zone must show why its policy and recovery integration is valuable. Storage and Agent follow buyer validation.
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.
The proposed name is name.secret.express, with a supported custom-domain path. Question 4 selects where TLS terminates: in the gateway’s own CVM, whose evidence must be checked, or through passthrough to the tenant’s CVM, whose certificate path must be validated.
Upstream dstack-gateway provides gateway termination and passthrough mechanisms. Zone still needs naming, routing and verification for the selected mode. Gateway termination adds that gateway to the trust boundary; host-side HTTPS does not satisfy either confidential path. DNS and gateway operators can interrupt access. See the gateway analysis, §6.
A link. The person who opens it did not deploy the workload, has no account, and installs nothing. That constraint is the entire product.
Reproduce the selected image from sources and build inputs that remain reachable. Upstream parity can reduce maintenance dependencies; a reproducible custom image is also possible. Workload identity, policy, freshness and the selected TLS boundary require their own checks.
The claim behind the claim
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.
One confidential computer, exposed four ways
A website, on a confidential computer, with a name. You can prove what's being served.
Your software, on a confidential computer, with a link. Secrets stay sealed to that machine.
Confidential AI with its own computer. You message it. You can watch the screen, or sit down at the desk.
A confidential bucket. Seal it or leave the lid off. Hook up one computer, or many, or none.
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 separately usable bucket. Agent needs adequate persistence and safe session control, not every Storage feature.
These screens describe proposed experiences. The developer journey is the first release recommendation; later scope depends on customer validation.
The hero, and the last thing built
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.
Proposed: human approval for defined external actions by default. Showing unsent drafts does not prove that sending is prevented. The implementation must enforce the agreed approval rules and test exclusive session handover.
The proposal is a seat you can take: observe, take exclusive control and explicitly hand the session back. The measured environment does not prove that an agent’s reasoning or actions are safe.
How an autonomous agent pays for its own compute. The paper's economics are operator-side burn with retail paying fiat, which does not obviously accommodate an agent paying per workload for itself. The incumbent answered this with x402 and an on-chain identity registration; neither appears in the paper or in the original design. Worth evaluating, not inheriting.
A bucket with a name
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 proposed bucket attaches to one computer, many, or none. Define grants, recovery and deletion before promising the feature. Revocation can stop future access or key release; it cannot erase plaintext or keys already obtained.
Positioning
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.
The comparison motivates a hypothesis: auditable admission, voluntary placement and checkpoint recovery, each with its conditions. It does not establish an exclusive moat or validated demand.
Revised 2026-09-12 after reading Phala Cloud's contracts and documentation rather than its pricing page. Two rows here overstated the gap and now say less: their on-chain KMS option puts the platform allowlist on Ethereum and Base where anyone can check it, and they run a hosted verifier. The difference is who may change the allowlist, and whether the governing set is open to join.
Revised 2026-09-14 (UTC). We withdrew eviction immunity: paper §7.1 requires a host’s acceptance, not continued service. Tenant-CVM TLS is not a settled choice; question 4 selects gateway termination or tenant passthrough. Checkpoint recovery is proposed for integrated Apps (PRD 1.11), not ordinary disks. Upstream parity is a maintenance option, not the only reproducible verification route. We also withdrew the exclusivity framing: Phala already offers public verification, so these conditional differences need customer validation. The revocation and unsent-draft examples now state their limits rather than imply enforced guarantees.
| Secret.Zone | Phala Cloud | Hyperscaler CVM | |
|---|---|---|---|
| Runtime | dstack | dstack, productised | Vendor-specific |
| Who decides which machines may run your code | Proposed authority: authenticated ledger policy and hardware-bound admission, checked independently by custodians; the tenant owner authorizes the workload image. The prototype’s supplied policy is not ledger authorization | Phala's own, off-chain, by default. Opt into on-chain KMS and it moves to Ethereum or Base — anyone can check whether a given image is allowed, listing them all needs archive log access — changed by a 2-of-3 multisig | Vendor-managed policy; evaluate the selected service’s evidence |
| Host acceptance of placement | The host must accept before provision and protocol fees (paper §7.1). This does not prevent eviction or DNS/gateway interruption | Terms of service | Terms of service |
| Rollback and freshness | Proposed for integrated Apps (PRD 1.11), requiring protocol support, a verified ledger head and tested recovery. Ordinary disks gain no protection automatically; the tenant interface remains question 1 | dstack requires an external freshness anchor and application integration | Evaluate the selected service and application’s freshness mechanism |
| Verification by a stranger | Proposed: readable public evidence plus reader-controlled verification; recorded prototype runs use development trust | A hosted verifier, live — app, KMS and gateway | Vendor APIs |
| GPU TEE | Not this cycle | h200 and b200 in the catalogue it served | Available |
| Maturity | Architecture in draft | Shipping and priced | Generally available |
The buyer hypothesis: a confidential-app developer whose customer values checkable execution and operating policy. Validate that need with a non-critical pilot and a matched workload comparison. Regulated procurement and money custody are outside the first release’s promise.
The first protocol-backed App release proposes a minimal checkpoint path independently of standalone Storage. A pre-protocol pilot does not claim those unavailable benefits or establish demand for them.
The inventory
Every surface on this page, with where its uncertainty sits. Each row is somewhere we would rather be corrected than agreed with.
| Surface | Status | Where the uncertainty is |
|---|---|---|
| The name and TLS path | Open | Question 4 selects gateway-CVM termination or tenant passthrough. Zone must integrate naming and verify the complete selected path |
| On-chain admission | In the paper | Specified for Zone; unimplemented in this prototype. The dated live registry evidence above belongs to SecretVM |
| The proof link | Proposed | Proposed product contract. A public development reader path has run under development trust; hardware-backed acceptance and independent customer validation remain required |
The zone command surface | Proposed | From the original design. Nothing matching it is published on npm, and the bare name is taken by an unrelated 2014 package — this is intent, not tooling |
| Agent seat handover | Proposed | A later proposal under D14, requiring buyer validation, adequate persistence and tested exclusive session control |
| Bucket grants to machines | Proposed | Semantics, not implementation. The backend is open |
| Recurring evidence checks | Proposed | PRD 2.3 requires a declared cadence and honest age, failure and change reporting. Periodic checks are not continuous proof; this screen is illustrative |
| Connecting a source | Proposed | Git or a folder plus a compose file. The compose hash is real and implemented; the git path is not |
| Agent payment | Open | Unresolved. See above |
Whether any of this already exists. We tested the public endpoints and found nothing serving — which rules out a public deployment and nothing else. If there is a prototype behind the original mockup, we would rather build on it than around it, and we would rather hear that in an hour than discover it in a month.