The Log Is Not the Evidence

A log is a statement written about an action, after the fact, by the system that took it. Evidence is produced by the action, at the moment it is authorized, bound to the policy that permitted it. The industry uses one word for both, and the difference is where audit trails quietly fail.

Almost every enterprise I speak to believes it has an audit trail. Most of them have logs.

I don't say that to be clever. The distinction sounds academic right up until someone asks you to prove that a specific action was permitted, and you discover that everything you have is a set of records the acting system wrote about itself, at a time of its choosing, in a format nobody bound to anything.

That is not a failure of diligence. It is what logging was designed to be. Logs exist to help engineers understand what happened. They were never designed to withstand an adversary, or to satisfy a regulator, or to answer a question about authority.

Autonomous systems have now made that the load-bearing question.

---

Three structural problems with a log

Take any log line generated when an agent performs an action against a production system, and ask what it can actually establish.

It was written by the party with the most to lose from it being complete. The system that took the action also authored the record of the action. In every other evidentiary context we treat that as a problem. In infrastructure we treat it as normal, because historically the acting system was a piece of software we wrote and the risk of it lying was theoretically nil. When the acting system is an agent that can be manipulated through its inputs, a log the agent's runtime can write is a log the agent can be induced to write.

It was written after. The action completed, then something recorded that it had. Between those two moments there is a gap — usually small, occasionally not — in which the record can be lost, buffered away, dropped under load, or simply never produced because the process died. A log is an artifact of goodwill: it exists if everything worked.

It is not bound to the decision. This is the one that matters most and gets the least attention. Somewhere upstream, a policy engine or an approver said yes. Somewhere downstream, something executed. The log records the execution. It does not, in any cryptographic sense, connect the two. If the arguments changed between approval and execution — the amount, the destination, the record set — the log will faithfully record the executed values and nothing anywhere will notice they were not the approved ones.

You can build a perfectly complete, perfectly retained, perfectly indexed logging estate and still be unable to answer: was this permitted?

---

Tamper-evident is a cryptographic construction, not an adjective

The market's answer to this has been the immutable audit trail, and the phrase deserves more scrutiny than it usually gets.

In most products, "immutable" means write-once storage, retention locks, or an append-only database. Those are real controls and I am not dismissing them. But look at who operates them. The storage is controlled by the same operator as the system that produced the records. The retention policy is set by that operator. The keys, if there are keys, are held by that operator or by their vendor.

What that gives you is a promise. A well-engineered, well-intentioned promise, but a promise: we did not alter these records. Anyone evaluating it has to trust the party making it — which is precisely the party whose conduct is in question.

Tamper-evidence is different in kind. It means a third party can determine, from the artifact itself, whether it has been altered, without trusting the operator and without access to the operator's systems. That is not a storage property. It is a cryptographic construction, and it has to be designed in from the beginning, because you cannot retrofit provability onto records that were never bound to anything.

---

What evidence produced by the action looks like

Here is the design principle we build to: the evidence record is created as part of execution, not reconstructed afterwards.

Concretely, when a consequential action is authorized, the system seals a canonical manifest that references the principal who initiated it, the signed mandate that delegated the authority, the digest of the exact requested action and its arguments, the policy version that was evaluated, the decision and any obligations attached to it, the approval if one was required, the permit that was issued, the result the target returned, and the jurisdiction it all occurred in.

That manifest is signed under a key the customer controls — not a key we hold.

Three properties follow from that construction, and they are the whole argument.

The decision and the execution are cryptographically linked. The permit that authorizes execution is bound to the digest of the arguments that policy evaluated. Change an argument between approval and execution and the permit no longer validates. The gap I described above is closed by construction rather than by discipline.

Semantically identical requests produce identical hashes. This sounds like a detail and it is foundational. If two representations of the same request can hash differently, binding is meaningless — you can always produce a variant that evades the check. Canonical serialization, with explicit rules for numbers, timestamps, Unicode, defaults and unordered sets, is what makes the binding real. RFC 8785 is one workable profile. The specific choice matters less than the fact that one is documented and enforced.

Integrity is append-only and independently checkable. Hash chaining or a Merkle structure gives you inclusion proofs and efficient verification. Signed checkpoints can be witnessed by an independent auditor or, in national deployments, by a secondary verifier operated by a different authority. The patterns are proven — certificate transparency and Rekor have run them at internet scale for years — and they work perfectly well in a private, customer-operated log. Nothing has to be published externally for the construction to hold.

---

Correlation is the wrong tool at agent speed

There is a second-order reason logs fail here that has nothing to do with cryptography.

SIEM assembles a picture by correlating traces across sources. That works when actions occur at human speed and the interesting question is what happened last night. It is investigative by design, and investigation is valuable — I am not arguing against it.

But an agent executing a business task may make hundreds of calls in the time it takes a correlation rule to evaluate. By the time a pattern surfaces, the payment has cleared, the export has completed, the configuration has changed. The correlation window and the window in which intervention is possible no longer overlap.

Logging is not control. A record cannot stop a transaction. If the only thing standing between an autonomous system and a consequential action is your ability to notice afterwards, you have monitoring, not governance.

---

What this construction does not do

I want to be precise about the limits, because a claim about proof that overstates itself is worse than no claim at all.

A hash does not anonymize. It proves integrity to a verifier who can obtain or already knows the underlying value. For predictable or low-entropy fields — an account number, a national ID, a small set of possible amounts — a hash is trivially reversible by enumeration. Anyone telling you that hashing a field protects the privacy of that field is wrong. Classified and personal data have to remain encrypted and access-controlled; the manifest references them, it does not launder them.

Evidence is a trade-off, not a setting. More reconstruction means more stored payload, which means more privacy exposure, more residency complexity, and more cost. Metadata-only evidence is cheap and high-volume but limits what you can reconstruct. Full transactional evidence supports legal proceedings and costs accordingly. Selective disclosure sits between them and buys that position with key-management complexity. External checkpointing gives you the strongest assurance and introduces a dependency on a witness. There is no profile that is correct for every action class, and any vendor offering you one has not thought about it.

Proof depends on key custody, and key custody is an operational problem. Evidence signed under a key we hold is evidence about our conduct, not yours. That is why the evidence signing key sits in the customer's HSM, separated from the permit signing key, with documented rotation, compromise recovery and re-sealing procedures. It also means the customer carries a real operational responsibility. Sovereignty is not free; it is the price of the thing being yours.

Availability of evidence is bounded by retention, and durability has a cost at runtime. If a high-impact action requires durable proof before it can complete, then evidence is on the critical path, and under backpressure the honest posture is to stop the action rather than lose the record. Degrade functionality before degrading governance. That is a real operational constraint and organisations should understand it before they enable it.

---

The test

Strip all of it back and there is one question that separates an audit trail from a log.

Can someone outside your organisation validate a record without access to your systems, and without trusting you?

A regulator with the public trust chain, the manifest, and an inclusion proof. An auditor checking a specific transaction. A customer's security team verifying that what executed inside their tenant matched what their policy permitted. If the answer requires them to log into your platform, query your database, or accept your assurance, you have a log.

Every framework now arriving at our customers — in Europe, in the Gulf — is converging on that question in one form or another. Not do you record what happens, but can you prove it, to someone who has no reason to take your word for it.

Evidence has to be produced by the action. Anything written afterwards is a description of the action, and descriptions are exactly what this generation of regulation has stopped accepting.

---

Weynand Kuijpers is Co-founder and CTO of Skipr. The evidence model described here is set out in full, including canonical schemas and verification procedures, in the Skipr technical architecture white paper.