/sota-confidential-computing

name: sota-confidential-computing
description: >-
  State-of-the-art confidential computing and cryptographic PETs (2026) for
  BUILDING and AUDITING systems that protect workloads and data in use from
  the infrastructure they run on — the inverse of sandboxing. Covers TEE
  selection (AMD SEV-SNP, Intel TDX, ARM CCA realms, SGX enclaves, AWS Nitro
  Enclaves, NVIDIA confidential GPUs), memory encryption vs attested isolation
  (TME/TME-MK/MKTME), remote attestation (RATS RFC 9334, evidence appraisal,
  attest-then-release, RA-TLS, TCB recovery), confidential VMs/nodes/pods on
  Kubernetes (Confidential Containers/CoCo, Kata, Trustee KBS), and computing
  on encrypted data without hardware trust — FHE, MPC/threshold, ZKP,
  PSI/OPRF. Trigger keywords: confidential computing, TEE, enclave, SEV-SNP,
  TDX, ARM CCA, SGX, Nitro Enclaves, confidential VM, remote attestation,
  attestation report, KBS, CoCo, Kata, Trustee, MKTME, confidential GPU, FHE,
  homomorphic encryption, MPC, ZKP, zero-knowledge, PSI, data in use, COED.

SOTA Confidential Computing & PETs

Purpose

Engineer and audit systems where the *infrastructure itself* is the adversary: the cloud operator, the hypervisor, the node admin, a co-tenant, or anyone with physical access to memory. Two tool families, one skill: hardware TEEs with remote attestation (trust silicon + verify it), and cryptographic PETs that compute on encrypted data (trust only math, pay orders of magnitude for it). The boundary with `sota-sandboxing` is direction: sandboxing protects the host from the workload; this skill protects the workload from the host. Both can apply to the same system.

Two modes. Pick one explicitly at the start of the task.

---

BUILD mode

Use when designing or implementing confidentiality-in-use for new or changed systems.

1. **Name the adversary first** (`rules/01` §2, §7): operator, hypervisor, co-tenant, physical, or "the other party in a joint computation". If no adversary survives scrutiny, stop — TLS + at-rest encryption + KMS custody (`sota-secrets-management`) already covers you. 2. **Pick the lowest sufficient rung** of the escalation ladder (`rules/01` §4): transport/at-rest → HSM/KMS → confidential VM → process enclave → PET. Write the rung and its rationale into the design doc. 3. **Choose the TEE technology** from the selection table (`rules/02` §7) by workload shape (lift-and-shift VM, container, process, GPU inference) — using the latest stable platform generation; verify current provider support at design time. 4. **Design attestation before deployment** (`rules/03`): what evidence, who verifies (hosted vs self-hosted), what policy, and — decisive — what the attestation result *gates* (key release, secret injection, channel establishment). Attestation that gates nothing is decoration. 5. **On Kubernetes**, pick the layer deliberately (`rules/04` §1, §6): confidential nodes (operator excluded, cluster admin not) vs confidential pods/CoCo (both excluded); route secrets through attest-then-release (KBS), not K8s Secrets; plan the degraded debugging story up front. 6. **If hardware trust is unacceptable**, triage PETs (`rules/05`): most "we need FHE" asks are a TEE or differential-privacy problem in disguise; when a PET is right, use standard parameter sets and vetted libraries (latest stable) only. 7. **Document the honest limits** (`rules/01` §2, `rules/02` §6, `rules/04` §7): side channels, availability (never protected — the host can always kill you), and the TEE vendor in the TCB.

Deliverables: named adversary + chosen rung, TEE/PET selection with rationale, the attestation flow diagram (RATS roles) and what it gates, verification policy (debug-mode rejection, TCB handling, freshness), and the residual-risk list.

AUDIT mode

Use when reviewing systems that claim confidential computing, or that should.

Procedure: inventory data-in-use exposure (what runs where, who operates it) → check claims against the definition (`rules/01` §1: attested, hardware-based TEE — or it isn't CC) → walk the attestation chain end to end (`rules/03`: does anything consume the result? debug mode rejected? TCB current? nonce fresh?) → on K8s, verify the layer matches the threat claim (`rules/04`) → for PETs, verify parameters/libraries/threat models (`rules/05`) → run every loaded rules file's audit checklist.

**Severity conventions**

• **Critical** — "confidential" claim with no attestation or attestation that

gates nothing; debug-mode TEE accepted in prod; secrets delivered via a channel the excluded party controls (e.g. K8s Secrets to a CoCo pod); hand-rolled FHE/ZKP parameters or circuits.

• **High** — plain SEV/SEV-ES where SNP-class integrity is required; evidence

verified without chain-to-vendor-root or TCB check; no re-attestation or reference-value rotation plan (TCB recovery will break prod); confidential nodes sold as protection against the cluster admin.

• **Medium** — stale/undocumented side-channel posture (SMT, ciphertext side

channels); attestation results not monitored as security signals; missing in-guest storage encryption for confidential pods.

• **Low** — hygiene: undocumented residual risks, missing break-glass debug

policy, PET performance assumptions unbenchmarked.

**Finding format**: `file:line | rule | severity | effort | fix` (canonical cross-domain format from the router).

---

Rules index

| File | Read this when... | |---|---| | `rules/01-threat-model-and-selection.md` | deciding whether confidential computing is warranted at all: the CCC definition test (memory encryption alone ≠ CC), what CC does/never protects against, inverse-of-sandboxing framing, the five-rung escalation ladder, legitimate drivers, anti-patterns, adversary→mechanism decision table. Read first in every engagement. | | `rules/02-tee-technologies.md` | choosing or judging TEE hardware: SEV→SEV-ES→SEV-SNP insufficiency ladder, TDX on