An audit trail is only as valuable as its credibility under examination. Here is the technical architecture behind Bastion's hash-chained intent ledger, and what it means for organizations that need AI audit evidence that holds up.
An audit trail is not just a log. A log records what happened. An audit trail is a record that can be presented to a skeptical third party — a regulator, an auditor, a court — and withstand examination. The difference is credibility: the examiner must be able to verify that the record has not been altered, selectively deleted, or fabricated after the fact.
Most AI system logs fail this test. They are append-able, modifiable, and held by the party whose behavior is being audited. That is not an audit trail. That is a diary.
Bastion's intent ledger is different. Here is how it works.
The foundation of a tamper-evident record is a hash chain. Each record in the ledger includes a cryptographic hash of the prior record. Modify any record — even by a single character — and the chain breaks at that point. Every subsequent record's hash is now invalid, because it was computed against the original version of the modified record.
This is not a novel idea. Certificate transparency logs, blockchain structures, and some modern audit databases use the same principle. What Bastion adds is the enforcement layer: IRONLAW's Rule 6 (Audit Chain) verifies the chain integrity before permitting any new record to be added. If the chain is broken, new actions cannot be authorized. The governance system itself stops working when the audit record is compromised — making tampering immediately visible rather than silently possible.
Each IRONLAW authorization cycle that succeeds writes a structured record to the ledger. The record contains:
Principal identity. The authorizing principal — the human or system that formed the intent — identified in a way that is durable and verifiable. This is not a session cookie or an ephemeral token. It is an identity reference that can be resolved to a named entity in your identity provider.
Intent hash. A cryptographic hash of the intent record as it existed at the moment of formation. This is what Intent Immutability (Rule 2) checks at execution time: the hash at formation must match the hash at execution. Any modification to the intent — including instructions passed to the LLM — breaks this match.
Scope record. The authorized scope of tool calls associated with this intent: which tools, in what modes, with what parameters. Actions outside this scope fail at the authorization gate without touching the ledger.
Warrant reference. If a warrant was required and issued, a reference to the warrant record (which is itself in the ledger) is included. This creates a verifiable chain of delegated authority from the warrant-issuing principal down to the executing agent.
Expected outcome class. The class of outcome the authorizing principal stated they expected before the action executed. Recorded at intent formation, not after.
Actual outcome. The actual outcome class recorded after execution, compared to the expected outcome for reconciliation.
Prior record hash. The hash of the immediately preceding ledger entry. This is the link in the chain.
Timestamp and execution context. Millisecond-precision UTC timestamp, agent version identifier, and infrastructure context sufficient to reconstruct the execution environment.
The audit record is designed to support replay: given a ledger entry, an auditor should be able to reconstruct the conditions under which the action occurred and verify that the same inputs would produce the same action record.
This requires capturing not just what happened but the context that determined what would happen. The scope record and the intent hash are the critical inputs. An auditor with access to the ledger entry and the original authorization context should be able to run the IRONLAW gate logic against them and arrive at the same authorization decision.
In practice, replay is used in two scenarios:
Incident investigation. When a question arises about whether an action was authorized, replay lets the investigating team demonstrate — not just assert — that the action passed the authorization gate given the context at the time. Or, if there was a bug, that the action should not have passed and the gate has since been fixed.
Regulatory examination. Regulators in financial services, healthcare, and government increasingly ask for what amounts to replay capability: "given these inputs, show me that your system would behave this way." The ledger record, combined with the replay verification infrastructure, provides this.
Tamper-evident does not mean tamper-proof. A sufficiently motivated attacker with full access to your infrastructure could, in principle, reconstruct a false ledger from scratch. The value of a hash chain is not absolute security — it is the cost it imposes on tampering.
To create a false ledger, an attacker must:
For organizations that export ledger entries to an external audit system (Datadog, Splunk, a SIEM, or a compliance platform like Drata or Vanta), step 3 becomes effectively impossible. The external copy holds independent records of what the hashes were at any given point. Reconstructing a false chain that matches the external record requires compromising both systems simultaneously.
The practical recommendation is to treat your Bastion ledger as a primary record and an external export as a secondary witness. Together they provide tamper-evidence that satisfies most regulatory and legal standards for the integrity of automated system records.
When a regulator, auditor, or opposing counsel examines an AI system's audit trail, they are asking a small set of questions:
A hash-chained intent ledger with the fields described above answers all four questions directly. The chain structure demonstrates completeness and authenticity. The outcome reconciliation demonstrates accuracy. The principal identity record demonstrates attributability.
This is what Bastion produces: not a log, but a record that holds up under examination. For organizations deploying AI into environments where examination is not hypothetical, that distinction is the difference between a defensible deployment and one that cannot be explained when the question is asked.
IRONLAW is the governance policy gate at the heart of Bastion. Here is what each of the seven rules does, why the ordering matters, and how they map to the compliance questions your legal and risk teams are already asking.
Most AI governance frameworks focus on the model. The harder problem is the chain of authority from the human who formed an intent to the system that acted on it. Here is why that distinction matters.
Interested in working together?
We help teams ship governed AI operations - book a call to discuss your specific needs.
Was this page helpful?
