Multi-Cloud Governance Is Broken & Now AI Agents Are Widening the Gap

Governance broke because the operating model changed twice, but the underlying frameworks didn't. First, the move to multi-cloud spread data across identity systems, consoles, and configuration models with no shared view of what's protected. Then, AI agents began creating and changing resources faster than any human classification process could follow. Every governance control still assumes a human is in the loop with time to catch up. That’s no longer a safe assumption.

The survey behind this post asked 583 cloud IT leaders how they recover, govern, and access cloud data at scale. The same pattern showed up on every governance question: confidence is high, evidence is thin, and the gap is widest in the most complex environments.

Multi-cloud was supposed to add flexibility, but instead, it added more blind spots

54% of respondents operate across three or more cloud platforms, making multi-cloud the default operating model.

Each cloud brings its own identity model, configuration patterns, and console. Most teams manage backups across dozens or hundreds of accounts with no single view of what's covered. The flexibility is real. So is the cost: every boundary the data crosses is another place coverage can drift without anyone noticing.

Governance gap: The distance between what a team believes is protected and what is actually protected, classified, and recoverable. It widens silently because nothing reports the difference until a restore is needed.

The gap is closeable, and the teams that have closed it changed one thing: they stopped running governance at human speed. How wide has the gap gotten?

What is the multi-cloud visibility paradox?

It's the gap between confidence and the reality of recovery, and it widens with every cloud added. 97% of organizations on three or more clouds are confident their protected data can be restored predictably across clouds. 84% of that same group had at least one recovery failure in the past 12 months.

Everything seems to be working. Dashboards report green, policies appear to be applied, and the failures stay buried in tickets that never escalate because the workarounds hold well enough. Resilience strategies move up through the org as polished narratives. The evidence that they aren't working stays at the bottom.

91% of respondents are confident they can identify what data is protected across accounts, regions, and clouds. 61% discover protection gaps only after an incident, audit, or failed restore.

The same people who say they know what's protected are the ones finding out they don't.

And when asked directly whether multi-cloud has weakened their visibility, only 7% say yes. Almost nobody perceives a problem. The recovery failures say one is already there, sitting under a layer of dashboards that have no way to report what they were never told to watch.

Why does every additional cloud make the underlying problems worse?

Because multi-cloud doesn't create new failure modes, it amplifies the ones that were already there. Across four governance measures, the three-or-more-cloud cohort fails more often than the one-to-two-cloud cohort, every time.

63% of all respondents have already uncovered unprotected workloads due to policy misconfiguration. When infrastructure gets created and modified faster than classification can keep up, that number only climbs. The teams running the most clouds aren't the most mature. They're the most exposed, and the instrumentation tells them otherwise.

Misconfiguration gap: A workload that exists but falls outside any protection or classification policy, usually because it was provisioned after the last manual tagging pass and nothing was watching for it automatically.

Migration makes it visible. 72% of teams say migration or modernization exposed protection and governance gaps. The gaps were there before the migration. Moving the workload is what brought them to light.

A Director of Data Infrastructure we spoke to said:
‍
"That is a constant challenge for us. We have over 1,200 accounts now, and that's a huge thorn in our side. We're still trying to get visibility into backups across all these accounts because there's nothing built in to do that."

How are AI agents a new kind of governance event?

AI agents break governance in two directions at once. They generate resources that need governing, and they are resources that need governing.

Agents create resources faster than anyone can classify them

AI coding agents and automated workflows spin up databases for a single test, create buckets and forget them, and issue service accounts that read production data. Each one needs to be classified and protected, and most environments don't detect it until a human notices, which can be days later or never.

The agents themselves are now governed entities

This is the part most governance models miss. The agents authenticate, hold permissions, and leave audit trails that look like legitimate operations because they are. Frameworks built for human actors and static resources have no slot for a non-human one that provisions infrastructure on its own.

AI supply chain security: Governing both the data an AI workload consumes and the agents, service accounts, and pipelines that touch it. In a multi-cloud estate, every one of those is a new entity to classify, scope, and prove coverage for.

Both problems are the same problem: speed

Classification that depends on a human remembering to tag a resource runs at human speed. Resources now appear at machine speed. The drift lives in that gap, and it widens as more provisioning moves to agents.

A VP of Engineering we spoke to said:

"100 new databases get turned on every day, and we don't know what data is residing in them. So we kind of hope that the teams are backing things up as they should be."

Hope is not a governance control. But it's what's left when the tooling assumes a human is in the loop and the human can't be.

The survey shows where this lands. 90% of respondents say ownership for data protection is clear or very clear, and on an org chart, it usually is. But clear ownership only covers the resources someone decided to own. The database an agent spun up for a test, the bucket created and forgotten, the data store behind a new AI feature: they show up in the resource inventory, but nothing assigns them a retention policy, a recovery target, or an accountable owner. They exist as infrastructure and stay invisible as protected data until a restore needs them and they aren't there.

A resource an agent created this morning can be in production by lunch and still belong to no one by the time it fails.

The shape of the fix follows directly from the problem. If the gap is speed, the answer is governance that runs at the same speed the resources do: classification and protection that attach the moment a resource appears, with no human-speed step left to fall behind.

What is Cloud Backup Posture Management (CBPM)?

CBPM is continuous, automatic classification and protection of cloud data across accounts, regions, and providers, so coverage follows resources instead of waiting for someone to tag them. It's the governance layer the AI-era operating model needs because classification happens at the same speed as resource creation.

Cloud Backup Posture Management (CBPM): An approach where new resources get classified the moment they're created, and retention and protection policies follow automatically. Misconfigurations and migration gaps stop being a recurring discovery because classification no longer depends on human tagging.

If you can't prove coverage, you don't have coverage.

The standing rule for governance is exactly that. CBPM exists to make that proof continuous rather than a quarterly audit exercise that's already stale by the time it finishes.

Sigdo Koppers ran into the multi-cloud version of this during a migration to Google Cloud. As workloads moved, coverage could have drifted across projects and regions the way it does for most teams mid-migration. Instead, they brought new GCE workloads under policy as the systems came online, governed protection across projects from a single place rather than rebuilding backup workflows for each environment, and kept compliance provable while the footprint was still changing.

Where Eon fits

The survey documents a governance model that runs at human speed, while the operating model no longer does. Multi-cloud spread the data out, AI agents now create and touch it faster than anyone can classify it, and the dashboards keep reporting green the whole time.

Eon closes that gap by making classification and protection properties of the infrastructure rather than tasks someone has to remember. New resources across AWS, Azure, and Google Cloud get discovered and classified as they appear, protection policies follow automatically, and coverage is something you can prove across accounts and regions instead of assuming. That's CBPM, and it's what governance looks like when the things being governed include AI agents provisioning infrastructure on their own. The same protected data also lands in open formats Eon ingests, so the dataset that was hardest to govern becomes the one that's finally usable for AI work.

If you’re running in multiple clouds, you're likely confident in your coverage and likely wrong about it. The full report breaks down all four governance gaps and the architecture the teams ahead of this shift are running instead. Read AI Is Outrunning the Cloud in 2026.

FAQ

What is the difference between CBPM and CSPM? 

CSPM (Cloud Security Posture Management) watches for security misconfigurations in your live cloud environment. CBPM (Cloud Backup Posture Management) governs the protection and recoverability of your data: what's backed up, classified, retained, and recoverable across accounts and clouds. CSPM tells you a bucket is public. CBPM tells you whether the data in it is protected and provably recoverable.

Why does multi-cloud make data governance harder? 

Each cloud has its own identity system, configuration model, and console, with no shared view of what's protected. Coverage drifts at every boundary, and most teams manage backups across dozens or hundreds of accounts with nothing built in to give a single view. The survey shows the three-or-more-cloud cohort failing more often than the one-to-two-cloud cohort on every governance measure.

If 91% of teams are confident they can identify protected data, why do 61% find gaps after the fact? 

Because confidence is built on instrumentation that reports policy state, not verified recovery, dashboards show policies as applied. They don't show whether a restore would actually succeed or whether a resource created last week ever got classified. The failures surfaced during incidents and audits, after the confidence was already recorded.

Are AI agents really a governance problem, or only another workload? 

Both. They create governance events by provisioning resources at machine speed, and they're themselves governed entities: they authenticate, hold permissions, and access production data with valid credentials. Most governance frameworks were built to track human actors and static resources, so an autonomous agent that spins up a database looks like normal activity until something goes wrong.

Can governance keep up with AI-speed resource creation through better tagging? 

No, because tagging is the bottleneck. Manual classification runs at human speed, and AI-driven provisioning runs at machine speed. The fix is to make classification automatic and continuous, triggered when a resource is created rather than when a human gets to it. That's the CBPM model.

Does Eon work across AWS, Azure, and Google Cloud? 

Yes. Eon discovers and classifies resources and applies protection policies across all three, which is the point for multi-cloud teams: one governance view instead of per-cloud workflows. Coverage and supported services vary by provider and service type, so confirm specifics for your estate.

Is multi-cloud backup visibility a solved problem with native cloud tools? 

Native tools govern their own cloud well and stop at its edge. They don't give a cross-cloud view of coverage, and they don't classify or protect resources in another provider's environment. The visibility paradox in the data is partly a product of teams assuming native green-light dashboards cover the whole estate when they cover one slice of it.

What's the first thing a multi-cloud team should check? 

Whether a resource created today by a human or an agent is classified and protected without anyone tagging it. If protection still depends on someone remembering, the governance gap is already open, and the survey says it's wider than most teams believe.