The attested tier — "unobservable in use"

Status: Production — and independently verifiable. A Space can run its turns inside a Nitro enclave in production today: turn on "Run this Space inside the enclave," and its key is sealed to the measured image below. Every measurement is one you can run yourself. It is the app builder's per-room choice — the platform can run any room in the enclave — and since 2026-08 the tier also closes the last reader this page used to concede: the model call can only leave the measured image through an attested no-log gateway into confidential-compute inference (see the confidential model below — the trade is an open-weights model, not the frontier vendor). A running enclave publishes its measurement at /enclave-claim.json (the PCR pin the client verifies before it seals anything); see Verify It Yourself for the full ladder of live checks.

Everything else on this site proves things about code we publish: the app's egress is locked, the store holds only ciphertext, the deployed render is a reproducible build of source you can read. All of it stops at one wall.

None of it proves what the machine actually loaded. Between the ciphertext arriving and the answer going back, plaintext exists in memory on a server we operate. Read Verify It Yourself closely and it says so: the one thing you cannot check is that the render is unobservable in use.

This is the tier that closes that.

What changes

Your room key already travels sealed to a service public key rather than in the clear (spaces/public/mkseal.js). That module was written for this moment, and said so in its own header: today the private half lives in the service; tomorrow it can live only inside an attested enclave, and nothing on this side changes.

In the attested tier, that recipient keypair is generated inside an AWS Nitro enclave, at boot, and never written or exported. Its public half is bound into a hardware-signed attestation document. Verify the document, and you are sealing your room key to a key that provably exists only inside a specific, measured image.

"We cannot read your room" stops being a policy and becomes a property.

The four things you can check

Nothing here asks you to trust us, and none of it requires our cooperation beyond us publishing what we already do.

1. The document is genuine AWS hardware. A Nitro attestation document is signed by a key in hardware the operator cannot reach. Our verifier (spaces/public/nitroVerify.js) checks the COSE signature and walks the certificate chain to the AWS Nitro root G1, pinned in the source — the document carries its own copy of that root and we discard it, because a verifier that trusts the anchor its input supplied is not verifying anything.

It runs in your browser. WebCrypto cannot walk an X.509 chain, so the chain walker is written out in spaces/public/x509.js — about 180 lines, ECDSA only.

2. The image is the one you can rebuild. PCR0 is a SHA-384 measurement of the running image. infra/enclave/build-eif.sh reproduces it from published source. Four things are pinned because each is an input: the base image by digest, SOURCE_DATE_EPOCH, buildkit by digest, and the nitro-cli version.

This is the part most projects skip. A measurement you cannot reproduce only tells you the image hasn't changed since we built it — which is the "trust us" the whole ladder exists to escape.

3. PCR8, from the certificate rather than our word for it. A signed image also reports PCR8, a measurement of the signing certificate. We publish the certificate, not just the number, so you derive PCR8 yourself: SHA-384(48 zero bytes ‖ SHA-384(certificate DER)). Our verifier prefers the value it computed and rejects a cert.json whose stated PCR8 contradicts its own certificate. A dishonest number is caught by arithmetic.

(AWS's own documentation describes PCR8 differently — as a hash of the certificate's "fingerprint" — which does not match their code and yields a different value. We follow the code, and confirmed it against real hardware.)

4. Liveness, if you ask for it. An attestation document with no challenge proves an enclave existed, not that it is the one answering you. Send a nonce; it comes back inside the signed document or the check fails. Our verifier reports fresh: false when no nonce was supplied, so a stale proof can never be presented as a live one.

What it still does not buy

This section is the point of the page. A security claim that only lists what it covers is marketing.

• Model egress is attestation-gated, not invisible. The enclave establishes TLS itself, so neither we nor the parent instance can read a model call — and the measured image refuses to send the prompt anywhere except an attested confidential-inference route (below). But attestation cannot make computation unreadable to the thing computing it: some measured environment always decrypts the prompt to answer it. What this tier changes is that every such environment is now attested and each link verifies the next — not that no environment reads it.
• PCR0 proves the image, not the behaviour. It proves the running code is the code you can rebuild. Whether that code does what we say is what reading it is for; reproducibility makes reading it worthwhile, not unnecessary.
• Metadata remains. Which room is active and when, message sizes and timing — an enclave changes none of it.
• The image is large. Running the existing pipeline means an interpreter, a libc and ~86 MB of dependencies, all measured. The measurement is exactly as sound; the audit is a much bigger job than reading two files. A minimal variant exists for cases where the smaller claim matters more than the existing code.
• Availability is still ours to break. The parent instance can refuse to forward your request. It cannot read it.

Measured, not asserted

On real hardware, 2026-07-29 — and the last row is the one that matters, because it is the product rather than a component of it:

That last line is not a reduced demo. It is the deployed handler, unmodified, with its tools, reached from a phone: the attestation verified in the browser, the room key sealed to a key born inside measured hardware, the reply generated in the enclave, sealed, stored on a parent that cannot open it, and rendered.

The verifier is also exercised against genuine attestation documents from unrelated production enclaves, so it is known to handle real AWS output and not merely our own.

Scale-to-zero — verifiable privacy that costs nothing idle

A confidential enclave used to mean a machine running around the clock — roughly $150 a month, whether or not anyone was in the room. That standing cost is exactly what made hardware-verified privacy expensive to leave running. It is gone.

• Idle → $0. No enclave runs. The Space still opens: its history is served content-blind from sealed storage — the parent hands back ciphertext, your device opens it with mk — so an asleep Space is never a blank one.
• Wake on interaction. Your first message (or approving a draft, or creating an enclave Space) signals a scheduled orchestrator, which launches an instance from a signed template. It self-provisions, pulls its measured image, opens its keys through the PCR8-gated KMS grant, and publishes its endpoint — no SSH, no operator step — in about three minutes. The client shows a "waking…" state and sends your message the moment the enclave attests.
• Re-attest on every launch. Each launch generates a fresh in-enclave recipient key, so the client re-verifies the hardware attestation and re-pins before it seals — a relaunched enclave is proven anew, never assumed.
• Reap when idle. About twenty minutes after the last real interaction the instance terminates itself and clears its endpoint. Passive reading never keeps it alive; only real turns do.

The point is not the saving. It is that leaving the tier available costs nothing when the room is quiet, so an app builder can offer verifiable privacy on any room without a standing bill.

Now switched on — and what is still left

This tier is Production: a Space can run inside an enclave in production today; the app builder enables the enclave per room. The parts that used to be "operational rather than unknown" are done — and worth stating precisely:

• Routing and lifecycle — done, as scale-to-zero. What was one instance started by hand is the on-demand orchestrator above; the published measurement lives at /enclave-claim.json, which the client verifies and pins before sealing.
• Secrets are released only to a measured enclave. Credentials are sealed under a KMS key that refuses to decrypt unless the request carries an attestation matching our signing identity (PCR8). An account administrator is denied. The host holding the IAM role, using the very credentials the enclave uses, is denied. The enclave is allowed. The parent hands over ciphertext and gets back a list of names — never a value.
• Storage is durable and still unreadable. Sealed blobs live in S3. Read back with account-admin credentials, a conversation is an IV, a ciphertext, and one recipient: the room. Not the operator.

What genuinely remains is scope, not mechanism:

• Per-room, by choice — not a platform gap. The platform can run any room in the enclave today; which rooms do is the app builder's per-room choice.
• Audit surface. Running the existing pipeline means an image of ~250 MB rather than the 5.6 MB minimal variant. The measurement is exactly as sound; reading it is a much bigger job.
• The model residual is closed on this tier — with two honest footnotes. The confidential-model axis below is shipped: the prompt reaches only attested environments end-to-end. The footnotes: verification of the model side is transitive (your one PCR check covers the measured code that verifies the gateway, which verifies the GPU workload — not a chip quote delivered to your browser), and nobody in the industry yet attests the model weights themselves ("these exact tensors") — the workload and serving stack are measured, the tensors are vouched.

A Space that runs in an enclave publishes its measurement at /enclave-claim.json, and the deployed web app verifies and pins it before sealing your key. This page now describes a property you can turn on, not only a capability.

The confidential model — closing the last reader (Shipped)

The bullet above used to name the one plaintext reader this tier did not remove: the model vendor. Since 2026-08 it does remove it. The render enclave no longer hands the prompt to a frontier vendor's API — the measured image declares a single model route: an attested, no-log inference gateway into confidential-compute inference on an open-weights model, with a hard floor (min_privacy: confidential) that refuses the request rather than routing it anywhere lesser.

A chain of attested links, each verifying the next. We buy the confidential-inference commodity and keep the verification (the make-or-buy call this axis was always going to face — the runtime is a commodity; the verifying is the product). Concretely: (1) the client verifies the render enclave's Nitro measurement, exactly as above; (2) the render enclave's measured code fetches and cryptographically verifies the gateway's live attestation — a Google Confidential Space document, Intel-TDX-rooted, secure-boot on, debug off, image digest bound to the gateway's open-source release — and refuses to send the prompt if any check fails; (3) the gateway's own measured, open-source code verifies the GPU workload's Intel TDX + NVIDIA confidential-computing evidence against pinned measurements and encrypts the prompt to the measured workload (ML-KEM + AEAD), failing closed. The prompt therefore exists only inside attested environments, end to end. The measured egress firewall makes the route exclusive: the enclave's allow-list — itself inside the measurement — carries the gateway, and the tier's key delivery carries only the gateway credential, so a frontier API is unreachable by construction, not by policy.

Two honest footnotes. First, verification of the model side is transitive: your one PCR check covers the code that verifies the next link, which verifies the next — a real chain of custody, but not a chip quote delivered to your browser (a direct-to-client model-enclave verification, as originally designed here, remains the strongest variant and a compatible upgrade). Second, nobody in the industry yet attests the weights — the machine, the serving stack, and the workload are measured; that the tensors inside are exactly the named model's is vouched by the attested stack, not measured. Both footnotes apply to every confidential-inference offering today, not just ours; we state them because a trust page that doesn't is marketing.

The honest trade — this one costs model quality. A model can only run confidentially if it can run in a TEE you can measure: an open-weights model (DeepSeek, Kimi, Qwen, GLM, gpt-oss and the like), not a frontier vendor's proprietary weights. Turning this axis on trades the frontier model for a confidential one — the tier's create toggle says so in as many words. The builder chooses per room: frontier, but the vendor sees the turn — or open, and every environment that touches the turn is measured. Frontier-confidential waits on a frontier vendor offering attested inference on its own side.

Status: Shipped. The confidential tier runs this route in production today — scale-to-zero render enclave, the attested gateway verified inside the measured image, confidential-compute inference behind the floor. It is the seventh privacy axis in Privacy tiers, and with it the double blind's last standing residual is reduced to the two footnotes above.

Read next: Verify It Yourself for the full ladder of live checks, and The double blind for the model this completes.

Machine-readable source: the-attested-tier.md · Generated 2026-08-29T18:46:30Z · build f3ff88cc · every doc in one fetch: llms-full.txt (HTML) · ← client-architecture · deployment-options →