Confidential Compute for Clinical AI
Why confidential computing matters for clinical AI
Confidential computing protects data in use — during computation — not just at rest (encryption) or in transit (TLS). In a clinical AI context, this means the model training process itself runs inside a hardware-enforced trusted execution environment (TEE) that the hospital infrastructure operator cannot inspect, modify, or exfiltrate data from.
This is critical because the hospital IT administrator is a privileged insider. They have root access to the server. Without confidential computing, they could — intentionally or through compromised credentials — access training data, model weights, or intermediate computation states. The TEE eliminates this trust requirement.
Rapha Protocol TEE architecture
The edge appliance runs three layers of hardware security:
- Intel SGX (Software Guard Extensions) — creates encrypted memory regions (enclaves) that the operating system cannot access. Model code and data processing run inside the enclave. The CPU enforces isolation at the hardware level.
- Intel TDX (Trust Domain Extensions) — extends SGX to full VM-level confidentiality. The entire training VM runs inside a hardware-isolated trust domain.
- TPM 2.0 (Trusted Platform Module) — provides measured boot, platform integrity, and remote attestation. The TPM records every boot component hash, creating a verifiable chain of trust from firmware to application.
Attestation verification flow
Before any model code touches clinical data, the Rapha Network Orchestration Hub verifies:
- SGX/DCAP quote — Intel Data Center Attestation Primitives verify the enclave identity, including MRENCLAVE (code measurement) and MRSIGNER (signer identity).
- TPM quote — platform configuration registers (PCRs) are checked against expected values for the boot chain.
- Intel root CA — the attestation verifier cross-checks the DCAP quote against Intel's published root certificate authority material.
- API key hash — the node's API key SHA-256 must match the expected value registered during node onboarding.
Only when all four checks pass does the attestor sign a proof digest that authorises training and enables settlement through RaphaClearingVault on Polygon mainnet.
Fail-closed design
Every component in the attestation chain fails closed:
- Missing DCAP verifier command → attestation fails.
- Missing TPM verifier command → attestation fails.
- Missing Intel root CA PEM → attestation fails.
- Missing expected MRENCLAVE → attestation fails.
- Missing API key hash → attestation fails.
- Non-SGX hardware → ENOTSUP (no dev fallback, no synthetic quote).
There is no "demo mode" path to production settlement. The clearing vault accepts only proofs signed by a configured trusted attestor after verified hardware evidence.