Confidential GPU compute: How AI outages expose a deeper security risk

Over the recent months we have seen both AI providers and hyperscalers go offline for several hours. Production workflows stalled almost immediately. Customer service bots went dark, code pipelines froze, and engineering teams struggled to come up with emergency plans most of them hadn’t prepared for. 

Every time there is an outage with a compute provider or massive AI company, there is  an important question that isn’t answered when the service comes back online: if these providers can't guarantee uptime, what else can't they guarantee?

That question leads somewhere uncomfortable. Because the same architectural choices that create a single point of failure for availability also create a single point of failure for trust. Your model weights, your training data, your inference inputs are all on a centralized cloud, and centralized providers have access to all of it. The outage is visible. The data exposure is quiet, ongoing, and built into how these systems work by design.

What these outages actually mean

Engineers who've built production systems on a single provider's API watch an outage and recognize a major problem. They know their inference pipeline has no real redundancy. They know the SLA is a legal document, not an engineering guarantee. The outage just makes the abstract risk painfully real.

But, availability is only half of what's exposed. Think about what happens during a normal day, even when everything is working exactly as intended. Your inference request goes to a centralized data center. Your input gets processed on hardware the provider controls entirely. If you've fine-tuned a model through their platform, your weights live on their storage. The provider has countless potential ways to access your intellectual property, and you have no way to audit or restrict them.

This isn't just hypothetical. It's in the contract. If you read the fine print on any major AI cloud provider's terms of service you'll find language granting them access to data processed through their systems. 

The centralized architecture is doing double duty here. One operator means one point of failure for uptime, and one point of trust for data. Fixing the availability problem without addressing the trust problem is just half a solution.

Enter confidential GPU compute 

Confidential computing changes the security model by grounding it in hardware rather than policy. The core mechanism is a Trusted Execution Environment, an isolated processing enclave where code and data are encrypted while in use, not just at rest or in transit. Even someone with root access to the physical host can't inspect what's running inside the TEE.

For CPU workloads, this is well established. Intel SGX and AMD SEV have been around for years, and Azure already offers confidential VMs. But this is harder for GPUs. GPU architectures with massive parallel pipelines, and high memory bandwidth weren't originally built with isolation in mind. So retrofitting it presents a real challenge.

NVIDIA has made progress with Confidential Computing mode on H100 and newer GPUs. In CC mode, the GPU establishes a hardware root of trust at boot, encrypts everything in GPU memory, and generates an attestation report so the workload owner can cryptographically verify that their code is running in a genuine, unmodified TEE. AMD's SEV-SNP covers analogous protections at the CPU and memory level, and their MI300X line is building toward similar capabilities.

This allows you to run inference on third-party hardware and cryptographically verify that neither the hardware operator nor anyone with privileged access to the host can see the model weights or inference inputs. The verification is rooted in the silicon itself, not in trusting a company’s terms-of-service.

The need for decentralization

Confidential computing addresses the trust problem. Decentralization addresses the availability problem. And, you need both.

A confidential workload on a single centralized provider still goes dark when that provider has an outage. And a decentralized network without confidential computing available when you need it can spread the trust problem across more nodes. Which isn’t necessarily an improvement worth celebrating.

VOLT aggregates GPU supply from data centers, mining operations, and enterprise clusters worldwide. When you choose to layer confidential compute onto that distributed supply, the result is infrastructure where no single party controls either uptime or data access. A workload can fail across regions and hardware providers without the need to trust any individual operator with your model or data.

The market is already moving in this direction. A 2025 Gartner analysis projected that by 2027, more than half of enterprise AI inference workloads will require verifiable data isolation guarantees. That's not a niche use case. It's where the bulk of enterprise spend is heading.

For teams working through their infrastructure roadmap for Q2 and Q3 2026, the practical steps are pretty clear. Audit your current deployment pipeline and identify potential points of failure both in terms of availability and data access. Understand your projects requirements, tolerance for downtime, and need for privacy. With this in mind you can best determine your compute need and begin to explore decentralized compute networks. Even if privacy isn't your primary driver, removing single-provider dependency can have a significant impact on your business uptime and revenue.

Outages are the just beginning of the conversation

AI and cloud outages get attention because they make a latent risk visible for a few hours. But that risk existed before the outage and continues to exist as long as infra remains centralized. Every AI workload on centralized infrastructure carries the same dual exposure to both the provider's availability, and to their access.

GPU compute on decentralized infrastructure is the answer to both. The hardware exists. The network architecture is here. The question is whether your infrastructure strategy is built to anticipate potential threats and challenges or just waiting for the next major outage or data breach.

To find our more about confidential compute on VOLT check out: https://buildonvolt.com/docs/guides/clouds/confidential-compute-overview