Tamper-evident log A record built so that any later edit shows up.
Short answer. A tamper-evident log is a record built so that any later change, deletion or reordering of entries can be detected, even though the log may not stop a determined administrator from trying. Entries are linked with cryptographic hashes, and a signed or independently held checkpoint fixes the log’s state at a point in time. Researchers Scott Crosby and Dan Wallach note that tamper-resistance against insiders with high-level access might be impossible, so tamper-detection should be guaranteed, and that this depends on auditors who check the log regularly. For an office: if a partner asks whether anyone edited last month’s AI activity records, a tamper-evident log lets you show the answer.
01
Proof, resistance and evidence
NIST’s overview of blockchain technology uses two related words. Linking each block to the previous one makes a ledger tamper evident, and as blocks are added the older ones become more difficult to modify, which makes it tamper resistant.
Term
Meaning
Example
Tamper-proof
Cannot be changed at all
Rarely true of anything stored on a computer
Tamper-resistant
Hard to change
Write-once media: NIST SP 800-53 control AU-9(1) calls for hardware-enforced write-once media for audit trails
Tamper-evident
Changes are detectable afterwards
Entries linked by hashes, with signed checkpoints
02
How it works
Each entry is hashed together with the hash of the entry before it, so the entries form a chain; the hash chain page shows a worked example. A hash is a fixed-length fingerprint. FIPS 180-4 says that digests are used to detect whether messages have changed, and that any change to a message will, with very high probability, produce a different digest.
The chain alone is not enough, because someone with write access could recompute every later hash. So the latest hash, the head, is signed or recorded somewhere the writer cannot alter: a separate machine, a printed page or an external timestamp service. NIST SP 800-53 control AU-9(3) names signed hash functions using asymmetric cryptography as a way to protect the integrity of audit information. Certificate Transparency (RFC 6962) shows a more scalable design: publicly auditable, append-only logs built on Merkle trees, where a log that shows different things to different people can be caught by comparing tree roots and consistency proofs.
03
What it cannot do
It cannot prevent deletion or rewriting. It makes them detectable, if somebody checks.
It needs auditors. Crosby and Wallach conclude that without regular auditing, clients cannot detect a logger that fails to log events, removes unaudited events or forks the log.
It cannot prove an entry was true when written. If the application logged the wrong user, the chain preserves the mistake faithfully.
It needs a trustworthy clock and a safe place for the checkpoint.
It does not hide content. A tamper-evident log of prompts can still leak them, so encryption and access control still matter.
04
Questions for a vendor
What exactly is hashed: the whole entry, or only some fields?
Where is the latest checkpoint kept, and can the administrator who writes the log also change it?
Who holds the signing key?
How do I verify the log myself, and is there a tool or a documented procedure?
What happens when a backup is restored, or entries are deleted under a retention rule? Is that itself recorded?
Has anyone outside the company reviewed the design?
05
Where ANVE stands
ANVE logs every model call with the user, the app, the model and whether it ran locally or in the cloud, and its security page (/security) says every tool call is logged too. Whether the log is tamper-evident is a question to settle in writing before a paid pilot. Put the questions above to ANVE, as you would to any vendor.
06
Questions people ask
Is a tamper-evident log the same as a blockchain?
No. NIST describes a blockchain as blocks linked by hashes, which makes it tamper evident, plus a consensus process among many parties. A single office log needs the hash links and a protected checkpoint, not the consensus.
Can an administrator still edit the log?
They may be able to try. The aim is that an edit cannot go unnoticed, provided the checkpoint is held where the administrator cannot alter it and someone verifies the chain.
Do we need one?
If you may need to show a court, a client or a regulator that your record of AI use has not been changed, a tamper-evident log helps. For routine troubleshooting an ordinary protected log may be enough.
How often should the log be checked?
Regularly and automatically, for example every night, with a report of any mismatch. Crosby and Wallach stress that auditing is what makes tamper detection work.
07
What is not real yet
No sealed ANVE unit exists; every image of the appliance on this site is a labelled render. The software runs today on a development machine. No customers yet, no certifications, no delivery date, and the final price is not announced.
Reservations are ₹999 in India or US$12 elsewhere, refundable in full until you confirm an order in writing (terms). Offices that cannot use cloud AI can apply to be one of ten design partners.
