Audit logs are only as credible as the proof that they have not been altered. A tamper-evident audit trail ensures that any sensitive action on the platform is recorded with a per-row digital signature, linked into a hash chain, and rolled into signed Merkle roots that can be anchored to an external transparency log. The result is an audit trail where any record can be verified independently — by you, your auditors, or a regulatory body — without relying on the platform's own assurances. For the broader context of how audit trails support compliance obligations, see how to audit AI agent activity.
Why Standard Log Tables Are Not Sufficient
A table of log rows tells you what was recorded. It does not tell you whether the record was altered after the fact. Any actor with sufficient database access can modify or delete rows without leaving a trace in the log itself — which is precisely the problem when the log is the evidence you need to protect.
This matters in several practical situations: an internal investigation where the sequence of events is disputed, a regulatory inquiry that requires demonstrating a control was consistently applied, or a security incident where an attacker may have tried to cover their tracks. In all three cases, the credibility of the record depends on a structural property — tamper-evidence — that plain log tables do not have.
The cryptographic techniques that provide tamper-evidence are well understood. The value of a dedicated audit infrastructure is their consistent, automatic application to every event the platform emits, together with the verification tooling to act on them.
Per-Row Digital Signatures
Before each audit record is committed to storage, a hash of its payload is signed with an asymmetric private key scoped to your organisation. The public key is available to any authorised party for independent verification.
The per-row signature provides two guarantees. First, it authenticates the record's origin: a valid signature confirms the record was written by a system in possession of the corresponding private key. Second, it detects modification: if any field in the record is changed after signing — including a timestamp, an actor identifier, or an action description — the signature verification fails.
A per-record verify endpoint is available at the audit API. When you load the forensics view, each record's integrity status is computed on load. Records that pass show a verified indicator; a failure immediately surfaces as an anomaly worth investigating.
Hash-Chaining: Ordering the Record
A signature verifies an individual row. Hash-chaining verifies the sequence. Each record includes the hash of the preceding record in its signed payload, so the records form an ordered chain where any modification to an earlier entry invalidates all subsequent entries.
The practical consequence is that silent modification of a historical record is not feasible — the chain break is detectable by anyone who can read the records in sequence. You do not need access to the signing key to detect tampering; the chain structure makes inconsistency visible.
Each record includes the timestamp of the preceding record in its chain link, and events are rejected when their claimed timestamp deviates outside expected bounds. This closes a separate attack surface: backdating events to misrepresent when something happened.
Merkle Roots and Inclusion Proofs
Hash-chaining secures the sequence row by row. Merkle trees provide a compact representation of the state of a batch of records at a point in time. Signed Merkle roots are computed periodically, summarising the chain into a single root hash that represents that window of the log.
Merkle roots enable inclusion proofs: given a specific record and a root, you can produce a short proof that the record was included in the batch that produced the root, without disclosing the rest of the batch. This is the mechanism behind offline verification — a third party can check that a specific record existed and was unmodified at the time the root was signed, using only the record, the proof path, and the root.
For records written after the most recent root computation, the proof endpoint indicates that the inclusion proof will be available once the next root is generated. This is a normal operational state, not an error, and resolves within the configured root interval.
External Anchoring: Trust Outside the System
Even with per-row signatures, hash-chaining, and Merkle roots, a determined insider who controls both the signing key and the storage layer could theoretically replace the entire log with a fabricated one. External anchoring addresses this by publishing Merkle roots to an independent, append-only transparency log that the organisation running the platform cannot retroactively alter.
One option is anchoring to a public transparency log such as Rekor, operated by the Sigstore project. When a Merkle root is published there, it receives a timestamped, independently verifiable existence record. If you later need to demonstrate that the audit log showed a particular state at a particular time, that entry provides corroborating evidence from a source outside your control — which is what independent verification actually requires.
For regulated workloads where auditability must be demonstrable to external parties, external anchoring shifts the evidence from self-asserted to independently checkable. This is particularly relevant for compliance frameworks that require demonstrable non-repudiation. For context on how tamper-evident logs fit into a SOC 2 audit, see SOC 2 for AI Platforms: What Auditors Look For.
Signed Bundle Export for Offline Verification
Browsing audit logs in the platform works for investigation. Handing evidence to an external auditor or regulatory body requires a self-contained artifact that can be verified without a live connection to the system.
A signed bundle export produces a zip archive containing the audit records, their per-row signatures, the Merkle inclusion proofs, and the public key material needed to verify them. A recipient can check the authenticity and integrity of every record in the bundle using only the bundle itself and standard cryptographic tooling — no platform access required.
Bundle export is scoped to a date range, available to organisation owners and users with the compliance officer role. Export requests are themselves logged to the audit trail.
Alert Rules, Forensics, and Anomaly Detection
A tamper-evident record is a passive artifact. Defining predicate-based alert rules that evaluate the audit corpus in real time adds an active layer — firing configured targets (webhooks or notification channels) when a pattern matches. Useful patterns include repeated failed authentication attempts, unexpected privilege escalation events, access to sensitive resources outside normal operating hours, and bulk export operations that may indicate data exfiltration. Alert rules can be back-tested against historical data before activation.
The forensics surface provides structured search over event types, including tool call records that capture what each AI agent invoked and when. This lets an investigator reconstruct the timeline of agent activity and cross-reference it with human-initiated actions in the same window — the kind of sequence reconstruction that incident response depends on. See Incident Response for AI Agent Breaches for how the audit trail feeds into an active response process.
A timestamp distribution view shows claimed event timestamps relative to server-observed time across the corpus. Anomalous windows — where recorded times cluster in ways inconsistent with normal traffic — surface as signals worth examining. Combined with hash-chaining's sequence guarantees, this makes retroactive timeline manipulation both structurally difficult and detectable.
Common Questions
How do I verify a specific record independently? Each record has a unique identifier. The audit API exposes a verify endpoint that returns the signature validity and chain status for that record. For offline verification, request the inclusion proof endpoint, which returns the Merkle path needed to check the record against a published root. Both endpoints are accessible to users with the audit view permission; cross-organisation requests are rejected.
What does "independently verifiable" mean in practice? It means a party who does not trust your systems can still check whether a specific record is authentic and unmodified. They need the record, its signature, the Merkle proof, and your organisation's public key — all of which are available in the signed bundle export. They do not need database access, platform credentials, or to contact the platform operator. The signed bundle is designed to stand alone as evidence for audits, regulatory submissions, and litigation holds.
Does external anchoring require additional configuration? External anchoring is optional. When enabled, periodic Merkle roots are submitted to the transparency log automatically. No per-event configuration is required. If you operate in an environment where outbound connections to external services are restricted, anchoring can remain disabled without affecting the internal hash-chain and signature guarantees.
How does a tamper-evident audit trail differ from append-only storage? Append-only storage prevents deletion through access controls — you rely on the storage system's guarantees. A tamper-evident trail using hash chains and signatures provides a cryptographic guarantee that is verifiable independently of the storage system's trustworthiness. If a database administrator with full access modified a record, append-only storage would not detect it; a broken hash chain would. The two are complementary: append-only storage raises the bar for an attacker, while cryptographic chaining makes any successful modification detectable after the fact. For a broader view of compliance controls for AI platforms, see An AI Agent Compliance Checklist for 2026.