The UK procurement checklist for sovereign AI in 2026. Seven properties, eleven contract clauses, one filing reference.

Procurement teams across UK government, NHS, defence, financial-regulator, and critical-infrastructure environments are writing AI procurement specifications without a usable structural checklist. The frameworks vendors are publishing are governance-themed; the actual structural properties that distinguish sovereign AI from sovereign-themed AI are absent from most specs. The result is procurement decisions that look defensible at signature and become indefensible after the first incident.

This article is the checklist. Seven structural properties from the Mickai manifesto (mickai.co.uk/articles/the-2026-sovereign-ai-manifesto) operationalised into eleven contract clauses with the supporting evidence each clause requires. It is designed to be pasted into an actual procurement document, edited for the specific deployment, and used as the structural acceptance test for any vendor proposal.

The seven properties (recap)

• 1. Physical locality.
• 2. Operator-side audit.
• 3. Hardware-bound identity.
• 4. Cryptographic tenant isolation.
• 5. Post-quantum signed memory.
• 6. Action-level rollback.
• 7. Runtime perimeter on every agent.

Each is described in detail in the manifesto article. The clauses below assume the buyer has read or links to the definitions.

Clause 1: Locality and right of refusal

The Vendor warrants that the deployed system performs all model inference, retrieval, audit-ledger writes, and long-term memory storage on hardware physically possessed by the Buyer at sites under the Buyer's exclusive operational control. The Vendor further warrants that the deployed system shall continue to perform its declared purpose for at least seventy-two hours when the Buyer disconnects all external network links. The Buyer reserves the right to perform the disconnection test at any time during the contract term.

Clause 2: Operator-side audit ownership

The Vendor warrants that the audit ledger for all decisions, actions, retrievals, and tool invocations performed by the deployed system is written under cryptographic keys whose private halves are held exclusively in hardware controlled by the Buyer. The Vendor shall not have read or write access to the audit ledger except as explicitly authorised in writing by the Buyer for a specific support engagement. Any vendor-side telemetry is opt-in by the Buyer and disabled by default.

Clause 3: Hardware-attested actor identity

The Vendor warrants that every actor identity recognised by the deployed system (user, agent, tool, downstream service) is bound to a hardware-attested cryptographic key, with the private half resident in TPM 2.0, secure enclave, hardware security module, or equivalent attested hardware approved by the Buyer's security authority. The Vendor shall provide attestation evidence that no actor identity has been issued whose private key has ever existed outside the attested hardware.

Clause 4: Cryptographic multi-tenancy

Where the deployed system supports multiple tenancies (organisational, departmental, classification, clinical, or other), the Vendor warrants that tenancy isolation is enforced by per-tenant encryption with no shared decryption surface accessible to the operating system kernel or to vendor-side support tooling. Tenancy switches shall require explicit hardware-attested authorisation and shall be recorded in the operator-side audit ledger under Clause 2.

Clause 5: Post-quantum signed audit records

The Vendor warrants that every audit record written under Clause 2 is signed under FIPS 204 ML-DSA-65 (or a successor post-quantum signature scheme approved by the Buyer's security authority) at the moment of generation. The signing scheme shall be in operation from contract commencement; retrofitting signatures after the fact is not acceptable evidence of compliance. The Buyer reserves the right to verify any signed record using the public key associated with the signing operation.

Clause 6: Inverse-action ontology and retroactive rollback

The Vendor warrants that every action the deployed system can perform declares its compensating inverse at action-definition time. The compensating inverse shall be stored alongside the signed action record under Clause 5 and shall be sufficient to revert the side effects of the action when applied to the post-action state. The Buyer reserves the right to issue a retroactive undo against any signed action; the deployed system shall construct the inverse chain and revert the side effects within a Service Level Agreement to be agreed at contract signature.

Clause 7: Runtime perimeter on every AI agent

Where the deployed system permits the operation of AI agents (whether developed by the Vendor, by the Buyer, or by third parties), the Vendor warrants that every action originating from an AI agent process is mediated at the syscall layer by a perimeter component that runs in a separate trust domain at a privilege the agent process cannot reach. The perimeter shall classify, snapshot, and sign every destructive action before commit. The Vendor shall provide the perimeter's policy specification, the classifier corpus, and the snapshot retention policy as part of the deliverable.

Clause 8: Pre-commit dry-run simulation for irreversible actions

Where the deployed system permits an AI agent to perform an action with irreversible side effects (deletion, transfer, transmission to a non-Buyer party, irreversible state mutation), the Vendor warrants that the action shall be simulated against a sandboxed copy of the affected resource before commit, the structured diff of the simulated outcome shall be presented for approval (human or policy), and the action shall not commit without explicit approval. Approval policy shall be configurable by the Buyer per resource class.

Clause 9: Federation across institutional boundaries

Where the deployment includes cooperation with Mickai-class systems operated by external institutions (defence subcontractors, NHS trusts in other regions, financial-regulator counterparties), the Vendor warrants that the federation protocol shall require hardware-attested identity attestations from each peer, signed federation records published to an append-only log auditable by all parties, and explicit Buyer policy for which classes of work may cross which boundaries. Cross-boundary work shall be auditable end to end under Clauses 2 and 5.

Clause 10: Disclosure of dependence on third-party hosted services

The Vendor shall enumerate, in writing, every third-party hosted service the deployed system depends on at any point in its operating cycle. For each dependency, the Vendor shall identify the data classes that flow to or from the service, the contractual basis under which the service holds the data, the procedure available to the Buyer to refuse the dependency without loss of declared functionality, and the effect on the deployed system if the dependency becomes unavailable. The Buyer reserves the right to refuse any dependency on contractual or security grounds.

Clause 11: Patent provenance and structural durability

The Vendor shall identify the patent or patent application reference, by jurisdiction and application number, covering each of the structural properties named in Clauses 1 to 7. Where the structural property is satisfied by composition of multiple patent claims, the Vendor shall identify the composition by claim block and reference. The Buyer relies on the patent provenance as evidence of structural durability and architectural commitment. A vendor unable to identify the patent provenance for one or more of the structural properties is not, for the purposes of this procurement, satisfying the property by construction.

Why the patent reference matters in procurement

Procurement teams have spent two decades being told that intellectual property is a commercial concern, not an architectural one. In sovereign-AI procurement that distinction collapses. A vendor whose architecture is composed by reference to filed patent claims has made an architectural commitment that survives team changes, vendor acquisition, and roadmap drift. A vendor whose architecture is described in marketing material has made a marketing commitment that does not. The patent reference is the difference between a structural commitment and a promissory one.

Mickai's filed UK patent applications are recorded on the UK IPO public register at numbers GB2607309.8 to GB2610422.4. Thirty-one filed patent applications, nine hundred and fourteen cryptographically signed claims, named inventor Micky Irons. The claims that map to each of the seven properties are as follows.

• Property 1 (Locality) is the design assumption underlying every Mickai patent in the portfolio. It is not a single claim; it is the architectural baseline.
• Property 2 (Operator-side audit) maps to Patent 16 (Decision Lineage and PQ-Signed Audit Ledger).
• Property 3 (Hardware-bound identity) maps to Patent 12 (Typed-Action Ontology with hardware-attested actor binding).
• Property 4 (Cryptographic tenant isolation) maps to Patent 04 (Adaptive Multi-Tenant OS).
• Property 5 (Post-quantum signed memory) maps to Patent 08 (Quantum-Safe Attestation, ML-DSA-65, FIPS 204 application).
• Property 6 (Action-level rollback) maps to Patent 14 (First-Class Actions with Compensating Rollback).
• Property 7 (Runtime perimeter on every agent) maps to Patent 21 (Sentinel: Universal AI-Agent Action Interceptor).
• Clause 8 (Pre-commit dry-run simulation) maps to Patent 13.
• Clause 9 (Federation across institutional boundaries) maps to Patent 17.

How Mickai is structured for procurement engagement

Mickai is held privately by its founder. There is no parent operator, no licensing intermediary, no commercial layer between the inventor of the claims and the procurement counterparty. A buyer engaging Mickai engages the inventor directly. The licensing terms can be structured per-deployment, per-vertical, or as a strategic cross-licence, in a single conversation. The contact is press@mickai.co.uk.

Where this sits

Mickai is the sovereign AI operating system. Thirty-one filed UK patent applications. Nine hundred and fourteen cryptographically signed claims. UK IPO public register, GB2607309.8 to GB2610422.4. The seven structural properties and eleven contract clauses are designed to be used by anyone writing a procurement spec for sovereign AI in a regulated UK environment, irrespective of whether Mickai is the chosen vendor. The framework is the contribution; the vendor selection is downstream.

“Sovereign means the procurement test is structural. The clauses are checkable. The patent provenance is auditable. The vendor's marketing roadmap is irrelevant to the test.”

Sources

• Mickai patent portfolio: mickai.co.uk/patents (31 filed UK patent applications, 914 signed claims, UK IPO public register, GB2607309.8 to GB2610422.4).
• Previous Mickai articles: mickai.co.uk/articles/the-2026-sovereign-ai-manifesto, mickai.co.uk/articles/authority-at-execution-is-the-control-point, mickai.co.uk/articles/federated-fleet-coordination-for-sovereign-ai, mickai.co.uk/articles/twenty-one-uk-sovereign-ai-patents-collaboration-open.
• FIPS 204 (ML-DSA): NIST post-quantum digital signature standard, federal requirement 2024.
• UK Cabinet Office and HM Treasury procurement guidance for AI in regulated sectors (current cycle).