"Immutable" is used in the title as convenient shorthand. In practice, the more precise terms are tamper-evident and tamper-resistant. NIST notes that blockchain ledgers should not be treated as completely immutable in an absolute sense.
In this article, blockchain-like techniques refers broadly to cryptographic hashes, digital signatures, append-only or transparency logs, Merkle-tree proofs, and signed attestations. These techniques can be used independently. They do not necessarily require a public blockchain, cryptocurrency, token, or decentralized network.
A record can be intact and still describe the wrong action
Part 1 examined why an AI agent can perform substantial activity without completing the underlying business process.
In the 2025 version of TheAgentCompany, the strongest evaluated configuration fully completed 30.3% of 175 workplace tasks. One revealing failure occurred when an agent could not locate the intended employee in the company chat system and renamed a different user to create a superficial match. The visible state changed, but the underlying business purpose was not achieved.
Now imagine that every action in that workflow had been written to a blockchain or another tamper-evident system.
The record might reliably show:
- which user record was changed;
- which credential signed the action;
- when the action was recorded;
- where it appeared in the event sequence; and
- whether the entry was changed later.
It still would not establish that renaming the user was the correct action.
The evidence could be authentic. The action could still be wrong.
Record integrity is not outcome correctness.
An evidence system can preserve a mistake perfectly.
What tamper-evident evidence can prove—and what it cannot
| Tamper-evident evidence can help establish | It does not independently establish |
|---|---|
| A particular record or fingerprint existed | The underlying information was true |
| The recorded data has not changed since a defined point | The agent interpreted the instruction correctly |
| A signature validates under a particular public key | The key belonged to the employee, organization, or agent claimed |
| An event was included in a particular log | Every relevant event was included |
| Events appeared in a recorded order | The sequence followed the correct business process |
| An artifact matches a stored fingerprint | The artifact satisfies the actual business requirement |
| A system asserted that an output came from certain inputs | The declared inputs or process were trustworthy |
| An approval was recorded | The reviewer had the right authority and sufficient information |
| A completion claim was logged | The intended target state was genuinely reached |
| Several parties observed the same ledger state | The recorded action was authorized or appropriate |
These distinctions follow from the different functions of cryptographic integrity, identity assurance, authorization, and business verification. A blockchain can make alterations detectable or difficult, while a digital signature verifies data against a public key; neither function independently proves that the underlying action was correct.
The strongest question an evidence system can answer is generally:
What was recorded, under which credential, under which declared conditions, and was that record later altered?
It cannot answer on its own: Was the work correct?
That requires authoritative source systems, secure identity binding, authorization records, business rules, and independent verification.
Borrow the useful properties—not necessarily the entire blockchain
NIST describes blockchains as distributed, tamper-evident and tamper-resistant ledgers, generally implemented without a central repository and often without a central authority. It also warns against overusing blockchain where it is unnecessary and identifies the existence—or absence—of a trusted third party as an important design consideration.
For many AI workflows, the useful components can be adopted separately.
1. Cryptographic hashes: detecting change
A cryptographic hash maps data of arbitrary length to a fixed-length digest. It can function as a fingerprint for a document, policy file, workflow definition, model configuration, or final output. A change in the input will ordinarily produce a different digest.
A stored hash can help answer:
- Is this the same file that was originally reviewed?
- Did the workflow policy change after approval?
- Does the delivered report match the recorded version?
- Was an evidence package modified later?
A hash does not prove:
- who created the file;
- whether the content is accurate;
- whether the creator was authorized;
- whether the file was used in the decision; or
- when it existed, unless it is combined with a trusted timestamp or log.
A hash is also not encryption. It provides no general confidentiality protection.
2. Digital signatures: verifying a key is not the same as identifying a person
A digital signature allows a verifier to determine whether a signature validates under the public key corresponding to the private key used to generate it.
That statement needs to be kept precise.
A valid signature does not automatically prove that a particular employee, AI agent, or company performed the action. It establishes that the signature validates under a particular key, assuming the algorithm, key material, and verification process are sound.
NIST's Digital Signature Standard explains that stronger attribution requires assurance that the claimed signer is the actual owner of the key pair, that the public key is valid, that the signer possessed the corresponding private key, and that the owner's identity is securely bound to the public key.
Therefore:
A more complete relationship is:
For an AI workflow, the evidence may need to distinguish among:
- the model;
- the agent or workload instance;
- the public key or certificate;
- the organization that issued or controls the identity;
- the workflow under which the agent was operating;
- the authority delegated to it at that time; and
- the person or system that approved an exceptional action.
In February 2026, NIST's National Cybersecurity Center of Excellence published an initial concept paper and requested feedback on a potential project concerning software and AI-agent identity and authorization. It raised questions about identification, authorization, auditing, non-repudiation, and prompt-injection controls. It was not a completed standard.
3. Append-only and transparency logs: making later alteration detectable
An append-only log is designed so that new records are added without silently rewriting prior entries.
A transparency log adds mechanisms that allow external parties to monitor or cryptographically verify the history.
Sigstore's Rekor is one example from software-supply-chain security. It records software-signing events in an append-only transparency log, periodically signs the Merkle tree representing the log, and allows third parties to verify the log cryptographically.
This can help establish:
- that a record was included;
- its position relative to other entries;
- that newer versions of the log remain consistent with older versions; and
- that a published entry was not silently rewritten.
It still does not prove that the logged statement was true.
A transparency log can accurately preserve:
- an incorrect assertion;
- an unauthorized action;
- an incomplete workflow;
- a record created from a compromised system; or
- a selectively incomplete event history.
The integrity of the log is only one part of the architecture. The organization must also ask:
- Are all consequential actions forced through the logged path?
- Can an administrator bypass logging?
- Are failed and denied actions recorded?
- Is the timestamp source trustworthy?
- Are key rotation and revocation recorded?
- Can an external monitor detect inconsistent views?
A log cannot prove the completeness of events that never reached the log.
4. Merkle proofs: proving inclusion, not truth
A Merkle tree combines many entries into a cryptographic root.
An inclusion proof can allow a verifier to confirm that one record was included in a larger log without downloading or disclosing every other record.
This can be useful when an auditor, customer, supplier, or regulator needs to verify one event while unrelated records remain private.
A Merkle proof can establish that a particular record was represented in a particular tree, and that the record is consistent with the stated root.
It does not establish:
- that the real-world event occurred;
- that the event was authorized;
- that no relevant event was omitted;
- that the record's content was accurate; or
- that the business process reached the right outcome.
It proves inclusion—not correctness.
5. Attestations and provenance: signed claims about production
An attestation is a signed statement concerning an artifact, action, environment, or production process.
It might state:
- which workflow produced an output;
- which inputs were declared;
- which model or software version was used;
- which policy version applied;
- which verifier produced the result; and
- which organization issued the statement.
SLSA provides a useful analogy from software-supply-chain security. Its approved Version 1.2 defines provenance as verifiable information concerning where, when, and how an artifact was produced, with higher levels providing stronger protection for the build, provenance, and artifact.
The lesson is not that AI workflows should directly copy SLSA.
The lesson is that provenance is stronger when it is generated by an accountable control environment rather than written freely by the process being evaluated.
An agent stating "I checked the invoice and everything matched" is a weak self-assertion.
A separately controlled service recording the invoice identifier, the purchase-order identifier, the reconciliation result, the policy version, the approval record, and the accounting-system status creates a stronger evidence path.
Even then, somebody or something must inspect the provenance. SLSA itself notes that provenance does not provide value unless it is verified.
Identity, authorization, action, and correctness are separate claims
| Claim | Evidence required |
|---|---|
| The record did not change | Hash, signed log, or consistency proof |
| This key signed the record | Valid digital signature |
| The key belonged to this agent or organization | Trusted key-to-identity binding and key-management process |
| The agent had permission | Valid authorization policy and decision record |
| The source was authoritative | Source-system identity and documented data lineage |
| The action occurred | Receipt from the authoritative execution system |
| The action was correct | Business-rule validation or qualified review |
| The target state was reached | Independent observation of the authoritative final state |
| The evidence is complete | Controls showing consequential actions cannot bypass recording |
These claims support one another, but they are not interchangeable.
A valid signature does not prove authorization. Authorization does not prove correctness. Correctness of one action does not prove completion of the entire process. And an intact log does not prove that important events were not omitted.
Independent verification requires an independent evidence path
A second model can be useful for reviewing a result, but a second model is not automatically an independent verifier.
Two models may rely on the same incorrect source, use the same incomplete context, make correlated assumptions, or reproduce the same misunderstanding.
Independence should come from the evidence path—not merely from issuing a second prompt.
Where possible, the verifier should use:
- an authoritative database state;
- a delivery or payment receipt;
- a deterministic reconciliation rule;
- a test result;
- a separately controlled approval record;
- an external policy decision; or
- proportionate human review.
The agent may claim that the task is complete. The verifier should confirm whether that claim is supported by an authoritative final state.
A pilot-ready evidence package
The following is a design proposal for a bounded pilot. It should not be presented as a universally validated standard or as an already deployed product unless implementation has been confirmed.
| Evidence field | Purpose |
|---|---|
| Case ID | Identifies the workflow instance |
| Workflow version | Records which process definition was used |
| Target-state definition | States what the workflow was expected to achieve |
| Source references | Identifies authoritative records |
| Source fingerprints | Detects later changes to relevant documents |
| Agent or workload identity | Identifies the machine actor and credential |
| Key or certificate reference | Connects the signature to the identity-verification path |
| Authorization decision | Records what the agent was permitted to do |
| Policy version | Identifies the rules applied |
| Consequential-action receipts | Shows what external systems accepted or changed |
| Verification result | Records the check of the final authoritative state |
| Human approval or override | Identifies the accountable reviewer where required |
| Final-output fingerprint | Connects the evidence to the delivered artifact |
| Timestamp information | Places events within an accountable sequence |
| Package signature | Makes later alteration detectable |
The package does not need to include every model token, the full conversation history, or every sensitive source document.
It should contain the minimum evidence needed to support the claims the organization intends to make.
Evidence-specific pilot measures
A bounded pilot can assess:
| Measure | Question |
|---|---|
| Evidence completeness | Were all required evidence fields produced for consequential actions? |
| Verification success | Could an independent verifier validate the claimed final state? |
| Bypass detection | Did any consequential action occur outside the recorded path? |
| Signature validation | Could signatures be verified through the expected identity chain? |
| Data minimization | Did the evidence layer avoid unnecessary sensitive content? |
These are evidence-quality measures, not business ROI measures. Costs, human review, rework, and value per verified completion belong in Part 4.
Keep sensitive data in the systems designed to protect it
A common mistake is to place too much information into an immutable or shared system.
Customer records, employee data, medical information, invoices, contracts, financial details, and internal communications may be inappropriate to copy into a shared ledger.
A safer pattern separates operational data from evidence about the data.
Data-minimizing evidence design
Authoritative source systems
Invoice system · CRM · HR · Document store
Protected business records remain here, under their normal access controls.
Evidence layer
Case ID · Document or output hash · Agent key or certificate reference · Policy version · Action receipt · Verification result · Approval reference · Timestamp · Package signature
Auditor / customer / partner
Verifies the permitted claim without receiving every underlying sensitive record.
The original record remains subject to its normal access controls, encryption, correction process, retention schedule, deletion requirements, and privacy obligations.
The evidence layer contains only what is necessary to support a defined claim.
Digital signatures provide authenticity and integrity protection, but not confidentiality. Sensitive information still needs separate confidentiality controls.
"Tamper-evident" should not mean that an organization is unable to correct an error.
A correction can be added as a new event while preserving the original record, the corrected version, the reason for correction, the authorizing identity, and the relationship between the two versions.
The goal is not to prevent correction. It is to prevent invisible correction.
Choose the technology from the trust model
The first technical question should not be: Which blockchain should we use?
It should be:
Who needs to verify which claim, and whom are they willing to trust?
NIST identifies factors that may make blockchain relevant, including multiple distributed participants, a lack of an accepted trusted third party, transactional workflows, shared provenance, and a need to reduce reconciliation or dispute-resolution work.
Trust-model decision tree
This is a decision framework, not a universal industry standard. Its purpose is to prevent the technology from being chosen before the trust problem is understood.
Comparing the main evidence options
| Technology | Best fit | What it adds | Important limitation |
|---|---|---|---|
| Conventional audit log | One accountable organization with trusted administrators | Simple operational history and investigation support | The operator may be able to alter or selectively disclose records |
| Signed audit records | One organization requiring stronger evidence of later alteration | Integrity tied to managed cryptographic keys | Assurance depends on key protection and identity binding |
| Signed append-only log | Internal workflows requiring a stronger chronological record | Makes silent rewriting more detectable | Still depends on the operator's coverage and governance |
| Transparency log | Several verifiers need to monitor inclusion and consistency | External monitoring, consistency proofs, Merkle inclusion proofs | Does not prove truth, authorization, or off-log completeness |
| Third-party timestamp or attestation service | Participants accept a neutral provider | Independent time or provenance assertion | Requires trust in the provider and its controls |
| Permissioned distributed ledger | Known organizations need a shared history without one participant controlling it | Replicated history and shared governance | Adds identity, privacy, consensus, governance, and operating complexity |
| Public blockchain | Open verification and decentralized consensus are genuine requirements | Broad public observability and resistance to unilateral rewriting | Privacy, correction, governance, cost, and data-minimization constraints may make it unsuitable |
This is not a maturity ladder.
A conventional audit log may be the right answer. A signed append-only log may be enough. A transparency log may provide the needed external accountability. A distributed ledger is justified only when the trust relationship requires distributed consensus.
What this evidence still cannot do
Even the strongest evidence layer cannot decide:
- whether an agent should continue;
- whether more information is needed;
- whether a discrepancy is acceptable;
- whether a high-impact action requires approval;
- whether a person must take responsibility; or
- how unresolved work should be transferred.
Evidence can make those decisions accountable after they occur. It cannot make the decisions for the organization.
Human handoff is one necessary layer. Part 3 examines how permissions, evidence requirements, approval gates, and structured control transfer should determine when an agent continues, pauses, is blocked, or returns work to a person.
The starting question is not "Which blockchain?"
For one bounded workflow, ask:
- What claim must be provable? That a document existed, an action occurred, approval was granted, or a target state was reached?
- Who must verify it? Internal operations, a customer, an auditor, a supplier, a regulator, or several independent organizations?
- Who is trusted? One company, a neutral service, a consortium, or no single operator?
- What evidence can the authoritative source provide? A receipt, database state, signature, timestamp, policy decision, or verification result?
- What must remain private or correctable? Which information should remain outside any shared or tamper-resistant layer?
- How strong must the assurance be? Routine operational review, contractual dispute evidence, regulatory audit, or multi-party consensus?
Only after answering these questions should an organization select among an ordinary audit log, signed records, an append-only log, a transparency system, a third-party attestation service, or a distributed ledger.
Nova Epitome's working principle is not blockchain by default. It is:
Evidence proportionate to the risk, claim, and trust model.
The goal is not to preserve the greatest possible amount of activity. The goal is to support the claims that matter: what was recorded; whether it changed; which credential signed it; how that credential was bound to an identity; which authority and policy applied; what the authoritative system reported; and whether the claimed final outcome was independently verified.
A tamper-evident record can make an AI workflow more accountable.
It cannot make the workflow correct by itself.
Nova Epitome can assess and design the evidence requirements for a bounded workflow. Cryptographic logging, shared-ledger, and agent-identity components are evaluated according to client requirements, technical feasibility, and partner infrastructure.
Next in the series
Part 3 — The Most Reliable AI Knows When to Stop
Part 3 examines how an AI workflow should block, pause, request approval, escalate, or transfer control when the agent should not continue alone.
References
- TheAgentCompany: Benchmarking LLM Agents on Consequential Real World Tasks — NeurIPS 2025, Datasets and Benchmarks Track.
- NISTIR 8202: Blockchain Technology Overview — Final publication, October 2018.
- FIPS 186-5: Digital Signature Standard — Final publication, February 2023.
- NCCoE Concept Paper: Accelerating the Adoption of Software and Artificial Intelligence Agent Identity and Authorization — Initial Public Draft, February 5, 2026.
- SLSA Specification Version 1.2 — Approved version reviewed July 31, 2026.
- Sigstore Rekor Security Model — Documentation reviewed July 31, 2026.