Fortanix Confidential AI vs. Opaque Systems vs. Anjuna: Choosing a Confidential Computing Platform for Private LLM Inference

Fortanix's technical materials describe composite attestation as the core mechanism: before an AI workload touches sensitive data, its Confidential Computing Manager verifies that GPU firmware, drivers, and the full software stack match approved measurements across both the CPU TEE (Intel TDX, SGX, or AMD SEV-SNP) and the GPU TEE (NVIDIA Hopper or Blackwell) before its Data Security Manager releases the decryption keys. That composite step, chaining CPU and GPU attestation together into one trust decision, is the part that is genuinely Fortanix engineering rather than a restatement of what the underlying chips already do. Fortanix positions Confidential AI for both training and inference, which is a broader claim than the other two vendors make and one worth verifying against your specific workload during a proof of concept, since training and inference have different memory, throughput, and multi-party key-release requirements.

Opaque Systems has the most academically documented origin of the three. Its confidential computing framework was designed and built by the RISELab team at UC Berkeley to run Apache Spark SQL on Intel SGX, giving it a research pedigree specifically in confidential data processing rather than starting from general-purpose confidential computing and adding a data layer later. Opaque's own documentation describes remote attestation as a cryptographic handshake verifying every component is running expected code on genuine confidential hardware, and its LLM inference offering is built to let an organization query a model while both the query content and any response stay unreadable to the model or service provider. Because Opaque's roots are in confidential analytics rather than general enclave hosting, its LLM inference product is an extension of that data-processing lineage; teams should confirm during evaluation how much of that Spark-era engineering (query planning, join optimization inside the enclave) actually carries over to transformer inference versus how much of the LLM-specific offering is newer.

Anjuna's core product has historically been a confidential computing enablement platform built around lift-and-shift: taking an existing, unmodified application and running it inside a TEE with encrypted memory, storage, and networking, without requiring the application to be rewritten for confidentiality. That general-purpose approach is genuinely differentiated for workloads where rewriting is impractical. Its extension into AI, branded Anjuna Seaglass, adds NVIDIA GPU confidential computing support (Hopper and Blackwell) on top of that same enablement model, plus built-in attestation that verifies enclave code has not been tampered with before secrets are released. For LLM inference specifically, this means Anjuna's story is largely "apply our proven general-purpose TEE enablement pattern to an inference server," which is a reasonable extrapolation of a mature core product but is a newer, less field-proven application of it than the lift-and-shift use cases Anjuna has supported for longer.

Fortanix Confidential AI is delivered as part of Fortanix's broader Confidential Computing Manager and Data Security Manager stack, meaning key management and attestation policy are centralized in a control plane that spans CPU and GPU TEEs across a workload's lifecycle. That fits an organization that wants one policy engine governing multiple confidential workloads, not just LLM inference in isolation.

Opaque Systems is delivered as a confidential AI platform with cloud marketplace availability (Opaque has published its platform on Azure Marketplace), oriented toward teams that want a managed service for confidential data processing and LLM inference rather than assembling TEE infrastructure themselves.

Anjuna is delivered as an enablement layer that sits underneath your own applications and inference servers, automating enclave deployment (Anjuna Confidential Containers) and attestation rather than providing a data-processing or query product of its own. That makes Anjuna closer to infrastructure than to an application-layer AI product: you are still responsible for the inference server and model serving stack, and Anjuna's job is making sure it runs inside a verified TEE.

All three integrate with the two major CPU TEE vendors (Intel and AMD) and, for AI-specific workloads, NVIDIA's confidential computing GPU line, so at the silicon layer there is real overlap. Fortanix's public materials specifically describe attestation support spanning Intel TDX, AMD SEV-SNP, and NVIDIA Hopper/Blackwell GPUs (H100, H200, RTX Pro 6000, B200, B300) under one control plane, the broadest explicit GPU list of the three as documented.

Opaque's integration story centers on data and analytics tooling given its Spark lineage; it supports Python and Spark-based pipelines and has extended that to ML pipelines, which matters most for a team whose sensitive data already lives in a Spark-adjacent analytics stack rather than a team starting from a plain inference API.

Anjuna's integration advantage is breadth at the infrastructure level rather than depth at the AI-tooling level: because it targets unmodified applications, it can in principle host any inference server or framework a team already runs, and it has added confidential container support on Google Cloud alongside AWS and Azure coverage. Confirm the exact list of supported cloud regions and instance types for confidential GPU availability directly with each vendor, since NVIDIA confidential computing GPU availability varies by cloud provider and region and changes as capacity is added.

Fortanix's composite attestation and automatic key release are designed to minimize per-workload effort once the Confidential Computing Manager and Data Security Manager are deployed, but standing up that control plane is itself a non-trivial infrastructure project, particularly for a team with no existing Fortanix key management footprint.

Opaque's managed platform model (including Azure Marketplace availability) is the lowest-effort path of the three for a team that wants confidential LLM inference as a service rather than infrastructure it operates itself, at the cost of less control over the underlying TEE configuration.

Anjuna's lift-and-shift pitch is specifically that it minimizes application-level rewrite effort, which is real for workloads that already run as a standard containerized service. The tradeoff is that a team adopting Anjuna is still responsible for everything above the enclave boundary (the inference server, model serving framework, and key release logic specific to their own workload), so the operational effort shifts from "rewrite the application" to "integrate your own key management and attestation verification logic with Anjuna's enclave runtime," which is a different kind of work, not necessarily less of it.

None of the three vendors publish list pricing for confidential AI inference specifically. All three sell through direct sales engagement with custom quotes scoped to workload volume, GPU instance type, and cloud provider, since confidential computing GPU instances (NVIDIA H100/H200/Blackwell in confidential mode) themselves carry a different, and generally higher, cloud provider price than standard instances, on top of whatever each vendor charges for its software layer. Treat any number a sales conversation gives you as a quote for your specific deal and your specific cloud provider's confidential instance pricing, not as a published market rate, since none of these figures are independently available for comparison. Budget time and cloud spend for a proof of concept on real confidential GPU instances as a required step in any of these evaluations.

Fortanix Confidential AI. Strength: the broadest explicitly documented composite attestation chain across both CPU and GPU TEEs, and a control plane built to govern confidential workloads beyond just LLM inference (training included), which suits an organization consolidating confidential computing policy across multiple use cases. Limit: that breadth means you are adopting a general confidential computing platform to get LLM inference protection, which is more infrastructure than a team that only needs private inference for one application may want to operate.

Opaque Systems. Strength: the deepest research pedigree in confidential data processing specifically (RISELab's Spark-on-SGX work), a managed platform option through cloud marketplace listings, and a security claim scoped clearly to keeping queries and data invisible to the model or service provider. Limit: its core engineering strength is in confidential analytics; how much of that translates into LLM-inference-specific performance and correctness at transformer scale, versus the Spark-era query engine, is not fully detailed in public materials and should be tested directly against your own model and query patterns.

Anjuna. Strength: the most mature and field-proven general-purpose confidential computing enablement pattern of the three, with attestation and enclave automation built for lift-and-shift of unmodified applications across AWS, Azure, and Google Cloud. Limit: its LLM-inference-specific offering (Anjuna Seaglass, built on NVIDIA GPU confidential computing) is a newer extension of that older core product; the underlying enablement pattern is proven, but its specific application to LLM inference workloads has a shorter public track record than Anjuna's general-purpose TEE hosting.

There is no universal winner here; the right choice tracks your architecture, your existing infrastructure, and what exactly you are trying to protect.

A team already running (or planning to run) multiple confidential computing workloads beyond just LLM inference, especially spanning both training and inference, and that wants one attestation and key management control plane across CPU and GPU TEEs is the clearest fit for Fortanix. Its composite attestation model is built for exactly this kind of consolidated governance.

A team whose sensitive data already lives in a Spark-based analytics pipeline, or that wants confidential LLM inference delivered as a managed platform rather than infrastructure it operates itself, and whose primary requirement is that queries and data stay invisible to the model provider fits Opaque Systems best. Its cloud marketplace availability lowers the barrier for a team that does not want to run its own TEE infrastructure.

A team with an existing unmodified inference server or application it needs to protect without a rewrite, that already operates across multiple cloud providers, and that values a proven general-purpose confidential computing pattern over an AI-native product fits Anjuna best, with the caveat that its specific LLM inference extension is newer than its core lift-and-shift platform.

A team whose primary driver is a specific regulatory or contractual requirement (a customer clause, a sector-specific mandate, or an internal policy naming confidential computing explicitly) rather than a fully scoped architecture should treat vendor selection as secondary to defining exactly what the requirement demands (what must be attested, to whom, and at what data volume) before running a proof of concept with any of the three.

Skip all three for now if your organization has not identified a specific, named threat model that non-confidential deployment does not already address. If your actual concern is standard access control and encryption-at-rest/in-transit against external attackers, standard cloud security controls may already cover it; confidential computing specifically addresses insider access and cloud-provider-operator access, and if that is not your threat model, the added cost and operational complexity of any of these three platforms is not buying you anything.

Also hold off if your compliance or customer requirement can be satisfied with contractual controls (a data processing agreement, a business associate agreement, or a customer's own attestation of controls) rather than technical enforcement. Confidential computing is the right tool when you specifically cannot or will not extend that trust contractually, for example when using a third-party LLM API on data a contract cannot cover, or when a regulator or auditor requires technical proof rather than a promise. And do not adopt any of the three based solely on the phrase "confidential computing" in a vendor's marketing without confirming which TEE is actually doing the isolation work underneath, since that silicon, not the vendor's software, is what carries the real security guarantee and the real attack surface described below.

Remote attestation is the mechanism that turns "confidential computing" from a marketing phrase into an enforceable security property, and every vendor evaluation should start by asking exactly what gets attested, by whom, and what happens if attestation fails. In practice, attestation is a cryptographic proof, signed by the TEE hardware itself (Intel, AMD, or NVIDIA's attestation infrastructure), that a specific enclave is running specific, unmodified code, measured against a known-good hash, before any secret (a decryption key, model weights, or a customer's data) is released to it. Fortanix describes this as composite attestation spanning CPU and GPU measurements before its key management service releases keys; Opaque describes it as a cryptographic handshake verifying expected code on genuine hardware; Anjuna describes it as built-in verification that enclave code has not been tampered with before secrets are transferred in.

The critical distinction for a security or compliance team is this: attestation proves the code running inside the enclave matches an expected measurement, and that the enclave is genuine silicon from the TEE vendor. It does not by itself prove that expected code is free of vulnerabilities, that the vendor's key release policy is configured correctly, or that the surrounding infrastructure (the orchestrator deciding which measurements count as "approved," the network path data takes before it reaches the enclave) is trustworthy. A security team evaluating any of these three vendors should ask, in writing: what exactly is measured and attested (the base enclave runtime only, or the full application and model-serving stack), who signs the attestation (the vendor, the cloud provider, or the chip vendor directly), what happens to in-flight requests if attestation fails or a measurement changes after a patch, and whether the attestation report is independently verifiable by the customer or only by the vendor's own service. If a vendor cannot answer these specifically for their product, that is a gap worth pressing on before a proof of concept, not after.

TEE-based confidential computing is a genuine improvement over software-only isolation, which relies on a hypervisor or operating system correctly enforcing boundaries that a privileged insider or a compromised host can bypass entirely. A TEE keeps memory encrypted and isolated even from a privileged host operator, which is the property none of these three vendors' software could deliver on its own without the underlying silicon.

But TEEs are not an unconditional guarantee, and the honest version of this comparison has to include their attack history. Foreshadow, disclosed in 2018, showed that speculative execution could be exploited to read SGX-protected memory and extract SGX's own attestation key, undermining the trust chain at its root. CipherLeaks, disclosed in 2021, showed that AMD SEV's ciphertext side channel could break constant-time cryptographic implementations running inside an SEV-protected VM. More recently, CounterSEVeillance (2025) demonstrated that performance counter events observable from the hypervisor could leak information out of SEV-SNP confidential VMs, and TEE.Fail (2025) demonstrated a physical side-channel attack against DDR5 memory that extracted secrets, including attestation keys, from Intel SGX, Intel TDX, and AMD SEV-SNP with Ciphertext Hiding enabled, on fully patched systems. These are not obscure or theoretical results; they are peer-reviewed or widely reported attacks against the exact TEE technologies underlying all three vendors in this comparison.

This history does not mean confidential computing is not worth adopting. It means a security team should treat any vendor's confidential computing claim as inheriting the current attack surface of its underlying silicon, not as a vendor-specific guarantee, and should ask each of Fortanix, Opaque, and Anjuna directly: which specific TEE generations and firmware versions do you support, what is your patch and re-attestation process when a new side-channel disclosure affects that silicon, and do you support the newer mitigations (such as ciphertext hiding on SEV-SNP) that reduce, though do not eliminate, exposure to these attack classes. None of these three vendors' public marketing pages are the right place to get a full, current answer to that question; it needs to be part of a direct vendor conversation and revisited on a recurring basis as new research is published.

Before signing with any of the three, validate the following against your own environment and threat model rather than a vendor demo:

1. Confirm the exact TEE generation and cloud provider region you will actually deploy on (Intel TDX vs. SGX, AMD SEV-SNP with or without Ciphertext Hiding, and which NVIDIA confidential GPU generation), since security posture and attack surface differ by generation, not just by vendor.
2. Request the vendor's specific attestation flow in writing: what is measured, who signs the attestation report, and whether you (the customer) can independently verify the report rather than trusting the vendor's own attestation service.
3. Run inference on a real, representative workload (your actual model size and a realistic prompt/response volume) and measure the latency and throughput overhead of confidential mode against a non-confidential baseline in the same cloud region, since public marketing does not publish comparable performance numbers across all three vendors.
4. Ask each vendor directly how they handle a disclosed side-channel vulnerability affecting their underlying TEE: patch timeline, whether re-attestation is forced automatically, and how customers are notified.
5. Test what happens to an in-flight request when attestation fails or a measurement mismatch is detected, both to confirm the failure mode is closed (data is not released) and to understand the operational impact of a false positive.
6. Confirm exactly what is and is not protected: prompts, model weights, outputs, and any intermediate state such as cached key-value attention data, since a vendor's marketing claim about "protecting AI workloads" can mean different scopes across these three products.
7. Get a written quote scoped to your actual confidential GPU instance requirements and expected volume, and confirm separately what the underlying cloud provider charges for the confidential instance type itself, since that cost is independent of and additive to the vendor's own pricing.