Python SDK
Verify evidence offline
eve-coreguard from PyPI — pip install "eve-coreguard[verify]", then from eve_coreguard import verify_decision_record. The [verify] extra is required: eve-coreguard ships with zero dependencies and asymmetric (Ed25519/ECDSA) verification needs cryptography. A bare install fails closed with a message telling you to add it. Earlier revisions of this page imported an in-repo facade (core.eve_sdk) that is not published on any registry; those snippets raised ModuleNotFoundError and have been replaced. For the client-side flow see the CoreGuard integration guide and the Python SDK reference.Verify a signed EVE evidence record independently and offline — in Python, Node, or the browser — without trusting the EVE server. Verification confirms the evidence is authentic and unaltered; it does not attest that the underlying decision was correct.
Prerequisites
- A signed evidence envelope from EVE (a decision, scan, MCP execution, monitoring, shadow, or red-team record).
- The ECDSA P-384 public key for independent (asymmetric) verification. An HMAC fallback is symmetric and not independently verifiable.
- Python, or Node 18+ (ESM) for the TypeScript/browser verifier.
Installation
Python: the published client exposes verify_decision_record; install it with the [verify] extra so cryptography is present for ECDSA P-384. TypeScript/browser: install the client and use verifyDecisionCertificate.
pip install "eve-coreguard[verify]" # Python: verify_decision_record (ECDSA needs [verify])
npm install eve-ai-governance # TS/browser: verifyDecisionCertificate
Runnable code
Python:
from eve_coreguard import verify_decision_record
# public_key_pem is the ECDSA P-384 key, pinned out of band. No secret, no network.
result = verify_decision_record(certificate, public_key_pem=public_key_pem)
print(result.valid) # True when authentic and unaltered
print(result.algorithm) # "kms-ecdsa-p384" in production config
print(result.independently_verifiable) # True for asymmetric; False for HMAC fallback
print(result.reason)
TypeScript / browser (verifier holds no secrets and never signs):
import { verifyDecisionCertificate } from "eve-ai-governance";
const result = await verifyDecisionCertificate(envelope); // offline; public key only, no network
console.log(result.valid); // true when authentic and unaltered
Expected result
- A genuine, unaltered envelope returns
valid: truewithsignature: "kms-ecdsa-p384-valid"(production config). - The same Python-signed
jcs-1envelope verifies in TypeScript and in the browser — cross-language parity for the supported value domain.
Evidence output
envelope{content_hash, signature: "kms-ecdsa-p384-...", canon: "jcs-1"}
verifyDecisionCertificate(env) -> {valid: true}
Verification
Tamper detection is the point: change any signed field and re-verify.
const tampered = { ...envelope, decision: { ...envelope.decision, action: "ALLOW" } };
console.log((await verifyDecisionCertificate(tampered)).valid); // false — tamper rejected
Failure example
Verifying with the wrong public key, or an envelope whose bytes were altered, returns valid: false. An artifact scan envelope whose artifact_digest was changed is rejected, which is how substituted artifacts are caught after approval.
Production considerations
- Distribute and pin the ECDSA P-384 public key out of band; independent verification depends on it.
- Use the browser/Node verifier in environments that must not trust the EVE server — it holds no secrets and never signs.
- Verification proves authenticity and integrity, not decision correctness; keep that distinction in audit language.
Limitations
- Offline verification is SUPPORTED. It verifies integrity, signature, and schema — it does not attest the correctness of the underlying decision, only that the evidence is authentic and unaltered.
- Independent (asymmetric) verification requires the ECDSA P-384 public key; the HMAC fallback is symmetric and not independently verifiable.
jcs-1is a constrained RFC 8785 profile: it does not serialize non-integer floats / NaN / Infinity (fail-closed). Signed governance artifacts stay inside the supported domain (rates carried as integer permille).
Next step
Return to any subsystem guide — govern-a-tool-call.md, scan-an-artifact.md, test-a-shadow-policy.md — and verify the evidence it produces.