Why ordinary activity logs fail
An activity log sounds like accountability: a timeline of everything the agent did. The failure is structural. Most agent logs are written by the agent's own runtime, inside the agent's trust domain. A 2026 study found 9 of 10 coding agent setups deleted their own session records when asked. An agent that can see its log can rewrite its log.
This matters because an activity log is read after something goes wrong: a surprise bill, a data leak, a compliance audit. At exactly that moment, the log is written by the system under suspicion. Readers who need the log most have the least reason to trust it.
The three properties of tamper-proof records
- Minted outside the agent's reach. The execution layer writes the record at execution time. The agent has no write path to it, so deletion and editing are not policy violations, they are structurally impossible from the agent's position.
- Cryptographic commitment per entry. Each record carries a SHA-256 hash over canonical bytes: tool, caller, timestamp, inputs, observed outputs. Change one byte and verification fails. The math does not care who you trust.
- Independently verifiable, append-only. A third party recomputes the commitments with no account and no API key. Sequence numbers make deletion visible as a gap, so even omission leaves a mark.
Miss any one of the three and the log is tamper-evident in name only. Minting without commitments gives you an honest-looking file nobody can check. Commitments without external minting give you a lock the agent holds the key to.
How AER-1 implements it
AER-1 is a verifiable execution receipt format, published as the IETF Internet-Draft draft-zambo-aer1. Each receipt is the activity log entry:
- Which tool ran and which agent called it
- Execution-time timestamp
- Canonical input and output bytes
- SHA-256 commitment over those bytes
- Sequence position, so a missing record is a visible gap
Chain the receipts and you have the full activity log, where every entry is checkable and every gap is visible. The agent never holds the pen, so the log is not a transcript the agent wrote about itself. It is a record the system wrote about the agent.
Tamper-evident AI agent logs, explained
The exact phrase to search is "tamper-evident AI agent logs". Here is what it means in one line: an agent log where any change to any entry is detectable by anyone holding the log. Tamper-evident is the audit property: not a promise that tampering is impossible, but a promise that tampering shows up.
In practice, tamper-evident AI agent logs are built the way this page describes: append-only entries, each entry committing to the previous one, a SHA-256 commitment per entry over canonical bytes, sequence numbers that make deletion a visible gap, and independent verification with no account and no trust in the operator. Miss any of the five and the log is tamper-evident in name only.
Cross-vendor verification is verified, not claimed: the independent AER-1 x Tanilo interop run checked an AER-1 receipt chain against real Tanilo values end to end on an independent implementation. For the full definition, read the tamper-evident AI agent logs guide.
What to check in your current logging
Audit any activity log with three questions. Who minted this entry? If the answer is the agent or its runtime, it is not tamper-proof. Can I recompute the commitment? If there is no commitment, or it needs the vendor's private infrastructure to check, it is trust, not evidence. Would a missing entry show up? If deletion is silent, the log is a highlight reel.
Compare: log vs receipt
A traditional activity log says what happened. A verifiable receipt proves what happened, in bytes anyone can recompute. Read the full comparison.
See a tamper-proof record live
The fastest way to understand the difference is to hold one. The live demo mints a real AER-1 receipt for a real tool call, free, no signup. Try changing one byte and watch verification fail.