The Governance System You Can't Swap Out Isn't Governance

Provider neutrality is an old idea, understood in adjacent disciplines for decades, that conversations about governance of autonomous AI keep skipping past as if it were a portability convenience rather than a structural property. The question worth making explicit is whether the governance system survives the vendor it currently runs on. Many systems I have looked at, including ones that are otherwise well-engineered, do not.

The test is straightforward. Replace the underlying provider — the cloud vendor, the model vendor, the runtime. Then ask whether the same policies still produce the same decisions, whether the same delegations still carry the same authority, whether the same evidence records still satisfy the same integrity properties. If the answer is yes, the governance system operates at a layer above the provider and the substitution is meaningful. If the answer is no, the governance system is bound to the provider, and what looks like governance is actually a provider feature with governance vocabulary attached to it.

Provider Neutrality Is a Substitution Test

Provider neutrality means the semantics of governance do not move when the infrastructure changes. The meaning of a policy, the structure of a delegation and the integrity of an evidence record must remain invariant across vendors, frameworks, runtimes and infrastructure. The substitution test is the cleanest way to see whether the property actually holds, because it is something that can be performed on the architecture as it stands rather than reasoned about abstractly.

If the substitution works cleanly, the organisation can move its agents from one provider to another, run them across multiple providers at once, or migrate away from a vendor that has changed its terms, without rebuilding governance. If the substitution does not work, then the policies, delegations and receipts the organisation has been producing are expressions of the provider’s capability rather than of its own requirements.

Why the Coupling Happens

The coupling happens because governance is easier to ship when it uses the provider’s native constructs. The provider offers identity management, and delegation gets mapped to provider identity; the provider offers logging, and evidence becomes provider logs; the provider offers a policy engine, and policy evaluation is written in the provider’s policy language. Each individual decision is locally rational. The provider’s constructs are well-tested, well-documented and available, and building governance on top of them is faster than building independent infrastructure.

The cost appears later, and it is worth being honest about. The delegation model is now defined in terms of the provider’s identity system, evidence lives in the provider’s log format, and policies are expressed in the provider’s policy language. The governance system has become coupled to the provider, not through one dramatic architecture decision but through a hundred reasonable shortcuts. The coupling is invisible during normal operation; the system works, evaluates actions and produces receipts, and the dependency becomes visible only when the organisation needs to operate across providers, migrate away, or verify governance claims without trusting the provider’s infrastructure.

The strongest argument for provider-native governance is speed. The provider has already solved identity integration, logging, policy distribution and operational support. For many teams, using those primitives is the only way anything ships. I do not think that argument is unserious. I think it proves the opposite of what people usually want it to prove. Provider-native controls can be valuable implementation components, but they cannot be the semantic source of governance if the organisation needs governance to survive the provider.

Neutrality Requires Four Properties

Four properties have to hold for governance to be genuinely provider-neutral.

Policy portability is the first. Governance policies must be expressible in a format that is not specific to any provider. The policy’s semantics, meaning what is authorised, under what conditions and with what constraints, must be interpretable without access to the provider’s documentation.

Evidence independence is the second. Governance receipts must be verifiable without access to the provider’s infrastructure. An auditor with the receipt, the policy version and the delegation artefacts must be able to reconstruct the decision on any machine, with any tools, without relying on the provider’s SDK.

Delegation abstraction is the third. Delegation artefacts must carry their authority properties, including scope, time bounds, revocability and chain, without reference to the provider’s identity system. The delegation is an authority artefact, not an identity artefact, and it must be interpretable by any governance system that understands the delegation schema, regardless of which provider issued it.

Evaluation invariance is the fourth. The same canonical action, evaluated against the same policy version and delegation artefacts, must produce the same decision regardless of which provider’s infrastructure runs the evaluation. This follows directly from the determinism requirement: if the evaluation function is pure, its output depends only on its inputs, not on the infrastructure that executes it.

Provider Coupling Changes Governance Semantics

Provider neutrality is not a portability convenience. It is a governance integrity requirement. If governance semantics are coupled to a provider, the provider becomes part of the governance system’s trusted computing base. The organisation is, in that arrangement, trusting the provider to maintain the semantics of its policies, the integrity of its evidence and the validity of its delegations. If the provider changes any of these (through an API update, a schema migration, a deprecation), governance semantics change with the provider’s decision, not with the organisation’s.

A governance system whose semantics can be altered by a vendor decision is not under the organisation’s control. The organisation may still have useful controls, and those controls may be worth using. What it does not have is independent governance. It has the vendor’s governance surface, projected into its own architecture.