# Confidential Computing

Using someone else's infrastructure means trusting someone else's administrators. Most cloud providers answer that with operational assurance: contracts, audits, certifications, and administrative controls. These are necessary, but they depend on trust in the provider, who ultimately controls the infrastructure and often holds the encryption keys. That leaves a residual risk that data can be accessed through internal privilege, misconfiguration, or legal compulsion such as the U.S. CLOUD Act.

This is not a hypothetical risk. In September 2026, after OpenAI announced a solution to the Navier–Stokes problem, two mathematicians who had been drafting their own proof in OpenAI's Codex asked whether their sessions had contributed to the result. The company responded that it could not rule out that de-identified data derived from their use of its products had helped improve its models (CNBC, Wikipedia). In 2023, Samsung banned generative AI tools company-wide after engineers pasted proprietary source code and meeting notes into ChatGPT (Bloomberg). In 2025, Anthropic changed its consumer terms so that chats and coding sessions are used for training unless the user opts out, with retention extended to five years (Anthropic). In each case the only thing standing between a customer's data and the provider's models was the provider's own policy at the time.

PHOENIQS takes a different approach: technical assurance. Cryptographic and hardware-enforced controls make access to plaintext data technically infeasible, even for our own administrators, and let you verify that for yourself instead of taking our word for it.

This page describes that architecture, which PHOENIQS is building in cooperation with IBM Research and Red Hat: what protects data in transit, at rest, and in use, how a workload proves it is trustworthy before it receives any secret, and how the same principles extend to the PHOENIQS AI Platform.

Confidential computing is often reduced to encrypted memory. Memory encryption is necessary, but it is only the first layer. The PHOENIQS architecture stacks five layers, each narrowing what has to be trusted.

Workloads execute inside confidential virtual machines (CVMs) protected by CPU trusted execution environments: Intel TDX, AMD SEV-SNP, and IBM Secure Execution on LinuxONE. The memory controller encrypts and decrypts every byte moving between the CPU and DRAM, so even physical access to memory yields only ciphertext. Modern TEEs also protect memory integrity, so it cannot be silently altered.

NVIDIA Confidential Computing mode establishes a GPU TEE with encrypted GPU memory and attested firmware. The GPU produces its own attestation evidence, which the CVM relays to the verifier. Model inference, embedding generation, and transcription then run entirely inside encrypted GPU memory: model weights, intermediate results, and user data are shielded from the host.

Even with SEV or TDX, the PCIe and CXL interconnects have historically been a gap where data could be intercepted. New hardware standards close it: SPDM provides link-level encryption and authentication, TDISP provides device attestation so that only verified GPUs and accelerators can exchange data with the host, and trusted DMA I/O enforces encryption and key isolation for every DMA transaction.

Above the hardware root of trust, workloads run as Confidential Containers (CoCo) using Kata Containers on Red Hat OpenShift sandboxed containers. Kata moves the isolation boundary from the shared kernel to a lightweight per-pod VM; the kata-cc runtime class launches that VM as a CVM on TEE hardware. Each pod gets its own confidential VM, hardware-encrypted memory, and an attestable launch measurement, while still looking like a normal pod to the rest of the cluster.

Opting a workload in takes a single line, plus an initdata annotation that carries the security intent (see Policy below):

apiVersion: v1
kind: Pod
metadata:
  name: myApp
  annotations:
    io.katacontainers.config.hypervisor.cc_init_data: <gzip+base64 of initdata.toml>
spec:
  runtimeClassName: kata-cc

This separates administrative control from workload visibility: cluster administrators operate the platform, but trust in workload execution is established through attestation and policy, not through infrastructure ownership.

At the centre of the target PHOENIQS confidential computing architecture is Trustee, the open-source Confidential Containers service responsible for verifying attestation evidence and releasing keys and secrets. When a confidential workload starts, Trustee effectively asks: is this really the approved workload, running in the expected confidential environment? Only when the evidence satisfies the defined policy are the secrets required by the workload released.

This makes Trustee particularly important. Confidential VMs and containers may protect individual workloads, but Trustee controls the keys that allow those workloads to operate. If the verifier itself could be modified, inspected, or have its keys extracted by the infrastructure operator, the confidential-computing trust chain would have a significant weakness.

There is therefore a fundamental question: who protects and verifies the verifier?

With conventional x86 confidential computing such as AMD SEV-SNP or Intel TDX, a VM can produce hardware-backed attestation evidence showing information about its execution environment and launch state. That evidence, however, must ultimately be evaluated by a verifier or key broker running somewhere else. Protecting that verifier can therefore introduce another component into the trust chain. Even if Trustee itself is placed inside another confidential VM, something still has to establish trust in that environment and securely operate the associated verification and key-management infrastructure.

PHOENIQS avoids making that verifier ordinary cloud infrastructure by placing Trustee inside IBM LinuxONE Secure Execution, using IBM Confidential Computing Container Runtime. LinuxONE provides a hardware-rooted confidential execution boundary in which the protected VM is isolated not only from other tenants, but also from the host operating system, hypervisor, and infrastructure administrators. Its protected image and boot process are cryptographically controlled, allowing the integrity and identity of the environment running Trustee to be established from the hardware-rooted Secure Execution architecture.

This is what makes LinuxONE important to the overall PHOENIQS design. Trustee becomes a confidential workload itself. The infrastructure operator cannot simply inspect Trustee's memory, extract its secrets, or modify its verification logic through normal administrative access. The verifier responsible for deciding whether other confidential workloads should receive their secrets is therefore itself placed inside a hardware-enforced confidential boundary.

Trustee's cryptographic foundation is further strengthened by IBM CryptoExpress HSMs, providing FIPS 140-2 Level 4 hardware protection for key operations and forming the same security foundation used by PHOENIQS Cloud HSM.

PHOENIQS creates an end-to-end chain of trust from the hardware root through LinuxONE Secure Execution and the protected Trustee to attestation and secret release for confidential x86 workloads. While SEV-SNP and TDX protect the application workloads, LinuxONE protects the critical verifier and key broker they depend on, extending confidential computing beyond the workload itself to the infrastructure that determines whether it can be trusted.

A confidential VM is not automatically a trusted workload. A CVM running the wrong kernel, a tampered boot image, or an unexpected configuration encrypts its memory just the same. Trust is only established through remote attestation: the TEE produces hardware-signed evidence of its state, a verifier validates the chain of trust and compares the evidence against known-good reference values, and secrets are released only if they match.

The Trustee bundles the services that make this binding:

• Attestation Agent (inside the CVM) gathers the hardware evidence and submits it.
• Key Broker Service (KBS) is the gatekeeper and entry point. It receives the evidence, drives verification, and decides which secrets the workload may access.
• Attestation Service (AS) validates the evidence's authenticity and evaluates it against the attestation policy.
• Reference Value Provider Service (RVPS) holds the trusted reference values, typically the known-good measurements of the TEE platform and boot.
• Confidential Data Hub (inside the CVM) fetches and unwraps the secrets once the KBS releases them.

End to end, for an AI workload:

1. The CPU (TDX or SEV-SNP) and the GPU (NVIDIA Confidential Mode) each provide a hardware root of trust with measured boot, hashing firmware, microcode, and initial OS state.
2. When the CVM boots, it generates a hardware-signed attestation report and sends it, with firmware and OS measurements, to the Attestation Service.
3. The Attestation Service validates the signature using the CPU vendor's endorsement keys and compares the measurements against reference values and policy.
4. The GPU firmware produces its own attestation quote, proving firmware integrity, Confidential GPU Mode, and encrypted memory. The CVM relays it to the same Attestation Service, which ties it to the CVM's record.
5. After successful verification, the Key Broker Service opens a secure channel to that specific CVM and releases encryption keys, tokens, or session secrets to it alone.
6. With secrets provisioned, the CVM decrypts model weights or data and executes inside encrypted memory; the GPU processes data over encrypted DMA and NVLink channels. Long-running workloads can be re-attested periodically.

The point is not just to verify a workload but to shrink the chain of trust: attestation pulls the host, the hypervisor, and the cluster operators out of the trusted computing base, leaving trust resting on the hardware root of trust and the evidence it signs.

A verified claim on its own does nothing; policy turns it into a decision. It lives in three places:

• Attestation policy (in the Attestation Service) defines which conditions must hold for a workload to count as trustworthy. Reference values are the most important input, but a policy can also insist on a specific launch configuration, not merely "a valid SEV-SNP guest" but "a valid SEV-SNP guest launched with exactly this configuration".
• Resource policy (in the Key Broker Service) answers a different question: given a trustworthy workload, which secrets is it entitled to? This is where a deployment picks its posture.
• Guest policy (enforced by the Kata agent inside the CVM) is an allowlist over the host-to-guest API. It is what stops an operator from using oc exec, reading a container's stdout, or mounting volumes into the guest. The policy is carried in initdata together with the Trustee address and the image verification policy, and the hash of initdata is bound into the attestation report, so a workload launched with a weakened policy produces different evidence and fails attestation.

Supply-chain trust enters through the image verification policy: only images signed by the keys the policy names are allowed to run.

Picture a cluster administrator with full control of the platform who decides to read what is inside a confidential workload. Memory encryption stops them from reading the VM's RAM. oc exec is refused by the guest policy. Reading the container's output stream is refused. Swapping the image is caught by signature verification. Launching the pod with a permissive policy changes the initdata hash, and attestation fails. Redirecting the Trustee address fails the same way. Tampering with the Trustee itself is prevented by LinuxONE Secure Execution. At every step, the operator is stopped by a control they cannot switch off.

The same architecture extends upward to the PHOENIQS AI Platform: chat, agents, transcription, and retrieval-augmented generation.

• Federated identity. Authentication runs through Keycloak, which can be federated with your identity provider (for example Microsoft Entra ID) over OpenID Connect. You keep control of access and MFA policy; PHOENIQS never handles user passwords.
• Client-held keys. Master keys are protected in HSMs under KYOK. You, not the platform provider, retain control over your data and cryptographic material.
• Confidential model execution. The PHOENIQS AI Model Service runs LLM inference and WhisperX transcription inside Kata-based confidential containers, with GPU and CPU resources allocated within attested enclaves, so prompts, outputs, and intermediate state stay private.
• Encrypted retrieval. The RAG subsystem ingests, indexes, and retrieves your documents into encrypted indexes and Data Pools, with embeddings, metadata, and document layout generated by confidential LLMs.
• Integrations under the same boundary. MCP connectors to Microsoft 365 and Atlassian keep sensitive data encrypted throughout transfer and ingestion. Before any external lookup such as web search, a redaction pipeline running inside the backend's TEE strips personal data, internal identifiers, and proprietary terms, so no plaintext user data leaves the enclave.

• Who verifies the verifier? Building verifiable trust into confidential containers, an engineering deep dive into attestation, policy, and Trustee on Hyper Protect.
• Advancing Confidential AI with Confidential Computing, the first proof of concept of an LLM running inside a confidential container with the GPU inside the boundary.
• Confidential Computing for Privacy-Preserving AI, the target architecture overview on phoeniqs.com.
• PHOENIQS Cloud HSM, the key management service that anchors the architecture.