Research: survey viable TEE/confidential-compute options on Cloudflare Workers/Containers

[JSONbored]

Problem

If #8136 concludes the reproducibility approach doesn't cover the real threat (specifically: verifying a held-out/private corpus's backtest result, which can't be published for a third party to independently re-run), the fallback is real TEE/confidential-compute infrastructure. This issue surveys what's actually viable before any commitment to build it.

Area

Research spike. No code changes expected.

Proposal

• Survey what TEE/attestation options are viable inside this repo's actual deploy targets (Cloudflare Workers/Containers). Provisioning core: create/destroy a tenant's Container + Postgres DB #7180 already contains a research comment surveying Cloudflare Containers vs. microVM isolation tiers for a different purpose (tenant execution sandboxing) — check whether that research transfers here before redoing it from scratch.
• If Cloudflare has no viable confidential-compute option, the alternative is running the attested piece on a different provider entirely — a real infra-split cost (a second cloud account, cross-provider data flow, added operational surface) to weigh explicitly, not a detail to gloss over.
• Produce a short written recommendation: worth pursuing once hosted ORB ships; worth pursuing now; or not worth pursuing given the infra cost relative to the narrow held-out-corpus case it would cover.

Deliverables

• A written recommendation (issue comment or a linked doc) covering the above.

Resources

• Epic: verifiable pre-merge backtest for ORB/AMS deterministic rules #8082 (parent epic), Research: is TEE hardware attestation necessary, or does a reproducible-backtest checksum approach cover the real threat? #8136 (the threat-model conclusion this depends on)
• Provisioning core: create/destroy a tenant's Container + Postgres DB #7180 (existing Cloudflare Containers vs. microVM research, different purpose, possibly transferable)

Boundaries

No production code commitment. No hosted-product architecture decision made here beyond the written recommendation.

maintainer-only — research/strategy, not a build task for contributors.

[linear-code]

JSO-5608

[JSONbored]

Survey + written recommendation (2026-07-22) — with #8136 now concluded ("reproducibility covers today's threat; TEE only matters for the future private-corpus subset"), here is the viability survey that decision defers to.

Cloudflare (this repo's current deploy target): no viable option

• Workers are V8 isolates on shared metal — no TEE, no attestation primitive, and none announced. Nothing to build on.
• Cloudflare Containers (still beta, per the Provisioning core: create/destroy a tenant's Container + Postgres DB #7180 research) are container-tier isolation with no confidential-compute mode and no attestation API. The Provisioning core: create/destroy a tenant's Container + Postgres DB #7180 competitive research already classified them in the weaker shared-kernel tier for sandboxing purposes — they are further still from attested execution.
• Conclusion: if attestation were needed today, it could not run on Cloudflare at all — it would mean the cross-provider infra split this issue flags (second account, cross-provider data flow for D1-resident corpora, new operational surface).

But the calculus changed on 2026-07-21 (#7180's isolation-tier decision)

The tenant-sandbox execution plane is now decided as self-hosted Kata Containers on bare metal, orchestrated by k3s. That matters here because Kata 3.x is also the base of the Confidential Containers (CoCo) project, which provides exactly the missing piece: hardware-attested confidential VMs (AMD SEV-SNP / Intel TDX) with an end-to-end attestation + secret-provisioning flow, running on your own metal under the same k3s runtime-class mechanics — see Kata's own SEV-SNP guide (host kernel ≥ 6.11).

Two real caveats to record now, so they're not rediscovered later:

1. The confidential runtime classes use QEMU/cloud-hypervisor, not Firecracker. Firecracker has no SEV-SNP support — an attested backtest runtime class would sit alongside the Firecracker-backed sandbox classes, not inside them. Kata supports per-runtime-class VMM choice, so this is a configuration split, not a stack replacement.
2. Attestation needs SNP-capable hardware. This is the one actionable-now output of this survey: when the bare-metal purchase for the Provisioning core: create/destroy a tenant's Container + Postgres DB #7180 stack happens, make AMD EPYC with SEV-SNP (Milan or newer) + BIOS/firmware SNP enablement a hard selection criterion. It costs nothing extra at purchase time and keeps the attested-backtest door open with zero infra split; omitting it forces the second-provider path later.

Recommendation

Not worth pursuing now. Advisory-only product, publishable corpora, reproducibility posture already shipped (#8136). No hosted customers exist yet to demand attestation.

When hosted ORB ships private-repo review: the path is CoCo/Kata SEV-SNP as an additional runtime class on the already-decided bare-metal k3s stack — no second cloud, no Cloudflare dependency, and the backtest piece is already provider-agnostic (pure @loopover/engine scoring over an exported corpus manifest; the CI scripts run anywhere Node runs).

Do now (single item): carry the SNP-capable-CPU criterion into the #7180 hardware purchase.

Sources: Confidential Containers overview, Kata Containers SEV-SNP how-to, Kata + CoCo zero-trust blog.

[JSONbored]

Closing as answered — survey + recommendation above: no Cloudflare option exists; the #7180 Kata/k3s bare-metal decision makes CoCo SEV-SNP the zero-infra-split future path; not worth pursuing until hosted ORB reviews private repos. The one actionable item (SNP-capable CPUs as a hardware-purchase criterion) is recorded on #7180's stack decision context.