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
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.
