By Micky Irons, founder of Mickai.
There is one question I now put to every organisation that tells me it has taken back control of its data. Not where does your compute run. Not which region your tenancy sits in. Something plainer and more uncomfortable: who holds the signing keys, and who can rotate them without your permission. The room usually goes quiet, because almost nobody has costed the answer.
We have spent three years arguing about cloud exit as if it were a geography problem. Repatriate the workloads, pull the inference back behind your own firewall, stop paying the egress tax, and the sovereignty box is ticked. I used to think that way too. I no longer do. The longer I have spent building a system whose entire value rests on records you can still trust years from now, the clearer it has become that location is the easy half of the question. Custody is the hard half, and it is the half that decides whether you own anything at all.
The cloud-exit debate measured the wrong thing
Compute location is visible, so it is what got measured. You can point at a rack, name a data centre, audit a network diagram. It feels like control because you can see it. Keys are invisible by design, so they slipped out of the conversation entirely. The result is a generation of so-called sovereign deployments where the servers sit in the building and the cryptographic authority sits somewhere else, in a managed key service governed by a contract nobody in the room has read closely.
Consider what a signing key actually does. Every record your intelligence layer produces, every decision, every action, every audit trail you might one day put in front of a regulator or a court, is only worth anything because it carries a signature that says this happened, in this order, and has not been altered since. The signature is the trust. The key is the thing that makes the signature. Move the key off your premises and you have moved the trust off your premises, however many servers you bought.
The hearth holds because one keeper tends it and the keys never leave her belt.
Custody, not location, is the real boundary
Let me name the property precisely, because the phrase matters. Key custody sovereignty means the keys behind your intelligence layer are generated, held, used and rotated on hardware you own, by an authority you control, with no third party able to reach past the threshold. It is not a feature you bolt on later. It is the line that separates an owned intelligence layer from a rented one wearing on-premise clothes.
The test is brutally simple. Ask whether a vendor, acting alone, could re-sign your history. If the honest answer is yes, even in theory, even through a support ticket and one privileged engineer, then you do not own your trust. You are borrowing it, and it can be recalled.
Whoever can rotate the keys can rewrite the past. Sovereignty that stops at the server door and hands the keys to a vendor is a stage set, not a fortress.
What rotation really means when someone else holds the key
Rotation sounds like hygiene. In a sane setup it is. You retire an old key, you bring a new one into service, you keep a verifiable chain so records signed under the old key still validate. Done by the right hand, rotation is how you stay secure over time. Done by the wrong hand, it is the most dangerous capability in the entire system, because the power to introduce a new signing key is the power to decide what counts as authentic going forward.
Here is the part nobody costs. If your provider controls rotation, your provider can do three things you would never knowingly authorise.
- Re-sign records under a fresh key and present a clean, altered history as if it were the original, with the old signatures quietly dropped from validation.
- Suppress specific records by declining to honour the keys that signed them, so inconvenient history simply fails to verify and disappears from the trusted set.
- Repudiate your own actions on your behalf, because a key you do not control is a signature you cannot ultimately stand behind in front of anyone who understands the chain.
None of that requires malice. It requires a subpoena served on the vendor, a state-level demand, a misconfigured policy, a breach of their key service, or a commercial dispute where your leverage evaporates the moment you remember who actually holds the keys. The threat model is not a cartoon villain. It is ordinary institutional pressure landing on a party that is not you.
The threshold is the whole point. No outside hand gets past it, no matter who sends it.
Why I built Mickai around custody, not location
This is the conviction underneath the Mickai Sovereign Intelligence Operating System. Fifty specialised brains run on the operator's own hardware, fully offline-capable, which is the location half of the answer and the half everyone fixates on. The half I lose sleep over is the other one. Every consequential action the system takes is sealed into a post-quantum Open Audit Record, signed under FIPS 204 ML-DSA-65, and the key that produces that seal is generated and held on the operator's own machine. Not escrowed with us. Not mirrored to a managed service. Held by the operator, rotated by the operator.
That choice costs us something commercially. A vendor-held key is a recurring relationship, a dependency you can monetise, a reason the customer can never quite leave. I gave that up on purpose. The moment Mickai could rotate a customer's keys, Mickai would become the weak point in their sovereignty, and I would be selling the exact thing I claim to abolish. The whole proposition collapses if the keys live with the vendor. So they do not.
Post-quantum is not a buzzword here, it is the custody horizon
There is a temporal dimension people miss. An audit record is a promise made to the future. It might be challenged in five years, in fifteen, in a courtroom or an inquiry that does not yet exist. Which means the signature has to survive not only today's adversaries but tomorrow's, including the arrival of cryptographically relevant quantum computers that will break the classical signatures protecting most records signed this decade.
That is why the seal uses a lattice-based, post-quantum scheme rather than a comfortable, familiar classical one. But notice that custody and post-quantum strength are the same argument from two angles. A future-proof signature held by a vendor is still a borrowed signature. A self-held signature using yesterday's broken maths is still a signature that will not hold up. You need both: the strongest available scheme and undisputed custody of the key that wields it. Either one alone is a false comfort.
A seal made to outlive its maker, struck by the keeper's own hand at her own fire.
The questions to put to any vendor before you sign
Here is the diligence I wish more buyers ran, because it cuts through the marketing in about four questions. If a supplier of any owned-intelligence claim cannot answer these cleanly, walk.
- Where are the signing keys generated, and can you prove they never left our hardware in the clear at any point in their lifecycle.
- Who, under any circumstance, can initiate a key rotation, and is there any path, contractual, technical or via your support function, by which you could do it without us.
- If we terminate tomorrow, do the keys and the full verifiable history remain entirely ours and independently verifiable, with no service of yours running.
- What signature scheme protects the records, and is it chosen to survive a quantum-capable adversary, not merely today's attacker.
Watch for the soft answers. We use bank-grade encryption tells you nothing about custody. Your data never leaves your region dodges the key question entirely. We are SOC 2 certified describes the vendor's hygiene, not your ownership. The only answer that means anything is the dull, specific one: the keys are yours, generated and held on your hardware, and there is no path by which we can rotate them.
Custody is what you cannot outsource and still call it yours
I keep returning to a very old image for this, older than computing by a few thousand years. The hearth that the keeper tends herself, in the inner room, with the household keys on her own belt and no outside hand permitted past the threshold. It is not a metaphor I reach for to sound grand. It is the actual security model. The fire is your history. The keys are the right to seal it. And the entire value of the arrangement is that one keeper, inside your own walls, holds both and admits no one.
You can rent compute. You can rent storage. You can rent models, though we will train our own and rent none. What you cannot rent, not without quietly handing back the sovereignty you paid for, is custody of the keys that decide whether your past stays true. That is the line. Everything I have built sits on the right side of it, and every serious owner of an intelligence layer is going to have to choose a side, whether they have costed the choice or not.
One keeper, one flame, one set of keys that never leaves the room. That is what owning the trust looks like.
So ask the quiet question, and refuse to be comforted until the answer is the dull one. If your provider can rotate the keys, you never owned the trust. You only borrowed it, and borrowed trust always comes due.
Written by Micky Irons. Originally published at https://mickai.co.uk/articles/key-custody-is-the-sovereignty-question-nobody-costed. More from Micky Irons and Mickai at mickai.co.uk.
