Threat model

This page describes what Shroud protects against, what it explicitly does not, and the assumptions you accept when you use the Cocoon SDK. Read it before claiming the privacy posture in production — attestation gives you cryptographic answers to specific questions, not blanket guarantees.

In scope

The following attacks are mitigated and the SDK lets you verify the mitigation cryptographically.

Threat

Mitigation

Verifier

Platform operator reads prompts or completions

End-to-end ECDH + AES-256-GCM session, neither TEE reveals plaintext to the gateway

The encrypted-blobs row in What the Gateway Can See

Operator silently swaps cocoon-bridge for an instrumented build

Per-session bridge attestation: image hash recomputed from the TDX measurement registers, checked against the SDK allowlist

Verification paths — Path 1

Operator silently swaps cocoon-proxy for an instrumented build

cocoon-bridge refuses to start unless the proxy quote matches TDX_ALLOWED_IMAGE_HASHES; the proxy quote is also exposed to the SDK for independent verification

Verification paths — Path 4

Operator forges a TDX quote without TDX hardware

Intel DCAP signature verification chains both quotes to the Intel-rooted TDX cert tree (TDX_VERIFICATION_MODE=dcap in production)

How attestation works — Step 4

Operator binds an attacker-controlled key to a real bridge quote

report_data == SHA-512(tee_session_pubkey) is verified on the bridge quote before any key is used

How attestation works — Step 4

Network observer reads the inference traffic

Per-session AES-256-GCM with random 12-byte nonces; TLS to the gateway on top

Wire protocol

Replay of a captured ciphertext

Random nonce per message; session key is per-WebSocket and not reused

Wire protocol

Operator inflates billing by claiming token counts the model didn't actually emit

TEE signs the usage report with its session-bound private key; the SDK exposes verified for callers

Selective Disclosure / Usage Attestation in Cocoon overview

TEE binary substitution between releases (either component)

Reproducible build of open-source repos; anyone can rederive the published hash for either TEE

How attestation works — Step 3

Both TEE attestations contribute to these mitigations. The default SDK path verifies the bridge quote and takes the proxy quote on transitive trust; the optional proxy-side verification (Path 4) turns that transitive step into an independent check.

Out of scope

These threats are not covered. If they're in your model, Shroud alone is not sufficient.

  • Hardware-level break of Intel TDX. A demonstrated compromise of TDX (microcode bug, side-channel that exfiltrates TEE memory, Intel root key compromise) breaks every guarantee on this page. Shroud has no defence-in-depth against a TDX root-of-trust failure.

  • TEE side-channel attacks. TDX is not constant-time for every workload; sufficiently sophisticated cache, branch-predictor, or DRAM side channels could leak information about the prompts or responses to a co-resident attacker. We don't claim coverage here.

  • Prompt extraction by an actively malicious model. Attestation proves which cocoon-bridge binary terminates the session, not that the model downstream is honest. A weights file that exfiltrates prompts in its outputs (e.g. by encoding them in responses) is undetectable from the SDK side. Run only models you trust.

  • Supply-chain attacks on the SDK or the build host. A compromised npm/Go module registry, a compromised developer laptop, or a malicious dependency in cocoon-bridge itself can invalidate the chain before any TEE is involved. Use lockfiles, audit dependencies, and reproduce builds.

  • Caller-side plaintext leakage. Anything you do with prompts or completions on your own device — logging, telemetry, RAG indexing, caching — is your responsibility. Shroud's TEE protects data in transit and during inference, not at rest on your machine.

  • Coercion or compelled disclosure of the SDK's attestation policy. The image-hash allowlist is data on the caller's machine. An attacker who can rewrite that data can broaden what the SDK accepts. Pinning a custom allowlist (Path 2 in Verification paths) and protecting the caller's runtime are both your job.

  • Denial-of-service. A platform operator can refuse to serve your requests, degrade them, or rate-limit them. Attestation does not give you availability — it gives you confidentiality conditional on a successful response.

  • Metadata visible to the gateway. Even with E2E encryption, the gateway sees: model name, token counts (signed by the TEE), session pubkeys, encrypted-blob sizes, request timings, and your API key. See the What the Gateway Can See table for the complete list. If your threat model treats any of these as sensitive, additional measures (cover traffic, padding, separate API keys per workload) are on you.

Assumptions you accept

By using the Cocoon SDK with attestation enabled, you are trusting:

  1. Intel as the TDX root of trust for hardware integrity and quote signing on both TEEs.

  2. The published source code of both TEEs — cocoon-bridge and the Cocoon proxy — to faithfully implement the protocol described in How attestation works. You can verify either or both by reading the source and reproducing the build (Path 3) and by checking the proxy quote independently (Path 4).

  3. Your own SDK install — that the package you installed is the one published, not a tampered copy. Lockfiles and registry integrity checks are the standard mitigations.

  4. Your operating environment to not be actively malicious in ways that subvert the SDK before it runs (e.g. a compromised process injecting code into your application).

You are not required to trust:

  • The Shroud gateway. It runs outside any TEE and is treated as an untrusted cache for attestation artifacts. Every cryptographic check happens between the SDK and the TEE; the gateway can drop, delay, or reorder traffic but cannot read or forge it.

  • Any third-party transparency log or attestation service. Shroud doesn't depend on one — the source is open and the build is deterministic, so there's no hash-only artifact you'd want a third party to log.

Production checklist

Before declaring a deployment "confidential":

  • The deployment runs cocoon-bridge with TDX_VERIFICATION_MODE=dcap and a non-empty TDX_ALLOWED_IMAGE_HASHES. (This is a cocoon-bridge env var, not an SDK setting.)

  • Your client uses the default AttestationPolicy or a custom policy with at least one bridge hash (and ideally a proxy hash) you've reviewed. Never null. For high-assurance environments, pin both hashes explicitly and re-verify the proxy quote on each session (Path 4).

  • Your code reads usage.verified (or Stream.Usage().Verified in Go) on every inference response and surfaces failures.

  • You've reviewed the model you're calling and accept that attestation does not bound model behaviour.

  • You've considered whether the metadata visible to the gateway is acceptable for your workload.

  • You have a process for accepting new image hashes when either TEE releases — review the diff between releases and optionally reproduce the build before broadening the allowlist.

Last modified: 08 May 2026
Verification pathsCocoon Wire Protocol