Model and supply-chain integrity, signed weights and licence provenance
Model and supply-chain integrity ensures that nothing runs inside Mickai unless it is signed: every binary, every brain, every model weight and every skill carries a signature, and loading an unsigned or tampered artefact fails closed. The operator can pin specific signed versions and refuse silent upgrades, so the deployment only ever runs the code and weights the operator has approved. Mickai runs its own specialised sovereign models with tracked licence provenance, so the origin and licensing of every artefact is known and defensible rather than an unverified download.
The AI supply chain is a growing attack surface: a poisoned model weight, a tampered binary or a malicious skill can compromise a system as thoroughly as any network intrusion, and a silent upgrade can change behaviour without the operator's knowledge or consent. In a cloud service the customer has no control over which model version is running, when it changes or where its weights came from, so there is no way to pin a validated configuration or to prove the provenance of the artefacts making decisions about regulated data. There is also a licensing dimension that regulated buyers cannot ignore: an artefact of unknown origin may carry usage terms that are incompatible with commercial deployment, which is a real legal exposure. Mickai closes both problems on hardware you own. Every binary, brain, model weight and skill is signed, and loading an unsigned or tampered artefact fails closed rather than running in a degraded or compromised state; the operator can pin specific signed versions and refuse silent upgrades so behaviour only changes when the operator approves it; and because Mickai runs its own specialised sovereign models with tracked licence provenance, the origin and terms of every artefact are known and defensible. Each load and each version pin is sealed to the Open Audit Record, so the exact software and weights behind any decision can be evidenced.
The 5 controls in this domain, each enforced by construction on hardware you own and mapped to the subsystem that provides it.
Signed Artefacts Fail Closed
Every Mickai binary, every brain, every model weight and every skill is signed, and loading an unsigned or tampered artefact fails closed rather than running in a degraded or compromised state. This closes the supply-chain attack in which a poisoned weight or a malicious binary is slipped into the system, because anything that does not carry a valid signature simply will not run. Failing closed is the safe default: the deployment stops rather than proceeding with an unverified component. Artefact signing is part of the defence-in-depth posture in the filed Sovereign Security Framework patent.
Version Pinning
The operator can pin specific signed versions of binaries, brains, weights and skills, so the deployment only ever runs the exact configuration the operator has validated and approved. This gives a reproducible, known-good state that a regulated firm can test, document and hold steady, rather than a moving target that changes underneath it. Pinning also means a validated configuration can be preserved for the long retention and reproducibility periods that regulated evidence requires. Each pin is recorded to the Open Audit Record.
No Silent Upgrades
Mickai will not silently upgrade itself: behaviour changes only when the operator approves a new signed version, so the system a firm validated on Monday is the same system running on Friday unless a change was deliberately authorised. This closes the risk that a background update alters how the system reasons about regulated data without anyone knowing, which is both a governance and a model-risk problem. The operator decides when and whether to move, and the decision is itself recorded. This complements version pinning to keep the deployment under operator control.
Licence Provenance Tracking
Mickai runs its own specialised sovereign models, and the origin and licensing of every artefact is tracked, so the deployment is not relying on components of unknown provenance whose usage terms might be incompatible with commercial or regulated use. Knowing where each artefact came from and under what terms is a real legal control, because an artefact of unknown origin can carry a licensing exposure a regulated buyer cannot accept. Tracked provenance makes the supply chain defensible in diligence and audit. It gives a firm a clear answer to what is running and on what basis.
Signed Model Load Lineage
Every load of a binary, brain, weight or skill is sealed to the Open Audit Record with its signature and version, so for any decision the system produced, the exact software and weights that produced it can be evidenced after the fact. This ties model-risk governance to a concrete, tamper-evident record of the components in play, which is what a regulator asking how a result was reached ultimately needs. It closes the gap where a decision can be reviewed but the version that made it cannot be established. The lineage uses the same signed audit substrate as the rest of the SIOS.
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.
How does Mickai protect against supply-chain attacks?
Every Mickai binary, every brain, every model weight and every skill is signed, and loading an unsigned or tampered artefact fails closed rather than running in a degraded or compromised state. This closes the attack in which a poisoned weight or a malicious binary is slipped into the system, because anything without a valid signature simply will not run. Failing closed is the safe default, so the deployment stops rather than proceeding with an unverified component. Artefact signing is part of the defence-in-depth posture in the filed Sovereign Security Framework patent.
Can we control which model version runs?
Yes. The operator can pin specific signed versions of binaries, brains, weights and skills, so the deployment only ever runs the exact configuration the operator has validated and approved. This gives a reproducible, known-good state that a regulated firm can test, document and hold steady, rather than a moving target that changes underneath it. Each pin is recorded to the Open Audit Record, and a validated configuration can be preserved for the retention and reproducibility periods that regulated evidence requires.
Does Mickai update itself silently?
No. Mickai will not silently upgrade itself. Behaviour changes only when the operator approves a new signed version, so the system a firm validated is the same system running later unless a change was deliberately authorised. This closes the risk that a background update alters how the system reasons about regulated data without anyone knowing, which is both a governance and a model-risk problem. The operator decides when and whether to move, and the decision is itself recorded.
What models does Mickai run, and how is licensing handled?
Mickai runs its own specialised sovereign models, and the origin and licensing of every artefact is tracked, so the deployment is not relying on components of unknown provenance whose usage terms might be incompatible with commercial or regulated use. Knowing where each artefact came from and under what terms is a real legal control, because an artefact of unknown origin can carry a licensing exposure a regulated buyer cannot accept. Tracked provenance makes the supply chain defensible in diligence and audit.
Can we prove which model version made a given decision?
Yes. Every load of a binary, brain, weight or skill is sealed to the Open Audit Record with its signature and version, so for any decision the system produced, the exact software and weights that produced it can be evidenced after the fact. This ties model-risk governance to a concrete, tamper-evident record of the components in play, which is what a regulator asking how a result was reached ultimately needs. It closes the gap where a decision can be reviewed but the version that made it cannot be established.
Which patents underpin supply-chain integrity?
Supply-chain integrity draws on the Sovereign Security Framework application, which covers the defence-in-depth posture including signed artefacts that fail closed, together with the signed audit substrate used to record every load and version pin. These sit within the 104 filed UK patent applications covering approximately 2,340 claims and owned by Mickai LTD. The controls run entirely on hardware you own, with each load sealed to the Open Audit Record.
Review the model and supply-chain integrity, signed weights and licence provenance 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.