Tamper-Evident Audit Logs with Cryptographic Proofs

Audit logs are only as credible as the proof that they have not been altered. A tamper-evident audit trail signs its records, links them into a hash chain, and rolls them into signed Merkle roots that can be anchored to an external transparency log. Praesidia records the decisions it makes in an append-only, hash-chained audit trail, signed under the default configuration; an operator can turn signing off. The result is an audit trail where a signed record can be verified independently — by you, your auditors, or a regulatory body — without relying on the platform's own assurances. A signed record shows it was not changed afterwards. It does not show that every action was captured. 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

For a runnable example, try the public signed-audit verification lab. Its nine synthetic cases show a changed amount, a broken chain, a different signer, and why a removed tail needs an independently trusted checkpoint. It uses an educational format, not Praesidia's production export format or verifier.

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 that, under the default configuration, it applies them automatically as it writes the platform's audit records, and that it ships the verification tooling to act on them.

Per-Row Digital Signatures

Under the default configuration, Praesidia signs a record before it is committed, with an asymmetric private key that belongs to your organisation, and links it to the previous signed record. The public key is available to any authorised party for independent verification. Two cases leave a record unsigned: an operator can turn signing off, and in the default observe mode a signing failure stores the record unsigned rather than losing it (enforce mode fails the write instead). An unsigned record is outside the chain, so the checks below do not cover it.

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.

The audit API has a per-row verify endpoint that returns the signature verdict and the chain-link status for one record, and reports a row with no signature as unsigned. Verification runs when you request it, not when a view loads, so check the records you rely on; a failed check is an anomaly worth investigating.

Hash-Chaining: Ordering the Record

A signature verifies an individual row. Hash-chaining verifies the sequence. A signed row's payload includes a hash of the signed row before it, so the signed rows form an ordered chain: change an earlier row and its hash no longer matches the link stored in the row after it, which breaks the chain from that point on.

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.

The link is a hash over the previous signed row's canonical bytes, its timestamp among them, so changing that timestamp breaks the chain like changing any other field. Timestamps are also checked on the way in: a record dated more than a few seconds before its write began, or more than a few seconds ahead of the clock, is refused. That narrows backdating at write time. Records added by a backfill of historical entries are not checked, and the check binds Praesidia's application, not someone with direct access to the stored records.

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.

In practice, that "standard cryptographic tooling" is @praesidia/audit-verifier, an Apache-2.0 licensed, dependency-free command-line tool built specifically for this: praesidia-verify your-bundle.zip, run entirely offline. See verify your audit trail yourself for the full command, exactly what it checks, and — just as importantly — what it does not.

Bundle export is scoped to a date range, available to organisation owners and users with the compliance officer role. A bundle export is recorded in the audit trail when it starts and again when it finishes or fails, though those entries are not guaranteed. The plain JSON or CSV export of the audit log, and reading it, are not themselves audited, so keep the roles that can do either to the people who need them.

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.