Encrypted audit logs: what offline verification proves

An encrypted audit log can give an outside reviewer useful evidence without giving that reviewer the contents of a single record. The reviewer can test whether ciphertext records still form the expected sequence, whether an earlier record changed, and where an export first stops matching its declared history.

That evidence has hard limits. A clean verification result does not prove that every logged claim is true, that the archive begins at the first event, or that a timestamp reflects real time. Teams weaken their own audit story when they call all of those things "integrity." They are different claims, and an auditor should ask for different evidence for each one.

Ciphertext can carry an integrity trail

Encrypted audit logs can support offline verification because the verifier does not need to understand a record to hash its stored bytes. It only needs an unambiguous record format and a rule that binds each record to the record before it.

A simple conceptual chain looks like this:

record_1 = Encrypt(event_1)
link_1   = H(record_1)

record_2 = Encrypt(event_2)
link_2   = H(link_1 || record_2)

record_3 = Encrypt(event_3)
link_3   = H(link_2 || record_3)

H is a cryptographic hash function. The || symbol means byte concatenation, not a text join. A production format must define the exact bytes, their order, and their length encoding. If one implementation hashes a newline that another omits, they will disagree for boring formatting reasons rather than evidence reasons.

The verifier reads the exported ciphertext records in order. For each record, it calculates the expected next link from the prior accepted link and the current ciphertext bytes. It then compares that calculated value with the link stored for the current record or the following record, depending on the format. A mismatch means the supplied sequence does not match the chain rule.

Encryption and chaining solve separate problems. Encryption stops the reviewer, a backup operator, or a person who obtains the export from reading request URLs, command arguments, response bodies, names, or other sensitive details in the records. The chain detects changes to the protected bytes. Encrypting a log without a chain protects confidentiality but leaves a reviewer unable to distinguish an untouched archive from one with a record quietly removed. Hashing plaintext before encryption can detect some changes, but it often creates avoidable format traps and does not by itself give the reviewer a continuous sequence to test.

An auditor who sees only ciphertext can therefore make a precise statement: "Given this chain rule and this anchor, these encrypted records have not changed or moved within this supplied sequence." That statement is worthwhile. Do not inflate it into a claim about the meaning of the hidden records.

A valid chain proves continuity, not truth

A hash chain proves a narrow integrity property: later links depend on earlier stored bytes. It does not prove that the software recorded an action accurately, that it recorded every action, or that an employee did not manufacture a clean but misleading history.

Consider a build agent that sends a deployment request. A logger might record the request before the network call, after the network call, or only after it receives a success response. All three choices can produce a perfect chain. Yet they answer different questions:

• A pre-call record shows an attempted action.
• A post-call record may show that the application reached its own completion point.
• A provider-side receipt may show that the remote service accepted the request.
• A network capture may show traffic but may not identify the user intent behind it.

A chain cannot resolve that semantic gap. The application decides what each record asserts. The audit design must state that meaning plainly, including whether failures, denials, retries, cancellations, and partial responses receive records.

This distinction matters most after an incident. Someone will ask, "Did the agent delete the repository?" A decrypted local record can say that the action gateway sent a delete request. It cannot, by itself, prove that the provider executed the request. A provider event record may answer that later question. Conversely, a provider event may prove a deletion occurred but not show which local process asked for it. Investigators need to join evidence rather than treating one log as a complete story.

The same problem appears with agent identity. A record can identify a process, a code-signing authority, a session, or a user approval. Those identities describe different actors. If the record says "agent session 42," an auditor should not rewrite that as "Alice did it" unless separate records bind Alice's approval to that session. The chain preserves the bytes. It does not repair an overbroad interpretation of those bytes.

The first trusted anchor decides how far the proof reaches

A chain has no meaningful beginning until an auditor holds an anchor that the log writer cannot rewrite along with the archive. The initial link, a checkpoint digest, or a signed commitment can fill that role. Without one, an attacker who controls storage can delete the whole log, generate a fresh chain from a new first record, and hand over a perfectly consistent replacement.

That is the most common mistake in internal designs. Teams run a verifier over a file and conclude that the file is complete. The verifier only established that the file is self-consistent. Completeness requires a prior commitment to an expected point in history.

A practical checkpoint contains enough information for a future reviewer to identify the claim. At minimum, preserve:

log identity: agent-actions-prod
checkpoint sequence: 18427
checkpoint digest: 7f...c2
record format version: 3
hash algorithm: SHA-256
checkpoint captured by: release-control process
checkpoint captured at: 2025-03-08T18:20:00Z

The digest above is illustrative. A real evidence record needs the full digest, exact byte encoding, and a durable copy outside the log store. Keep the checkpoint in a system with a different failure and access boundary. A source-control commit, a ticket attachment with restricted access, a signed release artifact, an append-only store, or a record held by an external auditor can all help, provided the people who can rewrite the log cannot silently rewrite every checkpoint too.

Checkpoints also let an auditor verify an interval rather than an entire archive. If the auditor trusts the checkpoint at sequence 18,427 and receives records through sequence 19,100, the verifier can test that the later segment descends from the trusted checkpoint. That limits the evidence claim to a stated window, which is better than pretending the log has an unbroken history since installation.

A checkpoint does not need to reveal record contents. The commitment can contain only a digest, sequence number, format version, and log identity. That makes external anchoring compatible with encrypted records. It also avoids a bad habit: exporting sensitive audit details merely so another team can confirm that the archive existed.

Time fields are claims until an independent party binds them

A timestamp inside an encrypted record can order events according to the writer's clock, but it cannot by itself prove when an event occurred in the outside world. Anyone who controls the machine clock, the process, or the log format can make a valid chain containing false time values.

Teams often confuse sequence with time. A chain can establish that record 108 followed record 107 under the chain rule. It cannot establish that record 108 happened at 09:17 UTC just because the record contains that text. Even monotonic counters have limits: they show order in one log but do not tell you how much physical time passed between entries.

If an audit needs trustworthy time, bind checkpoints to a source outside the writer's control. An independent timestamping authority, a remote service receipt, or a separately administered event collector can add that evidence. Each option makes a different trust claim. An independent timestamp says someone else saw a commitment no later than a stated time. A remote service receipt says that service observed a request or result. Neither one makes the local event text true by magic.

RFC 3161 describes a time-stamp protocol in which a time-stamp authority returns a signed token over a message imprint, commonly a hash. The useful part for encrypted logs is the message imprint. The authority can timestamp a checkpoint digest without receiving the encrypted records or their decryption keys. The limitation is equally useful to remember: the token binds a digest to the authority's asserted time. It does not inspect the hidden records, validate their semantics, or prove that the submitted digest represents a complete archive.

Clock problems also produce innocent verification disputes. A workstation may have an incorrect timezone, a process may write local time instead of UTC, or an operator may export files in an order that differs from event order. Store a clear time representation, but keep the chain's sequence number separate from any time claim. During review, ask which claim you need: order, approximate operating time, or independently witnessed time.

Offline verification must preserve the original evidence bytes

An offline verifier checks bytes, not a human-friendly rendering of those bytes. An audit team can break valid evidence by opening an export in an editor, converting line endings, reserializing JSON, truncating a file during a copy, or combining segments in the wrong order.

Treat the received export as an evidence object. Copy it bit for bit to controlled storage before anyone inspects it. Record where it came from, when the recipient received it, who handled it, and the digest of the received file. That handling record does not make a flawed source trustworthy, but it stops the review process from adding its own ambiguity.

The verification workflow should separate collection, integrity checking, and content access:

1. Preserve the encrypted export and calculate a file digest for the evidence register.
2. Obtain the relevant trusted checkpoint through the documented independent channel, not from a note inside the same export.
3. Run the verifier against an untouched working copy and retain its exit status and output.
4. If the check passes, decide whether the review needs decryption. If it does, grant that access under a separate process.
5. If the check fails, stop editing and preserve both the failed copy and the claimed checkpoint.

That third step is where a command-line artifact matters. On a machine with the Sallyport command-line tools installed, an auditor can run:

sp audit verify

The command verifies the encrypted hash chain offline and needs no vault key. Preserve the tool version, the exact command invocation, the input file identity if the tool accepts an export path, and the resulting terminal output with the case record. A screenshot alone is weak evidence because it hides the executable, arguments, and input provenance.

This check should happen before any decryption request. If the chain fails, opening records may help diagnose the source, but it cannot turn the failed archive into intact evidence. If the chain passes, the review team can often answer a preliminary question, such as whether the exported history changed after collection, while leaving operational secrets sealed.

A broken link tells you where to investigate, not who did it

When verification stops at a mismatch, the failure says that the verifier could not derive the stored link from the supplied predecessor and ciphertext. It does not identify the actor who caused the mismatch. Corruption during transfer, an incomplete export, a parser bug, a format-version mismatch, and deliberate tampering can produce the same initial symptom.

Work backward from the first failed relationship. Preserve the last accepted record, the first rejected record, their stored links, and the expected checkpoint. Then compare the evidence copies at each handoff. If the file digest changed between the producing host and evidence storage, investigate transport or collection first. If it remained stable but the chain fails consistently on a fresh export, investigate the producing application and its format assumptions.

A failure pattern can narrow the possibilities:

• A mismatch at the first supplied record often points to the wrong checkpoint, a missing earlier segment, or an export that starts after the intended boundary.
• A mismatch near the end often points to truncation during copy or a partial write that someone exported too early.
• Failures after every record commonly point to incompatible format versions or a verifier that calculates a different byte encoding.
• One isolated mismatch with later records that would otherwise link can suggest a modified, damaged, or omitted record.

Do not repair the file to see whether the remaining records verify. That exercise may help developers debug a parser, but it destroys the discipline needed for an audit finding. Keep a forensic copy untouched. Make any diagnostic derivative clearly separate, document its transformation, and never substitute it for the original evidence.

A well-designed verifier should report enough detail to support this investigation without exposing encrypted contents. A sequence number, record offset, expected digest, observed digest, and format version are usually sufficient. The report should avoid dumping ciphertext if that output will travel through ticketing systems or chat transcripts. Ciphertext may be unreadable without keys, but it still deserves controlled handling and can become sensitive if keys later leak.

Deletion and truncation need different defenses

A chain catches a changed middle record because later links stop matching. It can also expose a removed middle record when the next remaining record refers to a predecessor that the verifier did not receive. But a simple chain cannot always expose truncation at the end.

Imagine an archive with records 1 through 500. An attacker removes records 451 through 500 and gives the auditor records 1 through 450. The first 450 records may verify perfectly. The chain has no future record that points back to 451, and the reviewer needs an external expectation that the history should extend further.

That expectation can come from a checkpoint at 500, a signed daily count, an external system that knows the last sequence number, or a retention process that records completed export ranges. The useful claim is specific: "The archive includes every record through sequence 500." A chain alone only supports: "The supplied archive is consistent through sequence 450."

Deletion before the first supplied record has the same issue. If a reviewer receives a chain that starts at record 200, the reviewer cannot infer whether records 1 through 199 ever existed. The export format should state whether it is a complete genesis-to-current archive or a bounded segment. Bounded segments need their starting checkpoint. Complete archives still need a trusted genesis value or an outside commitment if an adversary could replace the whole file.

Record counts help detect accidental loss, but counts are not enough on their own. A file can retain 500 records after someone swaps one encrypted record for another, and a count cannot detect that. Use counts as supporting evidence beside a chain and checkpoint, not as a substitute.

This is where a tamper-evident trail differs from a write-once storage claim. A trail gives evidence that lets a reviewer detect certain changes. Write-once storage tries to block changes by access control or storage behavior. Strong audit programs use both, then test both. Treating one as proof of the other leaves a gap large enough for an incident review to fall through.

The verifier must know the format, not guess it

Cryptographic algorithms do not rescue an ambiguous record format. A verifier needs an exact specification for how the writer turns an event into ciphertext and how it combines metadata, prior links, and ciphertext for the next hash.

Avoid hash inputs that depend on convenient display formats. JSON object member order, whitespace, Unicode normalization, and optional fields can differ across implementations while expressing the same visible object. If the chain covers serialized JSON, define a canonical serialization and test it across language implementations. Better yet, chain a binary envelope with explicit field lengths and version bytes.

A minimal envelope might include a log identifier, monotonically increasing sequence, prior-link digest, encryption algorithm identifier, ciphertext, authentication tag, and a format version. The writer should include enough framing that the verifier can reject a record from another log instead of accepting it because the bytes happen to form a valid link.

Versioning needs care. If version 2 changes the record envelope, the verifier should state that it applied version 2 rules at the transition. Do not make a verifier silently fall back to a different parser. Silent fallback turns a compatibility feature into a way for malformed evidence to receive a false pass.

The National Institute of Standards and Technology publication FIPS 180-4 specifies the SHA-2 family and defines the hash function over a sequence of bits, not over an application's intention. That dry detail carries a practical warning. The integrity property attaches to exactly the input bytes. Teams that say "we hash the event" often have not decided whether they hash a UTF-8 string, a database row, a compressed object, or an encrypted envelope. Until they decide, they do not have a reproducible audit check.

Test the format with deliberately ugly cases: empty fields, non-ASCII text, large ciphertexts, interrupted writes, a record at a version boundary, and records copied between supported architectures. Also test mutations. Flip one byte in a ciphertext, swap two adjacent records, remove a record from the middle, and truncate the file. The verifier should fail predictably and identify the earliest point where its expected relationship breaks.

Agent logs need two levels of evidence

Autonomous agents create two related audit questions: which run obtained authority, and which action used that authority. One combined timeline can contain both, but reviewers should keep the claims distinct.

A session record answers questions about the process that connected to the action gateway, the code-signing authority associated with that process, when a human authorized the run, and when an operator revoked it. An action record answers questions about a particular HTTP or SSH request that the gateway executed. A run can have one authorization and many action records. A reviewer who sees only the session trail cannot infer every external effect, and a reviewer who sees only action records may miss why that process had authority.

Sallyport keeps a Sessions journal and an Activity journal projected from one write-blind encrypted, hash-chained audit log. That arrangement gives an auditor two views of the same protected history while retaining a single integrity trail to verify.

The phrase "write-blind" deserves precision. It means the component that appends audit evidence should not have a convenient path to read and rewrite old records as part of its normal job. It does not mean the log writer is incapable of producing false statements. A compromised agent can ask for harmful actions. A compromised gateway could record bad data while preserving a mathematically valid chain. The design reduces one class of rewrite risk; it does not remove the need for software integrity, session approval, action approval where needed, and comparison with remote-system evidence.

For HTTP actions, preserve enough protected metadata to distinguish the destination, method, credential reference, approval context, outcome class, and correlation identifier, while avoiding secret material in the record. For SSH actions, distinguish the intended host, command boundary, session context, and result. The encrypted record can carry those details for authorized investigators. The offline verifier does not need to see them to test whether the sequence changed.

That separation lets teams send an integrity package to a security reviewer who has no standing permission to inspect production secrets. It also makes incident work less chaotic. First establish whether the supplied evidence remains intact. Then grant the narrowest decryption access necessary to interpret the events.

An audit claim should fit the evidence you can show

A useful audit report states its scope in plain language. It identifies the exported segment, the chain format, the verifier version, the checkpoint source, the verification result, and the limits that remain. That report may sound less dramatic than "the logs are immutable," but it survives technical scrutiny.

Use language such as: "The verifier accepted records 18,428 through 19,100 as a continuous ciphertext chain rooted in checkpoint 18,427, which the release-control process preserved separately." That statement says what the evidence supports. If the team also has a signed external timestamp, say that separately. If it compared selected actions against a provider's event records, say that separately too.

Avoid phrases such as "nothing was deleted" unless an anchored end checkpoint or another independent source supports that claim. Avoid "the agent did this" when the evidence only identifies a local process. Avoid "at this exact time" when the only clock belonged to the host under review. These are not lawyerly distinctions. They determine whether another engineer can reproduce your conclusion when the incident is messy and everyone wants a simple answer.

The first operational test is simple: export a non-production sample, preserve a checkpoint outside the export location, run the offline verifier, then remove one record in a copy and run it again. If the team cannot explain both results and the limits of each, it has encryption and hashes but not yet an audit practice that will hold up when access to the plaintext becomes the disputed issue.