Secret³ · Secret.Zone · mockup v2 · 2026-09-07
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.
V1 · the substrate everything else rests on
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.
The claim behind the claim
"Which machines may run your code is decided on-chain, in public, rather than by a vendor" is the strongest sentence in this architecture. It reads like a promise. It is already true, and anyone can read it out of the chain today.
Queried directly from Secret's key-management contract on 2026-09-07, with no account and no permission:
A commercial confidential cloud cannot show you this, because its allowlist is a vendor decision. Here a stranger can list exactly which three images are permitted to run, and when governance admitted each one.
Nobody is pointing at it. It is in no documentation, and the contract's own source repository returns 404 — which is a separate and cheap thing to fix.
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 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.
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.
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.
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 bucket attaches to one computer, many, or none. It is the answer to files being stuck inside the thing that made them.
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.
Here is the honest comparison. Three rows carry the argument. Two are worse.
| Secret.Zone | Phala Cloud | Hyperscaler CVM | |
|---|---|---|---|
| Runtime | dstack | dstack, productised | Vendor-specific |
| Who decides which machines may run your code | On-chain, governance-curated, hardware-bound. Readable by anyone today | Vendor allowlist | Vendor, entirely |
| Can the operator be made to evict you | No consensus rule can compel a host to run — or stop running — a tenant's code | Terms of service | Terms of service |
| Rollback and freshness | Ledger-anchored checkpoints | Not provided — dstack's own security model says applications must anchor state externally | Not provided |
| Verification by a stranger | A link. No install, no account | Attestation available; surfacing it is the deployer's job | Vendor APIs |
| GPU TEE | Not this cycle | H100, H200, B300 | Available |
| Maturity | Architecture in draft | Shipping and priced | Generally available |
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.
Read this before reviewing the rest
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.
| Surface | Status | Where the uncertainty is |
|---|---|---|
| The name and TLS path | Specified | dstack-gateway does this today. But the paper never addresses it — its three uses of “gateway” mean something else — so adopting it is a decision nobody has recorded |
| On-chain admission | Specified | Already live and readable. Whether the same apparatus carries over to CVM hosts is unanswered |
| The proof link | Proposed | Our design. Today verification is a CLI subcommand and a paste-two-fields form, and the rebuild path leads to a 404 |
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 | The most differentiated idea here and the most dependent on everything else. Built last for that reason |
| Bucket grants to machines | Proposed | Semantics, not implementation. The backend is open |
| 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.