Trust Center

What is EVE?

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 core component is the evecore SDK — 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 most deployments. The SDK is published on PyPI (pip install evecore).

Every decision produces a governance certificate — an HMAC-SHA256 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.

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 — certificates include a time-bounded nonce; expired or replayed certificates fail verification.
• Cross-tenant certificate injection — the org identifier, policy version, and environment are bound into the HMAC payload; a certificate signed for one tenant does not verify under another.
• Signing key compromise in non-production — fallback to the JWT_SECRET_KEY environment variable emits a CRITICAL log and an audit event; production deployments should use a hardware-backed key.

What can be independently verified?

What assumptions does it make?

1. 1 The HMAC signing key is secret. If the key is compromised, an attacker can forge certificates. Production deployments should provision the key from a secrets manager or HSM, not an environment variable default.
2. 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. 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. 4 The host clock is approximately correct. TTL-based certificate expiry relies on system time. A misconfigured clock can allow replay of recently expired certificates.
5. 5 Tenant state persists across infrastructure events. In-memory nonce stores are cleared on restart. Distributed deployments should use an external nonce store for replay guarantees across instances.

What does it NOT claim?