EVE AI Core
The Infrastructure of No.
How EVE AI Core protects your AI infrastructure. Deterministic governance enforcement, cryptographic audit trails, and zero-trust architecture designed for the most demanding enterprise environments.
What is deployed today versus in progress or on the roadmap. EVE is pre-general-availability; controls marked Production or Implemented are deployed and internally tested but have not yet been independently validated by a third party.
| Control | Status | Deployment | Evidence | Independent validation |
|---|---|---|---|---|
| Deterministic pre-execution decisions (CoreGuard) | Production | Hosted API | POST /v1/decisions/evaluate | Not yet |
| ECDSA P-384-signed decision evidence + offline public-key verification | Production | Hosted | /verify · /.well-known/eve-pubkey | Not yet |
JWT authentication (RS256; none algorithm rejected) | Production | Hosted | Asymmetric signing + per-IP/account rate limiting | Not yet |
| Per-tenant isolation (authenticated org scoping) | Production | Hosted | Auth-derived tenant; DB row-level isolation opt-in | Not yet |
| Deterministic prompt-injection / exfiltration screens | Production | Hosted | Inline screens at the prompt-firewall stage | Not yet |
| Encryption at rest (AES-256-GCM, per-tenant keys) | Implemented | Hosted | Hierarchical key derivation; 90-day rotation | Not yet |
| Encryption in transit (TLS 1.3; internal mTLS on roadmap) | Implemented | Hosted | Forward secrecy; restricted cipher suites | Not yet |
| Hash-chained signed audit trail + signed GDPR deletion receipts | Implemented | Hosted | Chain verification; signed deletion receipts | Not yet |
| Opt-in red-team assurance harness (deterministic verdicts, signed reports) | Preview · off by default | Hosted (feature-flagged) | core/assurance (EVE_ASSURANCE_LAB) | Internal only |
| SOC 2 Type II | In progress | — | Continuous-evidence tooling; report not yet issued | Independent audit engaged — Decrypt CPA (AICPA firm) via the Scytale platform |
| ISO 27001 | Planned | — | — | — |
| Independent penetration test | Planned | — | Scope defined; not yet run | Third-party (planned) |
| Hardware root of trust / FPGA veto core | Roadmap | — | veto_interface.h C contract; pure veto_core | — |
Pre-GA disclosure. No control above has yet been independently validated by a third party. SOC 2 Type II (independent auditor Decrypt CPA, via the Scytale platform) and an independent black-box penetration test are in progress; this matrix will cite the report and completion date when each is available. Deployment scope refers to EVE's hosted service; self-hosted and VPC deployments vary by contract.
All stored data is encrypted with AES-256-GCM using per-tenant keys derived from a hierarchical key derivation scheme. Database volumes, backup snapshots, and privacy vault entries use independent encryption contexts. Key-rotation policy targets a 90-day rotation cycle.
All network communication enforces TLS 1.3 with forward secrecy. Internal service-to-service authentication is enforced at the application layer; mutual TLS between internal services is on the hardening roadmap. Cipher suites are restricted to TLS_AES_256_GCM_SHA384 and TLS_CHACHA20_POLY1305_SHA256.
A PII-redaction stage operates inline at the prompt-firewall stage, removing detected personally identifiable information before data reaches the LLM or logging infrastructure.
The PII redaction map that tracks entity-to-token substitutions exists only in process memory for the duration of a single request. It is never persisted to disk, cached, or transmitted to external services. On request completion, the map is zeroed and deallocated.
JWT-based authentication with configurable expiration, refresh token rotation, and automatic session invalidation. Tokens are signed with an asymmetric key (RS256 in production) and validated on every request; the none algorithm is rejected. Failed authentication attempts are rate-limited per IP and per account.
Five hierarchical roles with granular permissions: Viewer, Operator, Approver, Admin, and Platform Admin. Nine permission scopes enforce tenant isolation. All permission checks are evaluated server-side before action dispatch.
API keys are scoped to specific capabilities (sovereign, read, write, admin). Keys are stored as irreversible SHA-256 hashes; the plaintext secret is returned exactly once at creation and never stored. Keys can be deactivated immediately.
Active session tracking across devices with remote revocation capability. Device fingerprinting, IP tracking, and last-activity timestamps. Users can revoke all sessions or individual devices. Sessions auto-expire based on configurable inactivity timeouts.
The safety-critical veto core is a pure deterministic function with zero I/O, zero threading, and zero global state -- computable by embedded firmware and suitable for compilation to Microchip PolarFire SoC FPGA. Today charter rules, cognitive locks, and drift budgets are enforced by this deterministic software core; FPGA/silicon enforcement is on the roadmap.
Service isolation between the Pre-Execution Authority Resolution Layer (authority pack evaluation), Governed Inference Layer (LLM inference and action dispatch), and Cryptographic Authority Chain Layer (authority record storage) — separate processes with independent state stores, authenticated interfaces, and one-way enforcement authority: the Authority Resolution Layer can halt the Inference Layer, but never the reverse. Physical/hardware isolation is a roadmap item (see the FPGA veto core).
Each organization receives fully isolated governance instances: separate Charter, Claims Ledger, Trust Dial, Action Registry, and Reality Anchor. Tenant state is isolated per organization and enforced by server-side authorization on every request. LRU eviction with disk persistence ensures horizontal scalability.
Internal services authenticate before trust is granted; no service trusts another by default. The veto core runs as a pure, deterministic function (suitable for formal verification). 15 immutable charter rules and 5 ethical red lines are frozen constants that cannot be modified at runtime.
veto_interface.h) and validated by 87 determinism, equivalence, and purity tests.
All governance decisions, charter checks, veto events, and operator actions are recorded in append-only JSONL files with SHA-256 hash chaining. Each entry contains the hash of the previous entry, so any retroactive alteration breaks the chain and is immediately detectable when records are re-verified against the signed certificates and externally retained checkpoints.
Production governed-decision certificates are ECDSA P-384-signed and verifiable offline with EVE's public key — no access to EVE's internal state required. Self-hosted SDK deployments and resilience certificates may use HMAC-SHA256, which requires the shared secret to verify. Each certificate includes a content hash, signature, and timestamp for auditor verification.
The ECDSA P-384 private key that signs production governed-decision certificates is held by the signer and is never distributed — only its public half is published (at /.well-known/eve-pubkey), so an auditor verifies a record with the public key alone, needing no shared secret and no trust in EVE's systems. Governance audit-chain attestations are additionally signed with an asymmetric key managed by AWS KMS, whose private key never leaves the KMS boundary.
Audit trails are retained for a minimum of 7 years to satisfy financial services, healthcare, and regulatory compliance requirements. The tamper-evident, hash-chained ledger layer uses PostgreSQL with write-ahead logging for crash recovery.
Historical replay re-evaluates a decision against the exact policy version that governed it at the time (bound in its certificate); comparative replay re-runs the original inputs against a newer policy version to surface changed outcomes. Cross-system audit trails support correlation ID tracing across service boundaries. Export capabilities include CSV and JSON for external compliance tooling.
The EVE AI Core service runs behind the same pre-execution governance pipeline we sell: every action is evaluated against a versioned policy before it can take effect, and each decision produces a signed, hash-chained record. This is a control that protects the service — not just a product feature.
The governance pipeline is adversarially tested on an ongoing basis, and findings are converted into regression tests so that closed attack classes stay closed. Coverage is summarized in each resilience certificate.
The enforcement capabilities themselves — policy packs, deterministic verdicts, CRD scoring, decision certificates, and adversarial benchmarks — are documented on the product pages: EVE CoreGuard, EVE Governance, and the benchmark report.
EVE's governance architecture maps directly to EU AI Act requirements for high-risk AI systems: risk management (Article 9), data governance (Article 10), transparency and information provision (Article 13), human oversight (Article 14), and accuracy, robustness, and cybersecurity (Article 15).
Aligned with the NIST AI Risk Management Framework across all four functions: Govern (charter-based policy), Map (risk classification and CRD scoring), Measure (resilience scoring and calibration), and Manage (human-in-the-loop escalation and remediation).
Architecture and operational procedures map to ISO/IEC 42001 AI Management System requirements. The governance pipeline, audit trail, and bounded change-control provide auditable evidence for certification readiness.
Generate on-demand compliance reports that map EVE's governance controls to specific regulatory articles and framework requirements. Reports include evidence chains, attestation references, and coverage analysis for audit preparation.
21 webhook event types deliver governance notifications to your existing incident management stack. Native integrations with Slack, Microsoft Teams, and PagerDuty. Events include charter vetoes, trust violations, drift alerts, explosion indicators, and emergency shutdowns.
Per-provider and per-service circuit breakers automatically isolate failing components. States progress through closed (healthy), open (blocked), and half_open (testing recovery). Exponential backoff prevents cascade failures. The system fails safe -- degraded mode preserves governance integrity.
10 escalation triggers monitor for conditions requiring human judgment: emotional volatility, high uncertainty, ethical ambiguity, identity threats, and conflicting directives. Escalations include urgency levels, recommended pause actions, and context packages for rapid human decision-making.
Multi-layer operator emergency stop. Bounded change-control continuously monitors governance health indicators and halts automatically if critical thresholds are crossed, with full rollback protection. Manual emergency stop is available to any authorized operator at any time.
Our security team is available to walk through architecture details, compliance mappings, and deployment options for your environment.