sota-confidential-computinglisted

# 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