EVE — Proof-Bearing Governance and Enforcement for AI Agents

Decide before the action runs. Prove it after.

EVE is a governance and enforcement platform for AI agents and tool-using applications. It makes a deterministic policy decision — ALLOW, BLOCK, or MODIFY — before a governed action executes, and it produces a signed evidence record bound to that decision so anyone can verify what happened without trusting the EVE server.

  • What it governs: tool calls, MCP requests, action sequences, resource budgets, and ingested files (artifacts) that reach an agent or backend.
  • When enforcement occurs: at the pre-execution boundary. CoreGuard returns its verdict before the side effect — a blocked call never reaches the underlying tool.
  • What evidence is produced: a signed decision record (Ed25519 in the production configuration, HMAC-SHA256 fallback) containing the decision, reason codes, a decision identifier, and content hashes, canonicalized over the versioned jcs-1 profile.

Approved positioning: EVE is a proof-bearing governance and enforcement platform for organizations that require deterministic decisions and independently verifiable evidence.

Book a governed pilot »

The problem: agents act, and you can't prove what was allowed

Agent frameworks are good at deciding what to do with a model. They are not built to give you a deterministic, reviewable record of what was permitted and why before a real side effect happened. When an agent calls a tool, hits an MCP server, or ingests a file, you typically get logs written after the fact by the same system you're trying to audit.

EVE inverts that:

  1. The verdict is computed by deterministic policy code — no LLM is in the CoreGuard decision path. The same inputs produce the same decision. (The governed application may still use LLMs; this applies to the governance verdict only.)
  2. The decision is made before execution, so a BLOCK prevents the side effect rather than annotating it.
  3. The evidence is signed and independently verifiable — you can check integrity, signature, and schema offline, in Python, Node, or the browser, without trusting EVE.

Verification proves the evidence is authentic and unaltered. It does not attest that the underlying decision was correct — only that the record is genuine.

See enforcement happen live

The live-enforcement demo shows a single governed tool call flowing through CoreGuard: an allowed call executes, a high-risk call is blocked before the tool runs (zero unauthorized side effects), and a signed evidence record is emitted and then verified offline. Ask your EVE contact for the current demo pointer as part of a governed pilot — it runs against synthetic fixtures and recording tools, not production credentials.

Eight product pillars

  1. CoreGuard — deterministic pre-execution decisions. ALLOW / BLOCK / MODIFY computed by policy code (27 policy packs), with no model call in the decision path.
  2. EVE Proof — signed decision evidence. Every governed decision can produce a signed record bound to the decision (Ed25519 prod / HMAC fallback).
  3. Offline verification. Verify evidence independently and offline in Python, Node, or the browser — you do not have to trust the EVE server.
  4. MCP governance. Cryptographically bind the approved MCP request to the executed request; server-derive execution identity; atomically consume single-use authorizations.
  5. Agent behavior monitoring. Signed monitoring envelopes plus deterministic statistical anomaly detectors (rolling/robust z-score, EWMA, CUSUM).
  6. Sequence & budget controls. Block individually-permitted actions that combine into a prohibited sequence; enforce deterministic budget/resource limits.
  7. EVE Shadow. Authenticated, non-authoritative evaluation of candidate policies — live or by historical replay — with signed divergence reports.
  8. Artifact governance & Red Team. Deterministic file-content scanning with signed scan evidence, plus a customer-runnable adversarial regression suite.

How it works

 agent / app                EVE governance                    result
 ┌─────────┐   tool call    ┌───────────────────────┐   ALLOW  ┌──────────┐
 │  agent  │ ─────────────▶ │ CoreGuard (policy code)│ ───────▶ │ tool runs│
 └─────────┘                │  ALLOW / BLOCK / MODIFY│   BLOCK  └──────────┘
                            └──────────┬────────────┘   ───────▶ tool NOT run
                                       │ signed evidence
                                       ▼
                             ┌───────────────────┐  offline, no trust in EVE
                             │  verify_evidence   │  Python · Node · browser
                             └───────────────────┘
  1. Your agent or backend routes a tool call through EVE (via the SDK, a sidecar, or the MCP gateway).
  2. CoreGuard evaluates deterministic policy and returns ALLOW / BLOCK / MODIFY before the side effect. On BLOCK, the underlying tool is never called.
  3. EVE emits a signed evidence record bound to the decision.
  4. You (or a reviewer) verify that evidence offline at any later time.

If the EVE service is unreachable, every supported mode fails closed — no SDK silently falls back to permissive behavior.

Signed evidence and verification

  • Signed decision evidence. Each governed decision can produce a signed envelope: envelope{content_hash, signature: "ed25519-...", canon: "jcs-1"}. Ed25519 is used in the production configuration; an HMAC-SHA256 fallback exists but is symmetric and is not independently verifiable.
  • Independent, offline verification. verifyEvidence(env, {publicKeyPem}) (TypeScript / browser) and verify_evidence(...) (Python) return a structured result such as {valid: true, signature: "ed25519-valid"}. Independent (asymmetric) verification requires the Ed25519 public key.
  • Canonicalization. EVE signs over jcs-1, a constrained RFC 8785 profile with proven byte-for-byte parity across Python, TypeScript, and the browser for the supported value domain. jcs-1 fails closed on non-integer floats / NaN / Infinity (rates are carried as integer permille). It is not full RFC 8785 float compliance.

Verification confirms authenticity and integrity of the evidence — not the correctness of the decision it records.

Agent and MCP governance

For MCP tool calls, EVE closes the gap between what was approved and what actually ran:

  • Approved-versus-executed binding. EVE cryptographically binds the approved MCP request to the executed request. Any mutation between approval and execution is rejected before the side effect. This provides at-most-once authorization consumption — it does not provide remote exactly-once execution; unknown remote outcomes are recorded as OUTCOME_UNKNOWN and never silently retried.
  • Server-derived identity. MCP execution identity (tenant, principal, session) is derived server-side from authenticated context. Payload or header identity assertions must match, or the request is rejected (e.g. a forged X-Tenant header yields MCP_UNTRUSTED_PROXY_IDENTITY). This requires the authenticated middleware to be mounted.
  • Atomic distributed consumption. Single-use authorizations are atomically consumed across processes via a PostgreSQL-authoritative backend, so one authorization cannot be consumed twice. This was validated across separate OS processes on one host in the documented test topology (50 processes → exactly 1 winner, 1 recorded side effect).

Framework adapters route tool calls through the same governance composition root. The generic adapter is validated. Adapters for OpenAI Agents, Claude Agent SDK, LangChain, LangGraph, CrewAI, and Vercel AI SDK are structurally implemented but experimental — not yet validated against pinned live framework versions. Wrapper-enforced adapters are bypassable by a direct call to the underlying tool; Claude Code hooks are cooperative and are not an unbypassable boundary. Hard enforcement requires a gateway or sidecar.

Regulated and high-assurance use cases

EVE supports evidence collection, helps enforce policy at the pre-execution boundary, and produces records useful for review in settings where decisions must be reconstructable:

  • Lending / financial decisioning. Deterministic decisions with signed evidence for each governed action; CoreGuard ships policy packs including a lending pack.
  • Agent operations in regulated environments. Block prohibited action sequences, enforce budget limits, and monitor for behavioral anomalies with signed envelopes.
  • File and content ingestion. Detect the real media type from content, apply bounded safe-parsing limits, run deterministic scanners, and block / quarantine / require approval before ingestion — with signed scan evidence and artifact-digest binding so a substituted artifact after approval is detected at verification.
  • Adversarial regression. Run a packaged red-team suite against your own configuration; blocked attacks provably cause zero unauthorized side effects, and results are signed.

EVE can map controls to common frameworks and produces records useful for review. Standards mappings are descriptive; they are not a certification, and EVE does not make a system automatically compliant with any regulation.

Technical integration

Python (pilot / private distribution):

from eve_coreguard import EVE   # eve-coreguard 0.2.2 (release-candidate core client)

eve = EVE()  # hosted mode: reaches CoreGuard via a configured endpoint

result = eve.govern_tool_call(
    tool="transfer_funds",
    arguments={"amount": 50000, "to": "acct_123"},
    context={
        "tenant_id": "org_acme",
        "principal_id": "user_42",
        "session_id": "sess_abc",
    },
)
# result.action is ALLOW / BLOCK / MODIFY, with reason codes, a decision id, and evidence.

TypeScript / Node (pilot / private distribution):

import { EVE } from "@eve/coreguard"; // @eve/coreguard 0.1.0-rc1 (ESM, Node >= 18)

const eve = new EVE(); // hosted mode

const result = await eve.governToolCall({
  tool: "transfer_funds",
  arguments: { amount: 50000, to: "acct_123" },
  context: { tenantId: "org_acme", principalId: "user_42", sessionId: "sess_abc" },
});

Verify evidence offline (no trust in the EVE server):

import { verifyEvidence } from "@eve/coreguard";

const check = verifyEvidence(envelope, { publicKeyPem });
// -> { valid: true, signature: "ed25519-valid" }

The pip client governs via hosted mode and requires a reachable endpoint; embedded, in-process governance is provided by the EVE service, not the client wheel. The TypeScript SDK never signs and holds no secrets; embedded mode is Python/service-only in TS. The release-candidate clients are distributed privately for pilots — install the pilot artifact, not a public pip/npm install (see readiness for public-registry status).

Security and deployment

  • Deployment modes: embedded (in-service), hosted, sidecar, MCP-gateway, and sovereign/offline.
  • Fail-closed everywhere: in every mode, a service error yields BLOCK or a raised error — never a silent ALLOW.
  • Production config guard: production configuration refuses to disable signed evidence, strict verification, distributed consumption, fail-closed behavior, authenticated identity, or complete scanning.
  • Clean artifacts: built SDK packages contain no keys, credentials, .env, test directories, or repository metadata; the browser/TS SDK contains no server-only signing code.

Readiness

  • EVE SDK core: RELEASE CANDIDATE WITH EXCLUSIONS.
  • Python SDK (eve-coreguard 0.2.2) and TypeScript SDK (@eve/coreguard 0.1.0-rc1): release-candidate core clients.
  • Core governance architecture: pilot-validated. CoreGuard deterministic evaluation, MCP governance, monitoring, sequence/budget controls, Shadow, and artifact/red-team are PILOT_READY at their supported boundaries.
  • EVE Proof — signed decision evidence, offline verification (Python / Node / browser), and jcs-1 canonicalization — is SUPPORTED.
  • MCP distributed consumption: distributed-pilot validated in the documented test topology (single host, separate OS processes on a real PostgreSQL).
  • Framework adapters: only the generic adapter is validated; OpenAI Agents, Claude Agent SDK, LangChain, LangGraph, CrewAI, and Vercel adapters are experimental.
  • The release-candidate clients are distributed privately for pilots — install the pilot artifact, not a public pip/npm install (see readiness for public-registry status).

Limitations

  • The pip client SDK governs via hosted mode and needs a reachable endpoint; embedded in-process evaluation runs inside the EVE service, not the client wheel.
  • The zero-LLM property applies to the CoreGuard verdict only; the governed application may still use LLMs.
  • Independent (asymmetric) verification requires the Ed25519 public key. The HMAC-SHA256 fallback is symmetric and is not independently verifiable.
  • Offline verification proves the evidence is authentic and unaltered — not that the underlying decision was correct.
  • MCP execution binding provides at-most-once authorization consumption and approved-equals-executed binding; it does not provide remote exactly-once execution (unknown remote outcomes are recorded as OUTCOME_UNKNOWN).
  • Distributed consumption is validated across separate OS processes on a single host; multi-host operation across networked machines is argued from PostgreSQL's transactional guarantees but not yet demonstrated across hosts.
  • Monitoring and statistical anomaly detection are observational/advisory unless wired to a deterministic enforcement action.
  • Sequence and budget state are per-session and in-process in the pilot; durable cross-instance state requires a shared store.
  • Shadow evaluation is non-authoritative and cannot alter the active verdict; promotion is dry-run only. Divergence estimates are modeled effects, not observed production outcomes.
  • jcs-1 is a constrained RFC 8785 profile: it does not serialize non-integer floats, NaN, or Infinity (fail-closed). It is not full RFC 8785 float compliance.
  • Artifact scanners are pattern/structure-based; OCR, vision, and QR/barcode reading are probabilistic and disabled by default. Incomplete extraction is reported as partial and cannot masquerade as complete.
  • The red-team suite is representative, not exhaustive; standards mappings are descriptive and are not certification.
  • Only the generic framework adapter is validated. Other adapters are experimental and, for wrapper-enforced adapters, bypassable by a direct underlying-tool call; Claude Code hooks are cooperative and not an unbypassable boundary. Hard enforcement requires a gateway/sidecar.

Book a governed pilot

EVE is offered as a governed pilot at its supported boundaries. In a pilot you route real (or synthetic) tool calls through CoreGuard, receive signed decision evidence you can verify offline, and run the packaged red-team suite against your own configuration.

Book a governed pilot »

Part of the EVE AI Core control plane Deterministic AI Governance Control Plane → Policy decisions that return the same result for the same input every time, before execution.