There is a moment in every serious AI governance conversation when the question shifts from policy to proof. A regulator, an internal auditor, or a counterparty in a dispute stops asking what your governance says and starts asking what it can demonstrate. Can you show me the exact record for this specific decision — not a summary, not a dashboard — and can you prove that record has not been altered since it was written?
Most organizations discover at that moment that their "audit trail" is a collection of application logs produced by the same system being audited. The reasonable follow-up from any examiner is immediate: "Who could have edited this?" The silence that follows is the gap between logging and evidence. Cryptographic proofs close that gap. They replace the question "do you trust us?" with the statement "here is how you verify us — offline, with nothing more than a public key." This article explains the building blocks, the anatomy of a signed AI decision certificate, how those certificates compose into a portfolio-level proof, and what a rigorous buyer's checklist looks like.
Why ordinary logs aren't evidence
Mutable, vendor-controlled, and repudiable
Application logs have three structural weaknesses that disqualify them as primary evidence in a regulated governance inquiry. First, they are mutable. A log entry written to a database or a flat file can be updated, deleted, or overwritten by anyone with write access to that system — and the systems that write AI governance logs are typically operated by the same organization whose governance is under review. Second, they are vendor-controlled. When a SaaS provider's own infrastructure generates the log, the log's integrity is bounded by the provider's access controls and their honesty about not modifying records. Third, they are repudiable. Without a cryptographic commitment to the content of a record at the moment it was created, the issuing party can always claim the record is correct while the challenging party can always dispute it. There is no mathematical way to settle the argument.
The "who could have edited this?" problem
This is the practical consequence. When an examiner receives an application log as evidence, the examination does not end — it shifts to evaluating the trustworthiness of the log itself. Were access controls adequate? Is the log pipeline instrumented for tampering detection? Is there a separation of duties between the team that writes the log and the team that could benefit from a favorable record? These are answerable questions, but they are expensive ones, and answering them requires additional evidence about the logging system rather than about the AI decisions themselves. Every layer of metadata-about-the-log adds uncertainty rather than resolving it.
A cryptographic signature does not eliminate the need to examine the system — but it shifts the evidentiary burden decisively. If the signature is valid, the content of the record has not changed since the private key signed it. If the signature is invalid, the record has been tampered with and the fact of tampering is immediately visible. The examiner's question changes from "could this have been edited?" to "is this signature valid?" — a question that takes milliseconds to answer with freely available cryptographic tools.
A log line says: "This happened, and we are asking you to trust us." A signed certificate says: "This happened, and here is a mathematical proof that the content has not changed since it was created. Verify it yourself."
Cryptographic building blocks in plain English
Digital signatures (Ed25519) — authenticity and integrity in 64 bytes
A digital signature scheme uses a key pair: a private key known only to the signer, and a public key that can be distributed freely. To sign a document, the signer runs the document through a deterministic algorithm using the private key and produces a short signature. Anyone with the public key can verify the signature against the document — confirming both that the document was signed by the entity holding the private key (authenticity) and that the document has not been altered since signing (integrity). Neither property requires trusting the signer or contacting any third party; the verification is a local computation.
Ed25519, specified in NIST FIPS 186-5 and RFC 8032, is the variant used in production deployments where performance and security matter simultaneously. It produces a 64-byte signature from a 32-byte private key, is resistant to side-channel attacks by construction, and verifies in microseconds. For AI governance applications, the relevant properties are: verification is offline (no network call), deterministic (the same key and document produce the same signature), and computationally binding (a valid signature cannot be produced without the private key, and any modification to the signed content invalidates the signature immediately).
Hash chaining and Merkle aggregation — tamper-evident ordering
A single signed certificate proves the integrity of one record. A hash chain proves the integrity of a sequence of records, including the order in which they were created and the fact that no records were deleted from the middle of the sequence.
Hash chaining works by including the cryptographic hash of the previous record in the content of the current record before signing. If record N is altered after the fact, its hash changes. That changed hash is embedded in record N+1, so record N+1's signature is now invalid. The invalidity propagates forward through the chain, making the tampering visible to anyone who re-computes the hashes. Deletion of a record is equally detectable: the hash embedded in the next surviving record will not match the hash of its now-missing predecessor.
Merkle trees extend this to large batches efficiently. Rather than chaining records linearly, a Merkle tree hashes pairs of records together repeatedly until a single root hash represents the entire batch. Any record in the batch can be verified against the root hash with a short proof path (logarithmic in the batch size), and the root hash can be published — signed and timestamped — as a portfolio attestation covering the entire batch. An auditor verifying a single decision needs only the decision's record, the Merkle proof path, and the published root. They do not need to download every decision in the batch.
Offline verification — no vendor in the loop
The phrase "offline verification" has a specific meaning in this context. It means that the party performing the verification — the auditor, the examiner, the counterparty — does not need to send any data to the system that produced the original certificate. They need only the certificate itself and the public key. Both can be obtained in advance and held independently. The verification computation is a local operation that produces a binary result: the signature is valid, or it is not.
This property is critical for regulated evidence because it eliminates the dependency on vendor availability, cooperation, and honesty at the moment of verification. An organization that has signed its AI decision certificates can hand them to an examiner, go offline, and the examiner can still verify every record independently. The EVE CoreGuard Verify portal is a live worked example of this: a decision certificate can be pasted in and verified without any account, without any API call to EVE AI Core's infrastructure, and without the need for the original signing system to be running.
Key management and rotation — the part teams overlook
The security of a signed audit trail is bounded by the security of the private key. A compromised private key allows an attacker to produce validly-signed fraudulent records. Key management disciplines address this: private keys are stored in hardware security modules or equivalent isolated environments, access is controlled by separation of duties, and keys are rotated on a defined schedule. Critically, each signed record includes a key identifier that links it to the specific key generation that signed it. When a key is rotated, historical records signed by the old key remain verifiable using the old public key — the key identifier on each record tells the verifier which public key to use. An audit trail that spans multiple key rotations is still fully verifiable, provided the public keys for all historical rotations are retained and published.
Anatomy of a signed decision certificate
A signed AI decision certificate is not a log line. It is a structured document with specific fields, each of which carries a distinct evidentiary function. The following table maps the fields EVE CoreGuard produces to the question each field answers for an auditor.
| Field | What it contains | What it proves to an auditor |
|---|---|---|
| inputs_digest | SHA-256 hash of the canonicalized request payload (per RFC 8785 JSON Canonicalization Scheme) | Integrity of the input — the decision was made on exactly this data, and no input field has been altered since signing |
| policy_id | Identifier of the policy pack that evaluated the request (e.g., lending_v1) |
Policy identity — which rule set governed this decision, enabling the auditor to retrieve and inspect the exact rules |
| policy_version | Semantic version or content hash of the policy pack at evaluation time | Policy versioning — the decision can be attributed to the exact rule text that was active, not an approximation; supports change control review |
| verdict | ALLOWED, BLOCKED, or MODIFIED; plus violated rule IDs if blocked | Decision outcome — the governance result, with rule-level attribution sufficient for adverse-action reason codes and examiner explanation |
| timestamp | ISO 8601 UTC timestamp of the evaluation | Temporal placement — when the decision occurred relative to regulatory effective dates, SLA windows, and historical context |
| signature | Ed25519 signature over the canonicalized certificate content (HMAC-SHA256 in fallback mode) | Tamper evidence — any post-hoc modification to any field invalidates this value; verification requires only the public key |
| key_id | Identifier of the signing key pair used for this certificate | Key provenance — directs the verifier to the correct public key even after key rotation; supports full historical verification |
The canonical ordering of fields before signing follows RFC 8785 (JSON Canonicalization Scheme), which specifies a deterministic serialization of JSON objects. This is not a minor implementation detail: if the field ordering or whitespace in the signed payload is ambiguous, two parties can produce different byte sequences from the same logical content and the signature comparison will fail. Deterministic canonicalization is what makes the signature reliably reproducible across different implementations and time periods.
An auditor with a copy of the certificate JSON and the corresponding public key can run a verification command locally — no internet connection, no vendor account, no API call. The computation takes milliseconds and returns a binary answer. That is what distinguishes a signed certificate from a vendor-hosted audit log that the vendor could silently modify. See the Verify portal for a live demonstration.
From per-decision proof to portfolio proof
Signed audit lineage
Individual decision certificates establish point-in-time integrity for single events. A signed audit lineage extends that to the full sequence. EVE CoreGuard's audit bus hash-chains every governance event — not just individual decisions, but policy changes, key rotations, configuration updates, and system attestations — into a single append-only log where each entry commits to the hash of its predecessor. The chain can be verified from any point forward; the first broken link in a re-computation reveals exactly where and when a record was altered or removed.
For a compliance program, this means the audit trail itself becomes a tamper-evident artifact rather than a collection of independent log lines. An examiner examining the lineage can verify not just that a specific decision was recorded correctly, but that the sequence of decisions is complete and unmodified — including that no records were deleted to conceal a pattern.
Batched Merkle roots and published attestations
For organizations making large volumes of AI decisions, verifying every certificate individually would be impractical in an examination context. Merkle aggregation addresses this by batching decisions — daily, hourly, or per-session depending on volume — into a Merkle tree whose root hash is then signed and published. An auditor examining a sample of decisions needs only the individual certificates, their Merkle proof paths (short logarithmic proofs linking each leaf to the root), and the published signed root. The root itself can be published to a tamper-evident log or a third-party registry, making it independently verifiable without any reliance on EVE AI Core's infrastructure.
The published root serves as a portfolio attestation: a single signed artifact that commits to the contents of every AI decision in the batch. An organization can provide this root to an examiner as a starting point, allow the examiner to sample decisions at random, and demonstrate with mathematical certainty that each sampled decision is consistent with the root — and therefore consistent with the attested state of the entire batch at the time of publication.
Runtime attestation and build provenance
A decision certificate proves the integrity of a specific evaluation. Runtime attestation and build provenance extend that assurance to the system that produced the certificate. EVE CoreGuard generates build attestations that commit to the git state, dependency hashes, and source tree hash of the evaluation engine at the time a deployment was built. These attestations are signed independently of the decision certificates. An auditor reviewing a decision certificate can trace it to the specific build that produced it, verify that build's attestation, and confirm that the evaluation engine itself has not been modified since the attested build. This closes the loop from the decision all the way back to the code.
Post-quantum readiness and algorithm agility
Ed25519 is the production signing algorithm for EVE CoreGuard certificates today, and it is secure under current cryptographic assumptions. However, sufficiently large quantum computers — if they become practical — would be capable of breaking elliptic-curve signatures, including Ed25519, by running Shor's algorithm against the underlying discrete-logarithm problem. The NIST Post-Quantum Cryptography (PQC) standardization program has produced a set of quantum-resistant signature algorithms specifically to address this risk.
The correct posture for a governance infrastructure built today is not to claim post-quantum security, but to build for algorithm agility: the ability to migrate signing algorithms across the codebase without redesigning the certificate structure, the verification protocol, or the audit lineage. EVE AI Core's architecture tracks algorithm policy per certificate (the key_id field encodes algorithm metadata alongside the key generation), maintains sunset schedules for deprecated algorithms, and is designed to introduce new signing algorithms at the infrastructure layer without changes to the certificate schema or the external verifier contract. Post-quantum signature algorithms are a roadmap direction, not a shipped property — the honest statement is that the architecture is designed to accommodate the migration when NIST-standardized PQC algorithms are ready for production deployment at scale.
Any vendor claiming that their current production system is post-quantum secure should be asked which algorithm they are using. NIST's PQC standardization process has produced candidates, but production-grade, widely deployed implementations remain early. The defensible claim is algorithm agility: the ability to migrate cleanly when the time comes. Roadmap readiness is verifiable; post-quantum security claims for Ed25519-signed systems are not.
How EVE CoreGuard implements cryptographic governance
EVE CoreGuard is the enforcement plane of EVE AI Core's control stack — the layer that evaluates proposed AI actions against versioned regulatory policy packs before execution and emits a signed decision certificate as a byproduct of every evaluation. The cryptographic properties described in this article are structural, not add-on features.
In production deployments, EVE CoreGuard signs decision certificates using Ed25519 under NIST FIPS 186-5 / RFC 8032. HMAC-SHA256 is available as a fallback for environments where asymmetric key infrastructure is not yet in place. The private key remains within the tenant's deployment boundary — SaaS tenant isolation, customer VPC, or on-premises, depending on the deployment model selected. EVE AI Core does not hold the private signing key for customer deployments, which means offline verification by auditors, regulators, or counterparties requires no cooperation from EVE AI Core.
The EVE Proof model combines signed per-decision certificates, a hash-chained audit bus covering the full governance event sequence, Merkle aggregation with published signed roots, and build provenance attestations. The Verify portal provides a live, public demonstration: paste any EVE CoreGuard decision certificate and verify its signature offline in the browser, with no account and no API call to EVE AI Core's servers.
Policy versioning is a first-class property: each decision certificate references the exact policy pack version — semantic version and content hash — that governed the evaluation. Months or years later, an auditor can retrieve that specific policy version from the EVE CoreGuard registry, re-read the exact rules that applied, and confirm the verdict is consistent with those rules. The architecture overview documents the full key model, the chain of custody from private key through certificate to published root, and the deployment options. For organizations evaluating the security posture of the signing infrastructure, the trust center provides the relevant documentation.
EVE AI Core holds 90 filed U.S. provisional patent applications covering the deterministic governance control plane, including the cryptographic evidence chain (Serial Nos. 63/988,235 through 64/047,284; see the patent portfolio). Across the full range of deployment options, no decision data leaves the tenant's boundary — the governance evaluation and the signing both occur within the tenant's environment.
Buyer's checklist for verifiable AI evidence
When evaluating a governance vendor's evidentiary claims, the following eight questions distinguish cryptographic proof from marketing language about audit trails. A vendor that cannot answer all eight with specifics — not general statements — is describing logging, not evidence.
- What algorithm signs the decision certificates? Expect a specific answer (Ed25519, ECDSA P-384, RSA-PSS SHA-256) with a standards reference. "Signed with industry-standard cryptography" is not an answer.
- Where does the private key live? It must be within your deployment boundary — not held or accessible by the vendor. Verify this in the deployment architecture documentation.
- Can I verify a certificate offline, without any call to the vendor? The answer must be yes. If verification requires a round-trip to the vendor's API, the evidence is vendor-dependent.
- Is the payload canonicalized before signing? Ask which canonicalization scheme (RFC 8785 or equivalent). Without deterministic canonicalization, signatures may not reproduce reliably across implementations.
- Are decision records hash-chained? A standalone signed record proves one event. A hash-chained trail proves sequence integrity, including that records have not been deleted.
- Is there Merkle aggregation with published roots? For portfolio-level assurance, individual certificate verification should be composable into batch-level proof with published, third-party-verifiable roots.
- Does the certificate reference a specific policy version? The exact policy that governed a decision must be attributable — not the current policy, but the policy that was active at the time.
- What is the key rotation policy, and are historical keys retained for re-verification? Records signed by a rotated key must remain verifiable using the historical public key. Confirm that historical public keys are published and retained indefinitely.
A governance system that can only say "we blocked that" is still asking for trust. A governance system that produces a signed, hash-chained, offline-verifiable record saying "we blocked that, here is the proof, here is the rule, here is the policy version, verify it yourself" is the Infrastructure of No — where the evidence is as durable as the decision.
The choice between a signed evidence model and a log-based model is ultimately a question about whose word the regulator has to take. Cryptographic proofs shift the answer from "yours" to "nobody's — the math is self-verifying." For organizations in regulated industries where the cost of an unsubstantiated governance record is measured in enforcement actions, that shift is not an engineering preference. It is a compliance requirement that most governance stacks have not yet built to meet.
For a broader comparison of how evidence models differ across governance platforms, the comparison hub documents the landscape. The companion article on replayable decisions covers what auditors do with signed evidence once they have it, and the missing layer article situates cryptographic evidence within the full three-layer governance stack.
Frequently Asked Questions
Comparison based on publicly available product documentation as of June 2026; vendor capabilities evolve — verify current specifics with each vendor. References to NIST FIPS 186-5, RFC 8032, RFC 8785, and the NIST PQC program are factual citations to public standards documents.