What is the InstantDrive audit trail?

Last updated: 5 November 2026

What is a hash-chained audit ledger?

An audit ledger is an ordered list of events that happened to your documents: who did what, to which file, and when. InstantDrive keeps one ledger for each company. Every entry gets a sequence number (1, 2, 3 and so on) and a SHA-256 hash. The hash is calculated from the entry's own fields and from the hash of the previous entry. The first entry points back to a hash made of 64 zeros.

Because each hash depends on the one before it, changing an old entry changes its hash, which no longer matches the value stored in the next entry. A check that walks the chain from the start finds the break. This property is called tamper evidence. It lets you detect some kinds of change after the fact. It does not stop a change from being made.

Which events does the ledger record?

The ledger records a defined set of actions, listed below. It is not a log of everything that happens in the product, so read the list before you rely on it for a review or an investigation.

Not in this list: file downloads and views, sign-ins, uploads made through the Windows drive (WebDAV), Copilot commands and changes to expiry data. Sign-ins, ingest, deletes and dossier compiles also write rows to a separate, simpler activity log that is not hash-chained.

What does each ledger entry contain?

Each entry stores the sequence number, the time in UTC, the actor type and ID, the user email when a person acted, the IP address and user agent, the action, a resource type, resource ID and path, the SHA-256 of the file involved, a snapshot of details as JSON, the previous hash and its own hash.

Only some of those fields go into the hash. The hash covers the company ID, sequence number, timestamp, actor type, actor ID, action, resource path, file SHA-256, the details snapshot and the previous hash. The email, IP address, user agent, resource type and resource ID are stored with the entry but are not part of the hash, so the verify check would not notice an edit to those columns.

How does verification work?

The verify endpoint reads every entry of a company in sequence order and runs three tests on each one. First, the sequence number must be the expected next number, which detects a deleted row in the middle. Second, the stored previous hash must equal the hash of the entry before, which detects an inserted row or a fork. Third, the hash recomputed from the stored fields must equal the stored hash, which detects an edited field that is covered by the hash.

The result is one of three statuses. EMPTY means the company has no entries. TAMPERED means a test failed, and the response names the sequence number where the break was found. The success status is named LEGALLY_VALID in the code. That is a label for a passed mathematical check. It is not a legal opinion, and no court or regulator has been asked to accept it.

What does the certificate contain?

The certificate endpoint runs the same verification and returns a record with a certificate ID, the company legal name, the number of verified events, the time of the first and latest event, the first and latest chain hash, the verification status and the time of generation. It also returns a seal, which is a SHA-256 of the certificate ID, company ID, latest hash, event count and generation time.

The seal is a plain hash, not a digital signature. Anyone who knows those values can recompute it, so it identifies a state of the chain but does not prove who issued the certificate. Treat the document as a summary that your lawyers or auditors may use alongside other evidence.

What does tamper-evident mean, and what does it not mean?

Tamper-evident means a verify run can reveal certain changes made to ledger rows after they were written: a changed hashed field, a deleted row from the middle of the chain and an inserted row. It does not mean the data cannot be changed. The ledger sits in the same database as the rest of the product. InstantDrive does not use WORM storage, write-once media or immutable object locks for it.

Three cases pass verification even though the ledger was altered. A person with write access to the database could remove the newest entries, because the check compares entries with each other and not with an outside copy of the latest hash. The same person could rewrite the entire chain with recalculated hashes. And edits to columns outside the hash go unnoticed. To close these gaps, save a certificate and its latest hash outside InstantDrive on a regular schedule, so that you hold an independent record to compare against.

Who can see the audit trail?

This page makes no claim about per-role permissions on the ledger. The code defines roles such as admin, member, finance and auditor, but fine-grained restrictions on the audit trail are not confirmed. There is no Audit page in the main sidebar. The verify button and the certificate link are part of the MCP gateway panel in the Security view, which the product reaches by app state and not through the menu.

The entries list supports paging of up to 500 rows and filters by action, actor type and document ID. If you need to give an auditor access to the trail, contact InstantDrive first and agree how access is arranged for your company.

How long are audit entries kept?

No code deletes ledger entries. A nightly job at 03:17 does run under the name prune ledger, but it removes something else: completed background jobs and resolved error records older than 30 days, and temporary spool files older than 14 days. Ledger rows are not part of that clean-up.

This is not a retention policy. InstantDrive does not enforce a retention period, legal hold or scheduled destruction for ledger entries or documents. Deleting a document is a soft delete: the record is hidden, the stored file remains, and a TOMBSTONE_DELETE entry is written. Entries are kept for as long as the database is kept.

What is a worked example of verification?

Consider a fictional company, Gulf Harbour Logistics FZE. Over a quarter its ledger grows to 412 entries from uploads, deletes and one dispatch. On the first working day of each month its finance manager runs verify, saves the certificate as a PDF and stores the latest hash in a separate system.

The third row shows why the external copy matters.

What are the limits, and what should you do next?

The ledger covers a short list of actions, depends on the database it lives in, writes entries for ingest and delete on a best-effort basis (a failed write does not block the upload or delete), and has no retention rules, export tool or alerting of its own. It does not prove that a document is genuine, only that a recorded event has not been changed since it was written, within the limits above.

Next steps: decide who in your company will run verify, run it on a schedule, keep each certificate and its latest hash outside InstantDrive, and combine the ledger with your own access rules. For questions about audit evidence for a specific dispute or inspection, speak to your legal adviser.