Verifiable compute · API v1

Compute that
cannot see
your data.

Your apps. Your data. Your boundary.

Protection depends on the host. Windows host-OS memory exclusion was demonstrated in a local test on 2026-10-23; its per-app signed report does not attest that exclusion. Confidential CPUs add protection against operator software. See the boundaries →

Deploy an app How it works
  • Build onceRun across hosts
  • Verify firstCheck before connecting
  • Pay as you goOnly for compute used

Built on the hardware isolation enterprises trust.

  • Google
  • Microsoft
  • AMD
  • Intel
  • NVIDIA
  • Arm
  • AWS
What you get

Portable apps. Checkable evidence.

The architecture, in full ↗
one bundle

Portable

Build a WebAssembly component once and it runs on every backend. The host's operating system is an implementation detail, never a rewrite.

CPU + GPU protection

Enclave Shield

On the Windows reference host, CPU isolation kept the host OS out of guest memory in a local test; this is not attested per app. Shield also masks GPU inputs and checks returned results. How Shield works →

check the evidence

Verifiable

Check supported attestation evidence in your browser or CLI. Default checks use Enclave’s measurement allowlist and return a limited verdict; independently pin an expected measurement for the confidential-server check. Run it now →

no gatekeeper

Independent

Catalog, ledger and payments run on public contracts. Apps are content-addressed, the source is published for audit, and hosts are run by their owners. Designed to outlive any one company, ours included. What still runs on our servers, listed honestly →

Who it is for

Anything holding a key is a customer.

Four ways in, one identity. No accounts, no approvals.
deployers

Use an app

Pick an app, fund it, use it: a private model chat, an image generator, a game server, any tool you would not trust with your data anywhere else. Browse the store →

publishers

Publish an app

Ship a WebAssembly component to the catalog in a minute, set an hourly fee if you like, and get paid every time someone funds it. The developer guide →

hosts

Sell your hardware

Register a machine you own and get paid for every lease it serves. Your machine proves its protection when it attaches, so buyers never have to take your word for it. Host an enclave →

agents

Drive it with a key

Everything a person can do here, an agent can do over REST and MCP: browse, deploy, fund, verify. No step assumes a human. The MCP server →

Lifecycle

Five calls, start to finish.

From zero to a live endpoint you have checked. Click a step to see what crosses the wire.
The isolation contract

One contract.
Two paths to isolation.

The target contract is one hardware domain per app. Demonstrated protection and remaining trust depend on the backend.

Enclave Shield

Windows isolation.
Locally demonstrated.

On the Windows reference host, a privileged memory capture read an ordinary guest’s memory but not a VBS-isolated guest’s (2026-10-23). The Linux CPU-isolation backend remains a design.

  • A measured trusted layer enforces each app’s domain.
  • App identity, keys, and traffic stay bound together.
  • No software-only fallback.

Protects againstHost-OS memory access in that test.The per-app signed report still says host_excluded: no. The hypervisor and machine’s owner remain trusted; partition memory is not encrypted.

Confidential hardware

The same isolation.
A deeper boundary.

Adds processor-backed memory protection against the machine’s operator.

  • Encrypted, integrity-protected memory.
  • A processor-signed report you check before connecting.
  • TLS terminates inside the enclave.

Protects againstThe host OS and operator software.Physical attacks with lab equipment are outside this claim.

GPU protection

GPU power.
Protected data.

The documented deployment uses only Shield’s masked GPU offload: metal0’s V100-class cards and the Windows host’s integrated GPU (2026-10-14).

Confidential GPU · not currently deployed

The architecture supports a GPU inside the confidential boundary in a supported CC mode. The NVIDIA CC fleet was retired on 2026-10-14.

Deployed GPUs · Enclave Shield

The design masks protected tensors and checks returned results. Its protections depend on the trusted CPU component and the documented assumptions; review has been internal only. Read the Shield record →

One target contract. Evidence for each backend.

The full contract
Security boundaries & verification requirements

Enclave Shield

Shield combines per-app CPU isolation with masked GPU offload. Windows host-OS memory exclusion was demonstrated locally on the reference host on 2026-10-23, but the per-app report still records host_excluded: no. The hypervisor and physical operator remain trusted. Linux CPU isolation is a design; the complete isolation contract must not be inferred from per-app placement or a working GPU component.

Confidential hardware

Each app keeps its own domain, and the processor adds a boundary around the whole machine: memory is encrypted and integrity-protected against everything outside it, operator included. Before connecting, you check a report signed by the processor and chained to the silicon vendor.

GPU admission

A GPU in a supported confidential-computing mode runs inside the boundary. Any other GPU, even one beside a confidential processor, is used only through Shield's masked offload: the card sees masked inputs, its results are checked before use, and it never receives plaintext protected state. Admission reads proof of the card's own mode, never the CPU, the host, or a missing field. Until that proof checks out, the card is neither advertised nor routed.

Scope and limitations

Protection claims are specific to the backend and evidence: the Windows memory test is a local demonstration, not a per-app attested guarantee. Neither the platform nor Enclave Shield has had an external audit. A confidential processor defends memory against software, not against physical attacks with lab equipment, and a self-hosted seller has physical access to their own machine. Documented deployments do not establish the complete target contract. Ordinary virtualization with the host OS in charge is a research control, not a supported product tier. Which hosts are attached, and what each has proven, is on the live fleet panel and in the dated evidence note on the architecture page. The contract, property by property →

Root of trust

Check the evidence. Know the limits.

Walk through the confidential-server verification path and Shield GPU offload. Default verification uses Enclave’s measurement allowlist, so a successful check is limited. Run a host check below.

  1. On the documented confidential server, the CPU’s AMD SEV-SNP attestation chains to AMD’s hardware root. GPU work uses Shield’s masked offload outside that confidential boundary; no deployed GPU is attesting in NVIDIA confidential mode.

  2. On boot the AMD secure processor signs a report over the launch measurement, a SHA-384 digest of the firmware, the kernel, and the exact runtime image. Change one byte and it changes. Your app is deliberately not in it: the app arrives later by CID, and the runtime refuses any bytes that don't match the CID in your deployment record. (On Intel TDX: a DCAP quote over MRTD + RTMRs.)

  3. The deployed GPUs receive masked inputs through Shield, and the trusted CPU component checks returned results. This is not GPU hardware attestation. Its security depends on the trusted CPU component and Shield’s documented assumptions; review has been internal only. The NVIDIA confidential-GPU fleet was retired on 2026-10-14.

  4. The enclave generates its TLS keypair in sealed memory and folds the public-key hash into the quote's report_data. The private key never leaves the boundary, so the operator can't sit in the middle.

  5. Enclave's source-available verifier (verifier/ in the repo, served from this site) checks it in your browser: it sends the box a fresh nonce, then verifies the signed report up to AMD's root, the firmware floor, the guest policy, the key binding to your nonce and the launch measurement. The API’s selfCheck is only a diagnostic. By default, the expected measurement comes from Enclave’s allowlist, so a successful check is limited. For the confidential-server check, use enclave attest --expect <measurement> with a measurement you derived independently. Pinning does not remove other trust assumptions.

Illustrative policy and evidence
enclave · confidential vm · one per app
launch measurement · live fetching …

Check a host’s evidence

Your browser checks a live host's hardware attestation itself, with Enclave's source-available verifier.

Default verification uses Enclave’s measurement allowlist: a successful check is limited. For the confidential-server check, use enclave attest --expect <measurement> with a measurement you derived independently. This removes reliance on the allowlist for that comparison; other trust assumptions remain.

Pick a specific host →
How this works

The page draws a fresh nonce. The relay carries it to the host and brings the host's evidence back untouched, and the verifier (served from this site, hash-pinned) checks it against hardware roots built into it: AMD's for SEV-SNP, Google's for phone pVMs, the TPM maker's for Enclave Shield, where the page also mints the TPM credential itself. The relay can delay a check but cannot fake one. Expected builds come from the operator's list, so a pass reads "genuine and fresh", not "independently reproduced". From a terminal: enclave attest --expect <measurement>.

Pricing

Your workload.
Your choice of host.

Hosts set their own rates. Pick the hardware and protection your app needs and see the price before you pay.

Find an app Explore hosts
Metered by the second.
Your compute, itemizedHost-set rates

CPU & memory

The share of the host your app uses.

Your allocation

GPU compute & VRAM

Add accelerator resources when you need them.

Optional

App publisher fee

Included in the quoted rate for paid apps.

If applicable
Your deployment rateShown before you pay

Based on the host, resources, and app you choose.

  1. Find your fit

    Compare available hosts, hardware, and protection.

  2. Size your compute

    Allocate resources to match your app’s requirements.

  3. Fund your runtime

    Start with a small top-up. Add more time as you go.

How billing works

Rates come from the host. Your rate is your CPU and GPU shares at that host’s posted rates, plus any publisher fee, which goes to the app’s publisher. You see it before you fund.

Payments buy runtime. Prepaid time is metered by the second. Unused time stays on the deployment’s public record so you can stop and resume later, and cancelling returns the unspent part held for the host; the rest of a payment is final. Fund in small top-ups.

Resources follow your app. Each app sets minimum allocations, and GPU work needs an available GPU host. Shares are software-enforced allocations; they do not by themselves create hardware isolation. What does →

Rates round up. Per-second rates are rounded up to whole millionths of a dollar.

View the billing contract
The company

Who's behind this.

Enclave is designed so you never have to take the operator's word for anything. You should still know whose word you are not taking: Enclave Host, Inc.
the operator

Enclave Host, Inc.

The company that builds and operates Enclave. Payments to it settle on a public record, and its enclaves prove what they run before you send them a byte.

Source on GitHub support@enclave.host
the founder
Steven Batchelor

Steven Batchelor

Founder & CEO

Steven is a certified application architect focused on serverless architecture, with an enterprise consulting background and a passion for decentralized systems. He builds Enclave hands-on, from the attested enclave stack and settlement contracts to the site you are reading. Based in Arizona.

LinkedIn