The Defence AI Assurance Gap: Proving What an Autonomous System Did, On Your Own Keys
Sovereignty in defence AI is no longer about where a model runs, it is about whether an operator can prove what it did on keys they alone hold.
Through 2026 the language around defence AI has shifted from raw capability to something harder to demonstrate: assurance. The UK Sovereign AI programme, the ambition to hold compute and models on domestic soil, and concern about where sensitive data comes to rest have converged on one question. When an autonomous system takes an action that matters, who can prove, later and to an adversarial standard, exactly what it did.
The regulatory calendar sharpens the point. The EU AI Act reaches full application on 2 August 2026, ISO/IEC 42001 is becoming the reference frame for AI management systems, and governance bodies are turning to agentic audit, the discipline of holding systems that act, not just answer, to account. In a defence context the stakes are absolute. A model that recommends is one thing. A system that autonomously tasks, filters or triggers is another, and the assurance owed for it is greater.
Sovereignty has quietly changed its meaning
For several years sovereignty in AI was treated as a location problem. Keep the weights in country, keep the data in a national cloud, and the box was ticked. That framing no longer survives contact with how modern systems work. A model can sit on domestic hardware and still phone home for updates, telemetry, safety filtering or licensing checks, and each of those callbacks is a seam through which trust leaks.
The real question is narrower. Can the operator prove what the system did, using evidence the operator alone controls, without asking the vendor to vouch for anything. If the answer depends on a supplier dashboard, a cloud log or an unverifiable assertion, sovereignty has not been achieved, it has been relocated.
We built Mickai as a Sovereign Intelligence Operating System, a SIOS, around this distinction. It runs offline on operator-owned hardware, and every action it takes is cryptographically sealed at the moment it happens, so assurance lives with the operator rather than the vendor.
Why an assurance gap opens in autonomous systems
Autonomy widens the distance between an instruction and its consequences. A human analyst leaves a trail of decisions that can be reconstructed and questioned. An autonomous system compresses hundreds of those decisions into milliseconds, across model calls and tool invocations that go invisible once the output has been produced.
The gap is the difference between what the system did and what anyone can later demonstrate that it did. Conventional logging does not close it, because a log is only as trustworthy as the party that can quietly edit it afterwards. For a regulator, a court or a review board, an editable record held by an interested party is not evidence, it is a claim. Closing the gap means producing a record bound to the action, tamper-evident, and verifiable by someone who trusts neither party. That is a cryptographic problem before it is a policy one.
The mechanism: signed audit on operator-held keys
The core of a defensible approach is a signed audit chain generated at the point of action. Each decision the system takes, the inputs it saw, the models it consulted and the output it produced, is hashed and signed, then linked to the record before it so the sequence cannot be reordered or edited without breaking the chain.
Two properties make this sovereign rather than cosmetic. First, the signing keys are held by the operator, generated and stored on their own hardware, never escrowed to the vendor or any third party. Second, the signatures use post-quantum schemes, so a trail sealed today stays defensible against an adversary who later acquires a quantum capability, which for records with long classification lifetimes is not hypothetical. The result is a record the operator can hand to an auditor or regulator who verifies it independently, offline.
“Sovereign assurance means an operator can prove what an autonomous system did using cryptographic evidence they alone hold, with no vendor in the trust path.”
Identity that the hardware itself attests
A signed record is only as strong as the identity behind the signature. If the key can be lifted and used elsewhere, the chain proves that something signed, not that this machine, in this configuration, did the work. Hardware-attested identity binds the signing capability to a specific device and a measured software state, so the machine can demonstrate not merely that it holds a key but that it is the expected system, unmodified, before it is trusted to act. An audit chain anchored to attested hardware answers what ordinary logging cannot: not just what was done, but that it was done here, by this system, in this known state.
Verifiability without a network, and a perimeter with no way out
Air-gapped operation is treated by some suppliers as a degraded mode, tolerated when connectivity is impossible. For sovereign assurance it is the reference design: a system that can be fully verified offline never depended on a live link to a vendor at all.
That posture is enforced by a zero-egress inbound perimeter. Data and instructions can be brought in under control, but the system has no outbound path, so nothing leaves, no telemetry, no model callbacks, no quiet exfiltration through a licensing check. The assurance is not that egress is monitored, it is that egress is not architecturally possible. Because the audit chain is self-contained, an operator loses nothing by cutting the network.
Consensus across models, not faith in one
Assurance also concerns the quality of a decision, not only its record. A single model, however capable, is a single point of failure and of unexamined error. A more defensible pattern for consequential actions is cross-model consensus, several sovereign models reasoning over the same task. When they converge, that convergence is itself evidence. When they diverge, the divergence is surfaced rather than hidden, and routed to a human. Either way the chain preserves the deliberation, not just the answer.
Where the patents and the standards meet
The mechanisms of sealed audit, attested identity, offline verifiability and the zero-egress perimeter sit within a body of 104 filed UK patent applications and approximately 2,340 claims, owned by Mickai LTD, and they are filed and patent pending rather than granted. We describe them because the assurance problem is a shared one, and the field advances faster when the mechanisms are discussed in the open.
They also map onto the frameworks buyers and regulators are already adopting. ISO/IEC 42001 asks organisations to manage AI systems with demonstrable controls. The EU AI Act presses for traceability and human oversight of high-risk systems. Emerging agentic-audit governance asks the sharpest version: prove what the autonomous thing did. A signed, operator-held, offline-verifiable chain answers all three.
What a serious buyer should ask next
The useful test for any defence AI system is not a demonstration of what it can do, it is a demonstration of what it can prove. A CISO, a regulator or a public-sector buyer should ask to see the audit trail, ask who holds the signing keys, and ask whether it verifies with the network unplugged and the vendor uncontactable. The answers separate genuine sovereignty from a relocated dependency.
The assurance gap is the defining problem of autonomous systems in defence, and it will not be closed by better dashboards or stronger promises. It is closed by cryptography the operator controls, identity the hardware attests, and a boundary through which nothing leaves. The operator should be able to prove what the system did, on their own keys, with no one, the vendor included, in the trust path.