The paper argues that frontier providers can shape model-side safety, but enterprises still need final authority over the actions taken inside their own environments.
Our paper Final Authority in AI Governance: Frontier-Provider Sovereignty and Action-Centered Deployer Governance is now available on arXiv.
The central question is simple: when an AI agent acts inside an enterprise, who gets the final say?
Not who owns the model in the abstract. Not who writes the most careful safety narrative. Not who provides the chat interface. The operational question is narrower and more consequential: when an agent is about to touch a repository, customer record, workflow, payment path, public message, support queue, data export, or production system, who has final governance authority over that action?
This is where a lot of AI governance language becomes too vague.
Model providers can and should build strong safety systems. They can evaluate capabilities, define prohibited behavior, document frontier risk, harden model behavior, and refuse classes of misuse. Those controls matter. They are part of the safety stack.
But provider-side safety is not the same thing as deployer-side authority.
An enterprise owns context the model provider usually cannot see. It knows which branch is production-adjacent. It knows whether a customer record is regulated. It knows whether a deployment window is frozen. It knows which vendor endpoint is approved, which export is allowed, which internal workflow is sensitive, and which human role is accountable for the consequence.
If final authority quietly defaults to the model provider, the workflow vendor, the wrapper, or the agent runtime, the enterprise loses control over the most important part of agent deployment: the moment where intelligence becomes action.
The paper does not argue that frontier providers should have no safety responsibilities. That would be unserious.
It argues that final authority has to be assigned at the right layer.
Provider-side governance is strongest when it governs model access, model behavior, capability thresholds, abuse prevention, platform policy, and release risk. Deployer-side governance is strongest when it governs operational consequence: which action can run, which boundary it crosses, which system it touches, who approved it, whether approval can be reused, and what proof remains after execution.
Those are different jobs.
Blurring them creates a bad tradeoff. Either the provider becomes an overextended governor of downstream enterprise operations it cannot fully understand, or the deployer gets a vague promise of oversight without enforceable control over runtime action.
Serious enterprise AI needs both layers, not one pretending to be the other.
OSuite is built around the deployer-side part of the problem.
PCAA, Proof-Carrying Agent Actions, defines the governance kernel: approval should bind to the action an agent will actually execute, and the deployer should hold final operational authority over actions inside its own environment.
CAVA turns raw agent activity into a canonical action object. It separates intent, target, privilege, boundary, reversibility, data movement, runtime lane, policy pattern, and evidence quality so the system is not approving raw strings or vague summaries.
Policy posture lets the customer decide how strict the boundary should be. Decision Score turns the posture and action semantics into an explainable route. BAF turns approval into a bounded action lease so it cannot be casually reused. AREG maps the agent, runtime, action, and system relationships into a runtime security map.
The product expression is intentionally practical:
That is final authority made operational.
For a CISO or platform owner, the question is not philosophical.
If an agent makes a mistake, the organization will not be satisfied with a screenshot that says a human was involved. It will need to know what was proposed, what was approved, who had authority, whether the executed action matched the approved action, which systems were affected, and whether the record can survive audit.
That cannot be solved only by stronger model output.
It requires a control layer at the action boundary.
The model can recommend. The runtime can request. The workflow can carry the task. The deployer still needs the ability to decide, bind, enforce, and prove.
Enterprise AI is moving from experimentation into operation. The first phase was about whether models could answer useful questions. The next phase is about whether agents can safely perform useful work.
That shift changes the governance problem.
A wrong answer is a quality issue. A wrong action is an operational issue.
Once agents operate across code, data, identity, finance, customer systems, and external communication, final authority cannot remain implicit. It has to become part of the runtime path.
That is the position of the paper, and it is the product direction behind OSuite.
The future of enterprise AI should not be a choice between provider trust and deployer chaos. It should be a layered architecture: model-side safety where providers are strongest, and action-centered governance where deployers hold the context, accountability, and final operational authority.
Request enterprise access and send your first governed decision today.
