The phrase "confidential computing" gets used loosely. Marketing teams attach it to anything that encrypts data at some point in a pipeline. The actual technical definition is narrower and considerably more useful: confidential computing refers to hardware mechanisms that protect data while it is being computed on — not just at rest on a disk or in transit over a network. That "in use" protection is what makes it relevant to regulated AI workloads, and it is worth understanding the mechanism precisely before deciding whether it applies to your situation.
The Three States of Data — and Why "In Use" Has Been the Problem
Security practitioners have long operated with a mental model of data in three states: at rest, in transit, and in use. Encryption at rest is well-solved — full-disk encryption, database-level encryption, encrypted object storage. Encryption in transit is equally mature — TLS 1.3 handles this for almost every network layer. The third state, data in use during computation, had no satisfactory answer until hardware TEE (Trusted Execution Environment) technology matured commercially in the 2020s.
The core problem: a process running on a conventional CPU operates in memory that the operating system kernel, the hypervisor, and the cloud provider's management plane can all inspect. For most workloads that is an acceptable assumption. For a workload processing live patient records or active credit files, that assumption is exactly what a compliance officer objects to. Encryption at rest does not help when the data must be decrypted to run inference. And TLS ends at the boundary of the process — once data reaches the model, it is in cleartext in memory accessible to the host OS.
Confidential computing hardware changes this by creating a protected memory region — an enclave — where the CPU itself enforces that no outside entity, including the host OS, hypervisor, or system administrator, can read the region's contents. The data decrypts inside the enclave and is re-encrypted before it ever leaves.
What a Hardware Enclave Actually Does
Two mainstream hardware implementations exist today: Intel TDX (Trust Domain Extensions) and AMD SEV-SNP (Secure Encrypted Virtualization with Secure Nested Paging). Both achieve similar goals through somewhat different mechanisms, but the effect is comparable: a hardware-enforced memory boundary that even a privileged process on the same physical machine cannot cross.
At a high level, when an enclave launches: the CPU measures the workload — computes a cryptographic hash of the code and initial data loaded into the protected region. This measurement is called the MRENCLAVE in Intel terminology, or the launch digest in AMD's model. Any modification to the workload after measurement would produce a different hash. The CPU then generates an attestation report — a signed statement from the CPU firmware asserting "this specific code measurement is running inside a genuine hardware-protected region." That report can be verified by any external party with access to the CPU vendor's certificate chain.
What this means in practice: before your data enters an enclave, you can verify that the code running inside matches an approved measurement hash. The data then decrypts inside the boundary and the result exits — still encrypted — with an attestation receipt that proves which exact code version processed it. No trust in the cloud provider's infrastructure is required beyond the CPU hardware itself.
Attestation: The Part That Matters for Compliance
For regulated industries, attestation is arguably more valuable than the isolation itself. Isolation prevents access. Attestation creates a cryptographically verifiable audit record proving what code ran, when, on what data, producing what output.
A compliance officer reviewing an AI pipeline for APPI or FISC alignment does not simply want to know that data was protected. They want evidence they can present in an audit — evidence that is tamper-evident and independently verifiable. A signed attestation report, timestamped and tied to a specific measurement hash, is closer to a hardware HSM audit trail than to a policy statement. It answers the question "what code touched this data?" with a cryptographic proof rather than an assertion.
This distinction matters because the alternative — contractual assurances from a cloud provider — relies on the provider being truthful and their internal controls being correctly implemented. That is not a bad control, but it is a trust-based one. Attestation is a verification-based one.
What Confidential Computing Does Not Cover
It is worth being direct about the limits here. We are not saying confidential computing solves all security problems in an AI pipeline — it does not. An enclave protects the boundary of the executing workload. It does not protect against a vulnerability in the code inside the enclave itself. If the model or inference logic has a prompt injection flaw, a confidential enclave does not remediate that. If the input pipeline delivers malformed data that triggers memory corruption inside the enclave, hardware memory isolation does not inherently prevent that class of attack.
Confidential computing is specifically a solution to one well-defined problem: preventing the host execution environment from accessing data being processed. It is the right tool for regulated workloads where the primary compliance constraint is "we cannot allow the cloud provider or system administrator visibility into live sensitive data during computation." It is not a substitute for application-level security, supply-chain integrity, or model validation.
A Plausible Scenario: AI Inference on Transaction Records
Consider a growing regional bank piloting an anomaly-detection model that needs to run inference on live transaction records — same-day data, not a sanitized export. The compliance team's objection is straightforward: running that workload on a public cloud means the provider's infrastructure has visibility into transaction data during processing. Even with customer contracts and data processing agreements in place, that crosses the threshold the FISC compliance officer has drawn.
With an enclave-based pipeline, the architecture changes: the inference workload is packaged and measured before deployment. The measurement hash is registered with the compliance team. Before each inference run, the attestation report is verified — the code running inside matches the approved hash. Transaction records enter the enclave encrypted, decrypt only inside the hardware-protected region, and the inference result exits with an attached attestation receipt. The cloud provider's infrastructure handles scheduling and networking but has no pathway to the data during computation.
The compliance team can now review the attestation log: timestamp, measurement hash matching approved build, input data fingerprint, output hash. That is an audit trail a FISC review can engage with. The pilot approval conversation moves from "can we trust this cloud provider?" to "can we verify the code that ran?" — a question confidential computing is designed to answer.
The Infrastructure Gap Confidential Computing Fills
Regulated industries have been stuck in a pattern: either they run AI on sanitized, de-identified, or synthetic data that loses the signal that makes the model useful, or they run it on a private data center they fully control — expensive and slow to scale. Confidential computing opens a third path: public or hybrid cloud infrastructure where the sensitive computation happens inside a verified hardware boundary the data does not leave.
This is not hypothetical. Intel TDX is available on major cloud providers. AMD SEV-SNP has broad hypervisor support. AWS Nitro Enclaves offer a similar isolation primitive. The hardware layer exists. What has been missing is the tooling, attestation integration, and compliance-mapping layer that lets a regulated-industry team actually deploy into it without building that infrastructure themselves.
That is the gap Almure works in — not the hardware (that's Intel and AMD's work), but the enclave runtime, the attestation service, and the key management layer that together make a confidential-computing infrastructure production-ready for a compliance-constrained engineering team. The three layers are interconnected: isolation alone is not enough without verifiable attestation, and attestation without sealed key lifecycle management creates a different class of exposure. The full stack matters.