The Signature Has To Outlive the Signer

Build for the verifier who has not been born yet

Here is a question almost nobody designing artificial intelligence (AI) systems asks. Who checks the work after everyone who built it is dead? We obsess over training runs, benchmarks, and quarterly safety reviews. We sign things, casually, as if the signature is only for today. But a model that does real work, that approves a payment, files a record, or makes a clinical recommendation, leaves a trail. And that trail has a longer life than any of us. The person who reads it might be a regulator in twenty years, a court in forty, a historian in a century. None of them will have met me. None of them should have to trust me.

That is the uncomfortable shift. We build AI to be trusted in the present tense, by people who can phone the vendor, read the documentation, and assume good faith. The harder and more honest design target is the verifier who has not been born yet. They cannot ask us anything. The company may be gone. The keys may be lost. The only thing that can survive that gap is a record that proves itself, with no living party left to vouch for it. If your safety story depends on someone being around to explain it, you have not built safety. You have built a phone number that will one day stop ringing.

Keys are mortal, and we keep pretending they are not

A signing key is a fragile, perishable thing. It gets rotated. It gets compromised. It gets lost when an employee leaves, a laptop dies, or a hardware security module is decommissioned. Standard practice assumes a short horizon: rotate every year or two, keep the current key safe, move on. That is fine when the thing you are protecting is a web session. It is not fine when the thing you are protecting is the permanent record of what an autonomous system decided to do.

Now stretch the timeline. A model deployed in a hospital, a power grid, or a national registry can plausibly run, in some form, for decades. Over that span you will rotate keys many times. Each old key becomes a liability, because anything signed under it must still verify even though the key itself is retired and possibly broken. And here is the part the industry keeps deferring: a public-key signature that looks unbreakable today is not guaranteed to look that way in thirty years. The migration to post-quantum cryptography is happening precisely because the security community accepts, soberly, that today's elliptic-curve signatures may not survive a future adversary holding a large quantum computer. If your archive of signed actions rests entirely on a scheme that ages out, your proof rots quietly while you sleep. The threat is not only theft today. It is harvest-now, decrypt-later: an adversary who stores your signed history now and breaks it at leisure once the mathematics gives way.

The security-realist position: assume betrayal, including your own

There is a discipline of thinking, common among people who have spent careers watching systems fail, that I find more useful than optimism. It says: assume the key will leak. Assume the vendor will be acquired, will pivot, or will quietly change the logs to look better. Assume that the person with the most motive to rewrite history is the one who controls the database. Assume that you, the author, are not a trustworthy custodian of evidence about your own conduct, because nobody is. Design as if every convenient actor will eventually be compromised or self-interested, and then make the record true anyway.

Apply that to AI and the conclusions get sharp. A log that the operator can edit is not evidence, it is marketing. A signature that only the issuing company can validate is not a guarantee, it is a dependency. A safety claim that evaporates the moment the startup folds was never a safety claim. If the proof of good behaviour requires the continued existence and honesty of the party being audited, you do not have an audit. You have a promise, and promises do not survive succession. The whole point of an audit is that it works against the interests of the person who built it. Anything weaker is theatre with good production values.

Sign before you act, not after

Most logging happens after the fact. The system does something, then it writes a line describing what it did. That ordering is the original sin, because it means the description and the deed are separable. Anyone who controls the writer can let the action happen and then write a flattering account of it, or no account at all. The fix is almost embarrassingly simple to state and genuinely hard to build: sign the intended action before it executes, then chain that signature to the one before it so the whole history is a single unbroken thread. Tampering with any link breaks every link after it, visibly, forever.

This is the core of how we built the Open Audit Record (OAR) inside Mickai. Every action an AI takes is signed before it runs, hash-chained to the prior action, and written to an append-only record. The signing is post-quantum from the start, using the United States National Institute of Standards and Technology (NIST) Federal Information Processing Standard 204 (FIPS 204), the lattice-based scheme known as ML-DSA-65, because retrofitting quantum resistance onto a decades-old archive is not a plan, it is a regret. And the record verifies offline, in an ordinary web browser, with zero trust in us. That last property is the one that matters most for the long horizon. You should not need Mickai to be alive, honest, or even reachable to confirm what Mickai did.

Custody as succession, not as storage

Once you accept that keys are mortal, key custody stops being a storage problem and becomes a succession problem. The question is no longer 'where do we keep the key' but 'how does authority pass from one key to the next in a way a stranger can reconstruct decades later'. Each rotation has to be itself a signed event, anchored by the old key, introducing the new one, so the chain of custody is part of the record rather than a side note in a spreadsheet that will be lost. Done properly, a future verifier can walk the entire lineage of keys from first to last, see exactly when each handover happened, and trust none of the humans involved while still trusting the result.

This is why succession has to be engineered, not improvised. The mechanisms are unglamorous and essential: planned rotation, the ability to retire a compromised key without invalidating the honest history beneath it, trustee arrangements so authority does not die with one person, and a public anchor so the root of the record cannot be quietly re-pointed. In our architecture the audit root is anchored onto an independent sovereign Layer 1, the Pantheon chain, which in turn settles to Bitcoin, so the question 'was this record altered after the fact' has an answer that does not depend on our goodwill. The point is not the specific plumbing. The point is that succession is a first-class design requirement, the same way safety is, and it has to be wired in at the start, because you cannot retrofit a chain of custody onto a history that was never signed.

Why this is sovereignty, not paperwork

There is a regulatory tailwind here, and I would be dishonest to pretend it does not concentrate the mind. From August 2026 the European Union (EU) Artificial Intelligence Act places real obligations on high-risk systems, including record-keeping that lets authorities reconstruct how a system behaved. Liability for what automated systems decide is rising across jurisdictions. The era of 'trust us, the model is fine' is closing. But I do not think compliance is the deep reason to do this. The deep reason is sovereignty. If you cannot prove what your own AI did, without asking permission from the company that sold it to you, then you do not own the system. You are renting deniability from someone else.

A Sovereign Intelligence Operating System (SIOS) has to invert that. The owner holds the proof, the proof outlives the vendor, and the verifier of last resort is a piece of mathematics that does not care who is in the room. We are training our own models toward that end, fine-tuning and specialising open foundations today, building a sealed corpus, and scaling to fully native weights, precisely so the whole stack answers to its owner rather than to us. The fifty brains, the silicon they run on, and the 101 patent applications we have filed in the United Kingdom (UK), all of it is downstream of one stubborn commitment: the record must be true to a stranger in the future, or it is not a record at all.

The author is temporary. The proof should not be.

I will not always be here. Neither will my keys, my company in its current form, or the specific models we run today. That is not morbid, it is just the timescale that serious infrastructure operates on. The mistake is to build as if the present management will always be available to explain itself. Build instead for the verifier who arrives long after the explanations have stopped, holding nothing but the signed chain, and able to check every link without asking anyone for permission.

So the design brief is short, and I would put it on the wall of every team building autonomous systems. Sign before you act. Rotate without erasing. Anchor where you cannot reach back in. Make the proof of what your AI did survive the keys, the company, and the author. Do that, and you have built something that can be trusted by people who will never trust you, and never need to. That is the only kind of trust worth engineering for, because it is the only kind that lasts.