For the current, maintained treatment of this topic, see AI agent audit trail. This post is kept for reference.

An audit trail holds up when an independent party — an auditor, a regulator, or a judge — can verify not only that events were recorded, but that the record has not been altered since the moment it was written. A database table of log rows does not, by itself, provide that guarantee. The properties that matter are tamper-evidence, completeness, and provenance: each record must be authenticated, the sequence must be intact, and the whole corpus must be attributable to a system operating under known conditions.

Why a plain log table is not enough

Most application logs answer the question "what happened?" They do not answer "did anyone change this after the fact?" A row in a relational database can be updated or deleted by anyone with the right database credentials. Even if row-level auditing is enabled at the database level, the database audit log itself faces the same problem one layer up. There is no structural property that prevents a sufficiently privileged actor from silently altering the record.

This matters more than teams often acknowledge. Security incidents frequently involve an attacker covering their tracks. Internal fraud investigations routinely turn on whether a record was in place before or after a disputed event. Regulatory inquiries under GDPR, the EU AI Act, and SOC 2 all involve demonstrating that a control was consistently applied, which is only meaningful if the record of that control cannot be post-dated. For a deeper look at what GDPR and the EU AI Act require of AI systems specifically, see GDPR for AI Systems: Data Subject Rights and Erasure.

A plain log table also conflates availability with integrity. That it exists and is queryable tells you nothing about whether its contents are authentic.

What cryptographic integrity actually means

Cryptographic integrity for an audit trail typically involves three techniques used in combination.

Per-row digital signatures bind each log entry to the system that wrote it. Before a row is persisted, a hash of the record's payload is signed with a private key held by the logging system. Anyone with the corresponding public key can later verify that the record has not been altered and that it originated from a system in possession of that key. If a row is modified — even a single character — verification fails.

Hash-chaining links each row to the one before it by including the previous row's hash in the current row's data before signing. This creates an ordered, tamper-evident chain: altering any record invalidates all records that follow it, making silent modification extremely difficult. A chain break is detectable without needing access to the original signing key material.

Merkle trees extend this to batches of records. Periodic Merkle roots summarise a window of records into a single hash that represents the state of the log at a point in time. Merkle roots are useful because they allow efficient inclusion proofs: you can prove that a specific record was part of the batch without revealing the entire batch, and you can verify that proof offline.

None of these techniques is new. They underpin git, certificate transparency, and blockchain designs. What is novel in an audit context is applying them consistently to every action taken inside an operational system, automatically, without requiring engineers to remember to do so.

External anchoring: moving trust outside the system

Even with per-row signatures and hash-chaining, a determined insider who controls 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 outside the control of the organisation running the system.

The Rekor project, part of the Sigstore ecosystem, is one such public transparency log. Publishing a Merkle root to Rekor gives it a timestamped, independently verifiable existence proof. If an organisation later claims their audit log shows event X happened at time T, and Rekor contains a Merkle root consistent with that claim that was published at time T, that is strong corroborating evidence. An attacker who wanted to fabricate history would need to compromise both the internal system and the external log — two separate, uncoordinated systems with different trust models.

For regulated workloads, external anchoring shifts the audit conversation from "do you trust us?" to "here is a verifiable proof you can check yourself."

Scoping, access, and export

Cryptographic integrity is necessary but not sufficient. Auditors also need to navigate and extract the log in ways that respect the organisation's data model. A useful audit system provides:

  • Filtering by actor, resource, action type, and time range, so an investigation can narrow to the relevant slice without exporting everything.
  • Team and agent-scoped views, so a compliance officer reviewing a specific team or a specific AI agent can see exactly the actions attributable to that scope without noise from the rest of the organisation.
  • Export in machine-readable formats (CSV, JSON) for off-platform analysis and evidence packaging.
  • Signed bundle export: a self-contained archive that includes the records, their signatures, and the Merkle proofs needed to verify them offline, without requiring the verifier to hold a live connection to the original system.

The signed bundle is particularly important for regulatory submissions and litigation holds. It lets the organisation hand off a package that stands alone and can be verified by the recipient's own tooling.

Alert rules and anomaly detection over the audit corpus

A tamper-evident log is a passive record. An active audit system also monitors the corpus in real time for patterns that warrant attention. Predicate-based alert rules — if an action matching a certain pattern occurs, notify this webhook or email target — turn the audit trail into an operational signal.

Common use cases include: detecting repeated failed authentication attempts before they accumulate into a credential attack, flagging unexpected privilege escalations, alerting when a sensitive resource is accessed outside business hours, and catching bulk export operations that might indicate data exfiltration. The alert rules run over the same structured records that feed the compliance trail, so there is no instrumentation gap between what is logged and what is monitored.

Forensics and timestamp verification

One subtle attack on audit trails is timestamp manipulation: writing events with plausible but incorrect timestamps to obscure the sequence of actions. A well-designed system does not take a writer's claimed time on trust when a record is written, and after the fact it lets an investigator see where recorded times look out of line with the surrounding sequence.

Forensic search over structured event types — such as MCP tool calls recorded alongside AI agent activity — lets an investigator reconstruct what an agent did, in order, and cross-reference it with the human-initiated actions that occurred in the same window. This is the kind of timeline reconstruction that incident response depends on. For a step-by-step approach to using audit data during an incident, see How to Audit AI Agent Activity.

How Praesidia is designed around these principles

Praesidia records the decisions it makes in an append-only, hash-chained audit trail. Under the default configuration each record is signed, so a post-write modification is detectable; an operator can turn signing off, and in the default observe mode a record whose signing fails is written unsigned rather than dropped. External anchoring is optional; with it turned on, the trail is anchored in the public Sigstore Rekor transparency log, which Praesidia does not control. A signed record shows it was not changed afterwards. It does not show that every action was captured, and without external anchoring, removal of the most recent records cannot be detected. Calls that do not pass through Praesidia are not recorded.

The trail can be filtered down to a team or a single agent. Organization owners and compliance officers can export a signed bundle for a chosen period, and your auditor checks it on their own machine with a verifier we provide, without contacting Praesidia.

Alert rules (Advanced tier and Enterprise) can be defined over the audit trail to notify your webhooks, and forensic search (Advanced tier and Enterprise) covers agent activity, including the MCP tool calls that pass through Praesidia.

The design intent is that an organisation running Praesidia can answer an audit or an incident investigation with records an auditor can check independently, within the limits stated above. The AI agent audit trail guide covers what such a record should hold and the questions to put to any vendor, and verify your audit trail offline sets out what the verifier checks and what it does not.

See the tamper-evident audit logs post for how the underlying cryptographic proofs work.

Common questions

Does hash-chaining prevent all tampering? It makes undetected tampering extremely difficult. Altering any record in the chain invalidates all subsequent records, so the modification is detectable by anyone who verifies the chain. It does not prevent a sufficiently privileged attacker from attempting to rebuild the chain from scratch — which is why external anchoring to an independent transparency log provides an additional layer of protection that the attacker cannot retroactively control.

What does "offline verification" mean in practice? A signed bundle export contains the log records, their per-row signatures, and Merkle inclusion proofs. A verifier — an auditor, an external counsel, a regulatory body — can check the authenticity of the records using only the bundle and the organisation's public key, without connecting to the live system. This means the evidence can be handed off and verified independently, by someone who does not have to take the operator's word for it.

How does this help with GDPR and the EU AI Act? GDPR's accountability principle (Article 5(2)) makes the controller responsible for compliance and able to demonstrate it. A tamper-evident trail is one piece of that evidence, not compliance in itself: it shows the records were not changed after they were written, it covers only what passes through the system that writes it, and the rest of the obligation, from a lawful basis to erasure, sits elsewhere. The GDPR compliance page maps which articles Praesidia's controls support and what evidence each produces. For high-risk AI systems, the EU AI Act's record-keeping article requires that the system technically allow the automatic recording of events over its lifetime; EU AI Act Article 12 logging for AI agents covers what that means for agents. In both cases, a trail an auditor can check independently is stronger evidence than one that is simply asserted.