Trust Center

Controls aligned to ECOA / Reg B SR 26-2 FCRA HIPAA EU AI Act NIST AI RMF SOC 2 Type II in progress

You control which decision fields are sent; in VPC and on-prem deployments, governed content and evidence stay inside your boundary. With EU AI Act GPAI-model obligations applicable since 2 August 2025 and high-risk-system obligations phasing in from 2 December 2027 (Annex III) and 2 August 2028 (Annex I) under Regulation (EU) 2026/1744, and with SR 26-2 (the April 2026 interagency model-risk guidance that superseded SR 11-7, applied primarily to banking organizations above $30B in total consolidated assets) excluding generative and agentic AI from its formal scope while still expecting such technologies to be governed, the record has to exist at the moment of the decision. Trust Center · Security

Independent auditor: Decrypt CPA (an AICPA firm) · SOC 2 Type II examination in progress on the Scytale platform · the report will be published here on issuance.

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 Type II — In Progress” means an independent SOC 2 Type II audit is engaged (Decrypt CPA, via Scytale) and the observation period is underway; it is not a completed audit or an issued attestation.

What is EVE?

EVE is a governance layer for AI systems in regulated industries. It governs the execution boundary — the point at which a proposed action would become a real one: a tool call, an API operation, a payment, a database write, an MCP action. Every action routed through the governed execution path is evaluated against a deterministic policy before it is allowed to run, and the verdict is signed.

The model call is governed too — a pre-execution gate on what may be sent, and an evaluation of what came back before it is returned — but the model call is one governed action among many, not the boundary EVE is built around. Blocking at the model provider is the narrower problem; the durable one is every action downstream of it, which is where an ungoverned agent does its damage.

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 signed decision record, emitted for every verdict, a clean ALLOW included. The signature covers the verdict, the tenant (org_id), the request id, the violation count (violations) and risk score, and a UTC timestamp. On records that carry them — which the hosted evaluate path binds by default, best-effort — the signature also covers digests of the exact request and the governed response; a record without those digest fields is signed over the remaining fields only. Each record carries its position in the audit hash chain. Hosted EVE CoreGuard signs these records with ECDSA P-384, which a third party verifies offline against EVE’s published public key without contacting EVE; the self-hosted evecore SDK signs its local audit records with HMAC-SHA256, which is shared-key tamper-evidence rather than third-party proof (see below). The frozen policy version is additionally bound into the signature on the decision-record path; this has been on by default since 2026-09-12. The binding is best-effort: when the frozen policy version is unavailable at startup the field is emitted empty and the record is treated as unpinned, so “bound by default” is not the same as “bound on every record”. A deployment that needs the legacy byte-identical payload opts out with EVE_COREGUARD_SIGN_POLICY_VERSION=0, and must not then claim policy-version binding for ordinary records; a mandate-governed decision binds the policy version regardless of that opt-out. The richer Governed Decision Certificate, which adds the enforcement-detail block naming the pillar that fired, is issued when an enforcement pillar returns BLOCK or MODIFY — see the EVE Proof documentation for the distinction.

Two signing models apply, depending on deployment. Hosted EVE CoreGuard signs these production decision records with ECDSA P-384 — 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.

Why does it exist?

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.

What risks does it reduce?

Policy bypass at request time — high-value financial actions, PII exposure requests, and domain-specific prohibited patterns are evaluated before the model is called.
Unchecked model output — responses containing PII, sensitive data, or policy-violating content are evaluated before being returned to the caller.
Non-repudiation gaps — every decision is signed and hash-chained; altering a past record breaks chain integrity, detectable by any party with the audit log.
Replay attacks — the decision endpoint rejects duplicate, replayed and stale requests before evaluation, keyed on the authenticated tenant plus an idempotency key or a caller-supplied nonce, with a bounded freshness window (default 5 minutes) and clock-skew rejection. The seen-set is persisted, so detection survives a restart; every rejection is audited as replay_rejected, and any error in the guard fails closed. This is enforced at the API — offline certificate verification establishes authenticity and integrity, not freshness.
Cross-tenant record injection — the org identifier is bound into the signed payload, so it cannot be altered without breaking the signature. This is tamper-evidence, not tenant enforcement: verification takes no expected tenant, so a record legitimately signed for another tenant still verifies as authentic. A consumer must compare the signed org_id against the tenant it expected before accepting a record for a tenant-scoped operation. The frozen policy version is bound as well, on by default since 2026-09-12 (a deployment may opt out with EVE_COREGUARD_SIGN_POLICY_VERSION=0). Hosted production signs with ECDSA P-384; HMAC applies only to legacy and self-hosted symmetric records.
Silent signing downgrade — in production with an asymmetric signer configured, an unavailable signer fails closed: the record is refused rather than quietly signed with a symmetric key that an asymmetric-only verifier would reject. Outside production, or where HMAC is explicitly opted into via EVE_CERT_SIGN_ALG=hmac-sha256, the JWT_SECRET_KEY fallback is taken and logged with a running count. Production deployments should use a hardware-backed key.

What can be independently verified?

Audit chain integrity Read the JSONL log; call verify_chain(records). Returns True if every record correctly hashes its predecessor. No EVE server required.

Record signatures Call verify_signatures(records, key) with your shared HMAC key (self-hosted evecore records). Each record's HMAC-SHA256 signature is recomputed and compared. This is shared-key integrity checking, not independent third-party verification — a party able to verify this way can also forge. Hosted records signed with ECDSA P-384 are verifiable against the published public key with no shared secret.

Certificate authenticity Call verify_certificate(cert_dict) (no server, no network). Checks the signature over the certificate body. It does not check an expiry or a nonce: certificates carry neither today, so verification establishes authenticity and integrity, not freshness.

Policy version binding (on by default) On the decision-record path the frozen policy_version is bound into the signed payload; this is on by default since 2026-09-12. The binding is best-effort — when the frozen policy version is unavailable the field is emitted empty and the record is unpinned, so a populated policy_version should be checked rather than assumed. The legacy content-schema pins EVE_AUDIT_SCHEMA=1 and EVE_AUDIT_SCHEMA=3 also suppress it for ordinary records. A deployment that needs the legacy byte-identical payload opts out with EVE_COREGUARD_SIGN_POLICY_VERSION=0 and must not then claim policy-version binding for ordinary records; a mandate-governed decision binds it regardless. Where it is bound, tampering with the version invalidates the signature. Certificates issued by the fail-closed path do not carry a policy_version field.

Matrix — hosted production Signs with ECDSA P-384, verifiable offline by a third party against EVE’s published public key. Ordinary decisions bind policy_version by default on the content-binding tier, which is best-effort — an unavailable value is emitted empty and that record is unpinned. So the honest guarantee is bound by default, not bound on every record; GET /v1/decisions/health publishes policy_version_bound unauthenticated so a customer can confirm it rather than trust it. (This row is about hosted production, which is KMS-backed and signs ECDSA P-384. Signing is configuration-dependent, not universal: a deployment configured with EVE_CERT_SIGN_ALG=ed25519 — self-hosted, sidecar, or otherwise — signs Ed25519 instead, and a deployment without KMS configured does not use P-384 either. Read the algorithm from the certificate or from GET /v1/decisions/health rather than assuming this row applies to a given deployment.)

Matrix — legacy content-schema pins A deployment pinned to EVE_AUDIT_SCHEMA=1 or 3 suppresses the binding for ordinary records and must not be described as policy-version-bound. Records carrying a mandate block are the exception: that path signs the policy_version field regardless of the schema pin, because the authority claim is meaningless without it. Note this is about the FIELD, not the value — a guard BLOCK that carries a mandate block signs an empty version value, and an empty value is unpinned by the same record-specific rule that applies everywhere else. So: bound on the field, and read the value before calling that record policy-version-bound.

Matrix — self-hosted SDK The self-hosted evecore SDK signs its local audit records with HMAC-SHA256 — shared-key tamper-evidence, not third-party proof: anyone able to verify such a record is equally able to forge one. Treat these as evidence against later alteration, not as independent attestation.

Matrix — demonstration evidence The certificate preloaded on the public verifier is a demonstration record. It exercises the real signature and hash-integrity checks — which is what that page proves — but it is not production traffic and carries no external-governance provenance block. A passing demonstration shows that verification works, not that every production record is bound.

Compliance report attestation The generated report includes a SHA-256 hash of its own body. Re-hash to confirm the report has not been altered since generation.

Pilot validation Run python scripts/pilot_validation.py from the repo root. Produces a 7-check PASS/FAIL report in under one second, no API key required.

What assumptions does it make?

1 The HMAC signing key is secret (self-hosted SDK). The self-hosted 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 ECDSA P-384 asymmetric signing, so verification needs only the public key — there is no shared secret for a verifier to leak.
2 The audit log file is append-only. Chain integrity detection requires that records are not rewritten. Use filesystem permissions or a write-once storage backend in production.
3 Policy rules are correct for the deployment context. EVE enforces what the policy specifies. A policy that does not cover a risk category will not block requests in that category. Policy authorship is the operator's responsibility.
4 The host clock is approximately correct. The decision endpoint's replay guard rejects requests whose nonce timestamp falls outside a freshness window (default 5 minutes) or is skewed too far into the future, both of which depend on system time. A misconfigured clock can therefore reject legitimate requests or widen the window in which a replay is accepted. Certificates themselves carry no expiry.
5 Replay state persists across process restarts on the same container. The replay guard persists its seen-set to disk, so duplicate detection survives a process restart — but that store is container-local: it is lost on task replacement and is not shared between running instances. Distributed deployments should use an external store for replay guarantees across instances.

What does it NOT claim?

EVE claims

Deterministic pre/post evaluation of every call
Signed, hash-chained, offline-verifiable audit records
Tenant-isolated, replay-protected governance certificates
Structured veto exceptions with certificate IDs
Policy-version binding on signed decision records (on by default, best-effort)
Zero mandatory external dependencies at runtime

EVE does NOT claim

That LLM outputs are factually correct
That policy rules are legally sufficient for any jurisdiction
Real-time threat intelligence or adversarial prompt detection
Guaranteed prevention of all adversarial prompt injection
Model behavioural alignment beyond pattern-based policy rules
Compliance certification (SOC 2, HIPAA, PCI, GDPR) in any jurisdiction

Where does an EU reviewer go next?

These four pages answer the questions that follow, and each states what it does not cover.

Procurement pack — the control-by-control answers a security questionnaire asks for, with the current SOC 2 and penetration-test status stated as status, not as a certificate.
Deployment models — the hosted service runs in the United States; the customer VPC, private cloud and on-premises models keep data in a region the customer chooses. EU-located processing is not offered on the hosted tier.
Regulatory roles — who is provider, deployer, controller and processor, including why a GDPR Article 27 representative is not an EU AI Act Article 22 authorised representative.
Cookie Policy — everything this site stores in your browser, including the one measurement that is optional and off unless you accept it.