"Tamper-evident" is applied broadly enough to be nearly meaningless. An application log stored in a cloud-managed service is sometimes called tamper-evident because the vendor guarantees it against accidental modification. An audit database with strict write permissions and no delete access is sometimes called tamper-evident because the access controls prevent casual alteration. Neither is tamper-evident in the sense the IETF Internet-Draft draft-ruvalcaba-nhe-audit-00, published in August 2026, requires. The draft specifies audit infrastructure for non-human entities: AI agents, automated workflows, orchestration systems. Its definition of tamper-evidence is adversarial: the log must be verifiable by a party who explicitly does not trust the log operator. That requirement has a specific architectural implication, and the draft follows it.
The mechanism the draft specifies is a hash-linked chain. Each record includes a cryptographic hash of the previous record; a verifier who holds any historical record can confirm that nothing between that record and the current state has been altered, without trusting the organisation that runs the log infrastructure. This is the fundamental data structure of a blockchain, described as a security requirement for agent audit by practitioners in the security and AI communities. In September 2026, an independent arXiv submission (2609.04017) proposed an evidence layer for agent communication using OpenTimestamps as a chain anchoring mechanism and reached a structurally similar conclusion. Two specifications from non-blockchain authors arriving at the same architecture within six weeks is not a pattern. It is at least worth examining why.
What the specifications require
The August draft specifies five properties for a compliant NHE audit record. The record must be bound to the specific agent instance that generated it. Each entry must be sequenced within a chain covering that instance's full execution history. The chain must be anchored to an independently verifiable external timestamp. An entry must carry a proof of completeness: a verifier must be able to confirm that no events between two audit points have been omitted. And the structure must support selective disclosure: an operator must be able to prove that a specific decision was made without revealing the full decision content to the verifier.
The fifth property is the most technically demanding. Selective disclosure in a hash-linked audit chain requires zero-knowledge proofs or equivalent cryptographic machinery. It is not present in most logging systems and cannot be added retrospectively. The Internet Computer implements a related mechanism via query certificates: the network proves that a specific piece of state existed at a given block height, signed by a threshold of subnet nodes, without requiring the verifier to hold the full chain. The mechanism is not identical to the draft's selective disclosure requirement; it is the closest production implementation of that property family currently running at scale.
What ICP actually guarantees
The Internet Computer runs canisters, WebAssembly execution units with their own persistent memory. Orthogonal persistence means the canister's state survives restarts, upgrades, and node failures without a separate database layer. A canister recording an audit log is not writing to an external store; the log is part of the canister's memory, committed to the subnet's chain at each block boundary. The hash chain the August draft specifies is, for a canister, a property of the runtime rather than a discipline imposed on the developer.
The reverse gas model is the design choice most relevant to enterprise deployment and the one most often missed in evaluations. On Ethereum and most smart contract platforms, the caller pays for computation. On ICP, the developer loads cycles into the canister and the canister pays for its own execution. An end user interacting with a canister holds no ICP token. For an enterprise team evaluating blockchain infrastructure for an internal audit system, this distinction matters more than any architectural comparison: the objection that staff cannot be expected to hold tokens does not apply. The canister operates like a cloud service from the user's perspective. The verifiability guarantees run under the hood.
HTTPS outcalls allow a canister to call external HTTP endpoints with consensus verification. Each node in the subnet independently reaches the external endpoint, and the canister proceeds only if the results agree. An audit canister can call an external timestamp authority and incorporate the response into the chain, with that incorporation itself part of the verified execution. This satisfies the draft's external timestamp anchoring requirement without relying on the canister operator to perform the anchoring honestly.
Chain-key cryptography and threshold ECDSA distribute key custody across subnet nodes. No single node holds the private key for a canister's cryptographic identity; a threshold of nodes must cooperate to produce each valid signature. The NHI Management Group, a practitioner body publishing definitions for non-human identity management, stated in its 2026 glossary that tamper-evident logging and non-custodial machine identity are the paired requirements for credible agent audit. These are independent communities describing the same requirement pair. ICP implements both in the same protocol.
Deployments that exist
The UNDP's Universal Trusted Credentials initiative, announced in partnership with DFINITY in July 2024 and piloted in Cambodia, issues verifiable credentials to micro-enterprises using ICP canisters. The credential must be trustworthy to parties in multiple countries who cannot all agree to trust a single national registry. That multi-party trust requirement without a shared operator is the same property the IETF draft addresses from the agent audit direction. The infrastructure has been running since the partnership was announced.
The Pakistan Digital Authority signed a memorandum of understanding with DFINITY on 10 February 2026 covering a dedicated sovereign subnet on ICP and a verifiable government communications system. The choice of a dedicated subnet addresses sovereign data residency while preserving external verifiability: national government communications that are independently verifiable by foreign parties, without those parties needing to trust the national government's own infrastructure, is an application of the tamper-evidence property the draft specifies.
DFINITY's Caffeine, which launched publicly in October 2025, generates and deploys Motoko applications on ICP from a plain-language description. The Pakistan Digital Authority partnership includes 1,500 Caffeine licences for government-facing applications. The AI code generation wave and on-chain compute meet at the deployment step here: an application generated by a model lands in a runtime with orthogonal persistence and hash-chain commitments at each block boundary. Whether Caffeine produces applications a senior engineer would approve for production is an honest open question; DFINITY has acknowledged infrastructure cost pressures that constrain usage at scale, and no large-scale production case study for Caffeine-generated applications has been published.
The honest counter-arguments are unchanged since the previous time this journal addressed the Internet Computer. On-chain compute is slower and more expensive than a container. The tooling is immature against the AWS default: no equivalent of CloudWatch or X-Ray, fewer third-party integrations, a narrower talent pool. Hiring engineers with Motoko or ICP Rust CDK experience is genuinely difficult, and a fraction of that pool carries attitudes toward enterprise adoption shaped by the token cycle. The reputational residue of 2021 to 2023 has not fully cleared.
What the IETF draft contributes is not a technical counter to any of those objections. It establishes, independently of any blockchain advocate's argument, that a specific audit requirement implies a hash-linked architecture. For teams now working from that specification, the question of where a production implementation of that architecture exists has a concrete answer. The audit requirement is where the chain primitive earns its overhead.
“The audit requirement is where the chain primitive earns its overhead.”