Tamper-evident AI execution is the property that any modification to a recorded AI run is cryptographically detectable by a third party. It is achieved by sealing each execution into a Certified Execution Record with a SHA-256 hash over protected fields, then signing the record with an Ed25519 key from the NexArt attestation node. Any later change to the input, output, model identity, parameters, or context invalidates the hash; any change to the signed bundle invalidates the signature. 'Tamper-evident' is the accurate term; the phrase 'tamper-proof AI execution' is sometimes used interchangeably, but no real system can prevent deletion or overwriting, only make it detectable.
Tamper-evident vs tamper-proof
Tamper-proof implies modification is prevented. In practice, no software system can prevent a determined operator from deleting or overwriting a file. Tamper-evident is what real systems achieve: modification is detectable, so an auditor or third party can distinguish an intact record from an altered one. Regulatory and standards texts (EU AI Act, ISO/IEC 42001, NIST AI RMF, SOC 2) converge on tamper-evident as the operative property.
How the property is achieved in a CER
The protected fields of a CER (bundleType, version, createdAt, snapshot) are canonicalised and hashed with SHA-256, producing the certificateHash. The bundle plus certificateHash is then signed with Ed25519 by the NexArt attestation node. To verify, a third party recomputes the hash from the protected fields, checks it matches the sealed value, and checks the signature against the node's published public key. If either check fails, the record has been tampered with.
What tamper-evidence gives you operationally
Non-repudiation on disputes: neither the operator nor the model provider can silently retcon what happened. Regulator confidence: supervisory authorities can inspect a record without trusting your infrastructure. Portability: a CER sealed today remains verifiable years later, as long as the node's public key is published. Selective disclosure via confidential execution: you can seal sensitive fields as keyed commitments without weakening the tamper-evident property.
Where this fits in standards
EU AI Act Article 12 (automatic logging), Article 20 (retention), Article 72 (post-market monitoring). ISO/IEC 42001:2023 Annex A controls on transparency, traceability, and records of AI system events. NIST AI RMF Measure and Manage functions. SOC 2 processing integrity. A single tamper-evident record maps to obligations across all of these.
Related questions
Is tamper-evident the same as blockchain?
No. NexArt uses SHA-256 and Ed25519, which are the same primitives blockchains use, but there is no chain and no consensus. Records are individually verifiable JSON. You can anchor certificateHashes to a blockchain if you want, but it is not required.
What happens if the attestation node's key is rotated?
Historic keys remain published so past records remain verifiable. Rotation applies only to new records.
Can I make my existing logs tamper-evident retroactively?
Not in a meaningful way. Tamper-evidence must be applied at record time, before it is written into the confidential proof record. Going forward, one SDK call per AI decision produces a tamper-evident CER.