Verifying an EVE Decision Certificate

A decision certificate is the signed evidence record bound to a single CoreGuard governance decision (ALLOW / BLOCK / MODIFY). It lets a third party confirm that the decision was made under a specific policy version and has not been altered — without trusting the EVE server.

Readiness: EVE Proof — signed decision evidence is SUPPORTED; offline verification in Python, Node, and the browser is SUPPORTED. The CoreGuard decision that produced the certificate is PILOT_READY (pilot-validated core governance architecture).

What it proves

• Integrity — the certificate content has not changed since it was signed (the content_hash covers the canonical bytes of the decision payload).
• Authenticity — the signature was produced by the holder of the EVE signing key (Ed25519 in the production configuration; an HMAC-SHA256 fallback exists but is symmetric and not independently verifiable).
• Binding — the certificate carries the decision it belongs to: the disposition (ALLOW / BLOCK / MODIFY), the policy_version, the decision identifier, and the reason codes. A certificate from a different decision or policy version will not match.
• Zero-LLM decision path — the evidence records that no model call was in the decision path (llm_in_decision_path == false); verdicts are computed by deterministic policy code.

What it does NOT prove

• It does not attest that the underlying decision was correct for your business — only that the evidence is authentic and unaltered, and that the recorded decision was produced under the recorded policy version.
• It does not prove anything about the governed application itself; the application may still use LLMs. The zero-LLM statement applies to the CoreGuard verdict only.
• It does not by itself prove when it was consumed downstream, or that the governed action actually executed — a decision certificate records the decision, not the execution. (For approved-versus-executed binding of an MCP tool call, see MCP Execution Evidence.)
• An HMAC fallback signature proves integrity to a party who already shares the secret; it is not independent verification.

Required keys

A decision certificate envelope carries at least:

Verification fails closed if a required key is absent (see Failure categories).

Canonicalization (jcs-1)

Signatures are computed over a versioned canonicalization called jcs-1, a constrained RFC 8785 (JSON Canonicalization Scheme) profile with proven byte-for-byte parity across Python, TypeScript, and the browser for the supported value domain.

jcs-1 is fail-closed: it does not serialize non-integer floats, NaN, or Infinity. Numeric rates in EVE governance artifacts are carried as integer permille so they stay inside the supported domain. This is a constrained profile, not full RFC 8785 float formatting.

A verifier reading a certificate whose canon is not jcs-1 reports unsupported canonicalization rather than guessing.

Verification profiles: strict vs standard

• Standard — verifies canonicalization, content hash, signature, and schema. Accepts either an Ed25519 signature (with a supplied public key) or, where configured, an HMAC fallback.
• Strict — additionally requires an asymmetric, independently verifiable signature (Ed25519 with a supplied public key), rejects HMAC-fallback evidence as not independently verifiable, and enforces the full schema and canonicalization. Use strict when you are an external auditor who does not share any secret with EVE.

Linked evidence

A decision certificate references the policy version and decision identifier. Related artifacts that may accompany or reference it:

• MCP Execution Evidence — binds an approved MCP request to the executed request.
• Artifact Scan Evidence — binds a scanned artifact digest to a scan decision.
• Monitoring Envelope — summarizes agent behavior over a window.

Each linked artifact is verified independently with its own verifier; a decision certificate does not vouch for the contents of a linked artifact you have not separately verified.

Selective-disclosure / omission checks

The signature covers the canonical bytes of the whole payload. You cannot drop, add, or reorder a covered field without invalidating the content_hash and the signature. If your integration relies on a subset of fields, verify the full envelope first, then read the subset — do not re-canonicalize a reduced object and re-check, which would defeat the omission protection.

Failure categories

A verifier returns one of these categories (verification fails closed):

Freshness

A certificate is a record of a past decision; it does not expire on its own. Freshness is a policy you enforce: compare the decision's recorded timestamp against your acceptance window (for example, "reject decisions older than 24 hours" for a real-time gate). Treat an over-age certificate as stale and re-request a current decision rather than reusing an old one.

Replay behavior

A decision certificate is not an authorization token. Re-presenting the same certificate does not re-authorize an action and does not itself cause a side effect — CoreGuard's decision path is deterministic and does not consume single-use state. If your downstream system treats a decision as an authorization to act, enforce single-use / TOCTOU protection at that boundary using MCP Execution Evidence, which provides at-most-once authorization consumption (this is at-most-once, not remote exactly-once).

Verify it yourself

Python

# Verify a decision certificate offline with the Ed25519 public key.
# Synthetic fixture — no production credentials.
import json
from eve_coreguard import verify_decision_record

with open("public_key.pem", "r", encoding="utf-8") as fh:
    public_key_pem = fh.read()

with open("decision_certificate.json", "r", encoding="utf-8") as fh:
    envelope = json.load(fh)

# verify_decision_record returns a VerificationResult (truthy when valid).
# `independently_verifiable` is True only for asymmetric (Ed25519/ECDSA) records —
# an HMAC-fallback record verifies but is not independently verifiable.
result = verify_decision_record(envelope, public_key_pem=public_key_pem)
print(result.valid, result.independently_verifiable)  # True, True

Node (TypeScript / ESM, Node >= 18)

// @eve/coreguard is ESM; the verifier is browser-safe and never signs.
import { verifyEvidence } from "@eve/coreguard";
import { readFileSync } from "node:fs";

const publicKeyPem = readFileSync("public_key.pem", "utf8");
const envelope = JSON.parse(readFileSync("decision_certificate.json", "utf8"));

// Supplying the Ed25519 public key gives an independently verifiable result;
// with no key an ed25519 record only content-hash checks (signature not verified).
const result = verifyEvidence(envelope, { publicKeyPem });
console.log(result.valid, result.signature); // true "ed25519-valid"

CLI

# The `eve` CLI ships with the EVE service/repo (not the pip client wheel).
# Form: verify <kind> <evidence.json> [--strict]; the public key is
# auto-fetched from the issuer's /.well-known/eve-pubkey for Ed25519 records.
python -m core.eve_sdk.cli verify decision decision_certificate.json --strict
# -> JSON result {"valid": ..., "reason": ...}; non-zero exit on any failure category

Readiness

• Signed decision evidence and offline verification (Python / Node / browser) are SUPPORTED.
• The CoreGuard decision producing the certificate is PILOT_READY (pilot-validated).
• jcs-1 canonicalization is SUPPORTED as a constrained RFC 8785 profile.
• Independent (asymmetric) verification requires the Ed25519 public key; the HMAC fallback is symmetric and not independently verifiable.
• The Python eve-coreguard client (0.2.2) governs via hosted mode (needs an endpoint); embedded in-process governance is the EVE service. The TypeScript @eve/coreguard (0.1.0-rc1, ESM, Node >= 18) governs via hosted mode and verifies offline; it never signs.
• The release-candidate clients are distributed privately for pilots — install the pilot artifact, not a public pip/npm install (see readiness for public-registry status).

Limitations

• Verification confirms authenticity, integrity, canonicalization, and schema — it does not attest that the decision was correct, only that it was produced under the recorded policy version and is unaltered.
• HMAC-fallback signatures are not independently verifiable; use the Ed25519 configuration and the strict profile for third-party audit.
• A decision certificate records a decision, not an execution; for approved-versus-executed binding use MCP execution evidence.
• Freshness and single-use are enforced by your integration, not by the certificate itself.