An auditor sits across a table. They ask a question every compliance team in this market is about to start hearing more often.
"You said the AI attested control CC6.7 as PASS. Walk me through what evidence it looked at, what tool calls it made, who authorized the agent to act on this control, and prove the record has not been tampered with since."
If you cannot answer that — not in concept, in the literal records on disk, today — then no certification number on the agent matters. The accuracy claim might be impeccable. The audit still fails, because the audit is about this attestation, and there is no record of this attestation that survives scrutiny.
This is the substrate problem. Trustworthy Autonomy™ treats it as a first-class gate: an autonomous action that cannot be reconstructed from the record is disqualifying, regardless of how accurate the agent is.
What "tamper-evident" actually means here
Every autonomous action the agent takes produces an action record. The record binds four things together:
The action itself
What the agent did. The tool that was called, the arguments, the resulting state change. This is the verb of the record.
The basis
The evidence the agent reasoned over. The scanner finding, the policy excerpt, the configuration snapshot — hashed and pinned, so the same record could be re-evaluated by a third party against the same inputs and they would see what the agent saw.
The delegation chain
The human principal who licensed the agent to operate this action category at this tier, the scope they defined, and the version of that scope at the moment of the action. The CSA Agentic NIST AI RMF Profile calls this the agent accountability register. Trustworthy Autonomy makes it a per-action requirement, not a configuration setting.
The verification envelope
The cryptographic signature over the whole record, written into a hash chain such that every subsequent action's chain link incorporates this one's. A modification to any record breaks the chain for every record after it.
That last property is the one that lets an auditor reconstruct the record months or years later and verify it has not been edited. They do not have to trust the company's word on it. They run the chain verification themselves. The chain is either intact or it is not.
Why this beats "trust us"
Without this substrate, every claim about agent autonomy comes down to vendor word. The vendor says the agent only took authorized actions. The vendor says the action records have not been edited. The vendor says the policy in effect at the time was X, not Y. None of these claims are independently verifiable. The auditor either believes the vendor or does not.
Compare the two postures end-to-end.
"This control was attested PASS on 2026-09-14 at 14:22:18 UTC by agent build v2026.09, operating action category attest_control at Tier 2, under scope-of-authority defined by principal yolonda@vcisolite.com in delegation record dr-1782 on 2026-09-01. The basis was scanner finding F-9472 (hash a4f1e…), policy excerpt PE-CC6-014 (hash 3b88c…), and configuration snapshot CFG-4391 (hash 1c0d2…). The action record is signed; the action chain through this attestation verifies." Every clause is independently checkable.
Why this is not a blockchain
The first instinct of an architect hearing "signed, hash-chained, and verifiable" is to reach for a blockchain. Resist it. A blockchain solves a different problem, and adopting one here imports complexity you do not need for guarantees you already have.
One. A blockchain solves Byzantine consensus among mutually-distrusting parties. The compliance team and its auditor are not mutually-distrusting parties in the way a public chain assumes; they share a verification interest. Two. Throughput. A blockchain operates on the order of tens to thousands of transactions per second; a busy compliance agent produces action records in the thousands per hour and the chain has to keep up. Three. Operational complexity. A blockchain introduces consensus, replication, and key-distribution problems that would dwarf the agent itself. The compliance team's auditor does not want to learn a new infrastructure to verify an attestation.
What is needed instead is the hash-chained logprimitive that predates blockchains by decades — the same primitive certificate-transparency logs are built on, the same primitive any Merkle-tree append-only log uses. Single-writer, single trust boundary, with signatures and chain verification. Cheap, fast, boring, defensible. Exactly the properties a compliance log should have.
What "provable" buys, concretely
Three operational properties fall out of this substrate that do not exist without it.
The auditor reconstructs the run, not the description. Instead of reading a summary the company wrote about what happened, the auditor reads the actual action records and verifies them. If they want to test the agent's reasoning on a specific case, they replay the hashed basis against any model they care to test. The adjudication is about the actual run, not a narrative of it.
A change in policy creates a clean cutoff. If the scope of authority delegated to the agent changes on a specific date, every action record before that date is bound to the old delegation version, and every action after is bound to the new one. There is no ambiguity about which version of the rules was in effect for any given action.
A breach in the chain is visible.If anyone — a malicious insider, an attacker who reached the database, a misconfigured backup restore — modifies an action record, the chain verification fails. The compliance team detects the integrity violation. The auditor sees the integrity violation. The agent's next attestation cannot publish until the chain is reconciled.
What this substrate forces the team to give up
The substrate is not free. Three operational habits the team will have to retire to adopt it:
"Cleaning up" historical records.Once an action record is in the chain, it is in the chain. A record that turns out to be wrong does not get deleted; a corrective record is appended that supersedes it, and both records remain visible. This is the right behavior — it is also a habit shift.
Implicit policy version-skew. The scope of authority is versioned and bound to the action; "we updated the rules and applied them retroactively" stops being a legible workflow. Policy changes are explicit cutovers with a timestamp, not a rolling reinterpretation.
Trusting that the database is intact.The chain verification will, occasionally, fail. The team has to plan for the failure case — what triggers it, what the recovery is, who gets paged. This is the same operational discipline as managing an append-only event store; it does not happen for free.
Where this leaves the buyer
For the compliance team considering an AI agent, the question to ask a vendor is concrete and short.
"Show me the action record for any one autonomous action your agent took in the last 24 hours. Verify the chain in front of me. Walk me through reconstructing the evidence. Tell me which human principal authorized the scope, in which delegation record, at which version, on which date."
A vendor who can do that has built the substrate. A vendor who shows a database row and a description is at the conventional-audit-log tier — which is fine for a Tier 1 supervised workflow, and disqualifying for anything above it.
Where this matters next
How often is your compliance AI actually right? — the pillar. The certified accuracy claim is one of two things that has to hold for an action category to clear the autonomy gate; provenance completeness is the other.
The trust ladder: from approve-everything to goal-oriented — the four tiers of graduated autonomy, and why provenance completeness is a gating boolean (not a sliding metric) at every tier from 2 upward.