A tamper-evident log makes changes detectable. An immutable log claims change is impossible, which almost no system can hold once storage, backups and key custody are counted. Mickai's Open Audit Record is tamper-evident: append-only, hash-linked, entries signed with ML-DSA-65, with signed checkpoints held off the machine so an edited, removed or rolled-back entry fails verification.
What does tamper-evident actually mean?
Tamper-evident means a change leaves a mark that someone can find. The log does not stop an edit. It makes that edit fail a check anyone competent can run, using the record and a public key. The goal moves from stopping the act to making it visible afterwards.
The seal on a shipping container is the plain version of this. It does not stop anyone opening the doors. It stops anyone opening them quietly. If the seal is broken, or its number does not match the manifest, the inspection has a finding before anything is unpacked.
Prevention and evidence are different problems. Prevention is access control: who can reach the file, with what rights, on which machine. Evidence is verification: given this file today, can I show it is the same sequence of entries that was written, in the same order, with nothing inserted, edited or dropped. A serious audit record needs both, but only one of them can be checked by an outsider months later.
What does immutable mean, and why is it rarely true in practice?
Immutable means the data cannot change. Almost no running system holds that claim once you count where the data actually lives. Entries sit in a file, on a disk, in a filesystem, on a volume, in a snapshot, in a backup, on a replica. Root, a hypervisor administrator, a storage administrator and whoever holds the backup console all work below the layer that promised immutability.
In most products, immutable describes an interface rather than a physical property. The API offers append and read and no update, so nothing in normal operation rewrites history. That is a good design and it is worth having. It is not the same as saying history cannot be rewritten, because the people who maintain the system are not restricted to the API.
Two failures survive a perfectly append-only design that nobody checks from outside. The first is roll-back: restore last Tuesday's snapshot and the log is internally consistent, correctly ordered and missing four days. The second is truncation: remove the last two hundred entries and the remainder still reads cleanly from start to finish. Both look fine from inside. Both are caught only by comparing against something held elsewhere.
How does a hash chain make a change detectable?
Each entry carries a hash of the entry before it. Change one byte in entry forty and its hash changes, so the reference stored in entry forty-one no longer matches what entry forty now is. The break sits at a known position, which tells an auditor where to look rather than only that something is wrong.
To hide that break, you have to recompute entry forty-one and everything after it. In the Open Audit Record each entry is also signed with ML-DSA-65, the post-quantum signature scheme NIST published as FIPS 204 in 2024. Recomputing the chain therefore means re-signing it, which needs the signing key and not just write access to a file.
The chain gives ordering and completeness within the file. The signatures give origin. Together they make editing detectable. What they do not defeat on their own is a wholesale rebuild by someone who holds the key, because a rebuilt chain is a valid chain. That is the gap checkpoints close.
What do signed checkpoints held off the machine add?
A checkpoint is a short signed statement that at a given point the chain head was a particular value. Its usefulness comes from where it is kept: with the customer, in a second location, or with an auditor, rather than next to the record it describes.
Once an independent party holds a checkpoint, a rebuilt or shortened record stops working. The rebuild produces a different head, and the head the auditor already holds does not match it. Roll-back is caught the same way, because a restored file from last week cannot reproduce a head that has already been witnessed. This is the part buyers most often leave out of a requirement, and the part that turns an internally consistent file into something an outsider can test.
Is a keyed hash (HMAC) the same as a signature?
No, and the difference decides who can check the log. Some logs seal each entry with a keyed hash, such as HMAC-SHA256. A keyed hash uses one shared secret both to create a seal and to check it. Only someone holding that secret can verify the log, and anyone holding it can also create new entries that verify. An outside auditor either has to be given the secret, which would let them forge entries too, or has to trust whoever holds it.
A public-key signature splits those powers. Only the private key can sign. Anyone with the public key can verify, and the public key cannot be used to sign. For evidence meant for a third party, such as an auditor, a regulator or a court, that split is the property to ask for. A useful procurement question: can an auditor verify the log offline, with a public key and their own tools, without any secret from the supplier?
What can a tamper-evident log not prove?
Three limits, stated plainly, because a supplier who hides them is telling you something.
It cannot stop destruction. Someone with enough access can delete the whole record, decline to produce an export, or refuse to run the verifier. The design does not prevent that. It makes it conspicuous instead of silent: a missing record, a gap at a known position, or an unexplained refusal is itself the finding.
The assurance reaches as far as the last checkpoint an independent verifier has actually witnessed. Entries written since then are chained and signed, which is worth having, but they are not yet anchored outside the machine that produced them.
It rests on key custody. If the signing key can be used by someone who should not have it, the signatures prove only that something holding the key signed. Custody is an operational control, documented as a dependency, not something cryptography settles on your behalf.
One more limit matters for buyers: the record proves what was recorded, not that what was recorded was wise or correct. It shows which action ran, in what order, and which named person approved it. Consequential actions in SIOS wait for that approval, so the record names a person rather than only a process. Whether the decision was right remains a human judgement.
Is a write-once store or a blockchain really immutable?
Write-once storage and object lock are real controls and I would use them. The property is enforced by the storage service under a retention policy an administrator configured, so the question becomes who administers that policy and who operates the service. Trust has moved, not gone. Write-once storage also protects the object it holds and says nothing about whether the sequence inside that object is complete, which is the question an auditor is asking.
Blockchain immutability is economic and social before it is cryptographic. It works because many independent parties keep copies and rewriting is expensive. Publishing a regulated organisation's audit entries to a public chain creates a data protection problem rather than solving an audit one, so in practice what goes on-chain is a hash of the record. That is a checkpoint with extra steps. The genuinely useful idea is anchoring evidence outside your own custody, and you can have that without putting anything about your customers on a public ledger. This is an argument about the category, not about anyone's product.
Which term belongs in your policy and your contracts?
Write tamper-evident, then write the test, because the word without the test buys nothing. Ask for the record format specification, an export you can take away, a verifier you can run yourself, the public key delivered through a channel that is not the product, and a written list of limits. Useful requirement wording: the supplier shall enable the authority to verify offline, without supplier tooling, that an exported record is complete and unaltered relative to checkpoints the authority already holds.
If a supplier claims change is impossible, ask one question: what happens when an administrator with full access to the machine edits the store. Every honest answer lands in detection, or in prevention by policy. Both of those can be assessed. The slogan cannot.
Nothing in the regulatory picture asks for impossibility. Article 12 of the EU AI Act covers record-keeping: high-risk systems must technically allow the automatic recording of events over the system's lifetime, an obligation the Digital Omnibus deferred to 2 December 2027 rather than removed (Regulation (EU) 2024/1689, Article 12). The NCSC publishes guidance on logging for security purposes that is worth reading next to any logging requirement you are drafting. Regulators ask for records you can produce and defend, which is a detection question.
How does the Open Audit Record use these terms?
We say tamper-evident, and we do not reach for the stronger words. Every consequential action is sealed under ML-DSA-65. Entries are append-only and hash-linked, each one signed. Signed checkpoints are held off the machine. An auditor verifies an exported record offline with a public key, using tools that are not ours. That is the only version of the claim worth anything to a buyer.
SIOS runs on hardware the customer owns, offline capable, with no data egress, so the record is produced and held inside the organisation that has to answer for it. The closed beta is open and one regulated company is onboarding as a design partner. Related reading: the AI audit trail, sovereign AI and ML-DSA-65 explained for the audit trail.
None of this is an argument against cloud, or against the companies building the compute and cloud layer. Cloud stays valuable for work that is not regulated. The argument is with the assumption that a regulated organisation has to rent its intelligence, send its data offsite and take a supplier's word for what happened to it. Tamper-evident is the claim you can check. Immutable is the claim you have to believe.
Frequently asked questions
Is a blockchain audit log immutable?
Not in the absolute sense. A public chain resists rewriting because many independent parties hold copies and rewriting costs money, which is an economic property rather than a cryptographic one. In practice a regulated organisation publishes only a hash, because the entries themselves cannot leave. That hash is a checkpoint, and you can hold checkpoints without a chain.
Can someone simply delete the whole log?
Yes, with enough access to the machine. No design stops that, and any supplier claiming otherwise is overselling. What tamper-evidence changes is the noise it makes: a destroyed or truncated record cannot match the signed checkpoints an auditor already holds, so the absence becomes the finding rather than a quiet gap nobody notices.
Who holds the keys that sign the record?
You do. SIOS runs on hardware you own, so signing happens on your machine and the private key stays inside your estate. Verification needs only the public key, which you can hand to an auditor. We state this as a dependency rather than hiding it: the strength of the record rests on how well that key is held.
Can an auditor check the log without trusting the vendor?
That is the point of the design. An auditor takes an exported record, a public key delivered separately, and the published record format, then verifies the hash chain and the signatures offline with tools that are not ours. If verification needed our software to say yes, it would be a vendor assurance rather than an independent check.
Is tamper-evident enough for a regulator, or do they expect more?
Regulators ask for records you can produce, explain and defend, not for a claim that change is physically impossible. Article 12 of the EU AI Act is about keeping automatic records of events for high-risk systems. Detection, a stated retention period, access control and evidence of who approved what usually answer more questions than a slogan about impossibility.
Related briefings
Governance, audit and oversight
- Human on the Loop vs In the Loop: AI Oversight Explained
- Generative AI Logging Checklist: What UK Firms Record
- AI Audit Logs vs Data Minimisation: Keep Full Prompts?
- AI Incident Response Plan Checklist for UK Organisations
- Keeping Oversight as AI Scales Across a Business
Deploying private AI
- Private AI for Business: What It Is and How It Works
- Offline AI Assistant: What It Can Do for Your Staff
Part of a series of 60 briefings on deploying and governing AI in UK regulated organisations, archived with a DOI at 10.5281/zenodo.22975756.
Evaluating AI for a regulated organisation? Mickai runs on hardware you own, offline. Consequential actions wait for a named person to approve them, and what the AI did is sealed into a signed record an auditor can check without us. Applications for the invitation-only closed beta are open. Apply for the closed beta.
Written by Micky Irons, founder and chief executive of Mickai LTD.
Top comments (0)