Bounded Sovereignty and the Control Tax: Pricing AI Oversight When the Deployer Does Not Own the Model
arXiv:2608.192162026-08-21
Companies that rent AI instead of owning it can only do half of AI safety oversight
Regulated organisations that access frontier AI models through APIs often cannot see model weights, internal logs, or serving infrastructure, which quietly disables many standard AI safety control techniques. This paper sorts access into four layers - data, model, infrastructure, interaction - and maps which control protocols actually work under which access conditions, then tests this with 1.35 million synthetic case simulations. It finds that complete logs enable diagnosis, a pre-execution gateway enables intervention, and restricting what a system can do improves safety only by cutting usefulness.
What they did
AI control research usually assumes a deployer can fully instrument the model and its pipeline, but organisations using frontier models through APIs or managed endpoints often lack access to model weights, serving infrastructure, internal traces, the update process, or complete interaction logs
The paper names this condition 'bounded sovereignty' and builds a four-layer access typology (data, model, infrastructure, interaction) plus a matrix mapping which control protocols require which layers of access
It introduces 'sovereignty discount cost' - the extra spend, delay, residual risk, or lost usefulness a deployer pays to substitute for missing access via contracts, architecture, audits, vendor assurances, or narrowing the system's scope
Using a synthetic payments-dispute-triage workflow with 20 access profiles, 10 control protocols, and 3 agent behaviours, the authors ran 1.35 million synthetic case simulations, then interpreted results through an anonymised national-payments-infrastructure scenario
Complete logs improved post-incident diagnosis, a deployer-controlled execution gateway enabled stopping risky actions before they occurred, trace access and model-version control strengthened explanations after incidents, and restricting the system's allowed actions raised safety but reduced how useful it was
Figure 1: Gateway access turns detection into intervention.
Layer
What full access would mean
Typical access for an import-dependent regulated deployer
Data sovereignty
Control over what data trains or fine-tunes the model; ability to audit training-data provenance
Usually retains control over own transactional or fine-tuning data; no visibility into base-model training data
Model sovereignty
Access to weights, architecture, activations, and ability to retrain, patch, probe, or run interpretability tooling
Usually absent under API or managed-endpoint access; weights, architecture details, and activations are vendor-held
Infrastructure sovereignty
Compute located in-jurisdiction, under domestic legal control, observable by the deployer
Partial at best: often a foreign-operated cloud region, sometimes with data-residency commitments; serving stack remains vendor-operated
Interaction sovereignty
Full logging and audit of prompts, outputs, tool calls, traces, and pre-execution intervention points
Partial: input/output and tool logs may be contractable; internal traces are rarely available; gateway ownership depends on architecture
Figure 2: Logging affects both safety and reconstructability.
Figure 4: Reachability of ≤1% failure with ≥75% usefulness.
Paper layer
Experimental factor
Levels used
Interaction sovereignty
I/O logs
none, partial, complete
Interaction sovereignty
Tool-call logs
none, partial, complete
Interaction sovereignty
Pre-execution gateway
absent, present
Model sovereignty
Trace access
none, limited, oracle
Model / interaction sovereignty
Model-version control
unpinned, notified, pinned
Infrastructure / contractual sovereignty
Vendor support
none, delayed, guaranteed
Deployment design substitute
Tool scope
full, restricted
Figure 5: Scope restriction buys safety by giving up usefulness.
Agent
Behaviour
Honest
Usually follows the synthetic ground truth but makes occasional mistakes
Careless
Overconfident, error-prone, and less likely to escalate uncertain cases
Stealthy access-aware
Chooses lower-visibility synthetic failure modes when access is weak
Protocol
Interpretation
No control
Accept the agent’s proposed mock action
Output monitor
Score the final output or action for suspiciousness
Tool monitor
Score proposed tool/action use when tool visibility exists
Defer-to-trusted
Replace suspicious actions with a conservative trusted fallback when possible
Resampling
Generate alternative candidate actions and select the lowest-risk acceptable one
Human audit
Send flagged cases to a capacity-limited synthetic reviewer
Trusted editing
Edit or redact risky draft outputs, or fall back to a safer policy
Scope restriction
Remove higher-risk mock actions from the action space
Macro-shutdown
Escalate or safe-mode clusters after repeated suspiciousness
Vendor escalation
Request delayed or guaranteed synthetic vendor support for diagnosis or attestation
Setting
Value
Access profiles
20
Control protocols
10
Synthetic agent types
3
Monitor thresholds
0.35, 0.55, 0.75
Audit budgets
2%, 5%, 20%
Random seeds
5
Synthetic cases per condition
50
Aggregate condition rows
27,000
Synthetic case simulations
1,350,000
Synthetic agent
Profiles reaching ≤1% failure and ≥75% usefulness
Honest
90%
Careless
40%
Stealthy access-aware
35%
Layer
Operator’s position
Basis
Data
Partial
Full control of own case and transaction data used in prompts or fine-tuning; no visibility into base-model training data
Model
None
Managed-endpoint access; no weights, architecture detail, activations, or native patching ability; vendor may update the served model
Infrastructure
Partial
Data-residency rider constrains storage location; serving stack remains vendor-operated and not independently observable; legal reach is mediated by foreign law
Interaction
Partial
I/O logging and tool-call logging may be contractable and implemented at the Operator’s gateway; internal traces remain unavailable
Why it matters
Many organisations and governments depend on AI they don't own while still being held accountable for its safety, and this paper gives them a concrete way to ask which control techniques they can actually run versus which ones only look good on paper. Anyone designing or regulating AI safety protocols should treat 'full instrumentation access' as an assumption to check, not a given.
Terms in this paper
AI control · research into deployment techniques that keep an AI system's actions safe even if the model itself might be misaligned
bounded sovereignty · having only partial technical and contractual access across an AI system's data, model, infrastructure, and interaction layers
control tax · the operational and financial cost of adding safety-control measures to an AI deployment pipeline
sovereignty discount cost · the extra cost, delay, risk, or usefulness lost when a deployer substitutes for access it doesn't have
gateway · a point where the deployer can intercept and review a model's action before it actually executes
Original abstract (English)
AI control research asks how to deploy models safely even when they may be misaligned, but many control protocols assume that the deployer can instrument the model and its surrounding pipeline. That assumption often fails for regulated organisations using frontier models through APIs or managed endpoints, where the deployer may control the business process but not the model weights, serving infrastructure, internal traces, update process, or full interaction logs. This paper introduces bounded sovereignty: partial technical and contractual access across the data, model, infrastructure, and interaction layers of the AI stack. It argues that these access conditions determine which control protocols can be executed in practice. The paper contributes a four-layer access typology, a protocol-by-layer requirements matrix, and the concept of sovereignty discount cost: the part of the control tax spent substituting for missing access through contracts, architecture, audit, vendor assurance, residual risk, or reduced system scope. It also reports a synthetic access-ablation experiment over 1.35 million synthetic case simulations and interprets the findings through an anonymised national-payments-infrastructure scenario. The experiment is not real-world payment-system evidence; it is a construct-validity exercise. The results show that complete logs improve diagnosis, a pre-execution gateway enables intervention, trace access and model-version control strengthen post-incident explanation, and scope restriction can improve safety while reducing usefulness. Control protocols proposed as general safety solutions should therefore state their access assumptions explicitly.
