Every Vendor Governs Their Stack. Nobody Governs the Chain.

Microsoft has a governance story. It's called Copilot, and it runs inside Azure, inside M365, inside the Microsoft trust domain. It's real, it's serious, and for everything that lives inside that domain, it works.

Google has a governance story. It's called Vertex AI Agent Builder, and it runs inside Google Cloud, inside Workspace, inside the Google trust domain. Also real. Also serious. Also scoped to one world.

Every major platform vendor is building agent governance. And every one of them is building it for the same thing: the agents that run inside their own stack.

Nobody is building governance for what happens between stacks. That gap is not an oversight. It is a structural property of how enterprise technology actually works — and it is where most of the risk lives.

How enterprises actually run

No enterprise of any meaningful size runs on one vendor's stack. The idea is appealing in a vendor presentation. It is not how technology gets purchased, inherited, or operated across a decade of business decisions.

Take a mid-size hotel chain. Not a hyperscaler customer. Not a tech company. A normal regulated business with normal operational complexity.

Their daily technology stack looks something like this: Opera or Mews for property management. SiteMinder or D-EDGE for channel management. Booking.com and Expedia for distribution — not hyperscalers, independent platforms with their own APIs, their own data models, their own terms. IDeaS or Duetto for revenue management. Stripe or Adyen for payments. Oracle MICROS for point of sale. Revinate or Salesforce for CRM. SAP or NetSuite for accounting. Microsoft Entra for identity. AWS for infrastructure.

Ten to twenty vendors. Each with their own integration pattern. Each with their own access controls. Each with their own logging. Each optimizing for their own platform.

This is not an unusual enterprise. This is a typical one.

What an agent chain looks like across that stack

Now deploy AI agents into that environment. Not hypothetically — this is happening now, across the hospitality industry and every industry like it.

A demand signal comes in. Occupancy is rising. An event is happening in the city. The revenue management agent reads KPIs from the forecasting system, pulls historical data from the data lake, evaluates current pricing against competitor rates, and makes a decision: raise room prices by 18% across all channels.

That decision propagates. The channel management agent pushes updated pricing to Booking.com, Expedia, and the hotel's direct booking engine simultaneously. The procurement agent, seeing increased occupancy, orders additional housekeeping capacity, activates the external laundry service, and increases food and beverage stock. Purchase orders go out. Payments are authorized. Invoices are queued in SAP.

A guest agent, working from the same occupancy data, starts offering room upgrades and loyalty point incentives to guests who booked at the lower rate. Refunds are issued for price-match requests. Credits are applied.

The entire chain — from demand signal to payment authorization to physical operations — has been executed by AI agents. Across Opera, Booking.com, Stripe, SAP, Salesforce, and four other systems. In minutes.

Where governance breaks down

Each system in that chain has its own governance. Opera logs what happens in Opera. Stripe logs what happens in Stripe. SAP logs what happens in SAP. Booking.com logs what Booking.com sees.

None of them logs the chain.

Nobody has a record of the full decision sequence — the demand signal that triggered the revenue agent, the reasoning that produced the 18% price increase, the cascade of procurement and payment actions that followed, the guest interactions that resulted. The evidence is fragmented across ten vendor consoles, in ten different formats, with ten different retention policies, none of which are cryptographically verified.

When the CFO asks why procurement costs spiked on a Tuesday, the investigation begins. When a guest disputes a charge, the trail requires assembling logs from three systems. When a regulator asks for a complete audit of automated decisions affecting customer pricing, there is no single record that answers the question.

And this is the optimistic scenario — where nothing went wrong except that nobody can explain what happened.

Now add the adversarial case. The revenue agent has been manipulated through a prompt injection in a vendor data feed. For two weeks, it has been making pricing decisions that look reasonable individually but are systematically incorrect. The procurement agent has been authorizing payments to a vendor that shouldn't be on the approved list. Nobody noticed because each system's logs looked normal — in isolation.

The chain was compromised. The chain had no governance layer.

Why hyperscalers can't solve this — and won't

The structural reason Microsoft and Google cannot provide cross-system governance is not technical. It is political and commercial.

If Microsoft builds a governance layer that sits over AWS infrastructure, Google analytics, and Salesforce CRM — it controls its competitors' systems. AWS will not accept that. Salesforce will not accept that. The enterprise will not accept a situation where their primary cloud vendor has governance authority over every other vendor in their stack.

The same logic applies to every hyperscaler. Each one is incentivized to deepen governance within their own domain. None of them is incentivized — or positioned — to be the neutral authority over the others.

This is not a gap that will be filled by a better product from an existing vendor. It is a structural property of competitive markets. The control layer that governs cross-system agent chains cannot come from a vendor that has a stake in any of those systems.

It has to come from outside.

What neutral cross-system governance requires

The governance layer that covers a chain like the hotel example above needs four properties that no single-vendor solution can provide.

Neutrality. It cannot be owned by or optimized for any system in the chain. The moment it is, every other system in the chain has a reason to distrust it.

Position. It needs to sit in the data path — between agents and the systems they act on — not as a monitoring tool that reads logs after the fact, but as an interception layer that sees every action before it executes.

Identity across systems. Every agent action needs to be attributed to a specific agent identity, regardless of which system it touches. The revenue agent that raised prices, the procurement agent that authorized the payment, the guest agent that issued the refund — one identity layer, one attribution model, across all of them.

A single tamper-evident record. Not ten logs in ten consoles. One cryptographically signed, hash-chained audit trail that covers the full chain — every action, every system, every agent identity — in a record that cannot be modified after the fact.

The category that doesn't exist yet

Enterprise software has solved cross-system identity — that's what Okta does. It has solved cross-system network governance — that's what Cloudflare does. It has solved cross-system observability — that's what Datadog does.

It has not solved cross-system agent governance. The category does not yet have an established winner. The window to define it is open — and it is closing as agent deployments accelerate and the chains they operate across become load-bearing infrastructure.

The hotel chain is one example. The same structure exists in retail — agents spanning warehouse systems, logistics APIs, payment processors, and CRMs. In manufacturing — agents spanning ERP, supply chain platforms, quality systems, and logistics providers. In financial services — agents spanning core banking, risk engines, compliance databases, trading infrastructure, and payment rails.

Every enterprise is a chain of systems. Every enterprise is deploying agents into that chain. Every enterprise has a governance gap where the chain crosses vendor boundaries.

What this means for how you deploy agents

The practical implication is straightforward. Before you deploy agents into a multi-system environment, you need to answer one question: who governs the chain?

Not who governs the Microsoft part. Not who governs the Salesforce part. Who governs the sequence of actions that starts in one system and ends, four steps later, in another — and produces a financial, operational, or regulatory consequence that none of the individual systems logged completely?

If the answer is "each system governs itself," you don't have cross-system governance. You have fragmented logging with a governance-shaped gap in the middle.

The agents are already in the chain. The chain needs a control layer.