Why Security Teams Should Use IBM Cloud Confidential Computing

Your encryption story probably looks airtight on paper. Data at rest, encrypted. Data in transit, TLS everywhere. Then someone spins up an inference endpoint, and for the length of every request, the prompt, the retrieved documents, sometimes the model weights themselves, all of it sits in cleartext in a VM's memory. That's the window a root-access cloud admin, a compromised hypervisor, or a subpoenaed provider can reach into, and it's the part most security reviews never ask about.

What IBM Cloud confidential computing actually adds

IBM Cloud confidential computing closes that gap with IBM Secure Execution for Linux, the trusted execution environment (TEE) technology behind IBM Cloud Hyper Protect Virtual Servers for VPC. Instead of trusting the hypervisor and the cloud operator's access controls, each instance gets its own hardware-enforced boundary: memory stays encrypted while the workload runs, and IBM states directly that IBM Cloud administrators cannot access the environment or the data inside it.

The part that should matter most to a security team is attestation. Before you trust an instance with sensitive data, you can cryptographically verify the exact image that booted it, rather than taking anyone's word that the approved code is what's actually running. That turns "we trust the pipeline is running what we approved" from an assertion into something you can check.

Where this fits an AI inference pipeline

Picture a claims model reading redacted-but-still-sensitive medical notes, or a fraud model scoring live transaction data. On a standard VM, that data is encrypted at rest in storage and encrypted in transit over TLS, but it's decrypted and readable in memory for the entire time the model runs against it. Anyone with hypervisor-level access, malicious or compromised, has a window. That's what encrypted AI inference actually requires: protection while the data is being computed on, not only before and after.

Pair the compute side with IBM Cloud Hyper Protect Crypto Services for the keys. It's a single-tenant key management service backed by a FIPS 140-2 Level 4 hardware security module, the same physical-tamper-response standard used for the highest-assurance HSMs, and it supports Keep Your Own Key so IBM never holds a copy of your key material, even for keys used across AWS or Azure. If your AI workload touches regulated data under HIPAA, PCI or GDPR, that's the difference between "we promise not to look" and "there's nothing here for us to look at."

Provisioning a confidential instance

# List secure-execution profiles; the fourth character 'e' marks
# a confidential-computing-capable profile, e.g. bz2e
ibmcloud is instance-profiles | grep e-host

# Create a Hyper Protect Virtual Server instance in a VPC subnet
ibmcloud is instance-create <instance-name> <your-vpc-name> <zone> \
  bz2e-host-2x8 <your-subnet-name> \
  --image <hyper-protect-image-id> \
  --keys <your-ssh-key-id>

Swap in your own VPC, subnet, image and SSH key IDs. The profile is what switches on the trusted execution environment; everything else about provisioning is standard VPC.

The honest limitation

Here's the part a vendor pitch skips: Hyper Protect Virtual Servers run on IBM LinuxONE, s390x hardware, not the x86 GPU boxes your LLM training or high-throughput inference almost certainly runs on. There's no GPU inside this TEE today, so it isn't where you run the GPU-bound half of an AI stack.

What it's genuinely good for is the CPU-bound edges around that model: sanitizing and tokenizing sensitive input before it reaches a GPU inference service elsewhere, redacting output, running smaller classification or scoring models, and holding the keys and orchestration logic everything else depends on. Put the pieces that touch raw sensitive data and don't need a GPU inside the enclave; leave heavy inference where the accelerators live.

Where to start

Don't try to move a whole inference stack in one pass. Start with Hyper Protect Crypto Services for Keep Your Own Key on whatever already encrypts your training data and prompts, since that's close to a drop-in swap. Then pick one CPU-bound step that touches PII, like input sanitization or a lightweight classifier, and move just that step onto a Hyper Protect Virtual Server.

For a security team signing off on an AI deployment, the case for IBM Cloud confidential computing isn't that it replaces your existing controls. It's that it removes "trust the cloud admin" from the list of things you have to write into the risk assessment.