EVE AI Core
The Infrastructure of No.
EVE AI Core
The Infrastructure of No.
Independently verify EVE's governance: signed decision evidence, replayable records, and the security posture your auditors and procurement team need — without taking our word for it.
You control which decision fields are sent; in VPC and on-prem deployments, governed content and evidence stay inside your boundary. As EU AI Act obligations phase in and SR 11-7 examiners ask for model-decision evidence directly, the record has to exist at the moment of the decision. Trust Center · Security
Framework mappings describe technical control support and evidence capabilities. They do not constitute legal advice, regulatory certification, or a guarantee that a customer’s deployment is compliant. “SOC 2 readiness” is a preparation status, not a completed audit.
EVE is a governance layer for LLM-powered applications in regulated industries. It sits between your application code and the model provider, evaluating every request and response against a policy before allowing it to proceed.
The production enforcement runtime is EVE CoreGuard; organizations integrate through the EVE Sidecar, the REST API, or the evecore SDK depending on their deployment architecture. The evecore SDK is an OpenAI-compatible Python client that enforces policy, emits signed audit records, and raises structured exceptions when a policy rule is violated — replacing openai.OpenAI() with GovernedLLM(policy="financial-v1") is the integration surface for many deployments. The SDK is published on PyPI (pip install evecore).
Every decision produces a governance certificate — an Ed25519-signed record binding the verdict, the policy version, the tenant identifier, the environment, and a time-bounded nonce. The certificate can be verified offline without contacting EVE.
Two signing models apply, depending on deployment. Hosted EVE CoreGuard issues these production decision certificates with Ed25519 — asymmetric signatures verified against EVE's published public key, with no shared secret exposed to the verifier. The self-hosted evecore SDK signs its local audit records with HMAC-SHA256, verified with a shared key you hold; the verification steps and assumptions below describe that self-hosted HMAC model.
Regulated environments — lending, healthcare, insurance, government contracting — face a specific problem: LLM outputs must be auditable after the fact, and certain actions must be blocked before they reach a human or trigger a transaction.
Existing LLM providers do not emit independently verifiable compliance artifacts. EVE fills that gap by wrapping the provider call with deterministic pre- and post-evaluation, signing every decision, and producing an append-only hash-chained audit log that can be exported, verified offline, and submitted to regulators or auditors.
JWT_SECRET_KEY environment variable emits a CRITICAL log and an audit event; production deployments should use a hardware-backed key.verify_chain(records). Returns True if every record correctly hashes its predecessor. No EVE server required.
verify_signatures(records, key) with your shared HMAC key. Each record's HMAC-SHA256 signature is recomputed and compared.
verify_certificate(cert_dict) (no server, no network). Checks signature, TTL, and nonce fields.
policy_version field is included in the HMAC payload. Tampering with the version invalidates the certificate signature.
python scripts/pilot_validation.py from the repo root. Produces a 7-check PASS/FAIL report in under one second, no API key required.
evecore SDK signs audit records with HMAC-SHA256; if that shared key is compromised, an attacker can forge those records. Provision it from a secrets manager or HSM, not an environment variable default. Hosted EVE CoreGuard production certificates use Ed25519 asymmetric signing, so verification needs only the public key — there is no shared secret for a verifier to leak.