Platform teams spent the last two years making GPU capacity fungible. Training and inference now run wherever accelerators are available: a hyperscaler region, a neocloud, and increasingly back on-premises, on Kubernetes clusters the platform team owns. Schedulers, gateways, and node pools span providers as a matter of course. Compute went multicloud, but what happened to the data?

The short version is that the data those GPUs consume (and produce) hasn’t moved with them. Training corpora, fine-tuning checkpoints, model weights, vector indexes, and embedding caches all sit in object storage. But that object storage doesn’t have the right properties to move fluidly like the compute. It still rests on a trust model built for a single provider: a bucket, a set of credentials, a key held in a KMS. The only way to get resilience is by copying.

That model has a flaw that configuration can’t fix.

The attacks went around the application

The storage-layer incidents of the last two years share a pattern.

• In 2024, UNC5537 used stolen credentials to pull data from roughly 165 organizations’ cloud data warehouses (Mandiant). No exploit needed. Valid logins against complete data stores.
• In early 2025, the Codefinger campaign used Amazon Web Services’ (AWS) own server-side encryption with customer-provided keys (SSE-C) to re-encrypt objects in victim buckets (Halcyon). The platform worked as designed. That was the problem.
• In August 2025, stolen OAuth tokens from a single AI chat integration exposed data across more than 700 organizations’ Salesforce environments (Google Threat Intelligence Group). No prompt was filtered because no prompt was involved.

None of these touched a model, a guardrail ,or an application. They went through the storage and platform trust layer instead, which is where AI’s most valuable data now lives.

Every copy is a complete copy

The standard resilience tools share one assumption: each location holds a complete, usable copy of the data.

Cross-region replication makes a second complete copy. Backup makes a third: Velero ships cluster state and persistent-volume backups to another bucket, fully readable by whoever holds that bucket's credentials. Object lock makes a copy that can't be deleted but can still be read by anyone with the right credentials. Envelope encryption protects every copy with keys that one master key unlocks.

Hybrid makes it worse. The on-premises object store, often Rook-Ceph or MinIO deployed by an operator on the same Kubernetes clusters it serves, becomes one more complete copy. It usually has its own credentials, its own backup story, and often weaker controls than the cloud tiers around it. It also shares a blast radius with the clusters that depend on it.

So every copy is a full blast radius. Compromise any one location, account, or read credential and you have the data. Corrupt the primary and replication delivers the corruption to the replica on schedule. Ransomware operators understand this: 89% of organizations hit in the past year said attackers targeted their backup repositories (Veeam 2025 Ransomware Trends Report).

Why AI data raises the stakes

Weights concentrate value. A fine-tuned checkpoint can represent months of GPU time and an organization’s proprietary data in a single object.

Embeddings aren’t anonymized. Researchers reconstructed 92% of 32-token inputs exactly from their text embeddings (Morris et al., EMNLP 2023). A stolen vector store is a stolen corpus.

Agents write at machine speed. A pipeline that deletes the wrong dataset or writes model output back into its source bucket does it faster than anyone notices. Replication copies the mistake faithfully.

Five questions for your storage layer

If compute no longer depends on any single provider, including your own data center, the storage beneath it shouldn't depend on any single location staying uncompromised. Five questions test that:

1. Can any single location, account ,or credential yield usable data, including the object store in your own racks?
2. Is there a master key whose compromise unlocks the corpus?
3. Does geographic durability depend on replication jobs that copy corruption as faithfully as data?
4. Can storage roll back to the moment before a bad write, independent of the application or backup product that made it?
5. When a tenant or dataset must be erased, can you prove it’s gone everywhere, or only that you tried?

Most stacks answer at least three of these the wrong way. Separate accounts per region, client-side encryption and object lock with multifactor authentication (MFA) delete each improve one answer. None changes the underlying assumption.

The assumption is optional

The cryptography literature has described alternatives for decades. For example, Rabin’s Information Dispersal Algorithm splits data into “n” pieces so that any “k” of them reconstruct it at a fraction of the storage cost of full copies. Shamir’s secret sharing splits a key so that fewer than “k” shares reveal nothing about it (Shamir is the “S” in “RSA”). Combine them with per-object encryption and you get a storage model where no single location holds anything usable, durability comes from a threshold across independent providers, and destroying key shares erases data everywhere at once.

So why isn't everyone doing this? Because the math is the easy part. Turning it into a storage layer means building everything around it: an S3-compatible front end existing tools can use unchanged, metadata that survives the loss of any location, key handling that never reassembles a full key in one place, background repair when a site degrades, and placement that keeps the threshold satisfiable across clouds, regions and your own racks.

Then someone has to run it: track fragment health across providers with different APIs and failure modes, keep cross-provider egress from eating the budget, operate the on-premises storage cluster alongside everything else, and prove to an auditor that a deletion actually happened.

Each piece is known engineering. Together they're a storage product, and most platform teams have no interest in building and operating one.

Make storage trust a platform decision

Kubernetes turned GPUs into a schedulable, portable resource. The data behind them deserves the same deliberate design. Before the next training run lands on a new provider, ask where its weights will live, and what happens when one set of credentials leaks. Your GPUs will keep getting more mobile. If you can fix the trust and resilience model, then your storage can go with the flow, too. If you’re working through this in person, come find us there. KubeCon + CloudNativeCon is taking place in Salt Lake City from November 9 to 12. Register Now!