Hardware attestation, TPM 2.0 and measured boot
Hardware attestation roots the whole system in silicon the operator holds: identity is bound to a TPM 2.0 device, secure enclave or hardware security module that cannot be exported, and every Mickai signature is produced by that key. Measured boot proves the platform started in a known-good state before any brain runs, so the environment producing the audit record is itself attested. Copying the software to another machine produces a fresh, unauthorised identity the system refuses to recognise, which means sovereignty is cryptographically tied to the device and cloning is mathematically refused.
A signature is only as trustworthy as the environment that produced it, so an audit record signed by a software key that can be copied, exported or run on an unattested machine gives false assurance rather than real accountability. Cloud AI cannot offer hardware-rooted identity to the customer, because the keys live in the vendor's infrastructure and the boot state of the inference host is entirely opaque, which means the customer cannot prove which machine produced a decision or that it had not been tampered with. For clinical, defence and financial deployments, the standard is that identity is bound to hardware the operator controls and that the platform can attest it booted a known-good stack before processing any regulated data. Mickai meets that standard by binding operator identity to a TPM 2.0 device, secure enclave or HSM whose private key cannot leave the hardware, by taking measured-boot measurements that prove the platform integrity of the machine before the brains start, and by refusing to recognise a cloned instance whose identity does not match the enrolled hardware. The result is that every entry in the Open Audit Record is anchored to a specific, attested device the customer owns, which no shared cloud can replicate.
The 5 controls in this domain, each enforced by construction on hardware you own and mapped to the subsystem that provides it.
Hardware-Bound Operator Identity
The operator's cryptographic identity is bound to a hardware key held in a TPM 2.0 device, a secure enclave or a hardware security module, and that private key cannot be exported from the hardware. Every Mickai signature, and therefore every entry in the Open Audit Record, is produced by that hardware-held key, so a decision can be attributed to a specific device the operator controls. This removes the risk of a portable software key that could be copied to an attacker's machine, because the signing material never exists outside the secure element. The vendor never holds the key, so the vendor can never sign on your behalf.
Measured Boot Platform Integrity
Measured boot records cryptographic measurements of the boot chain, so the platform can attest that it started in a known-good state before any brain runs or any regulated data is processed. If the measurements do not match the expected values, the deployment can refuse to release keys or process sensitive workloads, which closes the risk of a tampered or backdoored platform silently producing signed records. This ties the trustworthiness of the audit record to the integrity of the machine that produced it. Platform attestation is the foundation on which the hardware-bound identity rests.
Clone Refusal
Because sovereignty is cryptographically tied to the enrolled hardware, copying the Mickai software to a different machine produces a fresh, unauthorised identity that the system refuses to recognise. Cloning is mathematically refused rather than merely discouraged, so a stolen disk image cannot be spun up as a working, trusted instance elsewhere. This protects the deployment against lift-and-shift theft and against an insider attempting to run a shadow copy outside governance. The refusal is enforced by the hardware key binding, not by a licence check that could be bypassed.
Hardware-Attested Actor Binding
Every action the system can perform is typed against a strict ontology and bound to a hardware-attested actor identity, so the record shows not only what was done but which attested actor on which attested device did it. This gives unambiguous provenance for each entry in the Open Audit Record and prevents an action being attributed to an identity that cannot be tied back to real hardware. Combined with measured boot, it means both the actor and the environment are attested at the point the action is signed. The typed-action-to-actor binding is anchored in the filed Typed-Action Ontology patent.
Fleet Trust Enrolment
Where an operator runs several devices, each attests to the others through a trust-on-first-use enrolment that the owner signs, so a workstation, a server and a hub form a coordinated fleet without any device or cloud acting as the master. State is shared through end-to-end encrypted channels, and the operator key remains the root of trust across the fleet. This lets multi-device and multi-site deployments preserve hardware-rooted identity end to end rather than falling back to a cloud directory. Fleet coordination is anchored in the filed Federated Fleet Coordination patent.
The advantages hold across every control domain, and they are architectural, not promotional. The third-party cloud-exposure vector is removed; your own physical, insider and compliance controls remain yours.
The data never leaves your hardware, so no third party and no cloud-provider employee ever sees it. What happens in the server room stays in the server room.
You own the compute and the capability, so the system runs independent of the internet and of any cloud vendor's pricing, terms, or availability.
The data never crosses a geographical or digital border because it never leaves the building, which removes the cross-border-transfer and third-party-processing friction of UK GDPR, Schrems II, and the sector rules. You keep your own obligations.
Fine-tune and run retrieval on your deepest archives to build a hyper-customised co-pilot, with no risk of your proprietary edge training a public model or leaking.
After the hardware and licence, queries cost essentially electricity. A capital asset you own and depreciate, instead of volatile per-token cloud bills.
There is no third-party cloud path, so no competitor and no vendor insider can scrape, intercept, or subpoena your prompts or your fine-tuned weights from the internet. The trust vault is closed by architecture.
You own the software snapshot on your own hardware, so a change to a cloud vendor's terms, a model deprecation, or an outage cannot reach you. The system stays predictable and auditable on-premise as the rules evolve.
What is hardware-bound identity in Mickai?
The operator identity is bound to a hardware key held in a TPM 2.0 device, a secure enclave or a hardware security module, and that private key cannot be exported from the hardware. Every Mickai signature is produced by that key, so each decision and each audit-record entry can be attributed to a specific device the operator controls. Copying the software to another machine produces a fresh, unauthorised identity that the system refuses to recognise, so cloning is mathematically refused rather than merely discouraged.
What does measured boot add?
Measured boot records cryptographic measurements of the boot chain so the platform can attest that it started in a known-good state before any brain runs or any regulated data is processed. If the measurements do not match the expected values, the deployment can refuse to release keys or process sensitive workloads. This ties the trustworthiness of every signed audit record to the verified integrity of the machine that produced it, which a shared cloud host cannot offer to the customer.
Why can a cloud service not offer the same attestation?
In a shared cloud, the signing keys live in the vendor infrastructure and the boot state of the inference host is opaque to the customer, so the customer cannot prove which machine produced a decision or that it had not been tampered with. Mickai instead binds identity to hardware you hold and attests the platform integrity of your own machine, so the whole chain of trust sits with the operator. This is the difference between attestation you control and assurance you have to take on faith.
What happens if someone copies the Mickai install to another machine?
The copy produces a fresh, unauthorised identity that the system refuses to recognise, because sovereignty is cryptographically tied to the enrolled hardware key. A stolen disk image therefore cannot be spun up as a trusted, working instance elsewhere, which protects against lift-and-shift theft and against an insider running a shadow copy outside governance. The refusal is enforced by the hardware key binding, not by a licence check that could be bypassed.
How does attestation work across several devices?
Where an operator runs several devices, each attests to the others through a trust-on-first-use enrolment that the owner signs, so the devices form a coordinated fleet with no device or cloud acting as the master. State is shared over end-to-end encrypted channels and the operator key remains the root of trust across the fleet. This preserves hardware-rooted identity end to end for multi-device and multi-site deployments, and it is anchored in the filed Federated Fleet Coordination patent.
Which patents cover the attestation layer?
Hardware attestation draws on several of the 104 filed UK patent applications, including the Quantum-Safe Attestation application for the signing scheme, the Typed-Action Ontology application for binding each action to a hardware-attested actor, and the Federated Fleet Coordination application for multi-device trust enrolment. The portfolio covers approximately 2,340 claims and is owned by Mickai LTD.
Review the hardware attestation, tpm 2.0 and measured boot controls with us.
Briefings are for organisations weighing a sovereign, on-premise deployment. Tell us about your estate and threat model and we will walk the controls, the attestation surface and the deployment that fits.