Chain every entry to the one before it with a cryptographic hash, write entries to storage that cannot be overwritten, and copy regular checkpoints of the chain to a system run by someone else. Then let internal audit verify the chain independently. Any edit, deletion or insertion breaks the chain at a point you can find, which is what tamper-evident means.
Tamper-proof or tamper-evident?
No record is fully tamper-proof against someone with enough access. The realistic goal is tamper-evident: if anyone changes the record, the change can be detected and located. That is enough for auditors and regulators, because it means the record can be trusted until a check shows otherwise, and the check is cheap.
An append-only record is the starting point: entries are added, never changed or removed. Tamper evidence is how you prove it stayed that way.
What are the steps, and who acts?
- Platform team: hashes each entry with the previous hash. Each verdict entry includes a hash of its own content plus the hash of the entry before it. Changing any entry changes every hash after it. Evidence: the chain itself.
- Platform team: signs entries. The service that writes the record signs each entry with a key held in a hardware or managed key store. Evidence: signatures verifiable with the public key.
- Infrastructure owner: stores the record write-once. Use storage configured so that existing objects cannot be overwritten or deleted during the retention period, even by administrators. Evidence: the storage configuration and its change history.
- Platform team: anchors checkpoints elsewhere. At fixed intervals, the latest hash is copied to a separate system controlled by a different team, such as risk or internal audit. Evidence: the checkpoint log in the second system.
- Security: separates duties. Nobody who can write to the record can also change storage settings or the checkpoint system. Evidence: the access matrix.
- Internal audit: verifies independently. Recompute the chain from the entries and compare with the anchored checkpoints. Evidence: the verification report.
- Platform team: synchronises clocks. Timestamps come from a trusted time source, so the order of events can be relied on. Evidence: time source configuration.
What should be in each entry?
Enough to reconstruct the decision without relying on systems that might change later: the request, the inputs with provenance, the versions of brief and sources, the proposed action, the bounds checked, the verdict and the bound that decided, the approver if any, and the timestamp. Our guide to reconstructing an AI agent's decision from the record shows how these are used.
| Threat | What detects it |
|---|---|
| An entry edited after the event | Its hash no longer matches; the chain breaks |
| An entry deleted | The next entry's previous-hash points to nothing |
| An entry inserted | Hashes after it no longer match the anchored checkpoint |
| The whole chain rebuilt | It no longer matches checkpoints held by another team |
| A forged entry | Its signature does not verify |
A worked example
Take an investment platform whose agent rebalances client portfolios within set bands. A client complains that a trade was made outside his instructions and suggests the record was altered afterwards.
Internal audit verifies the chain for the day in question against the checkpoints held in the risk team's system. Every hash matches; the signatures verify. The entry shows the agent's verdict, allowed, decided by the client's own band limits, and the band in force at the time. The client had changed his instructions by email after the trade, not before. The record's integrity makes that finding credible to the client and, if needed, to the regulator.
What may the agent do with its own record?
Nothing beyond writing new entries through the platform. It cannot read the signing key, change storage settings or edit entries. It may read its own past verdicts where needed for its work, through a read-only view. A separate reporting process can copy evidence into your control library; our guide on recording control evidence in your GRC platform covers that flow, which should copy from the record rather than replace it.
Which controls make the answer hold?
- Hash chain and signatures on every entry.
- Write-once storage for the retention period.
- Checkpoints held by another team.
- Separated access between writers, storage administrators and checkpoint holders.
- Regular independent verification, with failures treated as incidents.
The topic guide, agent governance is a bound, not a model, explains why a record you can trust is part of every bound.
Where Pryme fits
In Pryme, every verdict, allowed, held, refused or withheld, is filed in an append-only record with the bound that decided it. Facts arrive stamped with provenance, and sealed sources are themselves tamper-evident, so a reconstructed decision rests on evidence that can be checked.
Questions people ask
Does this need a blockchain?
No. A hash chain with checkpoints held by a separate team gives the same evidence of tampering without the cost and complexity of a distributed ledger.
What about correcting a mistaken entry?
Add a new entry that corrects it and references the original. Never edit the original.
How often should the chain be verified?
At least as often as checkpoints are anchored, automatically, and independently by internal audit on a schedule they set.