Key and identity sovereignty, operator-held keys and encryption at rest
Key and identity sovereignty means the operator holds every key that matters: the keys that sign each Mickai decision, the hardware that produces those signatures, the local audit ledger and the model weights, with the operator key encrypted at rest and backed up under the operator's control. There is no admin override a vendor can invoke and no leased component, so ownership is binary. Because the vendor never holds the signing material or the data, there is no third party that could be compelled to produce your activity, because the vendor never had it.
In cloud AI the customer rents identity and key management from the vendor, which means the vendor holds the keys that could decrypt the data and produce signatures, and a vendor that holds the keys can be compelled to hand over or unlock a customer's activity regardless of any contractual promise. That is the root reason a shared service can never offer true confidentiality for regulated data: the trust boundary sits with the provider, not the owner. There is also usually an administrative override that lets vendor staff reach into a tenant, which is precisely the insider-threat-at-a-hyperscaler exposure that regulated buyers must design out. Mickai removes the exposure by making ownership binary: the operator owns the keys that sign every decision, the hardware that produces those signatures, the local ledger that records them and the model weights themselves, and the operator key is encrypted at rest with a backup and restore path the operator controls for portability. There is no admin override the vendor can invoke, because the vendor never holds the key, and data at rest is encrypted under material the operator holds. The result is that confidentiality is enforced by custody, so no third party can be subpoenaed for activity it never possessed and no vendor employee can reach in.
The 5 controls in this domain, each enforced by construction on hardware you own and mapped to the subsystem that provides it.
Operator-Held Signing Keys
The operator owns the keys that sign every Mickai decision, and those keys live in a TPM 2.0 device, secure enclave or HSM the operator controls rather than in a vendor's key-management service. Because the signing material never leaves the operator's hardware, no vendor can produce a signature on the operator's behalf and no third party can be compelled to sign or unlock activity it does not hold. This is the practical meaning of user-owned: ownership is binary, with no leased key in the chain. The keys are the root of trust for the whole Open Audit Record.
No Vendor Admin Override
Mickai is built with no administrative override that the vendor can invoke, so there is no privileged back door through which vendor staff could reach into a deployment, read data or authorise an action. Governance is executable and enforced before any tool call, and the operator's signature is the only authority the system answers to. This designs out the insider-threat-at-a-hyperscaler exposure that regulated buyers must eliminate, because the vendor simply has no path in. The absence of an override is a property of the architecture, not a promise in a contract.
Encryption At Rest Under Operator Keys
Data at rest and the operator key itself are encrypted under material the operator holds, so a stolen disk or a seized machine does not yield readable regulated data or a usable identity. Because the encryption keys are the operator's and not the vendor's, confidentiality is enforced by custody rather than by a provider's assurance, which is what regulated data requires. This closes the physical-theft and cold-storage exposure that plaintext or vendor-encrypted storage leaves open. Encryption at rest works alongside the hardware-bound identity so both the data and the key are protected.
Key Backup, Restore And Portability
The operator can back up the encrypted operator key, restore it and move it between owned machines, so holding your own keys does not translate into a single point of failure. This gives the resilience an organisation needs, namely a controlled recovery path, without ever placing the key in a vendor's escrow. Portability lets a deployment migrate to new hardware while preserving its identity and its audit continuity, all under the operator's control. Backup and restore run entirely within the operator perimeter with no cloud key store.
Executable Governance Policy
Every permission, quota, retention rule, dead-man's switch and revocation rule is expressed as a cryptographic policy the operator signs, and the system enforces those policies before any tool call rather than after. Governance is therefore executable, not aspirational, and it cannot be quietly overridden because there is no admin path above the operator signature. This turns policy from a document into an enforced control, which is exactly what auditors expect to see evidenced. The signed policy is itself recorded to the Open Audit Record.
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.
Who holds the keys in a Mickai deployment?
The operator holds every key that matters: the keys that sign each Mickai decision, held in a TPM 2.0 device, secure enclave or HSM the operator controls, along with the local audit ledger and the model weights. Because the signing material never leaves the operator's hardware, no vendor can produce a signature on the operator's behalf and no third party can be compelled to unlock activity it does not hold. Ownership is binary, with no leased key in the chain.
Is there any vendor override or back door?
No. Mickai is built with no administrative override that the vendor can invoke, so there is no privileged path through which vendor staff could reach into a deployment, read data or authorise an action. The operator's signature is the only authority the system answers to, which designs out the insider-threat-at-a-hyperscaler exposure that regulated buyers must eliminate. The absence of an override is a property of the architecture, not a promise in a contract.
How is data protected at rest?
Data at rest and the operator key itself are encrypted under material the operator holds, so a stolen disk or a seized machine does not yield readable regulated data or a usable identity. Because the encryption keys are the operator's and not the vendor's, confidentiality is enforced by custody rather than by a provider's assurance. This closes the physical-theft exposure that plaintext or vendor-encrypted storage leaves open, and it works alongside the hardware-bound identity so both the data and the key are protected.
Does holding our own keys create a single point of failure?
No. The operator can back up the encrypted operator key, restore it and move it between owned machines, so holding your own keys does not translate into fragility. This gives a controlled recovery path and lets a deployment migrate to new hardware while preserving its identity and audit continuity, all without ever placing the key in a vendor's escrow. Backup and restore run entirely within the operator perimeter with no cloud key store.
What does user-governed mean in practice?
Every permission, quota, retention rule, dead-man's switch and revocation rule is expressed as a cryptographic policy the operator signs, and the system enforces those policies before any tool call rather than after. Governance is therefore executable, not aspirational, and it cannot be quietly overridden because there is no admin path above the operator signature. The signed policy is itself recorded to the Open Audit Record, so the rules and their enforcement are both evidenced.
Why does key custody matter for confidentiality and legal exposure?
In cloud AI the vendor holds the keys that could decrypt the data and produce signatures, so a vendor that holds the keys can be compelled to hand over or unlock a customer's activity regardless of any contractual promise. Mickai removes that exposure by keeping the keys and the data with the operator, so no third party can be subpoenaed for activity it never possessed and no vendor employee can reach in. Confidentiality is enforced by custody, which is the only durable basis for it.
Review the key and identity sovereignty, operator-held keys and encryption at rest 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.