Key custody for the long horizon

A signature is a promise made to strangers

When you sign something, you are not really talking to the person in front of you. You are talking to whoever shows up later. The auditor who opens the file in three years. The regulator who pulls a record after an incident. The litigator who wants to know what your system decided and why, long after the engineer who built it has moved on. A signature is a promise made to strangers you will never meet, in a future you cannot see. That is the part most people get wrong about cryptography in artificial intelligence (AI) systems. They treat the key as a login credential, something to use today and forget tomorrow. But a signature is the opposite of a login. A login proves who you are right now. A signature has to keep proving something true after you, your company, and your hardware are gone.

I build a Sovereign Intelligence Operating System (SIOS) called Mickai. It is built and in production, not a slide deck and not a plan. At the heart of it sits the Open Audit Record (OAR): every action one of our brains takes is signed before it executes, hash-chained, append-only, and verifiable offline in an ordinary browser with no trust in the vendor. That design forces a question most teams never ask out loud. If the signature has to survive decades, who holds the key, and how do they hand it on without breaking the chain? This piece is about that question. Key custody for the long horizon. It is less glamorous than model training and more important than most of it.

I want to be precise about why this matters to me specifically. Mickai holds 101 filed United Kingdom patent applications, roughly 2,234 claims, owned by Mickai LTD with me named as the inventor. A large share of that portfolio describes the record, the custody, and the verification machinery I am about to walk through. So this is not a thought experiment I am borrowing from somewhere else. It is the discipline we have spent years actually building, and the part of the system I would defend first if you took everything else away.

The mismatch between key lifetimes and record lifetimes

Start with a simple observation that has uncomfortable consequences. The records an AI system produces are durable. The keys that sign them are not. A medical decision, a credit refusal, a safety override, an automated trade. These are the kinds of actions European Union (EU) and other regulators increasingly expect you to explain after the fact, and the obligation does not expire when your signing key does. The EU Artificial Intelligence Act brings its high-risk obligations into force from August 2026, and the logic running through all of it is the same: keep a trustworthy record, and be able to produce it on demand. A record you cannot prove the origin of is not a record. It is a rumour with timestamps.

Now look at the key. Good practice says you rotate signing keys regularly, because a key that signs for years is a key that has more chances to leak, more exposure to a compromised machine, more attack surface as your team and infrastructure change. So you have a record that must stay verifiable for many years and a key you intend to retire in a fraction of that time. Those two timelines do not naturally fit. If you rotate the key and throw away the public half, every signature it ever made becomes unverifiable. If you never rotate, you are betting the whole archive on one secret never leaking, which is not a bet, it is a hope. Custody for the long horizon is the discipline of holding both truths at once: keys are short-lived, records are long-lived, and the verifier in the future must not need to care that they differ.

Most teams discover this mismatch the hard way, usually during an investigation, when someone asks them to verify a record signed by a key that was rotated out years earlier and never properly preserved. The honest answer in that moment is, we cannot. That is a failure of design, not of luck. The mismatch is foreseeable from day one, which means it can be engineered around from day one. Everything that follows in this piece is, in one way or another, an answer to this single tension between the lifetime of the proof and the lifetime of the thing it proves.

Rotation without amnesia

The instinct around key rotation is to treat the old key as garbage once the new one is live. That instinct is correct for the private half and dangerous for the public half. The private signing key, once retired, should be destroyed properly so it can never sign again. But the public verification key must live forever, because every signature the old key produced still needs to be checked against it. Rotation without amnesia means you retire the ability to sign while preserving, permanently, the ability to verify. The two halves of a key pair have opposite lifecycles, and the whole trick is refusing to treat them the same.

Concretely, that means each signing key has a published lifetime: a start and an end, recorded in the chain itself, not in a database you might lose. A signature is valid if it was made by a key during that key's active window and the action it covers carries a timestamp inside the same window. So the verifier in the future does not ask, is this key still in use? That would be the wrong question, because no key is in use forever. The verifier asks, was this key authorised to sign at the moment this record was created? That question has a permanent answer. You move the trust from the freshness of the key to the consistency of the timeline, and timelines, unlike secrets, can be made tamper-evident.

In the OAR this falls out of the structure rather than being bolted on. The record is hash-chained and append-only, so the moment a key was introduced and the moment it was retired are themselves entries in the chain. You cannot quietly backdate a key into existence to forge an old record, because doing so would break every hash that came after it. Rotation becomes a public event with a fixed place in history, not a quiet swap in a configuration file. That is the difference between a system that merely rotates keys and one that can prove, decades later, exactly when each key was allowed to act and that nobody moved the boundaries afterward.

Why one key is one person too few

Here is the failure mode nobody wants to admit to. A single signing key held by a single person, or living on a single machine, is a single point of catastrophe. If that key leaks, an attacker can sign as your system. If that key is lost, your system can no longer sign at all, or worse, can no longer prove succession to a new key. If the person holding it leaves, or is compromised, or simply makes a mistake at three in the morning, the entire integrity of the record rests on that one moment. Custody concentrated in one place is not security. It is a hostage situation you have arranged for yourself.

The answer is threshold signing, sometimes called a threshold scheme or, in its simpler form, multi-signature. Instead of one key that can act alone, you split the signing authority among several holders and require some agreed number of them to act together. A common shape is what is informally called k of n: there are n holders in total, and any k of them must cooperate to produce a valid signature. Five holders, any three required. Seven holders, any four required. The exact numbers are a governance choice, not a technical one, and they should be argued about openly rather than chosen by whoever set up the system first.

What threshold signing buys you is the removal of the single point of failure in both directions at once. No one holder can sign alone, so a single leaked or coerced key does nothing. And no one holder can stop the system either, because losing one share of n still leaves enough to reach the threshold. You have made the system robust against both the dishonest insider and the unlucky accident. The cost is coordination, and coordination is exactly the thing you want to be hard for a signing action that matters. The friction is the feature. A signature that any one person can produce alone, in a hurry, with nobody watching, is a signature that any one person can be forced to produce alone, in a hurry, with nobody watching.

Succession is the test most systems fail

Rotation handles the planned handover of one key to its successor. Succession handles the unplanned, harder thing: what happens when the people, the company, or the founder behind the system change, and authority itself has to pass to someone new. This is where I see almost every design quietly assume it will never matter. The original team will always be there. The current organisation will run forever. The founder will hold the keys until the heat death of the universe. None of that is true, and pretending it is just means the failure, when it comes, is sudden and unmanaged instead of planned.

Good succession looks boring on purpose. It is a documented, rehearsed procedure for transferring signing authority from one set of holders to another, and crucially, it leaves a trace. When authority passes, that handover is itself a signed, recorded event: the outgoing holders attest the transfer, the incoming holders are introduced into the chain, and the link between the two is permanent. A future verifier can walk the whole lineage. Key A signed records, key A handed to key B under a recorded succession event, key B handed to key C, and every step is checkable without trusting anyone's word for it. The chain of custody becomes part of the audit record rather than a story told about it afterwards.

This is also where the mechanisms people find slightly morbid earn their keep. A dead man's switch that triggers a succession if the holders go silent for too long. Trustee arrangements so authority passes to a named, accountable party rather than evaporating. Key rotation tied to those events rather than left to ad hoc decisions. These designs are not paranoia. They are the difference between a system whose integrity survives the absence of any particular human and one that quietly depends on a person who will not always be available. I would rather build the former and be accused of over-engineering than build the latter and be proven naive when it is too late to fix.

Signing today for a verifier in 2050

Now the part that makes long-horizon custody genuinely different from ordinary key management. The verifier you are signing for might be opening your record decades from now, on hardware and software you cannot imagine, in a world where the cryptography you trust today may have been broken. That last point is not science fiction. The migration to post-quantum cryptography is already underway across serious institutions precisely because a sufficiently capable quantum computer would break the classical signature schemes much of the internet runs on. Harvest now, decrypt later is a real strategy: an adversary stores your signed records today and waits for the machine that can forge or unpick them. If your signatures rest on cryptography that ages badly, your archive has a silent expiry date you did not choose.

This is why our signing uses a post-quantum scheme, the United States National Institute of Standards and Technology (NIST) standard known as the Module-Lattice Digital Signature Algorithm at security level 65 (ML-DSA-65, published in Federal Information Processing Standard 204). I am not going to pretend a specific standard is eternal, because nothing in cryptography is. The honest position is humbler and, I think, stronger: you choose the most durable scheme available now, you build the record so the signature algorithm is itself named and versioned inside each entry, and you design custody so that migrating to a future scheme is a recorded succession event rather than a rewrite. The verifier in 2050 does not need your assurances. They need a record that tells them exactly which algorithm signed which entry, and a chain that proves nobody changed the answer in between.

There is a deeper point hiding in that design choice. Naming the algorithm inside each entry turns cryptographic agility from a marketing word into a property you can actually check. When a scheme is eventually deprecated, you do not panic and you do not silently re-sign the archive, which would itself destroy the evidence. You introduce the new scheme as a recorded event, you keep verifying old entries against the old scheme and the public keys you preserved, and you let the chain carry both eras honestly. The record tells the truth about its own history, including the parts where the state of the art moved on. That is what it means to sign today for someone you will never meet: you give them the means to judge your cryptography by their standards, not just yours.

Offline is the property that makes the rest matter

Everything above is undermined if checking it requires trusting the vendor. Picture the version that fails. To verify a record, you call the company's application programming interface (API), it consults its own database, and it tells you the signature is good. You have learned nothing. You have asked the suspect whether the suspect is guilty. If that company is gone, hostile, hacked, or simply uninterested in your case fifteen years from now, your verifiable record was never verifiable at all. It was a promise that only the promiser could check.

So the custody design only pays off if verification is offline and independent. In the OAR, you can take the record, the public keys, the succession events, and the hash chain, open them in an ordinary browser with no network connection and no relationship with us, and confirm the whole thing yourself. The mathematics either checks or it does not. That is the entire point of holding public keys forever, of recording rotation and succession in the chain, of naming the algorithm inside each entry: it adds up to a record a stranger can verify with no trust in the vendor, including the case where the vendor is us and we are no longer around to be trusted.

There is one more layer, because offline verification still rests on the integrity of the timeline itself, and a timeline held by one company is a timeline one company can be pressured to rewrite. To anchor the root of that chain beyond any single party, we are building Pantheon, a sovereign Layer 1 blockchain that commits the audit root to Bitcoin, so the timeline has a witness no one company controls. Its native token is PAN, with a fixed supply of five billion. Pantheon is the one part of this story still in build while the SIOS itself runs in production, and I would rather tell you that plainly than blur the line. The principle it serves is simple: the strongest proof of when something happened is one that even I cannot quietly move after the fact.

The honest caveats

I will not sell this as solved. Threshold schemes move the risk rather than abolishing it: now your problem is the secure ceremony that generates and distributes the shares, and the governance that decides who holds them. Succession procedures are only as good as the rehearsals you actually run, and most organisations write the runbook once and never test it. Post-quantum standards will keep evolving, which means migration is not a one-time event but a permanent capability you have to maintain. And offline verification puts a real burden on whoever does the checking to use trustworthy tools, because a tampered verifier can lie about a perfect record.

None of these are reasons to skip the work. They are the shape of the work. Anyone who tells you key custody for the long horizon is a feature you ship once is selling you the rumour, not the record. The right posture is the one I try to hold on everything we build: name the residual risks out loud, design so that no single failure is fatal, and keep the means of checking in the hands of the people who will need to check. A system that is honest about its own limits is far easier to trust than one that claims to have none, and it is also, not coincidentally, far more likely to survive contact with a determined adversary.

What you are really buying

Strip it back and long-horizon custody comes down to one principle: separate the thing that must change from the thing that must not. Keys must change. They rotate, they retire, authority passes from hand to hand, and the algorithms behind them will be replaced as the threats evolve. The record must not change. Its integrity, and your ability to prove it, has to outlive every key that ever touched it, every person who ever held one, and the company that built the whole arrangement, including mine. Get that separation right and the future verifier never has to trust you. They trust the mathematics, the chain, and the recorded lineage of custody, and those things do not depend on you still being here.

That is the thesis I keep coming back to, across every part of what we build, including the models we are training ourselves right now by fine-tuning and specialising open foundations and assembling our own sealed corpus. The valuable artefact is not the model, and it is not even the key. It is the signed, hash-chained, post-quantum, offline-verifiable record, and the discipline of custody that keeps it provable long after everyone who made it has gone. Sign before you act, hold the public proof forever, hand the authority on in the open, and let a stranger check your work with no trust in you at all. Do that, and your signature finally keeps the promise it was always making: to be believed by people you will never meet, in a future you will not see.