EVE CoreGuard

Deterministic policy enforcement that runs before a governed action executes.

Who this is for

Teams building AI agents and automated decision systems that must decide, before an action runs, whether it is permitted — and later prove what was decided and why. Typical buyers are platform and risk owners in regulated or high-consequence workflows (lending, insurance, PII handling, banking/AML) who cannot accept a non-deterministic gate on the enforcement path.

The problem

Most guardrails are advisory, model-based, or post-hoc. A model-in-the-loop check can vary run to run, cannot be replayed exactly, and produces no record you can independently verify. When an action has a real side effect — a payout, a data write, a tool call — you need a decision that is computed by code, is the same every time for the same inputs, and leaves evidence.

Supported capabilities

• Deterministic ALLOW / BLOCK / MODIFY. EVE CoreGuard makes a deterministic policy decision (ALLOW / BLOCK / MODIFY) before a governed action executes. Implemented in core/coreguard/evaluator.py (evaluate / evaluate_hardened) with 31 policy packs under core/coreguard/policies/.
• No LLM in the decision path. No LLM is in the CoreGuard decision path; verdicts are computed by deterministic policy code. The evidence records llm_in_decision_path == false. (This applies to the governance verdict only; the governed application may still use LLMs.)
• Signed decision evidence. Every governed decision can produce a signed evidence record bound to the decision (ECDSA P-384 (AWS KMS) in production configuration, HMAC-SHA256 fallback).

Readiness: CoreGuard decision-making is PILOT_READY (pilot-validated core governance architecture). Signed evidence and offline verification are SUPPORTED.

How it works

1. Your application proposes an action (for example, a tool call or a decision output) with request context.
2. CoreGuard evaluates it against the selected policy set using deterministic policy code — no model call on the decision path.
3. CoreGuard returns a disposition (ALLOW / BLOCK / MODIFY) with reason codes and a decision id.
4. A signed evidence record is produced, bound to that decision, which can be verified later without trusting the EVE server.

The pip client SDK reaches CoreGuard via hosted mode (it needs a reachable endpoint). In-process evaluation runs embedded inside the EVE service.

Technical example (Python)

The clients are published on public registries: pip install eve-coreguard (PyPI) and npm install eve-ai-governance (npm). Install the provided eve-coreguard 0.2.7 wheel into your environment, then:

from eve_coreguard import CoreGuardClient

# hosted client: configured endpoint + credentials
client = CoreGuardClient(api_key="eve_sk_...", base_url="https://api.eveaicore.com")

result = client.evaluate(
    request_id="req-001",
    tenant_id="org_abc",
    proposed_action={"type": "loan_approval", "amount": 50000},
    model_output={"decision": "approve", "confidence": 0.9},
    context={
        "principal_id": "u_123",
        "session_id": "sess_001",
    },
    policy_set="lending_v1",
    include_evidence=True,
)

print(result.decision.status)    # "ALLOWED" | "BLOCKED" | "MODIFIED"
print(result.risk.level)         # LOW | MEDIUM | HIGH
print(result.signed_governance)  # signed evidence bound to the decision

If the service is unreachable, the SDK fails closed — it raises rather than silently allowing.

Signed evidence example

Each decision can emit a signed evidence envelope. Conceptually:

{
  "content_hash": "…",
  "canon": "jcs-1",
  "signature": "kms-ecdsa-p384-…",
  "decision": { "action": "BLOCK", "reason_codes": ["…"], "decision_id": "…" },
  "llm_in_decision_path": false
}

The signature is over a versioned canonicalization (jcs-1). In production configuration the signature is ECDSA P-384; an HMAC-SHA256 fallback exists but is symmetric and not independently verifiable.

Verifier example

Verify the evidence independently and offline — in Python, Node, or the browser — using the ECDSA P-384 public key, without trusting the EVE server:

import { verifyDecisionCertificate } from "eve-ai-governance";

const result = await verifyDecisionCertificate(envelope); // offline; public key only, no network
// result.valid === true when authentic and unaltered

Verification checks integrity, signature, and schema. It attests that the evidence is authentic and unaltered — not that the underlying decision was correct.

Deployment options

• Embedded (in-service): in-process deterministic evaluation inside the EVE service.
• Hosted: the pip/npm client governs via a reachable endpoint.
• Sidecar: a co-located governance process.

In every mode, a service error fails closed — no SDK silently falls back to permissive behavior.

Readiness

CoreGuard's deterministic evaluation and zero-LLM verdict are PILOT_READY — the core governance architecture is pilot-validated. Signed decision evidence and offline verification are SUPPORTED. The Python client is a release-candidate core client (eve-coreguard 0.2.7); the TypeScript client is a release-candidate core client (eve-ai-governance 0.3.1). The EVE SDK core overall is a RELEASE CANDIDATE WITH EXCLUSIONS.

Limitations

• The pip client governs via hosted mode and needs a reachable endpoint; embedded in-process evaluation is the EVE service, not the client wheel.
• The zero-LLM property applies to the governance verdict only — the governed application may still use LLMs.
• Independent (asymmetric) verification requires the ECDSA P-384 public key. The HMAC fallback is symmetric and not independently verifiable.
• The clients are published on public registries: pip install eve-coreguard (PyPI) and npm install eve-ai-governance (npm).

Next step

Request a pilot to evaluate CoreGuard against your policy set and deployment mode. You keep the signed evidence and can verify it independently.