Sovereign / offline mode

Run EVE governance in a sovereign deployment and verify signed evidence entirely offline — including in air-gapped environments — without trusting an external EVE server. The signed evidence produced in any mode can be verified independently in Python, Node, or the browser.

Prerequisites

• A sovereign EVE deployment (the governance service runs inside your boundary).
• The ECDSA P-384 public key distributed out of band for independent verification.
• Python, or Node 18+ (ESM) / the browser verifier for offline verification.

Installation

Deploy the EVE service inside your boundary (sovereign mode). For offline verification, install the client verifier:

pip install "eve-coreguard[verify]"   # Python: verify_evidence
npm install eve-ai-governance                 # TS/browser: verifyDecisionCertificate

Runnable code

Produce a decision inside the sovereign boundary, then verify its evidence offline with only the public key:

from eve_coreguard import verify_decision_record

# `certificate` was produced by the sovereign EVE service; verification needs
# only the public key, no network call to any EVE server.
result = verify_decision_record(certificate, public_key_pem=public_key_pem)
print(result.valid, result.reason)

Browser / Node (no secrets, no signing):

import { verifyDecisionCertificate } from "eve-ai-governance";
console.log((await verifyDecisionCertificate(envelope)).valid); // true if authentic and unaltered

Expected result

• Evidence produced inside your boundary verifies offline with valid: true and signature: "kms-ecdsa-p384-valid".
• No outbound call to an EVE-operated server is required to verify.
• Tampered evidence returns valid: false.

Evidence output

envelope{content_hash, signature: "kms-ecdsa-p384-...", canon: "jcs-1"}

Signed evidence is supported in sovereign mode alongside embedded, hosted, and sidecar.

Verification

Offline verification confirms integrity, signature, and schema. It does not attest that the underlying decision was correct — only that the evidence is authentic and unaltered. Distribute the ECDSA P-384 public key with your build so verification needs no server.

Failure example

If only the HMAC fallback signer is configured (not ECDSA P-384), the signature is symmetric and cannot be verified independently by a third party who lacks the shared secret. For independent offline verification, use the ECDSA P-384 configuration and distribute the public key.

Production considerations

• Distribute and pin the ECDSA P-384 public key out of band; sovereign verification depends on it.
• The production configuration refuses to disable signed evidence, strict verification, fail-closed behavior, authenticated identity, or complete scanning — keep these on in a sovereign deployment.
• The browser/Node verifier holds no secrets and never signs, which suits untrusted or air-gapped review environments.

Limitations

• Signed decision evidence is SUPPORTED, and offline verification is SUPPORTED; both are available in sovereign mode. Independent (asymmetric) verification requires the ECDSA P-384 public key; the HMAC fallback is symmetric and not independently verifiable.
• Verification proves authenticity and integrity, not decision correctness.
• jcs-1 is a constrained RFC 8785 profile (fail-closed on non-integer floats / NaN / Infinity); signed artifacts stay in the supported domain (rates as integer permille).

Next step

Review the full verification workflow in verify-evidence-offline.md, or start from install.md to set up the client verifier.