The cloud provider had done exactly what it promised. The bucket's access policy was entirely the customer's problem.
In August 2025, a mid-size fintech discovered that a Kubernetes secrets file, containing production database credentials, had been sitting in a publicly readable object storage bucket for eleven months. The cloud provider had done exactly what it promised: physical security, network isolation, platform uptime, all intact. The bucket's access policy, set by an engineer who never got around to locking it down after a migration, was entirely the customer's problem. That is the shared responsibility model working exactly as designed, and exactly as most buyers never expect it to.
Every major cloud provider publishes a shared responsibility model, and almost no buyer reads it until an incident forces the question of who was supposed to be doing what. The model draws a line between what the provider secures and what the customer secures, and that line moves depending on the service type. In infrastructure as a service (IaaS), the provider secures the physical data center, the network fabric, and the hypervisor. The customer is responsible for everything above that: the operating system, patching cadence, application code, identity and access configuration, and data encryption choices. Move to platform as a service (PaaS) and the provider absorbs the OS layer. Move to software as a service (SaaS) and the provider absorbs the application layer too. What never moves, in any model, is identity and access configuration and data classification. Those stay with the customer regardless of how much the provider manages underneath.
This matters because buyers routinely assume that paying a hyperscaler for infrastructure means the hyperscaler is also managing their security posture. It is not, and the contract says so explicitly.
The figure in this article's title traces back to a 2019 Gartner projection: through 2025, 99 percent of cloud security failures would be the customer's fault. That number gets cited constantly and rarely examined. It does not mean cloud platforms are flawless. It means that when researchers looked at the actual root cause of cloud security incidents, the overwhelming majority traced back to a customer-side decision, a permissive IAM role, a bucket left public, an API key committed to a public repository, rather than a failure in the provider's own infrastructure. The 2024 Verizon Data Breach Investigations Report reinforces the same pattern from a different angle: 82 percent of breaches involving cloud-stored data involved a misconfiguration or human error, not a platform vulnerability.
The gap between what buyers think they are purchasing and what the shared responsibility model actually delivers is the trap. It is not that providers are hiding the terms. It is that almost no procurement process treats the model as a technical requirement rather than a paragraph in a terms of service page. Spotting these gaps before they become incidents is its own discipline, and it is covered in more depth in How to Detect and Respond to Cloud Misconfigurations in Real Time.
Object storage is where this plays out most expensively, because a single misconfigured bucket can expose an entire dataset in one step, with no lateral movement required. Amazon S3 buckets default to private, and have for years, yet public bucket exposure remains one of the most common root causes in breach disclosures because engineers change the default during migrations, testing, or third-party integrations and never revert it.
This is also where storage vendor choice becomes a genuine security variable, not just a cost one. Providers like Backblaze and Wasabi built S3-compatible object storage with more conservative default access policies and simpler permission models specifically because their buyers are the ones who inherit the consequences of a misconfigured bucket, not the provider. Zero-egress pricing gets the attention in vendor comparisons, but the access control defaults matter just as much when a team is moving data between providers under time pressure, which is exactly when mistakes get made. A provider directory that lets a team compare default security posture alongside pricing is worth building into the vendor selection process, not treated as a separate exercise after the contract is signed.
The shared responsibility model was written for a world of virtual machines and databases. AI infrastructure adds layers the model never anticipated. Training data pipelines, vector databases, model weights, and GPU orchestration all carry their own access surfaces, and in almost every case, the provider's responsibility stops at the compute layer. Whether a GPU cluster from CoreWeave, Nebius, or another neocloud is even provisioned securely, meaning correctly isolated between tenants and not left with default credentials on the orchestration layer, is the customer's job to verify, not the provider's job to guarantee.
Vector databases used for retrieval-augmented generation are a particularly underexamined risk. They frequently hold embeddings derived from sensitive source documents, and teams treat them with far less access rigor than they would apply to the original database, because the data no longer looks like the original text. It still encodes it. A team that would never leave a customer records table publicly queryable will sometimes leave the vector index built from that same table with permissive access, simply because nobody applied the same review checklist to a newer kind of data store.
Comparing GPU pricing across providers gets the most attention in AI infrastructure planning, understandably, since a single training run can cost more than most companies' entire prior cloud bill. But the security posture of who can reach the orchestration layer, the training data, and the resulting model artifacts deserves the same line-item scrutiny as the hourly rate.
The table below lays out the split as it typically breaks down across the three most common service models. The pattern to notice is not which layers change hands, it is which ones never do. Identity and access configuration and data classification sit with the customer in every model, from raw infrastructure through fully managed software.
| Control Layer | IaaS | PaaS | SaaS |
|---|---|---|---|
| Physical data center and hardware | Provider | Provider | Provider |
| Network and hypervisor | Provider | Provider | Provider |
| Operating system and patching | Customer | Provider | Provider |
| Application code and runtime | Customer | Customer | Provider |
| Identity and access configuration | Customer | Customer | Customer |
| Data classification and encryption choices | Customer | Customer | Customer |
None of these require a bigger security budget. They require treating the shared responsibility line as an engineering checklist rather than a legal disclaimer.
First, run a quarterly audit specifically scoped to customer-owned controls: IAM roles, bucket and container access policies, and encryption-at-rest settings. Do not fold this into a general security review where it competes for attention with provider-side concerns the team cannot actually change.
Second, apply the same access review to newer data stores, vector databases, model artifact registries, feature stores, that the team already applies to production databases. New does not mean lower risk. It usually means lower scrutiny, which is worse.
Third, build default-deny into every new bucket, role, and service account at creation time, rather than auditing for over-permissioning after the fact. This is the same default-deny principle covered in Zero Trust Architecture: Implementation Guide for Cloud Teams, and the 2024 Verizon findings on misconfiguration as a leading breach cause are, almost without exception, stories of a permissive default that nobody tightened later.
Fourth, when comparing storage or GPU providers, put default access posture on the same evaluation sheet as pricing and egress terms. A cheaper provider with looser default permissions can cost far more than the difference in the invoice, once the first misconfiguration-driven incident lands.
The provider secures the building. You still have to lock your own door, and in 2026 that door has a lot more rooms behind it than it used to.
Compare AWS, Google Cloud, Azure, and alternatives like Backblaze B2 Discover how much you could save in seconds
