What is a tamper-evident audit trail?
A tamper-evident audit trail is a record of system activity designed so that any later change, insertion, or deletion of entries can be detected. It does not stop someone with access from altering the log, but it makes alteration visible, usually by linking each entry to the one before it with cryptographic hashes.
Tamper-evident versus tamper-proof
NIST defines tamper-evident as "a process which makes alterations to the data easily detectable" (NISTIR 8202). That is a different promise from tamper-proof or tamper-resistant, which aim to prevent changes. In practice, most audit systems combine both: access controls and write-once storage to resist tampering, and cryptographic checks to reveal it if it happens anyway.
Federal security controls reflect both goals. NIST SP 800-53 Rev. 5 control AU-9 asks organizations to "protect audit information and audit logging tools from unauthorized access, modification, and deletion," and its enhancement AU-9(3) calls for cryptographic mechanisms "to protect the integrity of audit information." Control AU-10, non-repudiation, asks for "irrefutable evidence" that a person or a process acting on their behalf performed an action.
How a hash chain works
The most common design is a hash chain:
- Each log entry records who or what acted, the action, the time, and the outcome.
- The system computes a cryptographic hash of the entry together with the previous entry's hash.
- That hash is stored with the entry and becomes the input for the next one.
If anyone edits or removes an earlier entry, its hash no longer matches, and every later link breaks. A verifier can recompute the chain from the start and find exactly where it diverges. Stronger designs add digital signatures, so entries can be attributed to a specific signer, and periodic anchoring of the latest hash somewhere the log's operator cannot rewrite. Certificate Transparency (IETF RFC 6962) applied a related idea, an append-only Merkle tree log, to web certificates.
Why it matters for healthcare AI
HIPAA's Security Rule requires audit controls: "hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information" (45 CFR 164.312(b)). It also requires policies to protect ePHI "from improper alteration or destruction" (164.312(c)(1)).
AI agents raise the stakes. An agent can take many actions quickly, and investigations after an incident depend on knowing exactly what it read, what it changed, and who approved it. A log that the vendor controls, or that can be quietly edited, is weak evidence for a hospital, a surveyor, or a court. The OVERT runtime evidence specification, for example, requires tamper-evident tool-call logs for AI agents.
How Skovos handles this
Skovos writes each permission decision and agent action to a hash-chained audit trail that the hospital owns, and it provides an integrity check that recomputes the chain to detect any altered or missing entry. Signed evidence exports let auditors verify records independently.
Frequently asked questions
Does HIPAA require a tamper-evident audit trail?
HIPAA requires audit controls and integrity protections but does not prescribe a specific technology such as hash chaining. Tamper evidence is one way to show logs have not been altered.
Is a blockchain needed for a tamper-evident log?
No. A hash chain with signatures and periodic anchoring provides tamper evidence without a distributed ledger.
What should an AI audit entry contain?
At minimum: the agent's identity, the action requested, the data or system involved, the policy decision, any human approval, a timestamp, and the hash link to the prior entry.
Related reading
- AI safety monitoring for health systems
- HIPAA compliance for agentic AI in health systems
- How to stop an AI agent in a hospital
Sources
- NIST CSRC Glossary, tamper-evident (NISTIR 8202): https://csrc.nist.gov/glossary/term/tamper_evident
- NIST SP 800-53 Rev. 5, AU-9 and AU-10 (OSCAL catalog): https://github.com/usnistgov/oscal-content/tree/main/nist.gov/SP800-53/rev5
- 45 CFR 164.312, HIPAA technical safeguards: https://www.law.cornell.edu/cfr/text/45/164.312
- IETF RFC 6962, Certificate Transparency: https://www.rfc-editor.org/rfc/rfc6962
- OVERT v1.1 standard text, TOOL-5 logging: https://overt.is/latest.md