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 by a verified chain, with two footnotes. The confidential-model axis below is shipped: the prompt leaves the measured image only through a gateway whose attestation our measured code verifies, and that gateway's own measured code verifies the model enclave's attestation before forwarding — fail-closed, and our measured code checks the gateway's signed receipt for every call. What remains is transitive trust and unattested weights; the section below names both.

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.

What is verified, link by link. 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 a published commit of the gateway's open-source release — and refuses to send the prompt if any check fails; (3) the gateway's measured code — the same bytes the digest in (2) commits to — verifies the model enclave before a byte of prompt leaves it: for Tinfoil-hosted models it fetches the SEV-SNP report, runs the AMD certificate chain and the Sigstore-signed code measurement, and pins the TLS session to the public key the report committed to (two independent derivations must agree; mismatch refuses; there is no unpinned fallback); for the TDX-hosted providers it verifies the Intel TDX quote and NVIDIA GPU evidence against pinned measurements and encrypts end-to-end to the verified instance's key. min_privacy: confidential is the routing floor that keeps the request inside that set; the verification is what makes the set mean something. 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.

Why link (3) is verifiable and not "trust us." Because the gateway is attested and its image digest is bound to a published commit, what it does per request is a matter of reading that commit's source — not of believing a policy page. We read it (the attested gateway repository, not the control plane, which is a separate codebase): the verification above is in the prompt path, per provider, with the result carried into a signed per-turn inference receipt — upstream.tier: tee-verified plus the verification policy and its validity window — signed by a key the gateway publishes under its own attestation. One correction on the record: an earlier revision of this page said the opposite, that the gateway treated the floor as a catalogue filter with no upstream check. That was read from the control-plane repository, not the attested one, and it was wrong. This page now says what the measured code does.

The per-turn check, now shipped. Verifying the gateway's attestation says who we are talking to; it does not by itself say what the gateway did with this request. So for every model call — the main turn and every helper call (titles, summaries, captions, reply decisions) alike — our measured code sends a fresh nonce and requires the gateway's signed inference receipt back: a signature under the instance key whose commitment is bound into the gateway's attestation, over the exact request bytes we sent and the exact response events we received, echoing our nonce, and stating the upstream verdict. The turn is refused unless that verdict is tee-verified under a policy on our allow-list — one of the three verifier paths named above — with the receipt inside its verification window. Any other outcome (a plain-TLS upstream, a policy we have not audited, a missing or unbound receipt) fails the call closed; the answer is discarded, never surfaced. An earlier revision of this page noted that the helper calls carried neither the floor nor this check; that gap was found by reading receipts and is closed by the same change.

Two further footnotes. First, this verification 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 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 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, the model enclave verified inside the measured gateway, confidential-compute inference behind the floor. It is the seventh privacy axis in Privacy tiers. The double blind's remaining residuals are the two footnotes.

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-09-13T10:04:40Z · build 9420f570 · every doc in one fetch: llms-full.txt (HTML) · ← client-architecture · deployment-options →