No clearing house ever settled a trade it couldn’t see — and no hyperscaler can clear an agent action that already crossed into someone else’s cloud.
Why Cross-Cloud Agent Governance Matters Now
Every hyperscaler now ships an agent governance story, and each one is true inside its own walls. Microsoft will govern agents that live in Agent 365. Salesforce will govern Agentforce. AWS will instrument what runs through Bedrock. Anthropic will scope what happens inside its own runtime. The pitch is coherent, the demos work, and the architecture diagrams are clean. The problem is that no real enterprise estate is single-vendor, and the moment an agent delegates across a border, every one of those promises stops at the edge of its own cloud.
Gartner has put the constraint about as bluntly as an analyst firm ever does: no cloud provider can unilaterally enforce runtime control over AI agents once they operate or delegate across another provider’s cloud or on-premises environment. That is not a maturity gap that closes with the next release. It is structural. A control plane that depends on the provider owning the runtime cannot, by construction, reach an action that has already left the runtime. The governance is real; the jurisdiction is not.
This is the cross-venue problem the buy-side learned the hard way. You can have flawless risk controls at each individual venue and still carry uncontrolled exposure across the book, because nobody is netting the positions in one place. The agent estate is now that book.
| Signal | Figure | Source |
|---|---|---|
| Enterprises operating more than one cloud | ~89% | Flexera 2024 State of the Cloud |
| Agent transactions that will cross a trust boundary by 2028 | Majority | Gartner agentic AI guidance |
| Internal/unauthorized agent actions vs. external attacks | 80%+ | Gartner (through 2028) |
| Window before independent agent governance is table-stakes | 12–18 months | Ospiri research |
Read those rows together. Nearly every enterprise is multi-cloud, most agent traffic will cross a boundary, and the bulk of the risk is endogenous — agents doing the wrong thing inside your own estate, not attackers breaking in. A per-cloud control plane addresses none of that the moment delegation crosses a line.
Where Each Provider’s Writ Actually Ends
The useful question is not whether a hyperscaler can govern agents — it is where its authority terminates. Map it honestly and the gaps are obvious.
| Control plane | Governs well | Where it stops |
|---|---|---|
| Microsoft Agent 365 / Entra | Agents inside the M365 + Entra tenant | A Bedrock or custom agent calling M365 APIs from outside |
| Salesforce Agentforce | Actions within the Salesforce runtime | Data the agent hands to a downstream tool off-platform |
| AWS Bedrock guardrails | Model calls routed through Bedrock | A local Python agent that bypasses Bedrock entirely |
| Anthropic runtime controls | Behavior inside the Claude runtime | The endpoint filesystem the agent writes to after |
| Custom in-house agents | Whatever you instrument yourself | Everything you forgot to instrument |
Each row is a counterparty that clears its own trades and reports its own risk. None of them sees the consolidated position. The cross-cloud action — Agentforce reasons over a record, hands it to a custom Python agent, which writes it to a local file, which a Copilot extension then reads — never lives inside any single jurisdiction long enough to be governed by it. The blast radius is assembled from individually compliant steps.
Anatomy of a Cross-Cloud Blast Radius
The failure mode is rarely a single dramatic breach. It is a relay where each handoff is locally authorized and the aggregate is uncontrolled.
- Origination. A sanctioned Agentforce workflow pulls a customer record. Fully compliant inside Salesforce.
- Delegation. It calls a custom orchestration agent running on a developer endpoint to enrich the record. Salesforce’s writ ends at the API boundary.
- Local action. The orchestration agent writes intermediate state to the local filesystem — a place no hyperscaler control plane can see.
- Re-entry. A Microsoft 365 Copilot extension reads that file and drafts an external email. Compliant inside M365.
- Settlement. The data has now traversed three trust boundaries, and no single control plane observed more than one hop. The audit trail is three disconnected fragments.
Notice that opt-in SDKs and provider partnerships do not close this. They standardize how cooperating runtimes talk; they do nothing for the local hop in step three, and nothing for the agent that never registered with any SDK at all — which, given that 80%+ of the risk is internal misuse, is exactly where the exposure concentrates.
Scoring Cross-Cloud Exposure
If you want to size this rather than fear it, treat each agent the way a desk treats a position that trades across venues.
Cross-Cloud Risk = (Boundary Crossings × Reversibility) + (Local Endpoint Reach × Observability Gap)
| Factor | What it measures | Low (1) | High (5) |
|---|---|---|---|
| Boundary crossings | Distinct trust boundaries per workflow | Single cloud | Three or more |
| Reversibility | Can the action be undone | Read-only | Irreversible write/send |
| Local endpoint reach | Filesystem / OS access off-platform | None | Full local permissions |
| Observability gap | Hops no control plane sees | 0 | Most of the chain |
The agents that should keep a buy-side CISO up at night are not the ones with the broadest cloud permissions. They are the ones with the most boundary crossings and the largest observability gap — the relays that no single provider can mark to market.
What Independent Enforcement Requires
The control plane that survives a multi-cloud estate cannot belong to any one cloud, because the one thing it must do is operate at the layer every agent eventually touches: the endpoint and the kernel. That is the only venue that is common to all of them. This is the architectural case for an agent firewall that sits below the runtimes rather than inside one of them.
| Requirement | Provider-bound control | Independent control plane |
|---|---|---|
| Reach across clouds | Stops at the provider border | Spans every runtime via the endpoint |
| Sees the local hop | No | Yes — kernel-level visibility |
| Governs unregistered agents | No | Yes — sanctioned and shadow alike |
| Consolidated audit | Per-cloud fragments | One trail across the chain |
To be precise about scope: independent enforcement is not a replacement for each provider’s native controls, any more than a prime broker replaces the exchanges. It is the layer that nets exposure across them. You still want Entra, you still want Bedrock guardrails — you want one place that can see and stop the action after it leaves them. That is the role an enterprise agent governance layer is meant to play.
What CISOs Should Do This Quarter
| Step | Action | Output | Effort |
|---|---|---|---|
| 1 | Map every agent workflow that crosses a cloud boundary | Cross-venue exposure inventory | Low |
| 2 | Score each by boundary crossings × observability gap | Ranked risk list | Low |
| 3 | Deploy kernel-level enforcement on the local hop | Coverage for the blind spot | Medium |
| 4 | Consolidate per-cloud logs into one audit trail | Defensible cross-cloud evidence | Medium |
The Bottom Line
Cross-cloud agent governance, as sold by the people who own the clouds, is a promise that holds right up to their own border and not one hop further. The hyperscalers are not wrong about what they can govern; they are silent about where their authority ends, and the exposure lives precisely in that silence — in the local hop and the unregistered agent that no single runtime sees. The only control plane that nets the whole position is one that does not belong to any cloud and operates at the layer they all share. If your team is sizing a multi-cloud agent estate for the next budget cycle, request a working session. We will walk through your actual delegation chains, build the cross-venue exposure map, and scope a deployment in 90 minutes.