/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`](../sota-sandboxing/SKILL.md) 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`](rules/01-threat-model-and-selection.md) §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`](../sota-secrets-management/SKILL.md)) already covers you. 2. **Pick the lowest sufficient rung** of the escalation ladder ([`rules/01`](rules/01-threat-model-and-selection.md) §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`](rules/02-tee-technologies.md) §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`](rules/03-remote-attestation.md)): 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`](rules/04-confidential-kubernetes.md) §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`](rules/05-pets-coed.md)): 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`](rules/01-threat-model-and-selection.md) §2, [`rules/02`](rules/02-tee-technologies.md) §6, [`rules/04`](rules/04-confidential-kubernetes.md) §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

**Coverage:** every `rules/` file's Audit checklist applies in AUDIT mode. Mark one *not applicable* only with its reason in the report — never skip a file because the thing it checks for is absent, since that absence may be the finding.

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`](rules/01-threat-model-and-selection.md) §1: attested, hardware-based TEE — or it isn't CC) → walk the attestation chain end to end ([`rules/03`](rules/03-remote-attestation.md): does anything consume the result? debug mode rejected? TCB current? nonce fresh?) → on K8s, verify the layer matches the threat claim ([`rules/04`](rules/04-confidential-kubernetes.md)) → for PETs, verify parameters/libraries/threat models ([`rules/05`](rules/05-pets-coed.md)) → 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 whose threat model excludes the cluster admin); confidential nodes sold as protection against the cluster admin; plain SEV/SEV-ES behind a "protect from the host" claim.

• **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); hand-rolled FHE/ZKP parameters or circuits, or a ZK circuit in production without an independent audit (`05`).

• **Medium** — stale/undocumented side-chann